IPv6/Firewall: Unterschied zwischen den Versionen
Markierung: Ersetzt |
K Textersetzung - „Kurzbeschreibung“ durch „Beschreibung“ |
||
(Eine dazwischenliegende Version desselben Benutzers wird nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
'''topic''' - | '''topic''' - Beschreibung | ||
=== Beschreibung === | === 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 (<nowiki>RFC 1918</nowiki> / 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: <nowiki>http://www.kernel.org/</nowiki> | |||
Besorgen Sie sich das aktuellste iptables Paket: | |||
* Source tarball (für Kernel Patches): <nowiki>http://www.netfilter.org/</nowiki> | |||
==== 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: | |||
<noinclude> | <noinclude> | ||
== Anhang == | == Anhang == | ||
=== Siehe auch === | === Siehe auch === |
Aktuelle Version vom 19. Oktober 2024, 13:40 Uhr
topic - Beschreibung
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