Die WatchGuard Firewall prüft jede neu anstehende Verbindung von einem Host auf der einen Seite der Firewall zu einem Host auf der anderen Seite der Firewall. Dabei werden zunächst die Header der IP-Pakete untersucht: Quell-IP-Adresse, Ziel-IP-Adresse, Quell-Port, Ziel-Port, verwendetes Protokoll (TCP, UDP, ICMP etc.). Die Firewall durchforstet nun das Regelwerk sequentiell “von oben nach unten” (wenn man sich in der Standard-Listenansicht des Policy Managers befindet).
Nacheinander wird jede einzelne Regel geprüft, ob sie die o.g. Kriterien erfüllt – so lange bis der erste “Treffer” gefunden wird. Nur diese Regel wird auch ausgeführt. Gibt es “weiter hinten” im Regelwerk eine andere Regel, auf die ebenfalls die o.g. Kriterien zutreffen, wird diese niemals erreicht/ausgeführt. Wird eine passende Regel gefunden, wird die Verbindung authentisiert und (bei TCP) in die TCP Session Table der Firewall eingetragen. Nachfolgende Pakete in der gleichen TCP-Verbindung werden dann automatisch von der Firewall durchgelassen und nicht noch einmal aufs Neue authentisiert (anders bei Application Proxy Regeln, die eine zusätzliche Kontrolle des Inhalts vornehmen).

Ganz am Ende des Regelwerks steht eine unsichtbare Deny Regel. Jeder Datenverkehr, der nicht ausdrücklich durch eine Firewall-Regel zugelassen wird, wird von dieser Default Deny-Regel ABGELEHNT. Je nachdem, ob der Verbindungsaufbau von innen oder von außen erfolgen sollte, erscheint im Traffic Monitor und im Logfile ein Unhandled Internal Packet oder einUnhandled External Packet.

Warum werden die Unhandled Packets angezeigt?

Weil im Policy Manager bei Setup > Default Threat Protection > Deafult Packet Handling > Logging das Häkchen “Send Log message” bei den Kategorien “Unhandled Internal Packet” und “Unhandled External Packet” gesetzt ist. Das Logging könnte zwar durch Entfernen des Häkchens ausgeschaltet werden – das ist aber keine gute Idee (bessere Idee weiter unten :-). Der Traffic Monitor und die Unhandled Packets sind ein extrem wichtiges und hochinteressantes Tool, um Fehlverhalten von Maschinen bzw. Fehlkonfigurationen im lokalen Netzwerk aufzudecken und abzustellen! Die Anzeige der Denied Packets kann der Administrator auch sehr gut nutzen, um den Bedarf für neue Regeln zu erkennen und wie diese auszusehen haben.

Das Default Regelwerk und die globale Outgoing-Regel

Der Quick Setup Wizard erzeugt bei der Ersteinrichtung der WatchGuard Firebox ein kleines Default Regelwerk, das im Prinzip sämtlichen TCP- und UDP-Verkehr sowie Ping in ausgehende Richtung (outgoing) zulässt – und sämtlichen eingehenden Verkehr (incoming) verbietet.
Gewissenhafte Administratoren wollen jedoch genau definieren, welcher ausgehende Datenverkehr zulässig ist und diesen auf Maschinen- und/oder User-Ebene auf das absolute Minimum beschränken. Neue Firewall-Regeln werden ins Regelwerk aufgenommen und so weit wie möglich einschränkt. Ein gutes Firewall-Regelwerk wächst dadurch auf 20-30 Regeln, teilweise aber auch auf 80-100 Regeln an. Das schöne feingliedrige Regelwerk wird aber nur dann wie beabsichtigt funktionieren, wenn die defaultmäßig vorhandeneOutgoing-Regel auf disabled gesetzt oder ganz gelöscht wird. Denn: das Regelwerk wird “von oben nach unten” abgearbeitet, der erste Treffer zählt. Solange “unten” die globale Outgoing-Regel steht, nützen die Einschränkungen weiter “oben” nichts. Der Verkehr würde trotzdem über die Outgoing-Regel rausgehen, also weg damit!

Anzeige von bestimmten Unhandled Packets unterdrücken

Bisweilen ärgert man sich doch über die Anzeige von Unhandled Packets. Eventuell kann man die Ursache dafür einfach nicht abstellen usw. Bei der Lösung hilft nun das bisher Gesagte: das unzulässige Paket erzeugt eben ein Unhandled Packet, weil es eben keine explizite Regel für diesen Verkehr gibt. Das Paket bleibt an der unsichtbaren Deny Regel ganz am Ende des Regelwerks hängen.
Der Trick besteht nun einfach darin, eine explizite Firewall-Regel zu bauen, die den Verkehr genau beschreibt (siehe oben: Quell-IP, Ziel-IP, Quell-Port, Ziel-Port, Protokoll), aber verbietet (“Denied”) – und das Logging ausschaltet. Der lästige Verkehr taucht künftig nicht mehr im Traffic Monitor und im Logfile auf. Im Regelwerk werden Deny-Regeln mit einem roten X angezeigt:

Konfigurationsbeispiel: HostWatch Namensauflösung (Port 137/udp) unterdrücken

Properties > Logging

Eine Denied-Regel verankert sich im Regelwerk automatisch OBERHALB einer Allow-Regel für den gleichen Port bzw. das gleiche Protokoll, wird also zeitlich gesehen früher geprüft. Das kennen wir: ein explizites Verbot ist mächtiger als eine nicht erfolgte Erlaubnis. Ich nutze die Kombinationsmöglichkeit aus Denied- und Allow-Regeln auch ganz gerne so: Ping.Allow von Any nach Any -und- Ping.Denied von Any-External nach Firebox. Damit kann innerhalb des lokalen Netzwerks/VPN fröhlich hin- und hergepingt werden – auf Pings aus dem Internet reagiert unsere Firebox jedoch nicht. Wenn’s stört, kann für die Denied-Regel natürlich auch das Logging ausgeschaltet werden…