Router/Paketfilter

Vorüberlegungen¶

Es geht hier um einen Router auf der Grenze (border) zwischen dem unsicheren Internet und dem als sicher vorausgesetzten internem Netzwerk, d.h. die Sicherheit des internen Bereichs muss bereits durch andere, hier nicht besprochene Maßnahmen gegeben sein. Die hier besprochen Firewall soll

• (1) das Router-Gerät selbst und damit die auf diesem Gerät erfolgende Funktion des Routings vor Angriffen aus dem Internet schützen sowie natürlich auch alle (aus Sicht des Internets) dahinter liegenden Hosts,
  und

• (2) verhindern, dass aus dem internen Netzwerk als Angriff interpretierbare IP-Pakete ins Internet gelangen und damit möglichen Sanktionen unseres Providers vorbeugen.

Die Aufgabenstellung für ingress (= Aufgabe (1)) erfordert die Filterung vor dem Routing in den Regelketten PREROUTING. Die Gebote^[1] für egress (= Aufgabe (2)) könnten technisch zwar durch Regeln in den Ketten FORWARD und OUTPUT implementiert werden, jedoch ist bequemer, dies gemeinsam in den Regelketten POSTROUTING vorzunehmen.

(In diesem Artikel wird mit dem Wort „Gebot“ immer eine Anforderung aus der Aufgabenstellung gemeint und mit „Regel“ eine Realisierung eines solchen Gebotes durch eine iptables-Regel.)

Grundsätzlich sollte man auf NAT zwar aus funktionalen Gründen (z.B. dann fehlende Transparenz Ende-zu-Ende) verzichten, aber dies ist leider für einen Border-Router für das Protokoll IPv4 im Jahre 2022 eine unrealistische Anforderung. Im weiteren Artikel wird daher angenommen, dass NAT leider unvermeidlich eingesetzt werden muss; wer wider Erwarten für seine Zwecke über genügend global verwendbarer IPv4-Adressen verfügt und damit auf NAT verzichten kann, sollte die in diesem Artikel vorgestellten Beispiele nicht verwenden! Auch auf connection tracking sollte man verzichten, da dies für einen Angreifer die Angriffsfläche vergrößert und damit die Firewall unsicherer macht. Leider benötigt NAT bei Linux aber die Funktionalität connection tracking von Netfilter. Die gesamte Firewall wird daher in den Tabellen mangle und nat realisiert.

Damit beschreibt dieser Artikel wegen der anderen Aufgabenstellung einen anderen Ansatz als die üblicherweise bei den Paketfiltern für Personal Firewalls angewendete Filterung von IP-Paketen nach dem Routing in der Tabelle (table) filter von Netfilter^[2]. Die Tabelle filter ist für die hier besprochene Aufgabenstellung für ingress völlig ungeeignet und für egress schlecht geeignet. Umgekehrt sind aber die in diesem Artikel besprochenen Methoden auch bei Personal Firewalls einsetzbar.

Die Aufgabenstellung^[1] erfordert mehrere Untersuchungen, ob des jeweilige Paket Element bestimmter Mengen ("Martian", „interne Adresse“, „vom Typ Broadcast“, „unsere weiße Liste“ usw.) ist. Dies kann entweder durch eine Vielzahl von einzelnen Regel für jedes mögliche Element einzeln oder mittels IP-Adressmengen erfolgen. Nur die letztere Variante wird in diesem Artikel weiter besprochenen; für die technische Umsetzung benötigt werden die Erweiterungen (Module) addrtype, mark, multiport und state von iptables^[2] sowie set aus dem Paket ipset.

Installation¶

Das Paket iptables und etliche Erweiterungen gehören immer zur Standardinstallation eines Ubuntu-Systems.

Zusätzlich muss installiert^[3] werden:

• ipset (main, Verwaltungswerkzeug für Kernel-IP-Sets)

Befehl zum Installieren der Pakete:

