Unerwartete Nebenwirkung
Routing-Einträge und Netzwerkobjekte für Paketfilter-Regeln sehen oft gleich aus, eine Netzwerkadresse und die Netzmaske bestimmen, für welche Adressen der Routing-Eintrag oder die Paketfilter-Regel gilt. Leider sind beides aber nur Zahlen, deren Bedeutung sich nicht jedem sofort erschließt. Aus diesem Grund gibt es in nahezu jeder Firewall Aliase, die es ermöglichen, diese Zahlen über einen Namen zu referenzieren. Das hat seine Vorteile, weil es erlaubt, mit weniger Regeln auszukommen, wenn man mehrere Netzwerkobjekte einem Alias zuordnen kann.
Genau hier lauert aber auch eine Gefahr. Denn obwohl sie gleich aussehen, dienen Routing-Einträge und Netzwerkobjekte in Firewall-Regeln unterschiedlichen Zwecken.
Ein Routing-Eintrag dient dazu, den Weg zu den beschriebenen Adressen zu beschreiben. Wird ein Alias verwendet und umfasst dieser mehrere Routing-Einträge, dann sollten alle über den gleichen Next-Hop erreichbar sein.
Eine Paketfilter-Regel hingegen beschreibt Zugangsrechte des Objekts, unabhängig davon, wie es topologisch erreichbar ist. Beschreibt der entsprechende Alias mehrere Netzwerke, so ist es der Zugangsregel egal, auf welchem Wege die Netzwerke erreichbar sind.
Vergisst man diesen Unterschied, kann es zu subtilen Nebenwirkungen und ungewollten Aha-Effekten kommen.
Neulich rief mich ein Kollege an, weil eine pfSense-Firewall Zugriffe von externen Adressen, die in den Firewall-Regeln freigegeben waren, nicht beantwortete. Die IP-Adressen lagen auf der WAN-Seite, die pfSense sendete die Antworten stattdessen auf der LAN-Seite.
Mein Kollege hatte bereits herausgefunden, dass es auf der pfSense einen statischen Routing-Eintrag gab, der einen Firewall-Alias verwendete.
Das war beim Eintragen dieser Route vermutlich noch korrekt,
wenn auch sehr fragwürdig.
Etwas später hatte ich jedoch
zu dem Firewall-Alias die externen Adressen hinzugefügt,
weil der Name des Aliases NET_MANAGEMENT lautete
und dieser in der Regel für den Management-Zugriff verwendet wurde.
Leider hatte ich beim Ergänzen des Aliases nicht geprüft,
ob der externe Zugang wirklich funktionierte.
So musste mein Kollege den Fehler suchen,
obwohl er den Zugang eigentlich nur benutzen wollte.
Daraus lassen sich zwei Regeln ableiten, von denen jede einzelne dieses Problem hätten verhindern können, die aber erst zusammen die Arbeit insgesamt resilienter machen:
Aliases, die für ACL bestimmt sind, sollten nicht für das Routing eingesetzt werden und eindeutig unterscheidbar sein. Diese Regel greift schon am Anfang und kann das Problem daher schon im Vorfeld verhindern. Mit ihr werden unerwünschte Nebenwirkungen reduziert.
Wann immer etwas geändert wird, sollte sofort anschließend getestet werden, ob die Änderung den gewünschten Effekt hat. Diese Regel greift erst am Ende und findet keine Nebenwirkungen, die sich auf etwas anderes auswirken, als das beabsichtigte und somit getestete Verhalten.