Nftables start: Unterschied zwischen den Versionen

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
Die Seite wurde neu angelegt: „=Vorüberlegung= *Sowohl nftables als auch der Vorgänger iptables arbeiten mit Tabellen und Ketten. *Beim Vorgänger gab es diese praktisch schon von Haus aus…“
 
 
(4 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
=Vorüberlegung=
=Vorüberlegung=
*Sowohl nftables als auch der Vorgänger iptables arbeiten mit Tabellen und Ketten.
*Sowohl nftables als auch der Vorgänger iptables arbeiten mit Tabellen und Ketten.
*Beim Vorgänger gab es diese praktisch schon von Haus aus.
*Bei iptables sind diese standardmäßig vorhanden.
*Bei nftables müssen wir diese selbst anlegen.
*Bei nftables müssen sie selbst angelegt und mit einem passenden Hook (z. B. input, forward, output) verbunden werden.
*Dies geschieht, indem man sie mit dem richtigen Hacken(Hook) verbindet.
*Das ist direkt über die Kommandozeile möglich, aber eleganter über eine Konfigurationsdatei.
*Dies könnte man auf der Kommandozeile machen.
*Bei einem frisch installierten Debian- oder Ubuntu-System sieht die Standardkonfiguration so aus:
*Eleganter ist es allerdings dies in eine Konfigurations Datei zu tun.
*Die Konfiguration entspricht dem klassischen iptables-Modell mit der Tabelle filter und den drei Ketten input, output und forward.
*Bei einem frisch installierten Debian oder Ubuntu System sieht die Konfiguration so aus
*Wird die Konfiguration geladen, wird implizit die Default Policy accept gesetzt.
*Diese stellt ein Zustand da, der an iptables erinnert.
*Wir haben die filter Tabelle und 3 Ketten: input, output und forward erstellt.
*Wenn wir die Konfiguration laden wird impliziet die Default Policy accept gesetzt.


=Datei=
=Datei=
Zeile 29: Zeile 26:
         }
         }
}
}
</pre>
</pre>


=Laden der Konfigurationsdatei=
=Laden der Konfigurationsdatei=
*nft -f /etc/nftables.conf
*nft -f /etc/nftables.conf
=Listen der aktuellen Konfiguration=
 