sudo apt-get install ipset 

Oder mit apturl installieren, Link: apt://ipset

Die Implementation von Filtern für IPv6 kann nach den gleichen Überlegungen wie hier explizit nur für IPv4 gezeigt erfolgen; man beachte dabei die Besonderheiten von IPv6 hinsichtlich Source Routing und benötigt natürlich kein NAT. Der Leser wird ausdrücklich ermutigt, bei IPv6 auf "connection tracking" zu verzichten, dieses zu deaktivieren und selber eigene zustandslose Filter zu entwerfen.

Ingress-Filter¶

Zuerst müssen die IP-Adressmengen Martians, Localnet, Internet und Auth-ext definiert werden. Die folgenden Shell-Befehle vereinigt man zweckmäßigerweise in einem Skript:

• Martians:
  

  ipset create Martians hash:net
  for x in	10.0.0.0/8 127.0.0.0/8 169.254.0.0/16 172.16.0.0/12	    \
  		192.168.0.0/16 192.0.0.0/24 192.0.2.0/24 198.51.100.0/24    \
  		203.0.113.0/24 224.0.0.0/4 240.0.0.0/4 0.0.0.0/8
  do ipset add Martians $x ; done

• In Localnet stehen alle internen Netzwerke; diese kann man aus den Regeln für das Routing auslesen:
  

  ipset create Localnet hash:net
  ip -4 route show table all scope link type unicast | grep -v ^169.254	|
    while read x _ ; do ipset add Localnet $x || true ; done

• In Internet und Auth-ext stehen die externen IP-Adressen, welche sich aus dem Internet am Border-Router anmelden dürfen und dann neue Verbindungen aufbauen dürfen. Die Mengen müssen existieren, dürfen aber leer sein:
  

  ipset create Internet hash:ip
  ipset create Auth-ext hash:ip timeout 60

Folgende Regeln müssen – einzeln nacheinander – per iptables^[2] in der Tabelle mangle definiert werden:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

-P PREROUTING ACCEPT
-A PREROUTING ! -i extern -j ACCEPT
-A PREROUTING -m state --state INVALID -j DROP
-A PREROUTING -m state --state RELATED,ESTABLISHED -j RETURN
-A PREROUTING -m addrtype --src-type LOCAL --limit-iface-in -j DROP
-A PREROUTING -m set --match-set Localnet src -j DROP
-A PREROUTING -m set --match-set Martians src -j DROP
-A PREROUTING -m addrtype --dst-type BROADCAST -j DROP
-A PREROUTING -m set --match-set Internet src -m addrtype --dst-type LOCAL --limit-iface-in -j RETURN
-A PREROUTING -m set --match-set Internet src -m set --match-set Localnet dst -j RETURN
-A PREROUTING -m set --match-set Auth-ext src -m addrtype --dst-type LOCAL --limit-iface-in -j RETURN
-A PREROUTING -m set --match-set Auth-ext src -m set --match-set Localnet dst -j RETURN
-A PREROUTING -m set --match-set Martians dst -j DROP
-A PREROUTING -p udp -m udp --dport 7 -j SET --add-set Auth-ext src
-A PREROUTING -p udp -m multiport --ports 161,162 -j DROP
-A PREROUTING -p icmp -j DROP
-A PREROUTING

Kontrolle: Der Befehl

iptables -t mangle -S PREROUTING 

muss die vorstehende Ausgabe ergeben.

• Zeile 1 setzt die Policy der Standardkette ACCEPT, also „vorläufig akzeptieren“. Damit entspricht die Aktion RETURN für das Paket ACCEPT, allerdings werden alle Pakete mit RETURN bei der Policy gemeinsam gezählt.

