10
Welcher DoS Schutz auf dem Managed Switch stört das Windows Netzwerk (Netzwerkumgebung)?
Ich war gestern mal so frei und hab sicherheitsfanatisch wie ich bin einfach mal alle DoS Schutzmaßnahmen auf unserem Managed Switch aktviert und musste dann feststellen das die Netzwerkumgebung nicht mehr alle PC's und Server gelistet hat.
Nach überprüfen mit diesem Tool
http://scottiestech.info/2009/02/14/how-to-determine-the-master-browser ...
hab ich dann festgestellt das die meisten PC's nur noch sich selbst als Master Browser drinne hatten.
Was ist da passiert?
Aktiviert waren folgende Defend Types:
Land Attack
Scan SYNFIN
Xmascan
NULL Scan
SYN sPort less 1024
Blat Attack
Ping Flooding
SYN/SYN-ACK Flooding
Nach überprüfen mit diesem Tool
http://scottiestech.info/2009/02/14/how-to-determine-the-master-browser ...
hab ich dann festgestellt das die meisten PC's nur noch sich selbst als Master Browser drinne hatten.
Was ist da passiert?
Aktiviert waren folgende Defend Types:
Land Attack
Scan SYNFIN
Xmascan
NULL Scan
SYN sPort less 1024
Blat Attack
Ping Flooding
SYN/SYN-ACK Flooding
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 206468
Url: https://administrator.de/contentid/206468
Printed on: April 23, 2024 at 19:04 o'clock
10 Comments
Latest comment
Hallo,
ohne weitere Informationen was du auf welchen Switchen aktiviert und konfiguriert hast wird das schwierig...
brammer
ohne weitere Informationen was du auf welchen Switchen aktiviert und konfiguriert hast wird das schwierig...
brammer
Eigentlich ist das Blödsinn, denn kein Switch kann Endgeräte schützen. Die ganzen SYN Attacken beziehen sich auf einen Sessionaufbau zwischen Endgeräten an denen Ein Switch aber niemals beteiligt ist, denn wie jeder Netzwerker weiss forwardet der nur dumm Frames auf Basis seiner Mac Adresse, mehr nicht. Rein Netzwerk technisch gesehen ist so ein aktiver Schutz angeblich für Endgeräte eigentlich vollkommen unsinnig !
Der Schutz gilt vermutlich nur ihm selber bzw. seinem eigenen Management Interface.
Sinnvoll wäre mal eine Info um welchen Switch es sich handelt (Modell) dann könnte man im Handbuch mal genau nachlesen WAS diese Massnahmen und Kommandos angeblich bewirken sollen. Du hast das ja vermutlich nicht gemacht
Der Schutz gilt vermutlich nur ihm selber bzw. seinem eigenen Management Interface.
Sinnvoll wäre mal eine Info um welchen Switch es sich handelt (Modell) dann könnte man im Handbuch mal genau nachlesen WAS diese Massnahmen und Kommandos angeblich bewirken sollen. Du hast das ja vermutlich nicht gemacht
Wir haben bloss ein Managed Switch (TL-SG3216) und da waren die oben genannten Defend Types aktiviert.
Land Attack The attacker sends a specific fake SYN packet to the destination Host.
Since both the source IP address and the destination IP address of the SYN
packet are set to be the IP address of the Host, the Host will be trapped in
an endless circle for building the initial connection. The performance of the
network will be reduced extremely.
Scan SYNFIN The attacker sends the packet with its SYN field and the FIN field set to 1.
The SYN field is used to request initial connection whereas the FIN field is
used to request disconnection. Therefore, the packet of this type is illegal.
The switch can defend this type of illegal packet.
Xmascan The attacker sends the illegal packet with its TCP index, FIN, URG and
PSH field set to 1.
NULL Scan Attack The attacker sends the illegal packet with its TCP index and all the control
fields set to 0. During the TCP connection and data transmission, the
packets with all the control fields set to 0 are considered as the illegal
packets.
SYN packet with its source port
less than 1024
The attacker sends the illegal packet with its TCP SYN field set to 1 and
source port less than 1024.
Blat Attack The attacker sends the illegal packet with its source port and destination
port on Layer 4 the same and its URG field set to 1. Similar to the Land
Attack, the system performance of the attacked Host is reduced since the
Host circularly attempts to build a connection with the attacker.
Ping Flooding The attacker floods the destination system with Ping broadcast storm
packets to forbid the system to respond to the legal communication.
SYN/SYN-ACK Flooding The attacker uses a fake IP address to send TCP request packets to the
Server. Upon receiving the request packets, the Server responds with
SYN-ACK packets. Since the IP address is fake, no response will be
returned. The Server will keep on sending SYN-ACK packets. If the attacker
sends overflowing fake request packets, the network resource will be
occupied maliciously and the requests of the legal clients will be denied.
Land Attack The attacker sends a specific fake SYN packet to the destination Host.
Since both the source IP address and the destination IP address of the SYN
packet are set to be the IP address of the Host, the Host will be trapped in
an endless circle for building the initial connection. The performance of the
network will be reduced extremely.
Scan SYNFIN The attacker sends the packet with its SYN field and the FIN field set to 1.
The SYN field is used to request initial connection whereas the FIN field is
used to request disconnection. Therefore, the packet of this type is illegal.
The switch can defend this type of illegal packet.
Xmascan The attacker sends the illegal packet with its TCP index, FIN, URG and
PSH field set to 1.
NULL Scan Attack The attacker sends the illegal packet with its TCP index and all the control
fields set to 0. During the TCP connection and data transmission, the
packets with all the control fields set to 0 are considered as the illegal
packets.
SYN packet with its source port
less than 1024
The attacker sends the illegal packet with its TCP SYN field set to 1 and
source port less than 1024.
Blat Attack The attacker sends the illegal packet with its source port and destination
port on Layer 4 the same and its URG field set to 1. Similar to the Land
Attack, the system performance of the attacked Host is reduced since the
Host circularly attempts to build a connection with the attacker.
Ping Flooding The attacker floods the destination system with Ping broadcast storm
packets to forbid the system to respond to the legal communication.
SYN/SYN-ACK Flooding The attacker uses a fake IP address to send TCP request packets to the
Server. Upon receiving the request packets, the Server responds with
SYN-ACK packets. Since the IP address is fake, no response will be
returned. The Server will keep on sending SYN-ACK packets. If the attacker
sends overflowing fake request packets, the network resource will be
occupied maliciously and the requests of the legal clients will be denied.
So wie es aussieht scheint es der Schutz gegen die Blat Attack zu sein.
Weiss zwar nicht warum aber wenn ich ihn an habe gibt es kein Master Browser mehr und ich sehe nur noch wenige PC's in der Netzwerkumgebung.
Weiss zwar nicht warum aber wenn ich ihn an habe gibt es kein Master Browser mehr und ich sehe nur noch wenige PC's in der Netzwerkumgebung.
Na ja das ist ein billiger TP-Link China Switch. Da kannst du mal von ausgehen das der keinerlei DoS Schutz implementiert hat, das ist Unsinn auf solch billigen Consumer Produkten. Hier verwechselst du also was.
Zumal bei der BLAT Attacke ja auch ganz klar steht das der auf "Layer 4" passiert !!
Kein Switch der Welt arbeitet auf Layer 4 !! Jeder einfache Netzwerker weiss sowas. Ein Layer 2 Switch arbeitet nur auf Basis der Mac Adressen wie der Name schon sagt und ein L3 Switch nur auf IPs.
Dein TP-Link Billigteil ist nur ein simpler L2 Switch ( http://www.tp-link.com/ch/products/details/?model=TL-SG3216 ) Der hat also gar keine Ahnung was in höheren Layern abgeht und kümmert sich logischerweise auch nicht drum.
Das dort blumig beschrieben wird als DoS Schutz ist nicht anderes als eine simple Broadcast Controll ACL nicht mehr und nicht weniger.
Das alles hat aber rein gar nichts mit deinem Problem zu tun, und wenn ist es ein Fehler im Switch.
Wenn deine Netzwerkumgebung flöten geht filtert der Switch UDP Naming Broadcasts was er aber nicht darf. Auch nicht mit DoS Schutzfunktion.
Da sollte man eher einen Firmware Bug vermuten bei solcherlei Produkten ?
Hast du den Switch denn wenigstens auf die aktuellste Firmware geflasht ??
Ansonsten hilft dir dann nur ein Anruf bei der TP Hotline !
Zumal bei der BLAT Attacke ja auch ganz klar steht das der auf "Layer 4" passiert !!
Kein Switch der Welt arbeitet auf Layer 4 !! Jeder einfache Netzwerker weiss sowas. Ein Layer 2 Switch arbeitet nur auf Basis der Mac Adressen wie der Name schon sagt und ein L3 Switch nur auf IPs.
Dein TP-Link Billigteil ist nur ein simpler L2 Switch ( http://www.tp-link.com/ch/products/details/?model=TL-SG3216 ) Der hat also gar keine Ahnung was in höheren Layern abgeht und kümmert sich logischerweise auch nicht drum.
Das dort blumig beschrieben wird als DoS Schutz ist nicht anderes als eine simple Broadcast Controll ACL nicht mehr und nicht weniger.
Das alles hat aber rein gar nichts mit deinem Problem zu tun, und wenn ist es ein Fehler im Switch.
Wenn deine Netzwerkumgebung flöten geht filtert der Switch UDP Naming Broadcasts was er aber nicht darf. Auch nicht mit DoS Schutzfunktion.
Da sollte man eher einen Firmware Bug vermuten bei solcherlei Produkten ?
Hast du den Switch denn wenigstens auf die aktuellste Firmware geflasht ??
Ansonsten hilft dir dann nur ein Anruf bei der TP Hotline !
Hab direkt nach der ersten Inbetriebnahme auf Firmware Version: 2.1.1 Build 20130128 Rel.37336 upgedated.
Lustigerweise ist diese jetzt nicht mehr unter Downloads zu finden?!
Wie auch immer, mit solch kleinen Bugs kann ich leben. Kann sich halt nicht jeder einen 1000 Euro Cisco Switch leisten...
Der Rest den ich nutze funktioniert ja einwandfrei, darunter:
SSH zur Verwaltung
Traffic Monitor
LACP
Port Mirroring
Loopback Erkennung
Port Security (limitiert max. Anzahl der MAC's pro Port)
ARP Poison Erkennung & Schutz (selbst getestet mit Tools unter Backtrack 5 und Cain & Abel unter Windows)
Die DoS Schutz Geschichte werde ich demnächst mal auf Funktion überprüfen.
Lustigerweise ist diese jetzt nicht mehr unter Downloads zu finden?!
Wie auch immer, mit solch kleinen Bugs kann ich leben. Kann sich halt nicht jeder einen 1000 Euro Cisco Switch leisten...
Der Rest den ich nutze funktioniert ja einwandfrei, darunter:
SSH zur Verwaltung
Traffic Monitor
LACP
Port Mirroring
Loopback Erkennung
Port Security (limitiert max. Anzahl der MAC's pro Port)
ARP Poison Erkennung & Schutz (selbst getestet mit Tools unter Backtrack 5 und Cain & Abel unter Windows)
Die DoS Schutz Geschichte werde ich demnächst mal auf Funktion überprüfen.
Also, hatte das selbe Problem und hab's gelöst. Auch wenn es alt ist, aber vielleicht hilft es jemandem.
Was aqui schreibt ist nur halb-richtig. Schuld ist der Switch mit der "Protect TCP/UDP Blat Attack".
Dabei werden source + destination port verglichen. Stimmen diese, dann werden sie verworfen. Das gibt dann Probleme bei SIP, DNS, Netbios, NTP und vielleicht noch anderen.
Er kann das! Warum? Weil ein unmanaged Switch - klar nur Pakete weiterleitet. Aber ein Web-managed/Smart-managed/L2+-managed oder wie auch immer die heißen, tatsächlich in höhere Schichten der Pakete reinschaut. Zumindest wenn er diese Features hat.
Ich hab das mit einem HP-Switch (HP-1820-24G - J9980A) durch. Ähnliches hab ich über Cisco gelesen. Auch höherwertigere Modelle haben diese (schlechte/gefährliche) Implementierung.
Bei uns war es die Auerswald die keine SIP-Verbindung mehr bekam. Also: Die Protection von internen Switches am besten deaktiviert lassen oder nu die Dinge aktivieren, die man auch versteht.
Ich wünsche allen viel Erfolg, die ähnliche Probleme haben.
Cheers.
Was aqui schreibt ist nur halb-richtig. Schuld ist der Switch mit der "Protect TCP/UDP Blat Attack".
Dabei werden source + destination port verglichen. Stimmen diese, dann werden sie verworfen. Das gibt dann Probleme bei SIP, DNS, Netbios, NTP und vielleicht noch anderen.
Er kann das! Warum? Weil ein unmanaged Switch - klar nur Pakete weiterleitet. Aber ein Web-managed/Smart-managed/L2+-managed oder wie auch immer die heißen, tatsächlich in höhere Schichten der Pakete reinschaut. Zumindest wenn er diese Features hat.
Ich hab das mit einem HP-Switch (HP-1820-24G - J9980A) durch. Ähnliches hab ich über Cisco gelesen. Auch höherwertigere Modelle haben diese (schlechte/gefährliche) Implementierung.
Bei uns war es die Auerswald die keine SIP-Verbindung mehr bekam. Also: Die Protection von internen Switches am besten deaktiviert lassen oder nu die Dinge aktivieren, die man auch versteht.
Ich wünsche allen viel Erfolg, die ähnliche Probleme haben.
Cheers.
Ein L2 Switch kann nur bis zum L2 (also Mac Adressen sehen) ein L3 Switch maximal in den IP Header.
Ein L2 Switch kann also niemals einen UDP oder TCP Port erkennen, da der logischerweise Teil des L3 Headers ist.
In sofern ist die o.a. "Erklärung" recht oberflächlich und fehlerhaft und zeugt eher von gefährlichem Halbwissen.
Websmart Switches können in der Regel niemals solche Funktionen ausführen, denn das würde eine massiv leistungsfähige CPU erfordern die den Traffic auf ALLEN Ports bis in den Layer 3 ansehen müsste.
Bei billigen gemanagten Websmart Switches oder den oben genannten HP Gurken der untersten Billigkategoie gehört sowas ins Reich der Märchen...allein schon aus ökonomische Gründen ist das pure Utopie.
Leistungsfähige Chassis Switche machen sowas immer mit einem exteren IDS/IPS Blade was diese Funktion übernimmt aber niemals die Switch CPU. Solche Blades kosten ein Vielfaches von dem was z.B. so ein Billig HP von oben kostet. Nur um mal die Relationen klar zu machen
Wenn es überhaupt rudimentären Schutz gegen sowas gibt dann machen Switches sowas mit sFlow oder Netflow. Einem statistischen Collector Verfahren was Wirktraffic captured und an einen Server sendet der Flows analysiert. Niemals aber macht ein Switch das direkt weil ihm die Leistung dafür fehlt. Klar, der soll forwarden und nicht analysieren.
Rudimentären Schutz gibt es wenn überhaupt auf das Management IP Interface des Switches selber. Aber auch da nur bei höherwertigen Switches wozu der oben zitierte HP ganz sicher nicht gehört.
Lass doch einfach mal mit nmap eine DoS Attacke auf das Teil los...dann bist du schlauer
Ein L2 Switch kann also niemals einen UDP oder TCP Port erkennen, da der logischerweise Teil des L3 Headers ist.
In sofern ist die o.a. "Erklärung" recht oberflächlich und fehlerhaft und zeugt eher von gefährlichem Halbwissen.
Websmart Switches können in der Regel niemals solche Funktionen ausführen, denn das würde eine massiv leistungsfähige CPU erfordern die den Traffic auf ALLEN Ports bis in den Layer 3 ansehen müsste.
Bei billigen gemanagten Websmart Switches oder den oben genannten HP Gurken der untersten Billigkategoie gehört sowas ins Reich der Märchen...allein schon aus ökonomische Gründen ist das pure Utopie.
Leistungsfähige Chassis Switche machen sowas immer mit einem exteren IDS/IPS Blade was diese Funktion übernimmt aber niemals die Switch CPU. Solche Blades kosten ein Vielfaches von dem was z.B. so ein Billig HP von oben kostet. Nur um mal die Relationen klar zu machen
Wenn es überhaupt rudimentären Schutz gegen sowas gibt dann machen Switches sowas mit sFlow oder Netflow. Einem statistischen Collector Verfahren was Wirktraffic captured und an einen Server sendet der Flows analysiert. Niemals aber macht ein Switch das direkt weil ihm die Leistung dafür fehlt. Klar, der soll forwarden und nicht analysieren.
Rudimentären Schutz gibt es wenn überhaupt auf das Management IP Interface des Switches selber. Aber auch da nur bei höherwertigen Switches wozu der oben zitierte HP ganz sicher nicht gehört.
Lass doch einfach mal mit nmap eine DoS Attacke auf das Teil los...dann bist du schlauer
Hey aqui,
ich sah das genau wie du. Wurde allederings eines Besseren belehrt. Als ich 1 Tag lang nach der Ursache geforscht hatte (und schier wahnsinnig wurde), fand ich diese im Switch. Siehe Szenario oben. Sobald ich dieses eine Feature aktiviere, ist Schluss mit VOIP. Wenn ich es deaktiviere, geht's wieder. Hab mit Wireshark die Pakete geprüft die hinter derm Switch durchkommen.
Wie der Switch nun intern arbeitet ist (mir) erstmal egal, wenn man auf der Suche nach der Lösung für obiges Problem ist. Ich hab auch nur so lange gesucht, weil ich den Fehler machte, den Web-managed HP-Switch auf Grund des OSI-Modells auszuschliessen. (Und debugging mit ner Auerswald - für mich - ein Graus ist.)
Mir geht es gar nicht um eine theoretische Diskussion hier, oder Recht zu haben. Ich möchte nur auf die praktische Lösung hinweisen. Für alle die noch kommen.
VG
ich sah das genau wie du. Wurde allederings eines Besseren belehrt. Als ich 1 Tag lang nach der Ursache geforscht hatte (und schier wahnsinnig wurde), fand ich diese im Switch. Siehe Szenario oben. Sobald ich dieses eine Feature aktiviere, ist Schluss mit VOIP. Wenn ich es deaktiviere, geht's wieder. Hab mit Wireshark die Pakete geprüft die hinter derm Switch durchkommen.
Wie der Switch nun intern arbeitet ist (mir) erstmal egal, wenn man auf der Suche nach der Lösung für obiges Problem ist. Ich hab auch nur so lange gesucht, weil ich den Fehler machte, den Web-managed HP-Switch auf Grund des OSI-Modells auszuschliessen. (Und debugging mit ner Auerswald - für mich - ein Graus ist.)
Mir geht es gar nicht um eine theoretische Diskussion hier, oder Recht zu haben. Ich möchte nur auf die praktische Lösung hinweisen. Für alle die noch kommen.
VG
Hallo,
Interessante Diskussion.
Zeigt aber doch nur das die relevanten RFC's von den Herstellern immer einer gewissen Interpretation unterliegen... was wiederum zu den o.g. Problemen führt.
Gerade wenn dann billig Geräte oder Geräte deren Software vor x Jahren vom einer anderen Firma entwickelt wurden und sich die Nachfolgenden Entwickler nicht mehr mit den Grundlagen auskennen/beschäftigen.
Eine Switch arbeitet auf Layer 2
Eine Router auf Layer 3
Was der Switch von dir macht ist Layer 2, Layer 3 und ein bisschen Layer 4-7....
Dazu dann noch mangelhafte Dokumentation und bei dem ein oder anderen Admin ein Wissensstand der dafür nicht ausreicht.
Wobei ich keinem was unterstelle!
Brammer
Interessante Diskussion.
Zeigt aber doch nur das die relevanten RFC's von den Herstellern immer einer gewissen Interpretation unterliegen... was wiederum zu den o.g. Problemen führt.
Gerade wenn dann billig Geräte oder Geräte deren Software vor x Jahren vom einer anderen Firma entwickelt wurden und sich die Nachfolgenden Entwickler nicht mehr mit den Grundlagen auskennen/beschäftigen.
Eine Switch arbeitet auf Layer 2
Eine Router auf Layer 3
Was der Switch von dir macht ist Layer 2, Layer 3 und ein bisschen Layer 4-7....
Dazu dann noch mangelhafte Dokumentation und bei dem ein oder anderen Admin ein Wissensstand der dafür nicht ausreicht.
Wobei ich keinem was unterstelle!
Brammer
