Aktuelle Switches der Netgear ProSafe-Serie haben eine Funktion eingebaut, die DoS-Angriffe abwehren soll. Stattdessen kann sie aber ebensogut dazu führen, dass der Switch selbst seinen Dienst verweigert.
Eine Funktion, die auf Netzwerkebene Angriffe erkennt und das angreifende Gerät vom übrigen Netz isoliert? Klingt erst mal gut und ist auf Geräten wie dem Netgear GS724Tv4 standardmäßig aktiv. In der Praxis stellt sich das aber schnell als ziemlich unausgegoren dar.
Bei einem Kunden, den ich betreue, habe ich kürzlich die Netzwerkverkabelung erneuert und bei der Gelegenheit auch drei der genannten Switches in Betrieb genommen. Kurz nach Abschluss der Arbeiten ging allerdings ein WLAN-Accesspoint vom Netz. Es stellte sich heraus, dass der zugehörige Switchport down war, nach kurzem Trennen der Stromzufuhr aber wieder funktionierte. Das wiederholte sich in den folgenden Tagen gelegentlich: mal war es der Switchport, mit dem der Accesspoint verbunden war, mal der Uplink des Switches.
Der hinzugezogene Netgear-Support war erst mal ratlos und wir stocherten eine Weile in den Energiespareinstellungen sowie bei LLDP herum. Das half aber nichts; auch Probleme in der Verkabelung und am Accesspoint konnten wir ausschließen. Stattdessen entdeckte ich eines Morgens folgende Meldung im Switch-Log:
Interface g24 has been shut down by Dos attack notificationDer Support bestätigte daraufhin, dass das der Auslöser sein könne:
Der DoS Attack wurde zur folge von der aktiven Auto DOS Option entdeckt. Das muss nicht bedeuten, dass jemand den Switch angegriffen hat, sondern im lokalen Netzwerk manche Dienste oder Services vorhanden sind, die beispielweise zu grosse ICPM Packete hin und her verschicken und der Switch has sie dank der Auto DOS Option identifiziert und je nach der Konfiguration reagiert.
An diesem Morgen waren alle drei Switches zeitgleich vom Netz gegangen, indem sie ihren Uplink getrennt hatten. Nach kurzem Trennen der Stromzufuhr (man kommt ja nicht mehr aufs Webinterface…) und Abschalten der DoS-Erkennung trat das Problem nicht mehr auf. Ich fragte bei Netgear nach, ob es irgendwelche Möglichkeiten gebe, das Problem einzukreisen – konkret: welcher der vielen Parameter hat auf ein missliebiges Paket reagiert? Und von welchem Client (IP-Adresse? MAC-Adresse?) kam es?
Der Support riet zum Einrichten eines Syslog-Servers. Das tat ich auch – natürlich direkt an den Switch angebunden. Befände sich der Syslog-Server hinter dem Uplink-Port, hätte im entscheidenden Moment wieder nichts protokolliert werden können. Nach ein paar Tagen war es wieder soweit: der Uplink eines Switches war down (bei den anderen hatte ich die Funktion ausgeschaltet gelassen). Ich fuhr schnell hin, startete den Switch neu und schaute sehr gespannt auf den Syslog-Server. Die Enttäuschung war groß, als ich dort trotz ausführlichstem Loglevel (“Debug”) auch nur wieder dieselbe Meldung vorfand, ohne weiterführende Details.
Auch im Handbuch (Seite 46/47) finden sich keine Informationen, wie sich die Funktion konstruktiver nutzen ließe.
Zusammengefasst: ein einziges, ungewöhnliches Paket, das die bisherigen Switches souverän verarbeitet oder ignoriert haben, reicht aus, um diese Modelle außer Betrieb zu nehmen. Es gibt keine Möglichkeit, die Quelle des Pakets zurückzuverfolgen, es gibt keine Information über die genaue Beschaffenheit des bemängelten Pakets, und es gibt auch keine Möglichkeit, vermeintliche Angriffe zunächst nur zu loggen, ohne mit einem Abschalten des Ports darauf zu reagieren. Damit erscheint mir Funktion hochgradig unnütz, ja sogar gefährlich, weil sie DoS-Angriffe sogar massiv vereinfacht, anstatt sie zu verhindern: ein falsches Paket als Broadcast, und schon steht alles still.
Damit bleibt nur eines: den “automatischen DoS” (sic!) schnell abschalten.
