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…“)
 
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.
  
 
=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=
 
*Die Idee ist nun alle '''established''' und '''related''' Pakekte freizuschalten.
 
*Und nur bestimmte Verbindungsinitiativen freizuschalten.
 
*Das Firewall Framework lässt dann jeweils nur die Pakete durch die zu einer bestehenden Verbindung gehören.
 
  
=Einbauen des Connection Tracking Grundgerüst=
+
=Ziel des Connection Tracking=
*Wir erlauben alle Pakete die zu einer bestehenden Verbindung gehören.
+
*Pakete mit Status '''established''' oder '''related''' sollen durchgelassen werden.
*Wir erlauben alle Pakete die in einer Relation zu einer bestehenden Verbindung stehen.
+
*Nur neue Verbindungen werden gezielt erlaubt.
*'''Achtung''' Die Firwall lässt immer noch nichts durch, weil wir noch keine neue Verbindung erlauben.
+
*So lässt man nur bekannte oder kontrollierte Kommunikation durch.
  
 +
=Einbauen des Connection Tracking Grundgerüsts=
 
*cat /etc/nftables.conf
 
*cat /etc/nftables.conf
 
<pre>
 
<pre>
Zeile 141: Zeile 130:
 
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 {
 
chain forward {
 
type filter hook forward priority filter; policy drop;
 
type filter hook forward priority filter; policy drop;
                ct state established,related accept
+
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=
 +
*systemctl enable nftables
 +
*systemctl start nftables

Version vom 12. April 2025, 14:18 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.

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.

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 forward {
		type filter hook forward 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

  • systemctl enable nftables
  • systemctl start nftables