pings erlauben mit iptables? [Gelöst]

[ingo2]

So, da hier mehrere User genau wie ich noch wenig Erfahrung mit nftables haben und sich auch einarbeiten möchten, poste ich mal (m)eine "Rezeptur" für den Start.

Unter Stretch rate ich dazu, nftables aus Backports zu installieren, das passiert dann parallel zum intallierten iptables. Die Version aus Stretch entfernt ipatables.

Also jetzt der Reihe nach:

Code: Alles auswählen

apt install -t stretch-backports nftables
...
5 aktualisiert, 3 neu installiert, 0 zu entfernen

Die einzige Konfigurationsdatei mit den Regeln ist /etc/nftables.conf.
Meine simple Version für einen Desktop-PC mit Erklärungen zu den jeweiligen Rules:
/etc/nftables.conf:

Code: Alles auswählen

#!/usr/sbin/nft -f

# /etc/nftables.conf

flush ruleset

table inet filter {
	chain input {
		type filter hook input priority 0;

		# accept any localhost traffic
		iif lo accept

		# accept traffic originated from us
		ct state established,related accept
		ct state invalid counter drop

		# allow ping (echo request) at limited rate. 2nd rule needed to handle established.
		ip6 nexthdr icmpv6 icmpv6 type echo-request limit rate 10/second accept
		ip6 nexthdr icmpv6 icmpv6 type echo-request counter log prefix "nft-ping_flood " drop
		ip protocol icmp icmp type echo-request limit rate 10/second accept/etc/nftables.conf
		ip protocol icmp icmp type echo-request counter log prefix "nft-ping_flood " drop

		# IPv6: accept ICMP for neighbour discovery, otherwise IPv6 connectivity breaks.
		ip6 nexthdr icmpv6 icmpv6 type { nd-neighbor-solicit,  nd-router-advert, nd-neighbor-advert } accept
		# IPv6: ICMP redirects (type 137) is included in "ct stat invalid"
                # ip6 nexthdr icmpv6 icmpv6 type nd-redirect counter drop

		# IPv4: accept & count all other ICMP.
		ip protocol icmp icmp type { destination-unreachable, router-solicitation, router-advertisement, time-exceeded, parameter-problem } counter accept
		# IPv4: drop & count IGMP (Multicast) i.e. FritzBox for IPTV, unused by me.
		ip protocol igmp counter drop

                # accept common local services: SSH, CUPS
                tcp dport { 22, 631 } ct state new accept

		# FritzBox scans for ports 80 und 14013: unused by me
		tcp dport { 80, 14013 }  ct state new counter drop

		# broadcast from this PC: AVAHI and CUPS
		udp dport { 5353, 161 } counter drop
		# broadcast from this PC: saned searching scanners
		udp dport { 1124, 3289, 8610, 8612 } counter drop
		# NetBIOS, SMB von b3, Win10 WM, laptops
		udp dport { 137, 138 } counter drop
		# broadcast from other clients for DHCP
		udp dport { 67 } counter drop

		# drop any other traffic, count and log to nftables.log.
		counter log prefix "nft-final_drop " drop
	}

	# Forwarding is not requiered on a desktop PC
	# chain forward {
	#	type filter hook forward priority 0;
	# }

	chain output {
		type filter hook output priority 0;
	}
}

Einfach nach /etc/ kopieren.

Fürs Logging in einem eigenen Logfile statt des "syslog" folgende Konfigurationsdatei erstellen:
/etc/rsyslog.d/01_nft_log.conf:

Code: Alles auswählen

# /etc/rsyslog.d/01_nft_log.conf

# Log for nftables if activated. Prevent writing to syslog by "& stop"

#
# prefix nft-* : where "*" indicates a specific rule in nftables.conf.
#
:msg,regex,"nft."        -/var/log/nftables.log
& stop

Dann:
Checken, ob bereits iptables aktiv ist (beides, d.h. iptables und nftables gleichzeitig wird nicht empfohlen):

Code: Alles auswählen

iptables -L

rsyslog neu starten, nftables starten - und wenn alles ok ist , nftables aktivieren

Code: Alles auswählen

systemctl restart rsyslog.service

systemctl (re)start|reload nftables.service

systemctl enable nftables.service

So, das sollte für nahezu alle Standard-Desktops reichen. Was ich darüberhinaus erlaubt habe:
SSH-Zugang
Drucker/CUPS von anderen PCs aus.

Meine Konfiguration ist jetzt soweit, dass ich alle normalerweise einfach durchs letzte "drop" verworfenen UDP-Pakete den entsprechenden Anwendungen zuordnen konnte - deshalb die Aufteilung auf mehrere Regeln. Kann dann auch jeder bei Bedarf separat auf "accept" setzen. Damit bleibt im Normalfall das Log leer, nur unerlaubte Zugriffsversuche werden geloggt.

