• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

[Erledigt] Frage zu Netfilter bei neuen Distributionen

gehrke

Administrator
Teammitglied
Code:
[root@j12 ~]# dnf info nftables
Installierte Pakete
Name         : nftables
Epoch        : 1
Version      : 0.9.1
Release      : 3.fc31
Architecture : x86_64
Size         : 813 k
Quelle       : nftables-0.9.1-3.fc31.src.rpm
Repository   : @System
Aus Paketque : fedora
Summary      : Netfilter Tables userspace utillites
URL          : http://netfilter.org/projects/nftables/
Lizenz       : GPLv2
Description  : Netfilter Tables userspace utilities.
 

marce

Guru
Was sind neue Distributionen?

Fedora: https://fedoraproject.org/wiki/Changes/firewalld_default_to_nftables
Debian: https://wiki.debian.org/nftables

https://wiki.nftables.org/wiki-nftables/index.php/Nftables_from_distributions
 
OP
Gräfin Klara

Gräfin Klara

Hacker
marce schrieb:
Was sind neue Distributionen?
Neue Distributionen sind "Neue Ausgaben unterschiedlicher Distributoren"

marce schrieb:
Fedora: https://fedoraproject.org/wiki/Changes/firewalld_default_to_nftables
Debian: https://wiki.debian.org/nftables
https://wiki.nftables.org/wiki-nftables/index.php/Nftables_from_distributions
Ich weiß, dass nftables von den Distributoren "unterstützt" wird, aber ob es auch umgesetzt wird, das weiß ich nicht.
Am Beispiel deiner Links:
Fedora: https://fedoraproject.org/wiki/Changes/firewalld_default_to_nftables
Die unterstützen es, sie wollen wechseln von iptables nach nftables, umgesetzt wurde es aber wahrscheinlich noch nicht.
Debian: https://wiki.debian.org/nftables
Die setzen nftables auch noch nicht ein, so zumindest zu lesen auf dieser Seite. Ob das so noch richtig ist, weiß ich nicht.
https://wiki.nftables.org/wiki-nftables/index.php/Nftables_from_distributions
Dass die Distributoren nftables unterstützen, das ist bekannt und keine Kunst. Ob sie es auch einsetzen, das läßt sich daraus nicht erlesen.

Oder wie ist das bei bei Suse? Ist mir auch nicht bekannt. Informationen dazu finde ich keine.
Diese Information wäre für mich aber wichtig. Hier treffen sich user mit unterschiedlichsten Systemen.
Deshalb ist dieses Forum auch der richtige Platz um nachzufragen, so meine ich.
Code:
# nft list tables inet
Dann weiß man es

Danke
 

marce

Guru
Tja, ich lese das anders - sowohl Fedora 32 als auch Debian Buster haben nftables als Default.

... wobei das, solange Paket-Technisch noch beides verfügbar ist Du auch immer wieder mal das eine, mal das andere vorfinden wirst. Der gemeine Linux-User ist manchmal ein wenig zäh bei der Migration auf neue Tools / Services / ...
 
OP
Gräfin Klara

Gräfin Klara

Hacker
gehrke schrieb:
Code:
[root@j12 ~]# dnf info nftables
Installierte Pakete
Name         : nftables
Epoch        : 1
Version      : 0.9.1
Release      : 3.fc31
Architecture : x86_64
Size         : 813 k
Quelle       : nftables-0.9.1-3.fc31.src.rpm
Repository   : @System
Aus Paketque : fedora
Summary      : Netfilter Tables userspace utillites
URL          : http://netfilter.org/projects/nftables/
Lizenz       : GPLv2
Description  : Netfilter Tables userspace utilities.

Danke! Damit weiß ich leider nur, dass es zur Verfügung gestellt wird.
Wird nftables auf fedora auch aktiv eingesetzt?
 
OP
Gräfin Klara

Gräfin Klara

Hacker
marce schrieb:
Tja, ich lese das anders - sowohl Fedora 32 als auch Debian Buster haben nftables als Default.
Bei Fedora, so ist dort zu lesen, werden alle chains und rules für die firewall mit iptables und ebtables gesetzt.
Bei Debian ebenso.
 

gehrke

Administrator
Teammitglied
Gräfin Klara schrieb:
Danke! Damit weiß ich leider nur, dass es zur Verfügung gestellt wird.
Wird nftables auf fedora auch aktiv eingesetzt?
Zumindest ist es installiert. Keinen Schimmer, wie ich das am besten bestimmen kann.

Hier mal Dein Statement von oben:
Code:
# nft list tables inet
<leer>
 
OP
Gräfin Klara

Gräfin Klara

Hacker
gehrke schrieb:
Hier mal Dein Statement von oben:
Code:
# nft list tables inet
<leer>
Danke, das wollte ich wissen.

