IPv6/Firewall

Aus Foxwiki

topic - Kurzbeschreibung

Beschreibung

Firewall-Funktionalität

Die IPv6 Firewall-Funktionalität ist wichtig; vor allem dann, wenn Sie auf Ihren internen Netzen IPv6 mit globalen IPv6 Adressen einsetzen. In IPv6 werden - im Unterschied zu IPv4, wo interne Hosts automatisch durch private IPv6 Adressen geschützt werden (RFC 1918 / Address Allocation for Private Internets bzw. Google search for Microsoft + APIPA) - globale Adressen verwendet und jeder mit IPv6-Anbindung kann alle internen Knoten, bei denen IPv6 aktiv ist, erreichen.

netfilter6

Von Haus aus unterstützt wird die IPv6-Firewall-Funktionalität im Kernel erst ab Version 2.4+. In älteren 2.2+ Versionen können sie nur mit Protocol 41 das generelle Tunnel von IPv6-in-IPv4-Paketen filtern.

Achtung: Es gibt keine Garantie, dass die beschriebenen Regeln und Beispiele ihr System auch wirklich schützen können!

Beobachten Sie nach der Installation ihr Regelset, siehe Abschnitt Abschnitt 19.3.

Kernels ab Version 2.6.20 (Februar 2007) unterstützen den IPv6-Verbindungsstatus (connection tracking) vollständig.

Kernels ab Version 3.9.0 (April 2013) unterstützen NAT für IPv6 in Verbindung mit ip6tables >= 1.4.18

Kernels ab Version 3.13 (April 2014) unterstützen ein neues Framework namens: nftables

Weitere Informationen

  • Netfilter project
  • maillist archive of netfilter users
  • maillist archive of netfilter developers
  • Unofficial status informations

Vorbereitung

Dies ist nur notwendig, wenn der mitgelieferte Kernel und Netfilter nicht den Ansprüchen genügt und neue Featurs bereits verfügbar sind, jedoch noch nicht beinhaltet.

Quellen besorgen

Besorgen Sie sich den aktuellsten Kernel: http://www.kernel.org/

Besorgen Sie sich das aktuellste iptables Paket:

  • Source tarball (für Kernel Patches): http://www.netfilter.org/

Quellen entpacken

Wechseln Sie in das Source-Verzeichnis:

Entpacken sie die Kernel-Quellen und vergeben diesen einen neuen Namen

Entpacken Sie die iptables Quellen


Neueste iptables/IPv6-relevante Patches den Kernel-Quellen hinzufügen

Wechseln Sie in das iptables Verzeichnis

Fügen Sie relevante Patches hinzu

Fügen Sie zusätzliche IPv6 relevante IPv6 Patches hinzu (die nach wie vor nicht im Standard-Kernel enthalten sind)

Sagen Sie zu folgenden Optionen (iptables-1.2.2) Ja:

  • ah-esp.patch
  • masq-dynaddr.patch (nur benötigt bei Systemen mit dynamischer IP-Zuweisung am WAN mittels PPP oder PPPoE)
  • ipv6-agr.patch.ipv6
  • ipv6-ports.patch.ipv6
  • LOG.patch.ipv6
  • REJECT.patch.ipv6

Überprüfen Sie die Erweiterungen


Konfiguration, kompilieren und Installation eines neues Kernels

Wechseln Sie zu den Kernel-Quellen

Editieren Sie das Makefile

Starten Sie configure und aktivieren Sie IPv6 relevante Optionen

Konfigurieren Sie bei Bedarf Sonstiges abseits von IPv6.

Kompilieren und Installation: siehe Kapitel Kernel sowie andere HOWTOs.

iptables neu kompilieren und installieren

Stellen Sie sicher, dass obige Kernel-Sourceverzeichnisstruktur unter /usr/src/linux liegt

Benennen sie das ältere Verzeichnis um

Erstellen Sie einen neuen symbolischen Link

Erstellen Sie ein neues SRPMS

Installieren Sie das neue iptables Paket (iptables + iptables-ipv6)

  • Bei RH 7.1 Systemen ist normalerweise eine ältere Version hiervon bereits installiert, verwenden Sie daher die Option ”Freshen”:


  • Ist keine ältere Version installiert, benutzen Sie die Option ”install”:


  • Bei RH 6.2 Systemen ist normalerweise kein Kernel Version 2.4.x installiert und die Anforderungen sind demnach nicht gegeben. Benutzen Sie in diesem Fall ”nodeps”:


Damit iptables die Libraries finden kann, ist es eventuell notwendig, einen symbolischen Link für die iptables Libraries zu erstellen:


Verwendung