• Zeile 2 erlaubt alle Pakete, die nicht an der Schnittstelle extern (Anschluss für externen Bereich) eintreffen. Dazu gehören Pakete, die der Router an sich selber schickt (Schnittstelle lo) und alles von den internen Schnittstellen. Die hier beispielhaft verwendete Bezeichnung extern muss natürlich an die Schnittstellenbezeichnung des eigenen Systems angepasst werden. Wer mehrere Schnittstellen zur externen Welt verwendet, muss statt dieser einen Regel mit mehreren Regeln sowohl lo als auch jede interne Schnittstelle erlauben.

• Die optionale Zeile 3 vernichtet alle Pakete, denen vom Modul connection tracking (hier in der Variante state) kein gültiger Status zugewiesen werden konnte. Diese Pakete würden aber später beim Routing ohnehin als unzustellbar verworfen.

• Zeile 4 erlaubt allen externen Stationen, zu denen eine Station aus dem internen Netzwerk eine Verbindung aufgebaut hat, durch Antworten die Verbindung aufrecht zu erhalten. Dies realisiert den ersten Fall von Gebot 7. (Pakete mit dem Status UNTRACKED bleiben hier unberücksichtigt.) Mit dieser Zeile beginnt das eigentliche Ingress-Filter; die bisherigen Regeln gewährleisten die Funktion des Routers für das interne Netzwerk. Ab hier wird RETURN statt ACCEPT verwendet, damit externe Pakete mit der Policy gezählt werden.

• Ab Zeile 5 kann es sich nur noch um Pakete handeln, die über die Schnittstelle zur externen Welt eintreffen und bei denen es sich um neue Verbindungsanfragen handelt.

• In Zeile 5 umfasst der Adress-Typ LOCAL alle IP-Adressen, welche der Router selbst als Absender verwenden kann. Pakete, welche laut Gebot 1 diese missbrauchen, werden verworfen.

• In Zeile 6 werden laut Gebot 2 auch alle Pakete von draußen verworfen, welche interne Adressen als Absender verwenden.

• Zeile 7 verbietet gemäß Gebot 3 alle Pakete mit Martian- und Multicast-Adressen als Absender, da die Multicast-Adressen auch in der Menge der Martians stehen.

• Zeile 8 verwirft Broadcast nach Gebot 6.

• Die optionalen Zeilen 9-12 und 14 realisieren den zweiten und dritten Fall von Gebot 7. Zeilen 9 und 10 erlauben den Aufbau einer neuen Verbindung für Stationen, die in der Menge Internet stehen und sich an den Router bzw. eine interne Adresse richten. Der Systemverwalter muss dafür die Menge mit ipset pflegen. Zeilen 11 und 12 leisten das gleiche mit der Menge Auth-ext, in die sich aber Stationen selber eintragen können: Die Hintertüre in Zeile 14 nimmt einen Absender für 60 Sekunden in diese Menge auf, wenn er ein UDP-Paket an Port 7 schickt. Dies ist natürlich nur ein Beispiel und dient hier nur als Aufforderung, über intelligentere und sicherere Mechanismen nachzudenken. Mindestens ist verwendetes Protokoll und Port geheim zu halten. Das anklopfende Paket wird im übrigen genauso wie alle anderen Pakete behandelt, d.h. ein externer Portscanner kann diese Hintertür nicht finden. (Genauer: Er kann sie in erster Ordnung nicht finden. Wenn der Angreifer höheren Aufwand leistet, dann doch: Er muss jeden Port2 nach jedem Port1 anfragen.)

• In der Zeile 13 werden aber gemäß Gebot 5 vorher noch alle Pakete verworfen, die Martians als Empfänger verwenden.

• Gebot 8 wird nicht über Netfilter realisiert, s.u.

• SNMP (Gebot 9), sofern nicht von angemeldeten Gegenstellen, wird in Zeile 15 gesperrt. Wenn man auch angemeldeten Stationen SNMP verwehren will, verschiebt man diese Zeile vor die Zeilen 9-12.