gehrke schrieb:
Zumindest ist es installiert. Keinen Schimmer, wie ich das am besten bestimmen kann.
Zur Erklärung:
Es gibt zur Zeit 2 namespaces für netfilter im kernel, ip_tables und nf_tables.
Beide sind völlig verschieden, in ip_tables stehen die Regeln in einer Art von Beschreibung.
In der neuen nf_tables stehen sie binär. nft liest die chains und rules, compiliert und trägt sie dort ein.
Der kernel arbeitet sie dann ab, so dass z.B. eine firewall wie gewünscht filtert.
Nun habe ich eine Software zu schreiben, die netfilter fürs routing braucht.
In welchen namespace soll ich die rules nun eintragen? Zwei libraries werde ich sicher nicht programmieren!
Fedora (Du) bist auf ip_tables, RedHat und Gentoo sind schon nf_tables, Suse, Debian und Arch weiß ich noch nicht.
Entscheidung ist schwierig, die Arbeit fällt genau in einen unangenehmen Zeitpunkt des Umbaus der Systeme.

Danke und Gruß
 

gehrke

Administrator
Teammitglied
Gut, dann hier noch von einem CentOS 8 (aka RHEL 8 ):
Code:
# nft list tables inet
table inet firewalld
 

/dev/null

Moderator
Teammitglied
Na, dann wünsche ich dir viel Spaß ;-)
Den Auftraggeber fragen? Der ist doch Chef und sollte alles wissen ... (oder etwa nicht?)
Und im Fall des Falles (Chef hat keine Ahnung ...) die zukunftsfähige Version wählen. (Hat ein hier nicht genannter Verkehrsminister auch gedacht ...)

Ich habe mal nachgeschaut (openSuSE Tumbleweed):
Auszug aus /etc/firewalld/firewalld.conf
Code:
# FirewallBackend
# Selects the firewall backend implementation.
# Choices are:
#       - nftables
#       - iptables (default)
FirewallBackend=iptables

MfG Peter
 
OP
Gräfin Klara

Gräfin Klara

Hacker
.
Danke für eure Unterstützung

Bei 10 aktuellen Distributionen liegt das Verhältnis derzeit bei 4 (nf_tables) zu 6 (ip_tables)
Ich muß beides. Der Abgabetermin ist damit außer Reichweite.

/dev/null schrieb:
Den Auftraggeber fragen?
Behörde! Da könnte ich auch in ein Ofenrohr hineinsprechen

Gruß
Gräfin Klara
 
OP
Gräfin Klara

Gräfin Klara

Hacker
.
ip_tables / nf_tables Kurzbrief

Die Unterschiede zwischen ip_tables und nf_tables lassen sich nicht einfach erklären, da es bei genauerer
Betrachtung - abgesehen vom Resultat - kaum Gemeinsamkeiten gibt.

Konfiguration und Verarbeitung

ip_tables wird meist in einem script Zeile für Zeit abgearbeitet.
Code:
#!/bin/bash

iptables -N Table
iptables -A add rule ....
iptables -A add next rule ....
usw.

Das ist mit nf_tables zwar noch möglich, sollte aber so nicht realisiert werden.
nf_tables ist unter anderem ein Interpreter, der files liest, compiliert und
in den Kernel schreibt. Auch wenn es im Internet als Konfiguration bezeichnet wird,
ist das so nicht zutreffend. Diese scripts - einfach beschrieben - haben folgende Struktur:

file: /etc/nft/myfilter.nft

Code:
#!/sbin/nft -f

include "irgendein_file_mit_konstanten_oder_weiteren_anweisungen"

table ip6 MY_TABLE {

	chain wan_in {
		type filter hook input priority 0;
		filter_anweisungen
		.....
	}
	chain wan_out {
		type filter hook output priority 0;
		filter_anweisungen
		...
	}
	chain do_anything {
		irgendwelche_anweisungen
		return
	}
}

table inet MY_NEXT_TABLE {
.....
}

Der Aufbau selbst ist C-ähnlich und beginnt wie bei bash mit der Angabe des Interpreters.
Die folgende Anweisung parsed das file, compiliert und schreibt die Regeln in den kernel:
# nft --file /etc/nft/myfilter.nft
und damit liest man dann die Regeln der Tabelle MY_TABLE aus dem kernel:
# nft list table ip6 MY_TABLE

Zum script /etc/nft/myfilter.nft:

table ip6 MY_TABLE
erzeugt eine Tabelle mit dem Namen "MY_TABLE", durch die nur der IPV6 traffic läuft.
ip wäre für IPV4, inet für IPV4 + IPV6 und das geht dann in der Hirarchie der Protokolle hinunter bis
zu Typen wie arp, bridge, usw.
D.h., nf_tables ersetzt nicht nur ip_tables, sondern auch eb_tables und arp_tables.

Chains sitzen wie Funktionen innerhalb der Tabelle und werden mit type (oder auch nicht) definiert.
Die folgende chain ist mit type definiert und damit eine "base chain".
Ihr Typ ist filter (typisch für firewalls), hook erzwingt den Datenfluss durch diese chain und
diese chain ist konfiguriert nur für den input traffic.
chain wan_in {
type filter hook input priority 0;
....
}



