FBF Firewall

Status
Für weitere Antworten geschlossen.

spongebob

Aktives Mitglied
Mitglied seit
22 Sep 2004
Beiträge
1,287
Punkte für Reaktionen
0
Punkte
0
Hallo Gruppe,

ich bräuchte mal Hilfe. Habe soeben bei http://scan.sygate.com ein paar Portscans auf meine FBF gemacht.

Hier die z.T. nicht klaren Ergebnisse mit der Bitte um Kommentare/Hilfestellungen.

Bislang bin ich davon ausgegangen, dass die Box ziemlich "dicht" ist für Angriffe von draussen. Zumindest habe ich kein einziges PFWD aktiviert. Auf meiner Client-Maschine laufen natürlich ein Haufen Services, aber - ich bin ja hinter einer Firewall (pfeif...)

Quick-Scan
Erwartungsgemäss bescheinigt mir der Test, dass alle wichtigen Ports nicht nur zu, sondern auch "stealthed" sind.

Ideally your status should be "Blocked". This indicates that your ports are not only closed, but they are completely hidden (stealthed) to attackers.
Sehr schön. Lediglich ICMP ist offen... Hmmm. Wieso das? Die FBF antwortet also auf PINGs und ist (wie sich zeigen wird) auch sonst ziemlich ICMP aussagewillig....

Stealth-Scan
Schön, alles dicht und versteckt.

TCP-Scan
Den habe ich bei Port 600 abgebrochen. Bis dahin alles zu.

Trojan-Scan
Nichts Aussergewöhnliches.

Aber jetzt kommts.....

UDP-Scan
Erster Hammer:
We have determined that you do not have any firewall blocking UDP ports!
OK, RTP geht über UDP, aber alles offen??

Was jetzt kommt, verstehe ich nicht mehr so recht:

Unter der Überschrift:
Results from UDP scan of commonly used ports at IP address: xxxxxxx
Werden mir folgende Ports als OPEN angedreht:

SUNRPC 111 (Often used by SUN and Unix machines for Remote Procedure Calls)

LOCATION SERVICE 135 (Microsoft relies upon DCE Locator service (RPC) to remotely manage services like DHCP server, DNS server and WINS server.)

NETBIOS NS 137, NETBIOS DGM 138 und NETBIOS 139 (Windows/Samba file and print sharing bzw. NetBios is used to share files through your Network Neighborhood. If you are connected to the internet with this open, you could be sharing your whole hard drive with the world! This is a very dangerous port to have open.

So. Und nun habe ich mal den DSL Trace mitlaufen lassen während des Scans. Es fällt auf, dass die Box sehr häufig mit ICMP DESTINATION UNREACHABLE antwortet. Sollte sie nicht besser stillhalten?

Aber auf die UDP Pakete auf 137, 138 und 139 wird ÜBERHAUPT NICHT GEANTWORTET.

Jetzt frage ich mich: Was soll das? Wieso markiert der Scanner die Ports als OFFEN, wenn überhaupt keiner zuckt? Oder geht die Antwort über Festnetz? :)

Sehr merkwürdig...Wollen die mir 'ne Firewall verkaufen?

Vielleicht kann ja mal jemand den Test nachvollziehen.

Grüsse
 

Martin_FfM

Mitglied
Mitglied seit
8 Okt 2004
Beiträge
222
Punkte für Reaktionen
0
Punkte
0
Hmmm...

bedenklich... Ich habe das noch nicht bei meiner Fritz!Box gemacht, habe aber zusätzlich Zone Alarm laufen, Gefahren können ja auch von innen kommen, wenn man sich was gefangen hat.

Schau doch mal, was Symantec für Ergebnisse liefert:
http://www.symantec.com/region/de/avcenter/
(dort auf Symantec Security Check).
Ist zwar nicht so hittig, was als Ergebnis gelistet wird, aber eine Alternative.

Im Zweifel mache die Ports von Hand in deinem Windows dicht.

Gruß
Martin
 

spongebob

Aktives Mitglied
Mitglied seit
22 Sep 2004
Beiträge
1,287
Punkte für Reaktionen
0
Punkte
0
Ich bin jetzt ein Stück weiter. Beginne jetzt die inverse Logik des Scanners zu schnallen. Ich habe mir noch mal die DSL Traces angesehen und dabei festgestellt, dass der Scan alle die UDP Ports als OFFEN markiert, für die KEINE EXPLIZITE ICMP DESTINATION UNREACHABLE Antwort erfolgt.

