Quality of Service als Denial of Service
Marc Ruef | 06.07.2009

Als wir Ende 2002 die Firma scip AG (http://www.scip.ch) gegründet haben, waren wir zu Dritt. Wie jedes Unternehmen, das im IT-Bereich aktiv ist, mussten auch wir uns um eine entsprechende IT-Infrastruktur bemühen. Als Sicherheitsunternehmen kam es für uns nicht in Frage, den Mailverkehr und die Webseite einer externen Firma anzuvertrauen. Zu hoch war und ist das Risiko, dass eine Drittperson etwelche Schwachstellen ausnutzt und uns damit unmittelbaren wirtschaftlichen Schaden zufügen könnte (Reputationsverlust und Verlust der Integrität der Daten).

Mittlerweile sind wir ein paar Leute mehr und damit sind ebenfalls die Anforderungen an die Infrastruktur gewachsen. So müssen die jeweiligen Server und Netzwerkkomponenten regelmässig administriert und auf den neuesten Stand gebracht werden. Eine Aufgabe, die zu gewissen Teilen ich übernehme. Mindestens einmal in der Woche nehme ich mir die Zeit, um die Funktionsweise zu prüfen, Patches einzuspielen, Anpassungen an den Konfigurationen vorzunehmen und Anomalien in den Log-Dateien auszumachen. In erster Linie behalte ich dabei das mehrstufige Firewall-System (Astaro, Zyxel, D-Link) im Auge.

Einmal im Monat verschicken wir den scip monthly Security Summary (smSS) (http://www.scip.ch/?publikationen.smss). Ein jeweils am 19ten jeden Monats erscheinendes E-Paper, welches die aktuellen Geschehnisse unserer Firma und der Branche dokumentiert. Über 1'000 registrierte Empfänger erhalten das PDF-Dokument, welches rund 1 MB umfasst. Der Versand dieser Nachricht ist nicht selten eine Belastung für unsere Mailserver und die Internet-Anbindung (VDSL). Um einer unschönen Erhöhung der Netzwerklatenz zu entgehen, diese könnte unsere Sicherheitsüberprüfungen negativ beeinflussen, habe ich mich auf dem Zyxel-Gerät um die Umsetzung von Quality of Service (QoS) bemüht.

Das QoS habe ich auf der Ebene der jeweiligen Ports durchgesetzt. So sollte Port 25 (SMTP), welcher für den Versand von Emails genutzt wird, eine verhältnismässig tiefe Priorität zugewiesen bekommen. Andere Dienste, vorzugsweise DNS und HTTP/HTTPS, sollten auch während des intensiven Mailversands ohne spürbare Einschränkungen nutzbar sein. Ohne Probleme konnte ich das Regelwerk der Firewall dahingehend anpassen, um unsere Bedürfnisse adressieren zu können.

Tags darauf sollte Stefan (http://www.fadetoblack.ch/) einen netzwerkbasierten Vulnerability Scan (http://www.scip.ch/?dienstleistungen.securityscan) durchführen. Mehrere im Internet exponierte Hosts eines Kunden sollten auf allfällige Schwachstellen hin untersucht werden. In einer relativ frühen Phase wird dabei mit nmap ein TCP-Portscan zur Ermittlung der Portstatus der Zielsysteme angesetzt. Zu unserem Erstaunen brach nach etwa 10 Sekunden, nachdem der Scan initiiert wurde, unsere Internetverbindung zusammen. Wir waren irritiert, denn schliesslich haben wir mit dem exakt gleichen Setup die letzten anderthalb Jahre ohne Probleme Hunderte von Scans erfolgreich durchgeführt.

So versuchten wir herauszufinden, welche Komponente das Problem verursachen sollte. Es schien, als könne die Zyxel-Firewall plötzlich nicht mehr mit den TCP-Scans von nmap umgehen. Selbst die konservativsten Timing-Optionen von nmap halfen nicht dabei, die Stabilität des Netzwerks aufrecht zu erhalten. Was war bloss los? Die einzige Änderung in unserem Setup seit dem Auftreten des Problems war das Aktivieren von Quality of Service. Also deaktivierte ich die entsprechende Option in den Konfigurationseinstellungen der Firewall wieder. Doch das Problem blieb bestehen.

Sichtlich irritiert setzte ich mich mit unserem Provider in Verbindung, um nachzufragen, ob sie irgendwelche Änderungen in ihrem Backbone vorgenommen hätten oder etwelche Störungen in unserem Segment bekannt seien. Man verneinte dies und so führte ich das Debugging in unserem Netzwerk weiter. Stefan und ich tippten je länger je mehr auf einen Hardware-Fehler in einer unserer Netzwerkkomponenten. Ärgerlich, denn wir sollten Netzwerkscans durchführen und nicht irgendwelche Netzwerkdiagnosen für unsere Internetanbindung durchführen.

Irgendwann fiel mir auf, dass ich zwar in der Zyxel-Konfiguration die Kontrollbox für Quality of Service deaktiviert hatte. Die acht QoS-Regeln, die ich für die einzelnen Ports definiert hatte, liess ich aber bestehen. Ich ging ja davon aus, dass das Deaktivieren von QoS automatisch ein Mitdeaktivieren der zugeordneten Regeln zur Folge haben würde. Zur Sicherheit deaktivierte ich aber ebenfalls die einzelnen QoS-Optionen separat. Und siehe da: Es funktionierte alles wieder!

Was war passiert? Es scheint, als würde das Zyxel-Gerät die QoS-Regeln in jedem Fall durchlaufen jedoch erst am Schluss durch die globale Aktivierung entscheiden, ob QoS auch wirklich durchgesetzt werden will. Die Folge davon ist, dass selbst bei nicht aktiviertem QoS ein Performance-Verlust zu beobachten ist, wenn einzelne QoS-Regeln vorgesehen sind. Salopp gesagt muss man sich dahingehend zur Firmware des Produkts äussern, dass sie schlecht strukturiert und programmiert ist. Schade, aber das scheint halt nach wie vor die Regel zu sein. Ein Hoch auf schlechte Produkte - Vor allem im SOHO/Appliance-Bereich!