[Frage] FritzBox 7360 - Firewall im Stealth Mode

GUI schrieb:

Von Programmen oft benötigte Anfragen werden weiterhin beantwortet.

Zum Vergrößern anklicken....

Offenbar gehört "ident" nach Ansicht von AVM dazu ... wobei das eigentlich die "normale" Reaktion des Linux-IP-Stacks ist, soweit ich weiß - AVM müßte dazu wohl beim "stealth mode" zusätzlich RST-Pakete auszufiltern, solange keine passende Verbindung existiert und das passiert für "ident" offenbar nicht.

Auch versuchen heutzutage nur noch wenige Anwendungen überhaupt darüber die Existenz eines Hosts (oder gar wirklich seine Identität) zu ermitteln, weil eben fast überall dieser Port/Service geblockt wird - so ganz als "schwarzes Loch" (ohne jeglichen Beleg für die Anwesenheit eines Gerätes unter der getesteten IP-Adresse) verhält sich eine FRITZ!Box in "normaler Konfiguration" ohnehin nicht und ein "fingerprinting" ist i.d.R. schon über andere Services möglich, wenn man die Box nicht wirklich nur als "dummen Router" benutzt und einige Dienste auf der Box selbst terminiert sind. Auch ist dieser Port m.W. der einzige, auf dem das RST-Paket tatsächlich gesendet wird, wenn man in den "stealth mode" schaltet - zumindest unterhalb von 1024.

Ob das nun als "Reminiszenz" an vergangene Zeiten zu werten ist und vielleicht direkt im IP-Stack von AVM immer die Weiterleitung auf den lokalen IP-Stack erfolgt, solange es kein anderes Ziel dafür gibt, weiß ich auch nicht ... aber da kommt eben ein RST-Paket zurück (aber auch kein ICMP-Paket mit zusätzlichen Informationen), wenn man ein SYN-Paket an diesen Port sendet.

Andererseits kann das auch nicht "ganz unten" bereits als Reaktion erfolgen, denn man kann auch diesen Port durchaus auf einen Client im LAN weiterleiten lassen - das kann also nicht schon davor entschieden werden.

Wobei so eine Firewall (wie die von AVM) normalerweise mit einem ICMP-Reply reagieren würde (konkret antwortet sie hier mit "unreachable - admin prohibited filter"), wenn ein SYN für einen nicht weitergeleiteten Port eintrifft (man kann das selbst ausprobieren, was die Box da antwortet, wenn sie nicht im Stealth-Modus ist) ... wenn AVM nur diese Antworten zusätzlich ausfiltert im Stealth-Mode und für 113 aus irgendeinem Grund kein solches ICMP-Paket erzeugt wird (s. die Annahme mit der impliziten Weiterleitung auf den lokalen IP-Stack), dann liegt die eigentliche Ursache wieder in der AVM-Firewall - vielleicht gibt es dort ja tatsächlich die vermutete (ältere) Sonderbehandlung für "ident", so wie es sie für NetBIOS und ein paar andere (u.a. Teredo) wohl auch gibt (wenn auch an anderen Stellen).

Das hat m.E. nicht mit "aus der Affäre ziehen" zu tun ... auch wenn es heute tatsächlich nur noch selten genutzt wird, war dieser "ident"-Service nun mal früher ein beliebtes Mittel (als das Internet noch der Hort des Guten war, der zugehörige RFC ist fast 25 Jahre alt), um die Identität der Gegenstelle zu ermitteln.

Selbst wenn eine Gegenstelle keine Antwort geben möchte, ist das auch nicht weiter kritisch ... unschön wird es halt erst dann, wenn da (wegen der Filterung der Antworten) beim anfragenden Host eine Verzögerung entsteht (i.d.R. ohnehin mit (automatischen) Wiederholungen von SYN-Paketen verbunden), bevor der dann zu der Erkenntnis gelangt, daß der Kommunikationspartner lieber anonym bleiben will (aber immerhin existiert und somit zumindest die angegebene IP-Adresse stimmen könnte, was mit einer - auch einer negativen - Antwort nun einmal deutlich schneller geht).

Ist das dann tatsächlich irgendein Server-Dienst, der auf diesem Weg die Existenz des anfragenden Clients verifizieren will, blockiert das eben auch Ressourcen auf diesem Server, wenn da erst mal 30 Sekunden mit SYN-Paketen nach der Gegenstelle gesucht wird.

Daher ja eigentlich auch die "Konvention", daß man "ident" nicht als "black hole" betreibt und durch das Ablehnen von Verbindungsanfragen deutlich macht, daß man keine weiteren Auskünfte geben will - da kann dann auch keiner der im verlinkten Text angedeuteten Angreifer irgendetwas auf diesem Port ausrichten. Solange da kein "richtiger Service" läuft und es gar nicht erst zum 3-Wege-Handshake kommt, kann auch kein Angriff mit irgendwie komisch aufgebauten TCP-Paketen erfolgen - das erste SYN-Paket hat keinen echten Payload und außerdem würde diese Gefahr dann praktisch für jedes eingehende TCP-SYN-Paket dieselbe sein (wenn wirklich schon der IP-Stack Fehler enthält).

