Linux Befehl "nftables"
nftables erlaubt den Aufbau eines Filter-Regelwerkes für beliebige Schnittstellen.
Ähnlich einer Firewall können Datenpakete je nach Protokoll,Ursprung oder Ziel verworfen werden.
Dieser Befehl hat einen ganz anderen Syntax als das vorherige iptables.
Installation
Bei aktuelleren Linux-Versionen sollte dieser Befehl bereits installiert sein.
Falls nicht kann er leicht nachinstalliert werden:
# apt-get install nftables
Die folgenden zusätzlichen Pakete werden installiert:
libjansson4 libmnl0 libmxml1 libnftnl0
Die folgenden NEUEN Pakete werden installiert:
libjansson4 libmnl0 libmxml1 libnftnl0 nftables
0 aktualisiert, 5 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
Es müssen 217 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 731 kB Plattenplatz zusätzlich benutzt.
Befehle
| # man nft | (ruft das dazugehörige Handbuch auf) |
| # nft | (ohne Parameter wird momentan eine Fehlermeldung ausgegeben) |
| # nft -f | (importiert Firewallregeln aus einer Datei, deren Pfad noch angegeben werden muss) |
| # nft -f /etc/nftables/firewall.test | (lädt ein Regelwerk aus Datei /etc/nftables/firewall.test) |
| # nft -h | (zeigt eine Übersicht möglicher Parameter und wenige Beispiele) |
| # nft list tables inet | (Anzeige aller Tabellen(-namen) des "inet" Protokolles) |
| # nft list table inet firewall | (Zeigt Regelwerk für Protokoll "inet" (Tabelle "firewall") |
| # nft flush table inet firewall | (setzt Regelwerk für Protokoll "inet" (Tabelle "firewall") auf leer) |
Grundlegendes
Unter /etc/nftables/ befinden sich einige(leere?) Beispieldateien.
Wiki des nftables-Teams.
nftables verhalten sich ganz anders als iptables!
Zwar können vorgegebene Firewallregeln aus einer Datei importiert werden, diese Regeln ersetzen jedoch NICHT bereits vorhandene.
So kann es vorkommen, das man mehrere Regeln "stapelt".
Die Methoden zum Löschen bereits vorhandener Regeln sind unhandlich; schnellster Weg die Regeln loszuwerden: # reboot..
Ein Einbau von "flush" in die Definitionsdatei führt zu einem Fehler.. da zu dem Zeitpunkt ja noch gar keine Tabelle definiert war..
Es MUSS zuerst eine Tabelle definiert worden sein, bevor "flush" genutzt werden kann.
Leider führt eine erste "dummy" Zuweisung mit gefolgtem "flush" innerhalb einer Definitionsdatei auch zu wirren Fehlern -.-
TABLES können definiert werden, dabei existieren fünf verschiedene Protokolle:
arp
unbekannter Zweck
bridge
unbekannter Zweck
inet
erst ab Kernel 3.14f; fasst ip/ip6 zusammen
ip
Protokoll ip4
ip6
Protokoll ip6
https://wiki.archlinux.org/index.php/nftables
https://home.regit.org/2014/01/why-you-will-love-nftables/
Die verschiedenen Firewallregeln sollte man unter /etc/nftables/ ablegen. Hierbei bietet es sich an die Dateien nach Nutzen zu benennen:
/etc/nftables/firewall-test (Regelwerk zum TESTEN, im Schadensfall einfach den Server neu booten lassen..)
/etc/nftables/firewall-default (geprüftes Regelwerk, das beim Booten automatisch gestartet werden sollte(s.u.!))
Solange man sich nicht ganz sicher ist, was man da eingentlich so treibt sollte man nur mit /etc/nftables.test arbeiten!!
Erst wenn ein Regelwerk definiert wurde und via # <datei> geladen wurde ist es aktiv!
Nach einem # reboot ist gar kein Regelwerk mehr aktiv(alles zugelassen!!)
Je nach Browsereinstellung können versteckte Steuerzeichen Fehler beim Kopieren erzeugen, dann von Hand eintippen..
Zu beachten: es gibt zwei verschiedene IP-Protokolle(ip4/ip6). Sowohl die Befehle als auch die "Tables" unterscheiden sich leicht!
/etc/nftables/firewall-default
Die folgende "Tabelle" kann einfach kopiert und unter /etc/nftables/firewall-default gespeichert werden.
Die Definitionen entsprechen einem minimalen Standard, die eigentlich überall(Ausnahmen:Nat/Routing) problemlos laufen sollten.
Wichtig: Zugriffe von aussen auf anderen Dienste sind hiermit(eingehend) gesperrt, das betrifft z.B. Minecraft- oder TeamSpeak-Server..
Nachteil: durch die Freigabe von SSH(Port22) werden die Skript-Kiddies(und die NSA?) weiterhin /var/log/auth.log vollspammen.
Diese Definitionen werden NICHT automatisch bei einem Systemstart geladen!
# nft -f /etc/nftables/firewall-default dient als provisorischer Aufruf, der nach jedem reboot einmal erfolgen muss!
Man könnte das mit einem Skript automatisieren,.. noch keine Ahnung, wie das mit Jessie funktioniert -.-
| # File: firewall-default | # (default definition file for nftables) |
| table inet firewall { | # inet = ip4/ip6 Stack(BEIDE Protokolle!); Tabelle heisst "firewall" |
| chain incoming { | # Verarbeitung EINGEHENDER Pakete |
| type filter hook input priority 0; | |
| ct state {established, related} accept | # Bereits bestehende/verknüpfte Verbindungen erlauben |
| ct state invalid drop | # ungültige Pakete verwerfen |
| iifname lo accept | # loopback erlauben |
| ip protocol icmp accept | # eingehende icmps erlauben |
| tcp dport ssh accept | # open tcp port: sshd (22) falls eigener IP-Pool nicht bekannt |
| tcp dport http accept | # open tcp ports: httpd (80) falls ein http-Server läuft |
| reject | # everything else |
| } | |
| } | |
| # Zum Abschluss muss eine Leerzeile stehen! |
/etc/nftables/firewall-test
Eine zusätzliche Definitionsdatei /etc/nftables/firewall-test dient für Experimente mit neuen Regeln.
# nft -f /etc/nftables/firewall-test aktiviert diese Regel.. bis zum nächsten reboot.
Bei schwerwiegenden Konfigurations-Fehlern reicht im schlimmsten Fall ein reboot aus um die Default-Firewall zu reaktivieren.
| # File: firewall-test | # (test definition file for nftables) |
| flush table inet firewall | # Löscht Regelwerk der Tabelle "firewall" des Protokolles inet |
| table inet firewall { | # inet = ip4/ip6 Stack(BEIDE Protokolle!); Tabelle heisst "firewall" |
| chain prerouting { | # Verarbeitung vor.. Verarbeitung?! |
| type filter hook prerouting priority -300; | |
| tcp flags & (fin|syn) == (fin|syn) drop | |
| tcp flags & (syn|rst) == (syn|rst) drop | |
| tcp flags & (fin|syn|rst|psh|ack|urg) < (fin) drop #==0 | |
| tcp flags & (fin|syn|rst|psh|ack|urg) == (fin|psh|urg) drop | |
| } | |
| chain incoming { | # Verarbeitung EINGEHENDER Pakete |
| type filter hook input priority 0; | |
| ct state {established, related} accept | # Bereits bestehende/verknüpfte Verbindungen erlauben |
| ct state invalid drop | # ungültige Pakete verwerfen |
| iifname lo accept | # loopback erlauben |
| ip daddr != 85.25.99.61 drop | # Nicht relevante Pakete verwerfen IP des Servers eintragen! |
| ip protocol icmp accept | # icmp |
| #tcp dport ssh accept | # open tcp port: sshd (22) falls eigener IP-Pool nicht bekannt |
| ip saddr 1.2.3.4/17 tcp dport ssh accept | # Eigener IP-Pool für SSH IP(Range) des Clients eintragen! |
| tcp dport ssh log drop | # SSH-Scans loggen und verwerfen |
| tcp dport http accept | # open tcp ports: httpd (80) |
| tcp dport {25565, 25566, 25567} accept | # open tcp ports: Minecraft-SERVER (server1..3) |
| udp dport {25565, 25566, 25567} accept | # open udp ports: Minecraft-QUERY (server1..3) |
| reject | # everything else |
| } | |
| } | |
| # Zum Abschluss muss eine Leerzeile stehen! |
Die Reaktion auf eine Filterregel kannACCEPT, DROP oder REJECT sein.
REJECT galt lange als "freundlich" bei Ablehnung von Verbindungsversuchen.
Für viele Anwendungen machte diese Einstellung Sinn, so bekam der andere Computer eine Rückmeldung(Port geschlossen, etc.).
Bei ftp-Verbindungen entfielen längere Wartezeiten da gleich auf eine andere Verbindungsart umgeschaltet werden könnte(active/passive).
DROP hingegen galt als "unfreundlich", da keine Rückmeldung bei verworfenen Datenpaketen erfolgt.