• ICMP (Gebot 10), sofern nicht als RELATED-Paket schon vorher erlaubt, sperrt Zeile 16. Das kann in manchen Fällen zu brutal sein und dann unerwünschte Funktionseinschränkungen verursachen. Details zu ICMP siehe unten.

• Zeile 17 enthält eine Catch-All-Regel (Regel ohne Selektor). Die (im Beispiel fehlende!) Aktion in dieser Regel muss an den konkreten Einsatzfall angepasst werden und kann sowohl RETURN oder DROP lauten. An diese Stelle im Regelsatz gelangen nur Pakete ohne generell offensichtlichen Mangel, die in diesem Sinne valide Verbindungsanfragen sind. Damit ist RETURN gerechtfertigt, dann benötigt man die Hintertür in Zeilen 9ff aber nicht. Andererseits möchte man in vielen Fällen gar keine unautorisierten Verbindungsanfragen von extern zulassen, und damit ist in diesen Fällen auch DROP richtig. Auf keinen Fall darf man auf eine Catch-All-Regel ganz verzichten, da diese für eine Beurteilung der Wirksamkeit der Filterfunktion benötigt wird; im Zweifel sollte man wenigstens wie im Beispiel eine reine Zählregel ohne Aktion vorsehen.

sysctl -w net.ipv4.conf.all.accept_source_route=0 

sysctl -ar net.ipv4.conf.*.accept_source_route 

sysctl -ar net.ipv6.conf.all.accept_source_route 

1

ip6tables -t mangle -A PREROUTING -m rt --rt-type 0 -j DROP

1
2
3

-A PREROUTING ! -i extern -j ACCEPT
-A PREROUTING -m state --state RELATED,ESTABLISHED -j ACCEPT
-A PREROUTING -j DROP

Egress-Filter¶

Man benötigt wieder IP-Adressmengen, kann aber die oben bei Ingress-Filter definierten verwenden und auch gemeinsam für Ingress und Egress benutzen.

Bei der Formulierung eines Filters gemäß der beim Beispiel für das Ingress-Filter gezeigten Methode ist oft die Reihenfolge der Regeln kritisch für die Funktion, da DROP, ACCEPT und RETURN für ein passendes Paket ja dessen Prüfung beenden. In diesem Kapitel wird daher eine andere Methode vorgestellt: Statt das Paket zu verwerfen oder zuzulassen und damit dessen Bearbeitung zu beenden, wird es nur als „böse“ oder „gut“ markiert, und erst am Ende des gesamten Regelsatzes werden diese Markierungen ausgewertet und über das Schicksal des Pakets entschieden. Die Auswahl der Methode hat nichts mit der Aufgabenstellung zu tun, sondern nur mit persönlichen Vorlieben. Das nebenstehende Bild zeigt das hier beschriebene Filter „bei der Arbeit“ unter Verwendung des Skripts IPTadmin.

Folgende Regeln müssen – einzeln nacheinander – per iptables^[2] in der Tabelle mangle definiert werden:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

-P POSTROUTING ACCEPT
-A POSTROUTING ! -o extern -m comment --comment nicht_nach_extern -j ACCEPT
-A POSTROUTING -m state --state RELATED,ESTABLISHED -j MARK --set-xmark 0x8/0x8
-A POSTROUTING -m state --state INVALID -j DROP
-A POSTROUTING -m set ! --match-set Localnet src -m comment --comment "Gebot_2/3" -j MARK --set-xmark 0x1/0x1
-A POSTROUTING -m set ! --match-set Localnet src -m comment --comment "Gebot_2/3" -j LOG
-A POSTROUTING -m addrtype --dst-type BROADCAST -m comment --comment Gebot_6 -j MARK --set-xmark 0x1/0x1
-A POSTROUTING -m set --match-set Martians dst -m comment --comment "Gebot_4/5" -j MARK --set-xmark 0x1/0x1
-A POSTROUTING -p udp -m multiport --ports 161,162 -m comment --comment Gebot_9 -j DROP
-A POSTROUTING -d 192.168.178.1/32 -p udp -m udp --dport 53 -m comment --comment DNS -j MARK --set-xmark 0x8/0x8
-A POSTROUTING -m mark --mark 0x8/0x9 -m comment --comment The_Good -j ACCEPT
-A POSTROUTING -m mark --mark 0x1/0x9 -m comment --comment the_Bad -j DROP
-A POSTROUTING -m mark --mark 0x9/0x9 -m comment --comment and_the_Ugly -j RETURN
-A POSTROUTING -m comment --comment Catch-All -j ACCEPT