Frage mich jetzt, ob das nicht sogar irgendwie logisch ist: Da schiesst einer gegen die Wand und es klatscht immer. Denkt er: Aha, Wand. Plötzlich klatscht es nicht mehr. Er denkt: Aha, Loch..

Mein Verständnis war bislang andersrum: Nur wer schreit, zeigt sich getroffen :)

Ist das logisch? Na ja, einen Schrecken hat es mir erst mal eingejagt.

Auf jeden Fall werde ich AVM kontaktieren, warum diese Ports nicht generell abgewíesen werden. Die RTP Ports wurden dabei noch gar nicht gescannt...

Grüsse
 

Martin_FfM

Mitglied
Mitglied seit
8 Okt 2004
Beiträge
222
Punkte für Reaktionen
0
Punkte
0
Jep, das ist ein Grund für ein Ticket.

Und ich muss wohl mal einen ausführlichen Portscann über Nacht machen.

Gruß
Martin
 

jochen

Mitglied
Mitglied seit
9 Jul 2004
Beiträge
249
Punkte für Reaktionen
0
Punkte
0
spongebob schrieb:
Ich bin jetzt ein Stück weiter. Beginne jetzt die inverse Logik des Scanners zu schnallen. Ich habe mir noch mal die DSL Traces angesehen und dabei festgestellt, dass der Scan alle die UDP Ports als OFFEN markiert, für die KEINE EXPLIZITE ICMP DESTINATION UNREACHABLE Antwort erfolgt.
Ich dachte der Sinn des Stealth-Modus wäre sich eben "tot" zu stellen und überhaupt nicht zu reagieren. :?
 

semilla

Mitglied
Mitglied seit
6 Jun 2004
Beiträge
352
Punkte für Reaktionen
0
Punkte
0
@spongebob
ich schätze, die udp-pakete werden nicht generell abgewiesen, da die box ja sonst für jedes ein ICMP-unreachable-paket senden müsste. mit eine DoS-attacke würde man somit die box ordentlich beschäftigen können bzw. zum absturz bringen...
 

Elmo

Mitglied
Mitglied seit
8 Sep 2004
Beiträge
313
Punkte für Reaktionen
0
Punkte
16
Yep, das ist meiner Meinung nach kein Bug sodern ein Feature. Wenn man einen Portsacn mit der Seite des Landes Niedersachsens macht, kommt keine Fehlermeldung.
 

spongebob

Aktives Mitglied
Mitglied seit
22 Sep 2004
Beiträge
1,287
Punkte für Reaktionen
0
Punkte
0
semilla schrieb:
@spongebob
ich schätze, die udp-pakete werden nicht generell abgewiesen, da die box ja sonst für jedes ein ICMP-unreachable-paket senden müsste. mit eine DoS-attacke würde man somit die box ordentlich beschäftigen können bzw. zum absturz bringen...
Dem ist leider nicht so und ich empfehle jedem einen DOS Versuch per UDP. Definitiv hat die Box jedes UDP Paket auf "unreachable" Ports mit ICMP Destination unreachable abgewiesen.

Das habe ich schriftlich :)

Grüsse
 

semilla

Mitglied
Mitglied seit
6 Jun 2004
Beiträge
352
Punkte für Reaktionen
0
Punkte
0
spongebob schrieb:
semilla schrieb:
@spongebob
ich schätze, die udp-pakete werden nicht generell abgewiesen, da die box ja sonst für jedes ein ICMP-unreachable-paket senden müsste. mit eine DoS-attacke würde man somit die box ordentlich beschäftigen können bzw. zum absturz bringen...
Dem ist leider nicht so und ich empfehle jedem einen DOS Versuch per UDP. Definitiv hat die Box jedes UDP Paket auf "unreachable" Ports mit ICMP Destination unreachable abgewiesen.

Das habe ich schriftlich :)

Grüsse
schriftlich? in form eines traces oder von avm?

offizielle aussage von avm (sinngemäß):
die box hat eine limiter-funktion - durch diese werden innerhalb eines bestimmten zeitraums nur eine bestimmte anzahl udp-pakete negativ beantwortet (ICMP unreachable). ist die anzahl erreicht, werden die ankommenden udp-pakete einfach verworfen - und zwar um nicht alle beantworten zu müssen und somit DoS-attacken aus dem weg zu gehen. diese würden nämlich sowohl die box auslasten als auch den upload-range des dsl-anschlusses.
bei verworfenen paketen denkt der portscanner halt, der betr. udp-port sei offen - dies ist eine fehlinterpretation, die den eigenheiten von udp geschuldet ist.

