.titleBar { margin-bottom: 5px!important; }

portscan killt gesamte verbindung

Dieses Thema im Forum "FRITZ!Box Fon: DSL, Internet und Netzwerk" wurde erstellt von Dreccon, 12 Juli 2005.

Status des Themas:
Es sind keine weiteren Antworten möglich.
  1. Dreccon

    Dreccon Neuer User

    Registriert seit:
    11 Juli 2005
    Beiträge:
    9
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    hallo zusammen,

    habe ein wie ich glaub recht merkwürdiges problem:
    hab ne fritz!box 2030 firmware version 17.03.45 mit 1und1 dsl 3000. rennt auch soweit alles ganz gut, downloads und uploads funktionieren speed is soweit ich weiss ok, allerdings kann ich keine portscans ins internet machen. sobald ich mit irgend nem tool, seis superscan nmap nessus oder gfi languard im internet nen portscan machen bricht die ganze leitung zusammen, wenn ich nebenher in ner cmd ein ping google.de /t laufen lasse hab ich nacher etwa 50-60% verlust und natürlich auch dementsprechend kein representatives ergebnis beim scan. wenn man bei nmap mit mehreren threads gleichzeitig scannt kommts sogar vor, dass die box sich resettet und kurzfristig im lan nicht mehr pingbar ist. der switch der angeschlossen ist zeigt keinerlei paketkollisionen oder ähnliches an, und der avm telefonsupport meinte er hätte sowas noch nicht gehört, e-mail support hat sich noch nicht gemeldet. hab jetzt leider keine idee mehr, was ich machen soll, weil ich darauf angewiesen bin, sicherheitsscans usw von zu hause aus machen zu können, und ich möcht mir au nich ausdenken , was passiert wenn mich jemand von aussen scannt. wenn also jemand von euch ne idee hat wär ich sehr dankbar für jede reaktion. danke schonmal im vorraus.
     
  2. Carli

    Carli Mitglied

    Registriert seit:
    19 Mai 2005
    Beiträge:
    454
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Hi,

    da die meisten Portscanner mehrere (sehr viele) Anfragen zeitgleich aussenden, vermute ich, dass einfach die Routingtabelle in der FBF voll läuft.
    Das passiert eigentlich bei allen Routern, je nach Güte des Routers eher oder später (durch die Größe der Routing-Tabelle - da die teuren Geräte meist mehr Speicher dafür haben). Und dieses seltsame Verhalten wird der etwas radikale Weg der FBF sein, die Tabelle vor einem Überlaufen zu schützen.

    Du kannst mal versuchen, die Parallelität bei den Portscans herab zu setzen, so dass weniger Einträge in der Routingtabelle landen.

    Du kannst auch mal auf dem Rechner von dem der Portscan ausgeht ein netstat absetzen, dann müssten extrem viele Verbindungen zu sehen sein, wenn meine Theorie zutrifft.

    Viele Grüße
    C.
     
  3. Dreccon

    Dreccon Neuer User

    Registriert seit:
    11 Juli 2005
    Beiträge:
    9
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    hmm,
    danke erstnal für deine antwort,
    war im urlaub, daher so späte antwort.
    das problem tritt leider auch shcon auf wenn ich nen einzelnen host scanne. da dürfte also keine routing tabelle überlaufen, weil ja immer nur der gleiche host kontaktiert wird. hab ausserdem herausgefunden, dass die scans einigermassen gut laufen (nur ca. jeder 10. ping kommt nich zurück) wenn auf dem remote rechner keine firewall rennt. wenn eine rennt dann kommts zu den oben beschriebenen verbindungsabbrüchen.
     
  4. Carli

    Carli Mitglied

    Registriert seit:
    19 Mai 2005
    Beiträge:
    454
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Hi,

    natürlich tritt das Phänomen auch bei einem Host auf, wenn Du mehrere Anfragen losschickst. Jede Anfrage auf jeden Host ist ein Eintrag. Wenn Du also 10 Requests an einen und denselben Rechner schickst, sind es trotzdem 10 Einträge in der Tabelle.

    Ich versuche mal zu visualisieren:

    Dein Rechner (R1) scannt die Ports von einem anderen Rechner (R2).
    R1 sendet Request an Port 1 von R2 - Dein Router merkt sich diese Verbindung.
    R1 sendet Request an Port 2 von R2 - Dein Router merkt sich diese Verbindung.
    ...
    ...
    ...
    R1 sendet Request an Port 815 von R2 - Dein Router merkt sich diese Verbindung.
    JETZT kommt vielleicht erst eine Antwort, dass Port 1 offen oder geschlossen ist und der Eintrag wird aus der Routingtabelle gelöscht - vielleicht aber auch noch nicht.
    R1 sendet Request an Port 816 von R2 - Dein Router merkt sich diese Verbindung.
    ...


    Da auf der Gegenseite - je nach Firewallkonfiguration und laufenden Diensten - vielleicht so gut wie nie eine Antwort kommt, verbleiben alle Anfragen in der Routingtabelle für X Sekunden (bei meinem Router sind es max. 5 Minuten). Wenn Du also Y Anfragen (bei meinem Router sind es 2000) losgeschickt hast, die alle nicht korrekt mit "ich bin da" oder "ich bin nicht da" beantwortet wurden, also "stealthed" sind, dann läuft die Tabelle über.

    Selbst wenn die Anfragen beantwortet werden, kann es durch das sehr schnelle Herausschicken der Anfragen sein, dass die Tabelle schneller gefüllt wird, als sie von der Gegenstelle abgearbeitet werden kann.

    Gute Portscanner können genau aus diesem Grund die Geschwindigkeit, mit der die Anfragen losgeschickt werden, herabsetzen.

    Gruß
    C.
     
  5. Dreccon

    Dreccon Neuer User

    Registriert seit:
    11 Juli 2005
    Beiträge:
    9
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    hmm,
    jo könntest wirklich recht haben. das würd erklären warum scans bei firewalls verheerender ausfallen, wenn der scanner auf antwort wartet aber nie eine kommt. wenn dann das ganze zielnetzwerk noch urlahm is wirds in dem fall noch schlimmer.
    das heisst dann im grunde, dass ich die fritzbox kaum nutzen kann, weil zb. der nessusinterne portscanner mit sicherheit kein throtteling vornimmt. softwaremässig wird man dann ja auch nix machen können oder? so ganz gut is die nachricht jetzt nich für mich *g* auch wenns zumindest mal die ursache gefunden ist.
    danke auf jeden fall
     
  6. Carli

    Carli Mitglied

    Registriert seit:
    19 Mai 2005
    Beiträge:
    454
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Nessus sagt mir nichts, aber mit dem hier z.B. kannst du die Geschwindigkeit runtersetzen.
    Was anderes kannst Du vom Rechner aus gar nicht machen (wenn es wirklich die Routingtabelle der FBF ist). In seltenen Fällen kann es auch sein, dass es an Betriebsystemeinstellungen (XP SP2 begrenzt soweit ich weiß die halboffenen Verbindungen) oder an darauf installierter Software (Routingsoftware, die auch lokal als Gateway angesprochen wird) usw.


    Gruß
    C.
     
  7. Dreccon

    Dreccon Neuer User

    Registriert seit:
    11 Juli 2005
    Beiträge:
    9
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    also nessus is n security scanner der unter linux rennt. gibt zwar seit n paar tagen auch nen extrem eingeschränkten windows port, aber der is noch nich wirklich brauchbar.
    hab natürlich mehrere scanner probiert, gab aber keine allzu grossen unterschiede. kann mal einer von euch nen portscan auf irgend nen gefirewalleten rehcner machen und nebenher ping laufen lassen, oder mir von euren erfahrungen erzählen?? hab echt shcon viel gesucht, aber niergends was ähnliches gefunden.

    ich weiss halt jetzt nich wie viele fb user überhaupt portscans machen ;=)

    thx im vorraus
     
  8. ujo

    ujo Neuer User

    Registriert seit:
    5 Mai 2005
    Beiträge:
    1
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Mit 'routing' hat das Problem nichts zu tun, eher ist das ein Problem des NAT.
    Ich denke aber, dass der durch das Scanning generierte ICMP Traffic limitiert wird (Schutzfunktion)
     
  9. kolbem

    kolbem Neuer User

    Registriert seit:
    4 Juli 2005
    Beiträge:
    66
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Nö, so wie es aussieht, kommen die Fritzboxen einfach nicht mit vielen Paketen (Und verbindungen) klar.
    Sobald die Boxen nur geringfügig stärker belastet, als man es von nem Otto-Normalanwender mit DSL2000 erwartet, ist die Box am Limit.
    d.h. Portscanns, eMule, saugen mit DSL6000 usw. bringt die Box ans Limit.

    Hier paar Werte, die ich festgestellt hab.
    Der dsld Prozess auf der Box braucht bei ca. 30 Verbindungen (viele davon im Leerlauf von ICQ usw.) und 600 KB/s Download per FTP z.b. schon 96% - 100% CPU-Last.
    Das selbe bei ca. 120 KB/s Download, aber insgesamt 600 Verbindungen (eMule + FTP-Download)
    Oder auch bei Portscan und FTP-Download (1000 und mehr Verbindugen bei Portscan mit 50-200 Threads)
     
  10. TWELVE

    TWELVE Aktives Mitglied

    Registriert seit:
    3 Okt. 2004
    Beiträge:
    940
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Kenn ich.Die Leitung bricht aber nicht zusammen, sobald der Scanner gestoppt wird, geht es weiter.Könnte mit dem TrafficShaper der Box zusammenhängen, weil TCP ACK Pakete bevorzugt werden ( neben VoiP
    Paketen).Bei einem TCP Scan werden ja keine richtigen Daten übertragen,
    sondern nur das Handshaking gemacht ( SYN und ACK Pakete).

    Testweise würde ich mal den Trafficshaper in der Box ausschalten..!


    Absolut korrekt.Die FBF hat einen sog. Limiter, der die Anzahl der ICMPs
    reduziert, sobald der Upload zu beschäftigt ist.Außerdem ist in der RFC die
    Anzahl der max. ICMPs / sec. festgelegt.Viele Portscanner "wissen" das und scannen deshalb nicht schneller als dieses Limit.Dieses bezieht sich aber
    auf einen Scan der Fritz von außen.




    Stimmt nicht.Im Gegenteil, andere Router kacken schon bei weniger (emule-)Last ab.Die Fritz ist schon sehr stabil.


    Grüße

    TWELVE
     
  11. redflo

    redflo Neuer User

    Registriert seit:
    3 Feb. 2007
    Beiträge:
    4
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Hallo,

    ist das Problem jemals gelöst worden? Hab das Problem auch mit der FB 7141 neueste Firmware und weiss nicht weiter.
     
  12. frank_m24

    frank_m24 IPPF-Urgestein

    Registriert seit:
    20 Aug. 2005
    Beiträge:
    17,571
    Zustimmungen:
    1
    Punkte für Erfolge:
    36
    Ort:
    Niederrhein
    Großer Gott, der Thread ist 4 Jahre alt. Nichts von dem ist heute noch gültig.

    Und zu. :weg:
     
Status des Themas:
Es sind keine weiteren Antworten möglich.