Kontrolle: Der Befehl

iptables -t mangle -S POSTROUTING 

muss bis auf die optionalen Kommentare die vorstehende Ausgabe ergeben.

• Die Zeilen 1 und 2 erfüllen die gleichen Aufgaben wie beim Ingress-Filter.

• In Zeile 3 werden Pakete von bestehenden Verbindungen als erwünscht mit 8 (d.h. Bit 3 aus 32) markiert.

• Zeile 4 selektiert irgendwelche kaputte Pakete, die zweifelsfrei verworfen werden müssen und vernichtet diese direkt.

• Die Umsetzung der Gebote 2 und 3 erfordert Nachdenken: An dieser Stelle dürfen valide Pakete nur Absender-Adressen aus Localnet verwenden. Bei normalem Gebrauch ist diese Anforderung immer erfüllt. Es ist jedoch technisch möglich, Absender-Adressen beliebig zu fälschen. Da solche Pakete – die nur einen illegitimen Zweck haben können – nicht in die externe Welt gelangen dürfen, werden sie in Zeile 5 mit 1 (d.h. Bit 0 aus 32) als „böse“ markiert. Zur Ermittlung des sich regelwidrig verhaltenden internen Absenders ist erforderlich, das Paket in Zeile 6 zu protokollieren. Da die Anforderung „nur Localnet als Absender zulässig“ einschränkender als die Anforderung „Martians als Absender unzulässig“ ist, bleiben Martians hier unberücksichtigt. Wenn NAT verwendet wird, dann darf Localnet sogar z.B. in Form privater IP-Adressen sogar ein Teil der Martians sein und tatsächlich wird dies sogar in vielen Fällen zutreffen. Pakete von Absendern aus Localnet werden daher nicht markiert.

• Gemäß den Geboten 4 und 5 werden Pakete mit Martians und Multicast als Empfängeradressen in Zeile 7 als „böse“ markiert.

• Zeile 8 markiert Broadcast nach Gebot 6 als „böse“.

• Zeile 9 gehört nicht zum Kanon der einschlägigen Gebote für Border-Router und wird benötigt, wenn der lokale DNS-Server aus Sicht des internen Netzwerks sich hinter diesem Border-Router befindet und vielleicht sogar eine IP-Adresse aus den Martians verwendet. Deshalb wird DNS-Verkehr (= Port 53/UDP) hier mit 8 (d.h. Bit 3 aus 32) als „zulässig“ markiert. Bei solchen Notlösungen sollte man zu Absicherung die Zieladresse(n) auf die ja dem Systemverwalter bekannten konkreten Adressen der DNS-Server beschränken; da auch der DNS-Port 53 missbraucht werden kann.

• Zeile 10 ist optional und verdammt gemäß Gebot 9 Antworten auf SNMP-Anfragen. Dies entspricht der über vorsichtigen Verwendung von „Leim am Hintern trotz obligatorischem Gürtel und Hosenträger“. Andererseits ist in Sicherheitsfragen Übervorsicht eine gute Grundeinstellung. Da es unerwünscht ist, solche Pakete ins Internet zu senden, werden sie hier mit DROP vernichtet ohne eine eventuell gesetzte Markierung als „gut“ zu berücksichtigen.