bei deinem scan mit einem "vernünftigen" portscanner ist die anzahl von udp-anfragen in dem definierten zeitraum wohl nicht überschritten worden...

gruss,
thomas
 

spongebob

Aktives Mitglied
Mitglied seit
22 Sep 2004
Beiträge
1,287
Punkte für Reaktionen
0
Punkte
0
Diese Antwort habe ich auch erhalten. Der Treshold soll bei 7 Paketen in 7 s liegen. Die Netbios Ports werden schon direkt nach PPPoE gedropt, deswegen zuckt dort kein Netzwerkstack mehr mit ICMP DEST UNR.

Allerdings weiss ich immer noch nicht, was es mit dem SUNRPC (113) auf sich hat, der ja auch nicht geantwortet hat ("Loch"?).

Bzgl. der Interpretation von verworfenen Paketen habe ich mich weiter oben schon geäussert. Da gehe ich mit der AVM Meinung konform.

PS: Schriftlich heisst: Per PPPoE Trace von AVM.

Grüsse
 

spongebob

Aktives Mitglied
Mitglied seit
22 Sep 2004
Beiträge
1,287
Punkte für Reaktionen
0
Punkte
0
So, habe die Box jetzt mal mit Hilfe des Programms LanTraffic (Demo auf http://www.zti-telecom.com/pages/main-lantrafficv2.htm ) so richtig mit UDP Paketen beschossen.

Ergebnis 1:
Beschuss auf z.B. Port 113 wird tatsächlich nur eine kurze Zeit mit ICMP DESTINATION UNREACHABLE beantwortet. Anschliessen schweigt sich die Box aus. AVM Erklärung stimmt also und alles ist gut.

Ergebnis 2:
Beschuss auf Port 111 versackt klaglos, bringt die Box aber ziemlich ins Schwitzen: Der DSL Trace zeigt an verschiedenen Stellen "Buffer overflow"

Telefonieren war in beiden Fällen möglich. Aber das ist wohl normal: Da ich selbst die Quelle des Beschusses war, hat der Traffic Shaper mich abgeregelt bzw. Pakete gedropt. Nur so konnte das Programm LanTraffic der Meinung sein, es würde mit 6 MBit/s senden (!!! bei einem Uplink von 500 k :))

Ich werde morgen mal meine Box von der Firma aus beschiessen. Dort ist allein der Uplink schon dicker, als der Downlink zur Box. Mal sehen, was passiert.

Vorsichtige Entwarnung :)

Grüsse
 

spongebob

Aktives Mitglied
Mitglied seit
22 Sep 2004
Beiträge
1,287
Punkte für Reaktionen
0
Punkte
0
Update: Habe jetzt mal den sygate Test an einem "direkten" Anschluss vollzogen, d.h. FBF weg und direkt und nur durch die XP Verbindungsfirewall geschützt ran. Sygate bescheinigt mir jetzt, dass eine Firewall alles blockt. Ein Blick in den Netzwerktrace zeigt, dass alle anfliegenden UDP Pakete KOMPLETT IGNORIERT werden, d.h. es erfolgt überhaupt keine Antwort.

In diesem Fall ist der Scanner überzeugt, dass mein System vollkommen perfekt geschützt und unangreifbar ist.

Irgendwie kann ich das nachvollziehen ;)

PS: Eine eingeschaltete XP Verbindungsfirewall hinter FBF verändert das ursprüngliche Bild nicht. Es bleibt bei den angemeckerten "offenen" Ports, d.h. es ist tatsächlich die FBF verantwortlich für das schlechte Testergebnis.

Grüsse
 

TWELVE

Aktives Mitglied
Mitglied seit
3 Okt 2004
Beiträge
940
Punkte für Reaktionen
0
Punkte
0
Port 113 TCP als auch UDP ist meinen Unterlagen zufolge der IDENT/AUTH Port, der zwar eigentlich nicht mehr benutzt werden sollte,
aber trotzdem noch von z.b. IRC Servern benutzt wird.Einige Server erwarten eine Response von diesem Port, obgleich sie ihn nicht mehr verwenden.Die Empfehlung für diesen Port ist daher CLOSED, nicht Stealth.Dies hat einfach den Grund, das Requests an solch einen Server hängenbleiben und auf den Timeout des Servers warten müssen, wenn der Port stealthed ist.Ist er closed, antwortet er dem Server seinen Status
und dieser ist dann zufrieden oder weist einen ab ( IRC z.B.).