Unterstützung im Kernel

Laden Sie das Modul (falls dies im Kernel so kompiliert wurde):

Überprüfen der IPv6-Unterstützung:


Die Benützung von iptables lernen

Auflistung aller netfilter Einträge
  • Kurze Auflistung:


  • Erweiterte Auflistung:


Auflistung angegebener Filter
Hinzufügen einer Log-Regel zum Input-Filter mit Optionen
Hinzufügen einer Drop-Regel zum Input-Filter
Löschen einer Regel mit Hilfe der Regelnummer
Aktiviere die Auswertung des Verbindungsstatus (connection tracking)

Seit Kernel-Version 2.6.20 ist die Auswertung des IPv6-Verbindungsstatus gut unterstützt. Die bis dahin statuslosen Filterregeln sollten ersetzt werden..


ICMPv6 erlauben

Bei älteren Kernelversionen (unpatched kernel 2.4.5 und iptables-1.2.2) kann keine nähere Spezifizierung des ICMPv6-Typs vorgenommen werden:

  • Eingehender ICMPv6 Verkehr durch Tunnel erlauben


  • Ausgehenden ICMPv6 Verkehr durch Tunnel erlauben


Neuere Kernel erlauben das Spezifizieren des ICMPv6-Typs:


Rate-limiting

Da es zu einem ICMPv6 Storm kommen kann (der Autor hat dies bereits mehrfach beobachtet), sollten sie das rate limiting zumindest für das ICMP Regelset einsetzen. Zusätzlich sollten auch die Logging Regeln mit rate limiting geschützt werden, um DoS Attacken gegen das syslog sowie gegen die Logdateien enthaltenden Patitionen entgegenzuwirken. Ein Beispiel für ein rate limited ICMPv6 sieht wie folgt aus:


Eingehende SSH-Verbindung erlauben

Im folgenden Beispiel werden eingehende SSH-Verbindungen von einer speziellen IPv6 Adresse zugelassen:

  • Eingehende SSH Verbindungen werden von der Adresse 2001:0db8:100::1/128 erlaubt


  • Erlaube Antwortpakete (nicht mehr notwendig, wenn der IPv6-Verbindungsstatus ausgewertet wird!)


Getunnelten IPv6-in-IPv4 Datenverkehr erlauben

Um getunnelte IPv6-in-IPv4 Pakete zu akzeptieren, müssen Sie in Ihrem IPv4 Firewall-Setup entsprechende Regeln einzufügen, z.B.

  • Akzeptiere eingehende IPv6-in-IPv4 Daten am interface ppp0


  • Akzeptiere ausgehende IPv6-in-IPv4 Daten am interface ppp0


Haben Sie nur einen statischen Tunnel, dann können sie die IPv4 Adresse auch dediziert angeben:

  • Akzeptiere eingehende IPv6-in-IPv4 Daten vom Tunnel-Endpunkt 192.0.2.2 am interface ppp0


  • Akzeptiere ausgehende IPv6-in-IPv4 Daten vom Tunnel-Endpunkt 192.0.2.2 am interface ppp0


Schutz gegen eingehende TCP-Verbindungs-Anfragen

SEHR EMPFOHLEN! Aus Sicherheitsgründen sollten Sie auf jeden Fall eine Regel inkludieren, wodurch eingehende TCP-Verbindungs-Anfragen geblockt werden. Wenn Sie andere Interfacenamen verwenden, müssen Sie die Option "-i" entsprechend anpassen!

  • Blockiere eingehende TCP-Verbindungs-Anfragen zu diesem Host
  • Blockiere eingehende TCP-Verbindungs-Anfragen zu Hosts hinter diesem Router


Eventuell müssen diese Regeln unterhalb anderer Regeln platziert werden. Nehmen Sie sich für die Reihenfolge der Regeln etwas Zeit. Sinnvoll wird es auch sein, ein Script mit den Regeln zu erstellen, damit die Regeln in der gewünschten Reihenfolge angewandt werden.

Schutz gegen eingehende UDP-Verbindungs-Anfragen

EBENFALLS SEHR EMPHOLEN! Wie bereits im Kapitel Firewall erwähnt, ist es möglich die Ports bei ausgehenden UDP/TCP-Verbindungen zu kontrollieren. Im Falle, dass all Ihre IPv6 Systeme lokale Ports verwenden, z.B. von 32768 bis 60999, dann können sie ebenfalls UDP Verbindungen filtern (bis das Verbindungs-Tracking funktioniert):

  • Blockiere eingehende UDP-Pakete, die nicht Antworten ausgehender Anfragen dieses Host sein können


  • Blockiere eingehende UDP-Pakete, die nicht Antworten auf Anfragen von hinter diesem Router gelegenen Hosts sein können