• Zeilen 11-13 werten die Markierungen nach der Methode der Klassifikation nach Positiv/Fraglich/Negativ aus:

  • Pakete mit gesetztem Bit 3, aber nicht gesetztem Bit 0 (also die nur als „gut“ erkannten) werden weiter befördert.

  • Pakete mit nicht gesetzten Bit 3, aber gesetzten Bit 0 (also die nur als „böse“ erkannten) werden verworfen.

  • Pakete mit gesetzten Bit 3 und gesetztem Bit 0 werden nach der Policy der Kette behandelt.

• Zeile 14 erlaubt alle Pakete ohne Markierungen. Dies können nur noch neue Verbindungsanfragen (NEW) sein, da der Zustand UNTRACKED hier nicht verwendet wird.

Das Filter muss in den meisten Fällen noch um NAT (bzw. MASQUERADE) ergänzt werden, hierfür in der Tabelle nat diese Regeln einfügen:

1
2

-P POSTROUTING ACCEPT
-A POSTROUTING -o extern -m set --match-set Localnet src -j MASQUERADE

Kontrolle:

iptables -t nat -S POSTROUTING 

Skript¶

Ein Skript, welches die vorgestellten Filter für Ingress und Egress implementiert und auch die benötigten IP-Adressmengen erstellt kann als Anhang zu diesem Artikel herunter geladen werden:

• border-router-skript ⮷ – Direkter Download

• Router/Paketfilter/border-router-skript – Download nach Vorschau

Es muss in einem der in der Umgebungsvariable PATH enthaltenen Verzeichnisse als ausführbares Programm abgelegt werden, root gehören und beim Aufruf mit dem Namen der Schnittstelle zur externen Welt versorgt werden.

Beachte: Dieses Skript installiert nur die Regeln für die beschriebene Firewall. Für die generellen Einstellungen zur Funktion eines Routers lese die anderen Teile der Artikelserie Router/Multifunktionsgerät bzw. den Artikel Router/Routing-Funktion.

Die mit diesem Skript definierten Regeln können mit Hilfe des Skripts IPTadmin gesichert und nach erneuten Start auch wieder geladen werden.

Links¶

• iptables – Das Werkzeug für Netfilter

• Firewall – Die Aufgabenstellung für die hier implementierte Firewall

• Firewall 🇩🇪

• RFC 6890 🇬🇧 – IP-Adressen für spezielle Zwecke

• RFC 3704 🇬🇧 – Ingress Filtering for Multihomed Networks

• Source Routing 🇩🇪

• Deprecation of Source Routing Options in IPv4 🇬🇧

• IPv6 Routing Header Security. 🇬🇧 – Vortrag von Philippe Biondi und Arnaud Ebalard zum Missbrauchspotential von RH0 (aka source routing)

• IPv6 source routing: history repeats itself 🇬🇧 – LWN-Artikel zu source routing bei IPv6

• Source-based routing in IPv4 and IPv6 networks 🇬🇧 – Eine Erklärung zu source routing

• RFC 5095 🇬🇧 – Deprecation of Type 0 Routing Headers in IPv6

• SNMP 🇩🇪 – Security is Not My Problem/Priority

• ICMP 🇩🇪 – Internet Control Message Protocol

• ICMP Parameters 🇬🇧 – Bei IANA: ICMP-Nachrichten mit Typen und Codes

• ICMP Packet Filtering 🇬🇧 – Meinung eines Sicherheits-Experten zum Thema. Die im vorliegenden Wiki-Artikel vorgestellten Filter folgen tendentiell dieser Quelle, sind aber weniger streng. Wer sie weiter verschärfen möchte, dem werden die Beispiele Cisco IOS Access-list 101/102 empfohlen.

• The Good, the Bad and the Ugly 🇬🇧 – Das einschlägige Narrativ zur Erklärung der Methodik der Klassifikation nach Positiv/Fraglich/Negativ