Es ist also nicht immer gut, alles zu blockieren, speziell die ICMP Paranoia
von manchen Leuten kann zu einigen bösen und unvorhersagbaren Fehlern und Phänomenen führen.ICMP ist ziemlich wichtig für die Kommunikation zwischen Gateway und Gateway und Rechner, u.a. wird
auch so die PMTU Discovery erledigt, welche den Rechner herausfinden läßt, welche die größtmögliche MTU im Pfad zum Server ist, um ein Droppen oder Fragmentieren der Pakete zu vermeiden.Ich habe allerdings
schon viele selbst Netzwerk-Erfahrene getroffen, die noch nichtmal wußten, das es sowas gibt.


Grüße

TWELVE
 

spongebob

Aktives Mitglied
Mitglied seit
22 Sep 2004
Beiträge
1,287
Punkte für Reaktionen
0
Punkte
0
Salopp gefragt: Was interessiert mich das Timeout eines möglicherweise "feindlichen" Servers? ICH will ja nichts von dem :)

Es geht doch um MEINEN Schutz, nicht um den der "bösen" Server.

PMTU ist ein Argument für ICMP, da aber die Aktivität von MIR ausgeht (ich habe keinen Server), sollte meine Gegenstelle ICMP nicht abweisen. Ich brauche das nicht an der FBF in einkommender Richtung.


Grüsse
 

semilla

Mitglied
Mitglied seit
6 Jun 2004
Beiträge
352
Punkte für Reaktionen
0
Punkte
0
salopp geantwortet: ne menge, wenn du was von ihm willst. :wink:
einige server (IRC, FTP) stellen eine rückanfrage an tcp113, um sicherzugehen, dass die absenderadresse der anfrage auch korrekt ist. ist der port stealthed, bricht der server die kommunikation ab...
daher wird tcp113 von der box auch als closed geführt - auch eine negative antwort ist eine antwort.
 

TWELVE

Aktives Mitglied
Mitglied seit
3 Okt 2004
Beiträge
940
Punkte für Reaktionen
0
Punkte
0
PMTU ist ein Argument für ICMP, da aber die Aktivität von MIR ausgeht (ich habe keinen Server), sollte meine Gegenstelle ICMP nicht abweisen. Ich brauche das nicht an der FBF in einkommender Richtung.
Kommunikation läuft immer zwischen 2 Seiten, na gut es gibt Leute, die reden immer nur, das nennt man dann Monolog...:)

Du willst Du doch eine Antwort auf deine ICMPs haben, damit PMTU auch funktioniert.Wenn Du die blockst, dann gibts auch keine Antwort.ICMP ist wichtiger als Du denkst.Traceroute z.B. verwendet ebenfalls ICMP.
Wie schon gesagt, viele Probleme basieren auf dem Blocken von wichtigen Paketen.Wenn Du mit einem Server kommunizierst, und das tust Du sobald Du im Internet unterwegs bist, wirst Du etwas von Dir preisgeben müssen.Das ist mindestens Deine IP Adresse.Ich wüßte jetzt aber nicht, welchen Schaden Dir jemand mit ICMP zufügen kann, außer einer DOS Attacke.Nur wer soll das, jemand mit einem DSL Anschluß...?
Der lahme Upload ist doch gar nicht in der Lage, da etwas auszurichten.
Außerdem muß sich Dein Router trotzdem mit den Paketen beschäftigen, ob der die nun droppt weil er nicht auf Pings antwortet oder ob er sie beantwortet, das spielt doch gar keine Rolle für die Last.Finden tut man Dich immer, und sei es über den Ident Port.Es gibt Millionen DSL Anschlüsse, wie kommst Du darauf, das ausgerechnet Du angegriffen wirst..? Das wichtigste ist doch, das die MS Ports zu sind.Alles andere ist doch egal.Selbst wenn Du einen Port offen hast, wenn dahinter nicht der entsprechende Server läuft, dann ist da nichts zu hacken.


Grüße

TWELVE
 
Status
Für weitere Antworten geschlossen.

3CX PBX - GRATIS
Linux / Win / Cloud

Statistik des Forums

Themen
233,305
Beiträge
2,032,617
Mitglieder
351,860
Neuestes Mitglied
farian