Durch die nächste chain läuft der ausgehende Datenverkehr. (Die Namen der chains sind natürlich beliebig)
chain wan_out {
type filter hook output priority 0;
....
}


Der dritten chain ist kein Typ zugerdnet und sie ist damit eine "regular chain". Durch solche chains,
weil kein "hook" vorhanden, fließen auch keine Daten. Aber solche chains dienen als Subfunktionen
für alle base chains. Von dort aus sind diese regular chains mit jump oder goto erreichbar.

chain do_anything {
irgendwelche_anweisungen
....
return
}


usw.


Chains type kann sein filter, nat oder route.
Wenn man nun bedenkt, dass table z.B. arp oder bridge sein kann, werden die Möglichkeiten in den chains klar.
Filtering und Routing durch alle Netzwerebenen bis hinunter auf ethernet. Pakete können auf Bitebene zerlegt
und Filter danach erstellt werden. Von IP(v4,6) nach TCP/UDP(v4,6) bis zur MAC ist alles in einem Paket verarbeitbar.

Weiters werden die virtuellen devices besser unterstützt, z.B, MACVLAN, MACVTAP, das Patchkabel VETH oder BRIDGE.
Diese devices werden in Zukunft an Bedeutung gewinnen. Obendrein unterstützt nf_tables direkt "tproxy".
tproxy ist ein im Kernel existierender transparenter proxy. Es gibt also kaum mehr eine Aufgabe, die
mit nf_tables nicht umgesetzt werden kann. Im Laufe dieses Jahres wird WireGuard in den kernel integriert.
Dieses VPN gemeinsam mit iproute2 und nf_tables ergibt das perfekte Gespann.

Wer wie ich ip_tables gut kennt, der wird von Beiträgen im Internet leicht dazu verführt, den Aufbau
der Konfiguration ähnlich der von ip_tables zu gestalten. Das funktioniert, ist aber ein Fehler. Vergesst
ip_tables und fangt neu an. nf_tables ist für eine Verarbeitung Zeile für Zeile nicht gemacht und in
einem bash bricht man seine atomicity, d.h. es entstehen gaps zwischen Anweisungen im kernel_namespace.
Alles in einem lesen, compilieren und schreiben, nur so arbeitet nf_tables problemlos.

Bis nf_tables auf einem System funktioniert, das nicht dafür konfiguriert wurde, dauert eine Weile.
Die notwendigen modules sind im kernel nicht leicht zu finden, z.B, IPV4 NAT für nf_tables steht abseits und ist gut versteckt.
nft gibt bei einem fehlenden module typischerweise die Fehlermeldung "File not found" aus. Das ist natürlich wenig hilfreich.

Die Geschwinfigkeit habe ich getestet, in dem ich mehrer Pakete im Kreis laufen ließ um sie an einer
Stelle mit postrouting zu entlassen. Das entspricht in etwa der typischen firewall mit NAT, pre- und postrouting.
Ich konnte mit diesem simplen Test keinen bemerkenswerten Unterschied zwischen ip_tables und nf_tables feststellen.
Wer aber Load balancing benötigt oder auf routing in nf_tables setzt, der darf mit einem Geschwinfigkeitsgewinn
von ca. 15% rechnen.

nf_tables ist sehr umfangreich weil es einfach alles abdeckt. Trotzdem ist es gelungen, die Übersicht zu erhalten.
Alle Regeln ziehen sich wie ein logischer Faden durch die Tabellen und diesem kann man einfach folgen.

Das wars
Gräfin Klara
 

/dev/null

Moderator
Teammitglied
Hi,

vielen Dank für diese ausführliche und aus der Praxis kommende (!) Erklärung. Ich wäre den von dir beschriebenen Fehler "mit ip_tables im Hinterkopf" garantiert gegangen. Mal schauen, ob ich das bei meinem - nun schon seit 5 Jahren nur noch privatem - IT-Gerödel noch anwenden werde. Zumindest dann, wenn die von mir genutzte Distribution auf nf_tables umstellt. Aber dann wird es ja garantiert auch mit der bekannten FW-GUI in Yast funktionieren, so dass ich mir dann die im Hintergrund stehenden Regeln anschauen und davon lernen kann.
Meine Maxime: Lernen ist den Bregen in Bewegung halten!


Wünsche allen Mitlesern und speziell dir, "Klara" ein schönes Wochenende!

MfG Peter
 

/dev/null

Moderator
Teammitglied
gehrke schrieb:
Ein Like-Button für solche Beiträge wäre fein...

Bitte nicht!
Das würde mich zu sehr an Fazzebuck erinnern und ich hasse diese Firma.
Ich nehme mir lieber die Zeit, um mit freundlichen Worten DANKE zu sagen.

MfG Peter
 
Oben