=Aktuelle Konfiguration anzeigen=
*nft list ruleset
*nft list ruleset
<pre>
<pre>
Zeile 41: Zeile 38:
type filter hook input priority filter; policy accept;
type filter hook input priority filter; policy accept;
}
}
chain forward {
chain forward {
type filter hook forward priority filter; policy accept;
type filter hook forward priority filter; policy accept;
}
}
chain output {
chain output {
type filter hook output priority filter; policy accept;
type filter hook output priority filter; policy accept;
Zeile 51: Zeile 46:
}
}
</pre>
</pre>
=Welchen Zustand haben wir denn nun?=
=Welchen Zustand haben wir denn nun?=
*Ein Paket geht grundsätzlich nur durch eine filter Kette.
*Ein Paket durchläuft genau eine dieser Ketten:
*Ist das Paket für den Rechner selbst bestimmt, ist es die input Kette.
*Ist das Paket für den lokalen Rechner bestimmt, geht es durch die input-Kette.
*Wird das Paket von einem lokalen Prozess generiert geht es durch die output Kette raus.
*Wird es lokal erzeugt, geht es durch die output-Kette.
*Kommt es von einem anderen Rechner und wird es weitergeleietet ist es die forward Kette.
*Kommt es von außen und soll weitergeleitet werden, geht es durch die forward-Kette.
{{#drawio:nftables-filter}}
{{#drawio:nftables-filter}}


=Funktionsweise=
=Funktionsweise=
==Regeln==
==Regeln==
*Jede dieser Kette hat nun eine Aneinanderreihung von Regeln.
*Jede dieser Ketten enthält eine Abfolge von Regeln.
*Diese werden von oben nach unten durchlaufen.
*Diese werden von oben nach unten durchlaufen.
*Trift eine wird sie angewandt, das bedeutet das sie nicht weiter geprüft wird.
*Trifft eine Regel zu, wird sie angewandt, und es wird nicht weiter geprüft.
*Es gibt hier aber auch je nach Ziel Ausnahmen  
*Je nach Ziel der Regel gibt es Ausnahmen.
*Am Ende wird die Default Policy angewandt.
*Am Ende greift die Default Policy.


==Ziele der Filter Ketten==
==Ziele der Filter-Ketten==
*ACCEPT: das Paket kann passieren
*ACCEPT: das Paket wird angenommen
*REJECT: das Paket wird zurückgewiesen und ein Fehlerpaket wird gesendet
*REJECT: das Paket wird abgelehnt, es wird ein Fehlerpaket gesendet
*LOG: schreibt einen Eintrag in die syslog
*LOG: das Paket wird protokolliert
*DROP: das Paket wird ignoriert und keine Antwort gesendet
*DROP: das Paket wird still verworfen


{| class="wikitable"
{| class="wikitable"
Zeile 98: Zeile 94:
type filter hook input priority filter; policy drop;
type filter hook input priority filter; policy drop;
}
}
chain forward {
chain forward {
type filter hook forward priority filter; policy drop;
type filter hook forward priority filter; policy drop;
}
}
chain output {
chain output {
type filter hook output priority filter; policy drop;
type filter hook output priority filter; policy drop;
Zeile 108: Zeile 102:
}
}
</pre>
</pre>
=Überlegung=
=Überlegung=
*Es ist momentan keine gute Idee diese Firewallkonfiguration zu aktivieren.
*Es ist momentan keine gute Idee, diese Konfiguration zu aktivieren, wenn man per SSH eingeloggt ist.
*Wenn wir per SSH eingelogt wären, würden wir uns selbst abschiessen.
*Man würde sich sofort selbst aussperren.
*Wir warten also noch mit der Aktivierung.
*Die Aktivierung erfolgt erst, wenn alle notwendigen Regeln gesetzt sind.
=Prioritäten=
{| class="wikitable"
|+ Prioritätenreihenfolge in nftables (je niedriger, desto früher)
! Symbolischer Name !! Numerischer Wert !! Beschreibung
|-
| raw || -300 || Früheste Verarbeitung (z. B. Conntrack-Bypass)
|-
| mangle || -150 || Paketmanipulation (MARK, TTL, etc.)
|-
| dstnat || -100 || Ziel-NAT (DNAT)
|-
| filter || 0 || Paketfilterung (ACCEPT, DROP, REJECT)
|-
| srcnat || 100 || Quell-NAT (SNAT, MASQUERADE)
|-
| security || 150 || Sicherheitsverarbeitung (SECMARK, SELinux)
|}


=Connection Tracking=
=Connection Tracking=
*Beim Connection Tracking wird über jede Verbindung die durchgelassen wird, Buch geführt.
*Connection Tracking merkt sich, welche Verbindungen gerade bestehen.
*Eine Verbindung die neu initiert wird, hat den Status '''new'''.  
*Ein neu aufgebautes Paket hat den Status '''new'''.
*Ein Paket das zu einer bestehenden Verbindung gehört, hat den Status '''established'''.
*Pakete, die zu einer bestehenden Verbindung gehören, haben den Status '''established'''.
*Es gibt noch den Zustand '''related'''. Dies bezieht sich auf icmp Pakete die einen Bezug zu dieser Verbindung haben.
*Zusätzlich gibt es '''related''' für z. B. ICMP- oder FTP-Sekundärverbindungen.
*Oder auch Mehr Kanal Verbindungen wie beispielsweise ftp oder sip.
*Auch UDP wird mit Hilfe von Timern getrackt.
*Dazu braucht man helper Module(prüfen)
*Für bestimmte Protokolle wie FTP oder SIP werden ggf. Helper-Module benötigt.
*Bei den Verbindung wird auch das eigentlich Verbindungslose Protokoll '''udp''' mit einbezogen.
*Dies wird über einen Timer geregelt.


=Die Idee hinter dem Connection Tracking=
=Ziel des Connection Tracking=
*Die Idee ist nun alle '''established''' und '''related''' Pakekte freizuschalten.
*Pakete mit Status '''established''' oder '''related''' sollen durchgelassen werden.
*Und nur bestimmte Verbindungsinitiativen freizuschalten.
*Nur neue Verbindungen werden gezielt erlaubt.
*Das Firewall Framework lässt dann jeweils nur die Pakete durch die zu einer bestehenden Verbindung gehören.
*So lässt man nur bekannte oder kontrollierte Kommunikation durch.
 
=Einbauen des Connection Tracking Grundgerüst=
*Wir erlauben alle Pakete die zu einer bestehenden Verbindung gehören.
*Wir erlauben alle Pakete die in einer Relation zu einer bestehenden Verbindung stehen.
*'''Achtung''' Die Firwall lässt immer noch nichts durch, weil wir noch keine neue Verbindung erlauben.


=Einbauen des Connection Tracking Grundgerüsts=
*cat /etc/nftables.conf
*cat /etc/nftables.conf
<pre>
<pre>
Zeile 141: Zeile 147:
chain input {
chain input {
type filter hook input priority filter; policy drop;
type filter hook input priority filter; policy drop;
                ct state established,related accept
ct state established,related accept
}
}
 
chain forward {
type filter hook forward priority filter; policy drop;
                ct state established,related accept
        }
 
chain output {
chain output {
type filter hook output priority filter; policy drop;
type filter hook output priority filter; policy drop;
                ct state established,related accept
ct state established,related accept
}
}
}
}
</pre>
</pre>
=Regeln dauerhaft aktivieren=
'''Noch nicht machen'''
*systemctl enable nftables
*systemctl start nftables

Aktuelle Version vom 30. Juni 2025, 14:47 Uhr

Vorüberlegung

  • Sowohl nftables als auch der Vorgänger iptables arbeiten mit Tabellen und Ketten.
  • Bei iptables sind diese standardmäßig vorhanden.
  • Bei nftables müssen sie selbst angelegt und mit einem passenden Hook (z. B. input, forward, output) verbunden werden.
  • Das ist direkt über die Kommandozeile möglich, aber eleganter über eine Konfigurationsdatei.
  • Bei einem frisch installierten Debian- oder Ubuntu-System sieht die Standardkonfiguration so aus:
  • Die Konfiguration entspricht dem klassischen iptables-Modell mit der Tabelle filter und den drei Ketten input, output und forward.
  • Wird die Konfiguration geladen, wird implizit die Default Policy accept gesetzt.

Datei

  • cat /etc/nftables.conf
#!/usr/sbin/nft -f

flush ruleset

table inet filter {
        chain input {
                type filter hook input priority 0;
        }
        chain forward {
                type filter hook forward priority 0;
        }
        chain output {
                type filter hook output priority 0;
        }
}

Laden der Konfigurationsdatei

  • nft -f /etc/nftables.conf

Aktuelle Konfiguration anzeigen

  • nft list ruleset
table inet filter {
	chain input {
		type filter hook input priority filter; policy accept;
	}
	chain forward {
		type filter hook forward priority filter; policy accept;
	}
	chain output {
		type filter hook output priority filter; policy accept;
	}
}

Welchen Zustand haben wir denn nun?

  • Ein Paket durchläuft genau eine dieser Ketten:
  • Ist das Paket für den lokalen Rechner bestimmt, geht es durch die input-Kette.
  • Wird es lokal erzeugt, geht es durch die output-Kette.
  • Kommt es von außen und soll weitergeleitet werden, geht es durch die forward-Kette.
nftables-filter

Funktionsweise

Regeln

  • Jede dieser Ketten enthält eine Abfolge von Regeln.
  • Diese werden von oben nach unten durchlaufen.
  • Trifft eine Regel zu, wird sie angewandt, und es wird nicht weiter geprüft.
  • Je nach Ziel der Regel gibt es Ausnahmen.
  • Am Ende greift die Default Policy.

Ziele der Filter-Ketten

  • ACCEPT: das Paket wird angenommen
  • REJECT: das Paket wird abgelehnt, es wird ein Fehlerpaket gesendet
  • LOG: das Paket wird protokolliert
  • DROP: das Paket wird still verworfen
filter table
input output forward
rule 1 rule 1 rule 1
rule 2 rule 2 rule 2
rule 3 rule 3
rule 4
DEFAULT POLICY DEFAULT POLICY DEFAULT POLICY

Wir ändern nun die Default Policy auf drop

  • cat /etc/nftables.conf
#!/usr/sbin/nft -f

flush ruleset
table inet filter {
	chain input {
		type filter hook input priority filter; policy drop;
	}
	chain forward {
		type filter hook forward priority filter; policy drop;
	}
	chain output {
		type filter hook output priority filter; policy drop;
	}
}

Überlegung

  • Es ist momentan keine gute Idee, diese Konfiguration zu aktivieren, wenn man per SSH eingeloggt ist.
  • Man würde sich sofort selbst aussperren.
  • Die Aktivierung erfolgt erst, wenn alle notwendigen Regeln gesetzt sind.

Prioritäten

Prioritätenreihenfolge in nftables (je niedriger, desto früher)
Symbolischer Name Numerischer Wert Beschreibung
raw -300 Früheste Verarbeitung (z. B. Conntrack-Bypass)
mangle -150 Paketmanipulation (MARK, TTL, etc.)
dstnat -100 Ziel-NAT (DNAT)
filter 0 Paketfilterung (ACCEPT, DROP, REJECT)
srcnat 100 Quell-NAT (SNAT, MASQUERADE)
security 150 Sicherheitsverarbeitung (SECMARK, SELinux)

Connection Tracking

  • Connection Tracking merkt sich, welche Verbindungen gerade bestehen.
  • Ein neu aufgebautes Paket hat den Status new.
  • Pakete, die zu einer bestehenden Verbindung gehören, haben den Status established.
  • Zusätzlich gibt es related für z. B. ICMP- oder FTP-Sekundärverbindungen.
  • Auch UDP wird mit Hilfe von Timern getrackt.
  • Für bestimmte Protokolle wie FTP oder SIP werden ggf. Helper-Module benötigt.

Ziel des Connection Tracking

  • Pakete mit Status established oder related sollen durchgelassen werden.
  • Nur neue Verbindungen werden gezielt erlaubt.
  • So lässt man nur bekannte oder kontrollierte Kommunikation durch.

Einbauen des Connection Tracking Grundgerüsts

  • cat /etc/nftables.conf
#!/usr/sbin/nft -f

flush ruleset
table inet filter {
	chain input {
		type filter hook input priority filter; policy drop;
		ct state established,related accept
	}
	
	chain output {
		type filter hook output priority filter; policy drop;
		ct state established,related accept
	}
}

Regeln dauerhaft aktivieren

Noch nicht machen

  • systemctl enable nftables
  • systemctl start nftables