Das Seltsame ist, daß die Fritz nur im Stealth-Modus auf 113 antwortet. Wurde in einem anderen Thread (ergebnislos) besprochen.
http://www.ip-phone-forum.de/showthread.php?t=288893

Würde ich so nicht bestätigen wollen ... eben noch einmal mit einer 7580 (06.54) geprüft: Stealth-Modus ist aus und die Box (LAN1-Router) antwortet auf ein SYN-Paket an TCP/113 auf dem WAN-Interface mit einem RST-Paket.

- - - Aktualisiert - - -

113.06.83 (DSL-Modem aktiv) genauso ... es kommt sowohl bei aktiven als auch bei abgeschaltetem Stealth-Modus dieselbe Antwort mit dem RST-Paket (und ich habe geprüft, daß die testweise mal eingerichtete Weiterleitung auf einen Host im LAN nicht mehr aktiv ist).

- - - Aktualisiert - - -

Wobei sich die Ansicht zum "ping" bei AVM wohl wirklich geändert hat ... aber die Anzeige im GUI bei der 06.83 spricht auch nur noch von " Aktivieren Sie diese Option dann, wenn Sie die Identifikation Ihrer FRITZ!Box gegenüber Portscans erschweren wollen.". Dieses "fingerprinting" wird durch ein ICMP-Reply für einen "echo request" ja nicht wirklich erleichtert, da nur die vom Absender kommenden Daten 1:1 zurückgesendet werden im Payload.

Dafür bleiben aber nun noch andere Optionen offen, z.B. die "Nachfrage" des MyFRITZ!-Service, ob da noch jemand unter der bei ihm registrierten Adresse erreichbar ist oder nicht (auch wenn das nicht allzu genau ist, weil das natürlich auch ein anderer sein könnte) - anders kann man z.B. keine Statusanzeige im MyFRITZ!-Service steuern (oder man müßte dann gleich mit der großen Keule des TLS-Handshakes auf dem externen TLS-Port kommen).

Wobei ich gerade mal beim "neuen" MyFRITZ!-Service nachgesehen habe ... so etwas wie eine "bereit"-Anzeige (oder auch "erreichbar") gibt es ja gar nicht.

Die damaligen Ergebnisse sind bei mir auch mit 6.83 geblieben. Getestet wieder mit GRC. Verwendet wird bei mir das interne DSL-Modem, nicht LAN1.

Keine Ahnung, woran GRC das festmachen mag, welchen Zustand so ein Port am Ende hat ... mit einem simplen "tcpdump" sieht man sehr gut, daß da ein RST-Paket unmittelbar auf das erste SYN-Paket (getestet mit einem "telnet <hostname> 113"-Aufruf) als Antwort gesendet wird - ich habe (so auf Anhieb mit dem rudimentären Dissector vom "tcpdump") auch keinen Unterschied im Paket zwischen aktiviertem und deaktiviertem Stealth-Mode gesehen (bei der 7490 mit 06.83).

Wobei ich dabei nicht auf zusätzliche ICMP-Antworten geschaut hatte ("port 113" als Filter für "tcpdump") ... gut möglich, daß da in einem der beiden Zustände noch ein zusätzliches ICMP-Paket mit einer "Begründung" kommt und GRC daraus dann irgendwelche anderen Anzeigen ableitet.

Ich würde aus dem aktivierten Stealth-Mode auch nicht unmittelbar darauf schließen, daß das "sicherer" ist - das hängt deutlich davon ab, ob bereits die Anfrage abgefangen wird oder nur die Reaktion. Wenn nur die Reaktionen ausgefiltert werden (das ist wie das "Zerstreuen" der reflektierten Radarwellen beim militärischen Teil der "Stealth"-Technlogie), erreichen die Anfragen immer noch ihr Ziel und - sofern es da Weiterleitungen gibt - auch irgendeinen Service.

Das dürfte bei neueren Firmware-Versionen z.B. für diesen ominösen "IGDPROBE"-Dienst gelten (im Zusammenhang mit dem PCP) - der wird (wenn auch mit zusätzlichen Filtern) grundsätzlich als Forwarding im Router-Modus eingerichtet (siehe Support-Daten und dort "showpcpinfo" - an anderen Stellen wird er (teilweise nachvollziehbar) nicht angezeigt) und korrekt eingehende Pakete erreichen mit ziemlicher Sicherheit auch immer ihr Ziel (wenn sie den Filter passieren konnten) - damit landen sie auch auf dem Zielport und im dort lauschenden Dienst. Da sollte man also unterstellen, daß AVM dort besonders gehärteten Code bei der Interpretation solcher Pakete verwendet, damit darüber eben keine Probleme initiiert werden können - die betreffende Stelle mit dem "Empfänger" müßte im "kdsldmod.ko" (Closed Source) liegen.