Aus dem Alltag eines Firewall-Administrators

"Wenn ich per Telnet auf den Server gehen will, dann sehe ich 'connection refused'! Schalten sie mir das mal umgehen frei!".

Mit dieser Form des Unwissens sind die Kollegen leider am häufigsten konfrontiert.

PEBCAC!

Problem Exists Between Chair And Console! Denn wenn die Firewall das Paket verworfen hätte, dann wäre die Fehlermeldung connection timed out.

Der Server hat offensichtlich auf den Verbindungswunsch geantwortet (wenn auch ablehnend). Die Anfrage kann logischerweise nicht auf der Firewall geblockt worden sein (sonst hätte der Server nicht geantwortet).

Warum funktioniert diese Verbindung also nicht? Ganz klar: Der Kunde hat vergessen seinen Telnet-Service zu starten. Dann kann er zwar den Server anpingen. Einloggen geht so aber eben nicht. Der Telnet-Client zeigt das empfangene RST-Paket mit connection refused an.

Unter Linux ist es leicht zu prüfen, ob ein Port erreichbar ist. Unter Windows wissen die wenigsten, wie man vorgeht. Eine Möglichkeit mittels PowerShell wäre:

Test-NetConnection -ComputerName <IP-Adresse> -Port <dst-port>

Vor einer Woche habe ich zu diesem Thema passend wieder einen Workshop über Netzwerk-Traffic gehalten. Die Kurzfassung liegt hier:

Basics to Pro - Die Kurzfassung

Wie man aus Netzwerkpaketen auf installierte Software schließen kann, oder eventuelle Probleme identifiziert... oder: Wie funktioniert ein Portscanner und welche Eigenschaften werden dabei ausgenutzt? Das OSI-Model Das OSI-Modell (Open Systems Interconnection) ist eine theoretische Grundlage zur…

Meister-Tech-BlogMichael Meister

Proxy

Ein Kunde möchte eine Webseite im internen Firmennetz aufrufen. Doch diese scheint unerreichbar. Er beschwert sich letztlich bei den Firewall-Kollegen. Diese können keinen Datenverkehr zwischen seinem Browser und dem Webserver finden. Allerdings spricht sein PC mit dem Firmenproxy. Das Problem ist offensichtlich: Es wurde vergessen für den internen Webserver im Browser eine Ausnahme einzutragen.

Routing

Will man erst einmal Ruhe haben, stellt man kurz die Frage: "Haben sie mal das Routing geprüft?". In 80% der Fälle liegt man damit richtig. Vor Allem verschafft es einem Zeit, um sich das Problem genauer anzuschauen und vorbereitet zu sein, wenn der Kunde mit den Ergebnissen zurückruft.

Traceroute

Natürlich prüfen die meisten Kunden mittels Traceroute, ob der Weg bis zum Ziel gefunden werden kann. Dabei vergessen sie jedoch meist, dass traceroute unter Linux UDP verwendet und unter Windows ICMP. Welches Layer-4 Protokoll letztlich verwendet wird, ist für den Weg zum Ziel irrelevant. Solange es auf der Firewall freigeschaltet ist. Wenn man also den Weg zu einem Webserver verfolgen will, wäre die Nutzung des freigeschalteten Ports hilfreich. Zum Beispiel so:

traceroute --tcp --port=80 <dst-ip>

Wenn auf der Firewall ICMP nicht offen ist, wird man einige Hops nicht beantwortet bekommen. Dennoch sollte das Paket seinen Weg bis zum Server schaffen. Ohne Parameter ist traceroute somit reine Glückssache.

Ernsthafte Fehlersuche

Ein Kunde ruft an, und behauptet er könne seinen Server nicht nutzen. Aufgrund der Firewall wäre dieser nicht erreichbar.

Ich habe den Kunden gebeten, mir den genauen Output zu geben. Und das Folgende hat er mir geliefert:

# ping 10.118.90.11

PING 10.118.90.11 (10.118.90.11) 56(84) bytes of data.
Reply from 10.190.11.252: Destination host unreachable 

Damit ist das Problem eigentlich schon gelöst. Denn die Ausgabe von ping enthält normalerweise viele nützliche Informationen. Zunächst einmal Destination host unreachable. Mit dieser Meldung versucht ein Gerät mitzuteilen, dass der gesuchte Host bei ihm nicht angeschlossen ist. Offensichtlich gehört die 10.190.11.252 einem Router. Und zwar dem letzten auf dem Weg zum Ziel. Denn er möchte das Paket dem Host zustellen, den er nicht sehen kann, weil er wahrscheinlich ausgeschaltet ist.

Wenn dieser Router nicht der letzte auf dem Weg wäre, wäre die Fehlermeldung Destination net unreachable. Es ist also ohne einen Blick auf die Firewall zu werfen bereits klar, wo das Problem gelöst werden kann: Auf dem meldenden Router 10.190.11.252.

Fazit

Es ist einfach, in die Logfiles einer Firewall zu schauen. Hier kann man sehen, ob ein Paket erlaubt oder verboten wird. Doch auf diesem Level lassen sich vielleicht 5% der Probleme lösen. Der größte Teil der Störungen liegt bei den Kunden. Das soll nicht heißen, dass die Firewall nie das Problem darstellt. Aber in einem zunehmend komplexen System, in dem Sicherheit wichtig ist, gibt es immer mehr beteiligte Bausteine, die Fehler aufweisen können. Sind beispielsweise Kunden, Router, Weitverkehrsnetze und Firewalls im Verhältnis 1:1:1:1 involviert, so gebietet die Mathematik dass mit 75 prozentiger Wahrscheinlichkeit das Problem außerhalb der Firewall liegt.

Gerade die Firewall ist in der Regel an strategisch günstigen Orten aufgestellt und bietet beste Möglichkeiten den Datenfluss zu analysieren. Dazu braucht es Spezialisten mit viel Erfahrung im Bereich der Netzprotokolle, die sich permanent weiterbilden müssen. Denn QUIC ist auf dem Vormarsch...