Anwendungsbeispiele

Einfaches Beispiel für Fedora

Folgende Zeilen zeigen eine einfache Firewall-Konfiguration für Fedora 6 (ab Kernel-Version 2.6.20). Ausgehend von dem Origina (generiert durch system-config-firewall) wurden Modifikationen für die Unterstützung des Verbindungsstatus und der Rückgabe der passenden ICMPv6-Meldung für Rejects. Eingehende SSH (Port 22) Verbindungen sind erlaubt.

Zwecks der Vollständigkeit ist hier auch die entsprechende Konfiguration für IPv4 gezeigt:

Benutzung:

  • Erzeugen/Modifizieren der Konfigurationsdateien
  • Aktivieren von IPv4 & IPv6 Firewalling
  • Aktivieren des automatischen Starts nach dem Reboot
Umfangreicheres Beispiel

Folgende Zeilen zeigen ein umfangreicheres Setup. Happy netfilter6 Regelset erstellen...

Network Address Translation (NAT) mit netfilter6

Seit mindestens Linux Kernel-Version 3.9.0 und ip6tables ab 1.4.18 kann Network Address Translation (NAT) genutzt werden.

IPv6 Maskierung

Wie bei IPv4 können Systeme hinter einem Router versteckt werden mit Hilfe von IPv6 Maskierung (hide/overlap NAT), z.B.

IPv6 Destination NAT

Eine dedizierte öffentliche IPv6-Adresse kann zu einer internen IPv6-Adresse weitergeleitet werden, z.B.

IPv6 Port Weiterleitung

Ein dedizierter Port kann zu einem internen System weitergeleitet werden, z.B.

Firewall-Setup mit nftables

Mit nftables wurde die Unterstützung einer Tabelle names ”inet” eingeführt in welcher Regeln für IPv4/IPv6 gleichzeitig gelten

Präparation zur Nutzung von nftables

Installieren einer Linux-Distribution, welche die Unterstützung für nftables bereits eingebaut hat. Beim Schreiben dieses Absatzes (Mai 2014) war mindestens Fedora Rawhide (Vorläufer der Version 21) mit entsprechendem Support und nftables version 0.2.0 versehen.

Basis-nftables Konfiguration

Laden der Kernel-Module:

Löschen der Regeln in iptables and ip6tables um Interferenzen zu vermeiden:

Erzeugen der Filter-Tabelle:

Erzeugen einer input chain in der Filter-Tabelle:

Einfache Filter-Policy mit nftables

Konfiguration

Erlauben von Paketen, die zu existierenden Einträgen in der Connection-Tracking-Tabelle gehören

Erlauben von IPv4 und IPv6 ICMP echo-request (aka ping)

Erlauben einiger wichtiger IPv6 ICMP Pakete, ohne Zähler, dafür mit Hop-Limit-Prüfung (erhöht die Sicherheit)

Erlauben von eingehenden SSH-Verbindungen für IPv4 und IPv6

Reject/drop anderer Pakete

Ergebnis

Tabelle für IP unabhängigen Filter

Tipps für's Loggen

Für Logging wird ein zusätzliches Kernelmodul benötigt:

ACHTUNG, MOMENTAN KANN DER LOG-LEVEL NICHT ANGEGEBEN WERDEN, dadurch werden nftables-Ereignisse mit Log-Level kern.emerg ausgegeben - ES BESTEHT DIE GEFAHR, DASS DIE KONSOLE DADURCH ÜBERFLUTET WIRD!

Für erste Tests mit der Log-Option kann es nützlich sein, das Loggens für emergency-Ereignisse in z.B. /etc/rsyslog.conf zu deaktivieren mit Hilfe eines ”#” am Anfang der Zeile und Neustart des logging-Daemons

Regel von oben, welche SSH auf Port 22 erlaubt, nun mit Logging:

Filter-Policy mit nftables unter Benutzung der Tablellen ”ip”, ”ip6” und ”inet”

Wie oben schon beschrieben, wenn die Regeln in den einzelnen Tabellen konfiguriert werden, muss gesichert sein, dass frühere ”accepts” nicht aufgehoben werden. Eine einfache Lösung ist die Benutzung von Markierungen. Regeln, die Pakete erlauben, setzen die Marke mit ”meta mark set xxxx”. Eine generische Regel erlaubt Pakete mit gesetzter Marke ”mark xxxx”. Beispiel für ein resultierendes Filter-Regelwerk:


Anhang

Siehe auch

Dokumentation

Links

Projekt
Weblinks