Ich stelle die ganze Konfiguration zur Diskussion und bin über weitere Anregungen/Verbesserungen dankbar. Eine ergiebige Quelle für Information ist das Projekt-Wiki https://wiki.nftables.org/wiki-nftables ... 10_minutes und auch die Wikis von Arch und Gentoo.


EDIT/Nachtrag, nur zur Info:
a) Anzeige des gesamten Filters mit Anzahl der gefilterten Pakete, bei denen "counter" gesetzt ist:
Als root:

Code: Alles auswählen

nft list ruleset

b) SIP-Telefonie (mit linphone geht ohne jede Portöffnung in beide Richtungen.
c) nano nutzt Syntax-Highlighting beim Editieren der nftables.conf - eine gute Hilfe.
d) Sehr comfortabel: Einträge in der table "inet" gelten gleich für beides, IPv4 und IPv6!

[jmar83]

Danke, werde es testen wenn ich das nächste Mal ein fertig konfiguriertes Linux-Image (inkl. allem "drum und dran") aufbaue.

[ReturnToSender]

Noch eine Idee, da ja bald (mit Buster) nftables zum Standard wird:

Ich habe gestern Buster installiert und da ist es anscheinend noch nicht Standard...iptables wurde vom Installer installiert, nftables nicht. Gibts da irgendwo Aussagen, wie es bei dem Thema weitergeht?

[ingo2]

Ich habe gestern Buster installiert und da ist es anscheinend noch nicht Standard...iptables wurde vom Installer installiert, nftables nicht. Gibts da irgendwo Aussagen, wie es bei dem Thema weitergeht?

Auf jeden Fall kannst du nftables problemlos installieren ohne dass iptables entfernt wird.
Soviel ich es verstanden hab', kann eine bestehende ipatbles-Konfiguration von nftables entweder mit einer Zwischenschicht weiter benutzt werden (z.B. für die Leute, die upgraden), aber es soll auch per Übersetzung möglich sein, eine bestehende iptables-Konfiguration direkt in nftables zu übertragen.

Das wird wohl noch diskutiert, wie das für Buster umgesetzt werden soll. Quelle habe ich leider nicht mehr,

Ingo

[ReturnToSender]

Auf jeden Fall kannst du nftables problemlos installieren ohne dass iptables entfernt wird.

Ja, ich weiss. aber ich habs bislang nicht eingesetzt, weils bisher mit der Stretch-Version Probleme für Stateful-Regeln gab. Der Paketfilter hat regelmäßig meine IPV6-Konfiguration still gelegt. Mit dem alten Paketfilter gabs diese Probleme nicht.

Ich habe gerade auch den Hinweis gefunden: https://wiki.debian.org/nftables
Current status
NOTE: Debian Buster will use the nftables framework by default.

Merkwürdig, dass der aktuelle Installer das noch nicht so sieht. Aber egal, ich werde mal die neuere Version testen.

[dufty2]

Noch eine Idee, da ja bald (mit Buster) nftables zum Standard wird:

Der neueste Schrei ist bpfilter.
Müsste blos noch wissen, wie man die wiederum konfiguriert:
Über iptables oder nftables oder assembler ...

[ingo2]

Der Paketfilter hat regelmäßig meine IPV6-Konfiguration still gelegt. Mit dem alten Paketfilter gabs diese Probleme nicht.

Dann hst du vielleicht vergessen, gewisse ICMPv6-Funktionen explizit freizuschalten (s. in meinem Beispiel):

Code: Alles auswählen

# IPv6: accept ICMP for neighbour discovery, otherwise IPv6 connectivity breaks.
ip6 nexthdr icmpv6 icmpv6 type { nd-neighbor-solicit,  nd-router-advert, nd-neighbor-advert } accept

Gruß,
Ingo

[ReturnToSender]

Dann hst du vielleicht vergessen, gewisse ICMPv6-Funktionen explizit freizuschalten (s. in meinem Beispiel):

Ich hoffe nicht. Dagegen spricht ja auch die Tatsache, dass quasi das gleiche Regelwerk unter iptables einwandfrei läuft. Möglicherweise war das auch nur ein Bug, den es vielleicht in der aktuellen Version gar nicht mehr gibt. Mal abwarten, das werde ich ja jetzt in kürze herausfinden.

[ReturnToSender]

Der neueste Schrei ist bpfilter.
Müsste blos noch wissen, wie man die wiederum konfiguriert: Über iptables oder nftables oder assembler ...

Das war für mich auch was neues. Aber ich schätze, das wird noch eine ganze Zeit dauern, bis wir uns darüber den Kopf zerbrechen müssen....
http://www.linux-magazin.de/news/bpfilt ... ux-kernel/

[jmar83]

Hallo

Sry. habe den Thread inwtischen abbestellt, und deshalb deinen Beitrag nicht mehr gesehen. Nun ist es aber so, dass der davon betroffene Server wieder plattgemacht wurde und somit nicht mehr verfügbar ist.

Bei der nächstbesten Gelegenheit werde ich es aber nochmal durchspielen!