Discussion:
[Debian] iptables Einträge wo speichern?
(zu alt für eine Antwort)
Andreas Kohlbach
2024-02-20 05:05:10 UTC
Permalink
Das alte Debian hat iptables Aufrufe von mir in /etc/rc.local
bekommen. Wurde mir mal vor über 10 Jahren empfohlen.

Da das nicht der "beste" Ort sein kann, suchte ich und fand Seiten, die
/etc/iptables/rules.v4 empfahlen. Ich habe das Verzeichnis iptables und
die Datei rules.v4 selbst angelegt, und die iptables Zeile per Zeile dort
eingetragen.

Nach dem Booten aber wurden die Werte nicht übernommen. Dazu wurde der
Inhalt der Datei modifiziert. Und meine Einträge sind dort nicht mehr.

Wo trage ich in Debian die iptables-Zeilen ein?
--
Andreas
Paul Muster
2024-02-20 06:16:13 UTC
Permalink
Post by Andreas Kohlbach
Das alte Debian hat iptables Aufrufe von mir in /etc/rc.local
bekommen. Wurde mir mal vor über 10 Jahren empfohlen.
Da das nicht der "beste" Ort sein kann, suchte ich und fand Seiten, die
/etc/iptables/rules.v4 empfahlen. Ich habe das Verzeichnis iptables und
die Datei rules.v4 selbst angelegt, und die iptables Zeile per Zeile dort
eingetragen.
Nach dem Booten aber wurden die Werte nicht übernommen. Dazu wurde der
Inhalt der Datei modifiziert. Und meine Einträge sind dort nicht mehr.
Wo trage ich in Debian die iptables-Zeilen ein?
Die speichert man mittels
iptables-save > /etc/iptables/rules.v4 && ip6tables-save >
/etc/iptables/rules.v6
, dann werden sie beim Booten auch wieder geladen. Sofern
iptables-persistent installiert ist.


mfP Paul
Andreas Kohlbach
2024-02-20 16:49:19 UTC
Permalink
Post by Paul Muster
Post by Andreas Kohlbach
Das alte Debian hat iptables Aufrufe von mir in /etc/rc.local
bekommen. Wurde mir mal vor über 10 Jahren empfohlen.
Da das nicht der "beste" Ort sein kann, suchte ich und fand Seiten, die
/etc/iptables/rules.v4 empfahlen. Ich habe das Verzeichnis iptables und
die Datei rules.v4 selbst angelegt, und die iptables Zeile per Zeile dort
eingetragen.
Nach dem Booten aber wurden die Werte nicht übernommen. Dazu wurde der
Inhalt der Datei modifiziert. Und meine Einträge sind dort nicht mehr.
Wo trage ich in Debian die iptables-Zeilen ein?
Die speichert man mittels
iptables-save > /etc/iptables/rules.v4 && ip6tables-save >
/etc/iptables/rules.v6
, dann werden sie beim Booten auch wieder geladen. Sofern
iptables-persistent installiert ist.
Ah!

Erst also von Hand setzen, dann mittels

iptables-save > /etc/iptables/rules.v4

wegsichern.

Danke.
--
Andreas
Marc Haber
2024-02-20 18:03:20 UTC
Permalink
Post by Andreas Kohlbach
Post by Paul Muster
Post by Andreas Kohlbach
Das alte Debian hat iptables Aufrufe von mir in /etc/rc.local
bekommen. Wurde mir mal vor über 10 Jahren empfohlen.
Da das nicht der "beste" Ort sein kann, suchte ich und fand Seiten, die
/etc/iptables/rules.v4 empfahlen. Ich habe das Verzeichnis iptables und
die Datei rules.v4 selbst angelegt, und die iptables Zeile per Zeile dort
eingetragen.
Nach dem Booten aber wurden die Werte nicht übernommen. Dazu wurde der
Inhalt der Datei modifiziert. Und meine Einträge sind dort nicht mehr.
Wo trage ich in Debian die iptables-Zeilen ein?
Die speichert man mittels
iptables-save > /etc/iptables/rules.v4 && ip6tables-save >
/etc/iptables/rules.v6
, dann werden sie beim Booten auch wieder geladen. Sofern
iptables-persistent installiert ist.
Ah!
Erst also von Hand setzen, dann mittels
iptables-save > /etc/iptables/rules.v4
wegsichern.
Ich glaube, iptables-persistent macht das beim Herunterfahren auch von
selbst, und bietet auch eine Möglichkeit diesen Prozess manuell
anzustoßen.

Grüße
Marc
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
Paul Muster
2024-02-20 20:16:37 UTC
Permalink
Post by Marc Haber
Post by Andreas Kohlbach
Erst also von Hand setzen, dann mittels
iptables-save > /etc/iptables/rules.v4
wegsichern.
Ich glaube, iptables-persistent macht das beim Herunterfahren auch von
selbst,
Meiner vagen Erinnerung nach war das vor Jahr und Tag mal tatsächlich
der Fall. Da sich aber zu viele DAUs aus ihren Systemen ausgesperrt
haben, wurde das wieder rausgenommen. Somit muss man nun aktiv zum
richtigen Zeitpunkt den gewünschten Status speichern.
Post by Marc Haber
und bietet auch eine Möglichkeit diesen Prozess manuell
anzustoßen.
Ja, siehe oben, plus 'dpkg-reconfigure iptables-persistent'.


mfG Paul
Andreas Kohlbach
2024-02-21 03:12:54 UTC
Permalink
Post by Paul Muster
Post by Marc Haber
Post by Andreas Kohlbach
Erst also von Hand setzen, dann mittels
iptables-save > /etc/iptables/rules.v4
wegsichern.
Ich glaube, iptables-persistent macht das beim Herunterfahren auch von
selbst,
Meiner vagen Erinnerung nach war das vor Jahr und Tag mal tatsächlich
der Fall. Da sich aber zu viele DAUs aus ihren Systemen ausgesperrt
haben, wurde das wieder rausgenommen. Somit muss man nun aktiv zum
richtigen Zeitpunkt den gewünschten Status speichern.
Nehme ich auch an. Ich hatte die Regeln von Hand eingestellt und gestern
neu gebootet. Wurden *nicht* übernommen.
--
Andreas
Marc Haber
2024-02-20 07:59:08 UTC
Permalink
Post by Andreas Kohlbach
Das alte Debian hat iptables Aufrufe von mir in /etc/rc.local
bekommen. Wurde mir mal vor über 10 Jahren empfohlen.
Ich würde ja empfehlen auf nftables umzusteigen, dessen Regeln
sind IMHO wesentlich angenehmer zu lesen/schreiben, und sie werden
in /etc/nftables.conf gespeichert, und werden von da bei Debian auch
automatisch geladen.
Der Rat ist grundsätzlich nicht falsch, aber ich finde dass es bei
nftables einfach noch keinen Komfortlevel gibt der mit dem Ökosystem,
das sich in 20 Jahren iptables entwicktle hat, mithalten kann. Zum
Beispiel ferm.

Mit nftables ist insbesondere das Schreiben von dualstack-Regelwerken
echt schmerzhaft.

Grüße
Marc
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
Marco Moock
2024-02-20 08:00:29 UTC
Permalink
Post by Marc Haber
Mit nftables ist insbesondere das Schreiben von dualstack-Regelwerken
echt schmerzhaft.
Genau deswegen nutze ich firewalld.
--
Gruß
Marco

Spam und Werbung bitte an ***@cartoonies.org
Marc Haber
2024-02-20 08:44:39 UTC
Permalink
Post by Marco Moock
Post by Marc Haber
Mit nftables ist insbesondere das Schreiben von dualstack-Regelwerken
echt schmerzhaft.
Genau deswegen nutze ich firewalld.
Das scheint ungefähr das einzige zu sein, wollte ich mir angucken bei
Gelegenheit. Dunkle Winterabende gibt es jetzt erstmal keine.

Grüße
Marc
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
Marco Moock
2024-02-20 08:49:02 UTC
Permalink
Post by Marc Haber
Das scheint ungefähr das einzige zu sein, wollte ich mir angucken bei
Gelegenheit. Dunkle Winterabende gibt es jetzt erstmal keine.
Du hast ein Thinkpad, damit kannst du dich auch an schönen Tagen Abends
draußen hinsetzen.
--
Gruß
Marco

Spam und Werbung bitte an ***@cartoonies.org
Marc Haber
2024-02-20 12:55:45 UTC
Permalink
Post by Marco Moock
Post by Marc Haber
Das scheint ungefähr das einzige zu sein, wollte ich mir angucken bei
Gelegenheit. Dunkle Winterabende gibt es jetzt erstmal keine.
Du hast ein Thinkpad,
nicht nur eins
Post by Marco Moock
damit kannst du dich auch an schönen Tagen Abends
draußen hinsetzen.
ja, aber dann habe ich besseres zu tun.

Grüße
Marc
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
Marco Moock
2024-02-20 19:24:06 UTC
Permalink
Post by Marc Haber
Post by Marco Moock
Post by Marc Haber
Das scheint ungefähr das einzige zu sein, wollte ich mir angucken
bei Gelegenheit. Dunkle Winterabende gibt es jetzt erstmal keine.
Du hast ein Thinkpad,
nicht nur eins
Dann kannst du ja diese draußen vernetzen (per Ad-Hoc-WLAN oder auch per
Kabel) und da mit firewalld rumtesten.
Post by Marc Haber
Post by Marco Moock
damit kannst du dich auch an schönen Tagen Abends
draußen hinsetzen.
ja, aber dann habe ich besseres zu tun.
Und das wäre?
--
Gruß
Marco

Spam und Werbung bitte an ***@cartoonies.org
Kay Martinen
2024-02-20 12:35:06 UTC
Permalink
Post by Marc Haber
Post by Marco Moock
Post by Marc Haber
Mit nftables ist insbesondere das Schreiben von dualstack-Regelwerken
echt schmerzhaft.
Genau deswegen nutze ich firewalld.
Das scheint ungefähr das einzige zu sein, wollte ich mir angucken bei
Gelegenheit.
Und es scheint auch das einzige zu sein das mit dem Network-Manager
(GUI) Zonen interagiert. Jedenfalls fand ich bei mehreren Debian/Ubuntu
Systemen das deren Standard-installations Kandidat (g)ufw NICHT mit
spielt. Wirft man den raus und installiert firewalld dann tauchen in der
NM-GUI auch firewall-zonen auf die man auswählen kann. Mit ufw bleibt
das Leer.

Leider ist das (UI)Setup für Firewalld mehr als nur verwirrend. Es ist
schlicht eine Katastrophe bei der man nicht durchblickt was-womit-wie
zusammen hängt oder sich ggf. auf etwas bezieht oder evtl. auch
irgendwas übernimmt. Ich bekam nicht mal raus was genau bei den
Presets/Zonen nun geblockt oder Erlaubt ist.

Oder kann man das Biest nur per CLI-Tools zähmen?
Post by Marc Haber
Dunkle Winterabende gibt es jetzt erstmal keine.
Mach's Licht aus! :)

Bye/
/Kay
--
nix
Marco Moock
2024-02-20 19:28:08 UTC
Permalink
Post by Kay Martinen
Post by Marc Haber
Post by Marco Moock
Post by Marc Haber
Mit nftables ist insbesondere das Schreiben von
dualstack-Regelwerken echt schmerzhaft.
Genau deswegen nutze ich firewalld.
Das scheint ungefähr das einzige zu sein, wollte ich mir angucken
bei Gelegenheit.
Und es scheint auch das einzige zu sein das mit dem Network-Manager
(GUI) Zonen interagiert. Jedenfalls fand ich bei mehreren
Debian/Ubuntu Systemen das deren Standard-installations Kandidat
(g)ufw NICHT mit spielt. Wirft man den raus und installiert firewalld
dann tauchen in der NM-GUI auch firewall-zonen auf die man auswählen
kann. Mit ufw bleibt das Leer.
Leider ist das (UI)Setup für Firewalld mehr als nur verwirrend. Es
ist schlicht eine Katastrophe bei der man nicht durchblickt
was-womit-wie zusammen hängt oder sich ggf. auf etwas bezieht oder
evtl. auch irgendwas übernimmt. Ich bekam nicht mal raus was genau
bei den Presets/Zonen nun geblockt oder Erlaubt ist.
sudo firewall-cmd --list-all-zones
Welche UI verwendest du dafür?
Post by Kay Martinen
Oder kann man das Biest nur per CLI-Tools zähmen?
firewall-cmd ist da mein Favorit.
Das GUI-Geraffel habe ich nie richtig getestet.
Post by Kay Martinen
Post by Marc Haber
Dunkle Winterabende gibt es jetzt erstmal keine.
Mach's Licht aus! :)
Das hätte bei der Sonne gravierende Auswirkungen.
--
Gruß
Marco

Spam und Werbung bitte an ***@cartoonies.org
Friedemann Stoyan
2024-02-20 12:12:54 UTC
Permalink
Post by Marco Moock
Genau deswegen nutze ich firewalld.
firewalld war, als ich ihn mir angesehen hatte, besonders unbrauchbar. Konnte
nur einfache Sache, wie permitte Port.

Komplexe Ausdrücke ließen sich damit nicht realisieren.

mfg Friedemann
Marco Moock
2024-02-20 19:46:56 UTC
Permalink
Post by Friedemann Stoyan
Post by Marco Moock
Genau deswegen nutze ich firewalld.
firewalld war, als ich ihn mir angesehen hatte, besonders
unbrauchbar. Konnte nur einfache Sache, wie permitte Port.
Komplexe Ausdrücke ließen sich damit nicht realisieren.
Es gibt die rich-rules. Damit lässt sich IP/Port kombinieren.
Ob mehr damit geht, weiß ich nicht. Ist ja nur ein Frontend für
nftables (und iptables, aber deprecated).

Als personal Firewall für mich prima geeignet.
--
Gruß
Marco

Spam und Werbung bitte an ***@cartoonies.org
Ralph Aichinger
2024-02-20 08:34:33 UTC
Permalink
Post by Marc Haber
Der Rat ist grundsätzlich nicht falsch, aber ich finde dass es bei
nftables einfach noch keinen Komfortlevel gibt der mit dem Ökosystem,
das sich in 20 Jahren iptables entwicktle hat, mithalten kann. Zum
Klar, nftables ist immer noch relativ jung für ein Subsystem, das so
viele Querverbindungen zu allen möglichen Stellen im System hat, aber
langsam wird es.
Post by Marc Haber
Beispiel ferm.
Ich habe früher auch ferm verwendet, aber gerade das geht mir bei
nftables nicht wirklich ab, weil sich die nftables-Syntax eh sehr stark
an ferm anlehnt. Mag sein, dass ich nicht viele der advanced features
von ferm verwendet habe, aber aktuell geht mir bei nftables nix ab.
Post by Marc Haber
Mit nftables ist insbesondere das Schreiben von dualstack-Regelwerken
echt schmerzhaft.
Jein, das mag sein, leider ist mein Dualstack-Regelwerk im v6-Teil
komplett unterschiedlich vom v4-Teil, beispielsweise weil v6
kein NAT braucht, dafür durch die großzügigere Verfügbarkeit von
Netzen ein sinnvolleres auftrennen in DMZs ermöglicht.

/ralph
Marc Haber
2024-02-20 08:50:52 UTC
Permalink
Post by Ralph Aichinger
Post by Marc Haber
Der Rat ist grundsätzlich nicht falsch, aber ich finde dass es bei
nftables einfach noch keinen Komfortlevel gibt der mit dem Ökosystem,
das sich in 20 Jahren iptables entwicktle hat, mithalten kann. Zum
Klar, nftables ist immer noch relativ jung für ein Subsystem, das so
viele Querverbindungen zu allen möglichen Stellen im System hat, aber
langsam wird es.
Ja, aber leider haben die Entwickler sehr die Entwicklerbrille auf,
das ist alles ein Tool das die Bedürfnisse derjenigen, die die Regeln
schreiben, ziemlich vernachlässigt. Auch die Diskussionen in der
Mailingliste machen klar, dass es den Entwicklern eher wichtig ist,
dass der Kernel mit großen Regelwerken und unter höchster Last
effiizent mit dem Regelwerk umgehen kann. Das ist auch wichtig, aber
am Ende ist es halt blöd wenn dafür die Menschen mit einer
umständlichen und fehleranfälligen Notation umgehen müssen.
Post by Ralph Aichinger
Post by Marc Haber
Beispiel ferm.
Ich habe früher auch ferm verwendet, aber gerade das geht mir bei
nftables nicht wirklich ab, weil sich die nftables-Syntax eh sehr stark
an ferm anlehnt. Mag sein, dass ich nicht viele der advanced features
von ferm verwendet habe, aber aktuell geht mir bei nftables nix ab.
Mir fehlen subchains und der transparente Umgang mit gemischten
Adressen. In ferm kann ich für einen HOstnamen IPv4 und IPv6 Adressen
nebeneinander schreiben und wenn ich eien Regel für den Hostnamen
schreibe fällt da unten halt eine Regel für IPv4 und eine für IPv6
raus.
Post by Ralph Aichinger
Post by Marc Haber
Mit nftables ist insbesondere das Schreiben von dualstack-Regelwerken
echt schmerzhaft.
Jein, das mag sein, leider ist mein Dualstack-Regelwerk im v6-Teil
komplett unterschiedlich vom v4-Teil, beispielsweise weil v6
kein NAT braucht, dafür durch die großzügigere Verfügbarkeit von
Netzen ein sinnvolleres auftrennen in DMZs ermöglicht.
Meine Regelwerke für die einfacheren Netze (und das sind doch ehrlich
gesagt die meisten) sind ziemlich kongruent für beide Protokollsuiten.
Das NAT für IPv4 kann man unabhängig von den Filterregeln schreiben.

Grüße
Marc
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
Christian Garbs
2024-02-22 20:15:03 UTC
Permalink
Mahlzeit!
Post by Marc Haber
Mir fehlen subchains und der transparente Umgang mit gemischten
Adressen. In ferm kann ich für einen HOstnamen IPv4 und IPv6 Adressen
nebeneinander schreiben und wenn ich eien Regel für den Hostnamen
schreibe fällt da unten halt eine Regel für IPv4 und eine für IPv6
raus.
Ich hab schon wieder vergessen, wie das mit iptables genau war.
Zumindest sowas ähnliches wie Subchains geht, vermutlich sind da aber
irgendwo Unterschiede im Detail.

Ich habe hier das "hübsche" Reject (statt kommentarlosem Drop) in eine
Subchain ausgelagert, um eine Code-Doppelung zu vermeiden. Ich rufe
die Sub-Chain dann am Ende sowohl der forward- als auch der
input-chain auf, um ein "reject all other" zu realisieren, bevor
"policy drop" zum Tragen kommt:

#v+
table inet filter {

chain input {
type filter hook input priority 0; policy drop;

[…]

# reject statt drop
jump reject_if_possible
}

chain forward {
type filter hook forward priority 0; policy drop;

[…]

# reject statt drop
jump reject_if_possible
}

chain reject_if_possible {
counter reject with tcp reset comment "reject/tcp"
counter reject with icmpx type port-unreachable comment "reject/icmp unreachable"
counter comment "reject/drop"
}
}
#v-

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de
Und nun etwas Mathematik:
Wenn Du vier Wecker hast, die um acht Uhr klingeln sollen,
auf welche Zeit musst Du sie dann stellen?
Marc Haber
2024-02-23 09:23:41 UTC
Permalink
Post by Christian Garbs
Post by Marc Haber
Mir fehlen subchains und der transparente Umgang mit gemischten
Adressen. In ferm kann ich für einen HOstnamen IPv4 und IPv6 Adressen
nebeneinander schreiben und wenn ich eien Regel für den Hostnamen
schreibe fällt da unten halt eine Regel für IPv4 und eine für IPv6
raus.
Ich hab schon wieder vergessen, wie das mit iptables genau war.
Zumindest sowas ähnliches wie Subchains geht, vermutlich sind da aber
irgendwo Unterschiede im Detail.
In ferm kann man sowas schreiben wie

interaface vlan104 subchain vlan104-in {
regeln
regeln
regeln
}

und damit automatisch implizit eine Subchain erzeugen. Das ist
hochpraktisch, weil die Regeln im menschenlesbaren Regelwerk an der
richtigen Stelle stehen und es trotzdem so im kernel ankommt dass
dieser halbwegs effizient arbeiten kann.

ferm wird von vielen Leuten als iptables-Makroassembler verballhornt.
Genau das ist es auch. Aber genau das ist ja gerade das praktische
daran.

nft ist da Jahre hinterher, obwohl die Notation so ähnlich ist. nft
ist ein Tool von Entwicklern, die nicht wirklich daran gedacht haben,
dass Regeln manchmal auch von Menschen geschrieben werden.

Grüße
Marc
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
Friedemann Stoyan
2024-02-20 12:10:08 UTC
Permalink
Post by Marc Haber
Mit nftables ist insbesondere das Schreiben von dualstack-Regelwerken
echt schmerzhaft.
Aber es gibt dort ja extra den Type "inet", welcher auf V4 und V6 matcht. Das
ist schon einfacher, finde ich.

mfg Friedemann
Marc Haber
2024-02-20 12:57:17 UTC
Permalink
Post by Friedemann Stoyan
Post by Marc Haber
Mit nftables ist insbesondere das Schreiben von dualstack-Regelwerken
echt schmerzhaft.
Aber es gibt dort ja extra den Type "inet", welcher auf V4 und V6 matcht. Das
ist schon einfacher, finde ich.
Magst Du mir mal ein Beispiel geben?

in ferm schreibst Du (Syntaxvermutlich unrichtig)

@h_meinhost=(192.0.2.1 2001:db8::1)

daddr @h_meinhost proto tcp dport 22 ALLOW

Grüße
Marc
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
Kay Martinen
2024-02-21 13:25:28 UTC
Permalink
Post by Marc Haber
Post by Friedemann Stoyan
Post by Marc Haber
Mit nftables ist insbesondere das Schreiben von dualstack-Regelwerken
echt schmerzhaft.
Aber es gibt dort ja extra den Type "inet", welcher auf V4 und V6 matcht. Das
ist schon einfacher, finde ich.
Magst Du mir mal ein Beispiel geben?
in ferm schreibst Du (Syntaxvermutlich unrichtig)
@h_meinhost=(192.0.2.1 2001:db8::1)
Folgendes Beispiel: Eine SSID soll nur Basisdienste bekommen (V4+V6), nichts
table inet main_filter {
chain input {
# SSID besuch: only basic services (DNS, DHCP, DNSoverTLS)
iifname $SSID_BESUCH meta l4proto { tcp, udp } th dport != { 53, 67, 547, 853 } counter log group 1 prefix "Besuch" queue-threshold 8 snaplen 9000 goto t_reject
}
}
Ob das jetzt auch mit beiden Adressfamilien geht, in einer Zeile, da bin ich
mir jetzt unsicher. Aber auf alle Fälle kann man UDP/TCP für V4 und für V6 in
einer Zeile abfrühstücken.
Leider funktioniert da aber bei Sets nicht (wie ja nebenan bemerkt). Das Set
möchte ja bei der Definition genau wissen, welcher Adresstype da genutzt
werden soll.
Ich kenne mich da leider nicht aus, aber mir fällt auf das du oben bei
Table 'inet' stehen hast und drunter 'l4proto'. Fräge wäre ob es statt
l4proto auch mit 'inet' ginge und das dann v4 und v6 inkludiert, oder ob
es auch l6proto gibt - oder eines das z.B. 'l4+6proto' wäre. Quasi
beides zusammen. Eine IP sehe ich da ja nicht, nur ports und die dürften
auf beiden Adressfamilien eher gleich sein oder?


Bye/
/Kay
--
nix
Friedemann Stoyan
2024-02-21 16:54:36 UTC
Permalink
Post by Kay Martinen
table inet main_filter {
chain input {
# SSID besuch: only basic services (DNS, DHCP, DNSoverTLS)
iifname $SSID_BESUCH meta l4proto { tcp, udp } th dport != { 53, 67, 547, 853 } counter log group 1 prefix "Besuch" queue-threshold 8 snaplen 9000 goto t_reject
}
}
Ich kenne mich da leider nicht aus, aber mir fällt auf das du oben bei
Table 'inet' stehen hast und drunter 'l4proto'. Fräge wäre ob es statt
l4proto auch mit 'inet' ginge und das dann v4 und v6 inkludiert, oder ob
es auch l6proto gibt - oder eines das z.B. 'l4+6proto' wäre. Quasi
beides zusammen. Eine IP sehe ich da ja nicht, nur ports und die dürften
auf beiden Adressfamilien eher gleich sein oder?
Ich verstehe nicht so ganz, was Du fragen möchtest. Du brauchst die "meta
l4proto"-Direktive, damit Du später auf den Transportheader "th" filtern
kannst. Du kannst ja gerne mal experimentieren. Ich habe nichts anderes
gefunden, was in einer Zeile genau das tut.


mfg Friedemann
Christian Garbs
2024-02-22 20:24:38 UTC
Permalink
Mahlzeit!
Post by Friedemann Stoyan
Post by Kay Martinen
table inet main_filter {
chain input {
# SSID besuch: only basic services (DNS, DHCP, DNSoverTLS)
iifname $SSID_BESUCH meta l4proto { tcp, udp } th dport != { 53, 67, 547, 853 } counter log group 1 prefix "Besuch" queue-threshold 8 snaplen 9000 goto t_reject
}
}
Ich kenne mich da leider nicht aus, aber mir fällt auf das du oben
bei Table 'inet' stehen hast und drunter 'l4proto'. Fräge wäre ob
es statt l4proto auch mit 'inet' ginge und das dann v4 und v6
inkludiert, oder ob es auch l6proto gibt - oder eines das
z.B. 'l4+6proto' wäre. Quasi beides zusammen. Eine IP sehe ich da
ja nicht, nur ports und die dürften auf beiden Adressfamilien eher
gleich sein oder?
Ich verstehe nicht so ganz, was Du fragen möchtest. Du brauchst die
"meta l4proto"-Direktive, damit Du später auf den Transportheader
"th" filtern kannst. Du kannst ja gerne mal experimentieren. Ich
habe nichts anderes gefunden, was in einer Zeile genau das tut.
Ist das mit dem Transportheader eine Sondergeschichte wegen WLAN?
Verschachtelte Protokolle oder so?

Ich habe am Server nur ein Ethernetkabel, alles was vom Router (der
macht das WLAN) kommt, filtere ich dort so:

#v+
# http, SSH Portmap Samba___ […]
define accept_tcp_ports = { http, ssh, 111, 139, 445, ... }

# Portmap NFS mountd […]
define accept_udp_ports = { 111, 2049, 2050, ... }


table inet filter {
chain input {
# […]

# open external ports
tcp dport $accept_tcp_ports accept
udp dport $accept_udp_ports accept

# allow DHCPv6
ip6 nexthdr udp udp dport dhcpv6-client udp sport dhcpv6-server accept

# […]
}
}
#v-

Das "tcp dport" und "udp dport" wirken sowohl auf IPv4 als auch auf
IPv6.

Rührt das Problem daher, dass Du udp+tcp in einer Zeile abwickeln
willst? Vielleicht lohnt es ja, das zu trennen. DHCP über TCP ist
glaube ich eher ungewöhnlich ;-)

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de
A day without sunshine is like night.
Stefan+ (Stefan Froehlich)
2024-02-20 14:54:56 UTC
Permalink
Post by Friedemann Stoyan
Post by Marc Haber
Mit nftables ist insbesondere das Schreiben von
dualstack-Regelwerken echt schmerzhaft.
Aber es gibt dort ja extra den Type "inet", welcher auf V4 und V6
matcht. Das ist schon einfacher, finde ich.
Dort, wo ich es gerne hätte, fehlt es. Einer der Hauptpunkte, für
die ich nft verwende sind ein paar sets, die von fail2ban befüllt
werden (das Beste aus beiden Welten: Ein Regelverstoß irgendwo
bewirkt eine sich selbst verlängernde Sperre für den gesamten
Traffic). Und diese sets muss ich nun jeweils für IPv4 und IPv6
getrennt definieren, weil sich das dort nicht mischen lässt.

(Eine Skriptsprache, die mir das abnimmt, fände ich btw nur marginal
besser, ich hätte das gerne direkt in den Sets implementiert)

Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Zittern in Ewigkeit - Stefan!
(Sloganizer)
Marc Haber
2024-02-20 18:05:19 UTC
Permalink
Post by Stefan+ (Stefan Froehlich)
Dort, wo ich es gerne hätte, fehlt es. Einer der Hauptpunkte, für
die ich nft verwende sind ein paar sets, die von fail2ban befüllt
werden (das Beste aus beiden Welten: Ein Regelverstoß irgendwo
bewirkt eine sich selbst verlängernde Sperre für den gesamten
Traffic). Und diese sets muss ich nun jeweils für IPv4 und IPv6
getrennt definieren, weil sich das dort nicht mischen lässt.
(Eine Skriptsprache, die mir das abnimmt, fände ich btw nur marginal
besser, ich hätte das gerne direkt in den Sets implementiert)
Dennoch finde ich python-nftables schon die reizvollste Lösung.

Grüße
Marc
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
Christian Garbs
2024-02-22 20:38:52 UTC
Permalink
Mahlzeit!
Post by Stefan+ (Stefan Froehlich)
Post by Friedemann Stoyan
Post by Marc Haber
Mit nftables ist insbesondere das Schreiben von
dualstack-Regelwerken echt schmerzhaft.
Aber es gibt dort ja extra den Type "inet", welcher auf V4 und V6
matcht. Das ist schon einfacher, finde ich.
Dort, wo ich es gerne hätte, fehlt es. Einer der Hauptpunkte, für
die ich nft verwende sind ein paar sets, die von fail2ban befüllt
werden (das Beste aus beiden Welten: Ein Regelverstoß irgendwo
bewirkt eine sich selbst verlängernde Sperre für den gesamten
Traffic). Und diese sets muss ich nun jeweils für IPv4 und IPv6
getrennt definieren, weil sich das dort nicht mischen lässt.
Hast Du da eine Sonderkonfiguration mit den Sets, so dass nftables das
an eine ganz bestimmte Stelle im Regelwerk schreiben muss?

Ich habe in meiner /etc/nftables.conf für fail2ban eine eigene Table
eingerichtet, die ist initial leer:

#v+
table inet fail2ban {
chain INPUT {
type filter hook input priority 100;
}
}
#v-

Alles weitere richtet sich fail2ban dann selbständig ein, wenn es die
ersten IPs blockt. Es erzeugt dabei getrennte Sets und Regeln für
IPv4 und IPv6, aber das macht es alleine, da soll es ruhig zwei
verschiedene Regeln anlegen, das stört mich ja nicht.

Gerade habe ich extra eine Sperre über IPv6 provoziert, damit ich das
auch mal sehe (die Script-Kiddies scheinen den Server ausschließlich
über IPv4 abzuklopfen). So sieht es aktuell aus (verkürzt und
anonymisiert):

#v+
table inet f2b-table {
set addr-set-sshd {
type ipv4_addr
elements = { xx.xxx.xx.xx, xx.xxx.xx.xx,
xxx.xx.xxx.xx }
}

set addr6-set-sshd {
type ipv6_addr
elements = { xxxx:xxx:xxx:xxxx::x }
}

chain f2b-chain {
type filter hook input priority filter - 1; policy accept;
tcp dport 22 ip saddr @addr-set-sshd reject with icmp port-unreachable
tcp dport 22 ip6 saddr @addr6-set-sshd reject with icmpv6 port-unreachable
}
}
#v-


ÖHEM, das ist ja eine andere Table als ich vorher angegeben habe… Der
richtet sich wohl ALLES selber ein. Da kann ich meine
selbstdefinierte Table "fail2ban" auch wieder löschen :)


Disclaimer: Ich bin nicht firm in fail2ban, ich habe das vor Jahren
einmalig eingerichtet und seitdem läuft das vor sich hin. (Wie man
sieht mit unnötiger Konfiguration.)

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de
Is your homepage Y2K compliant? Pipe it through "tr 'yY' 'kK'" to make sure.
Stefan+ (Stefan Froehlich)
2024-02-23 12:41:56 UTC
Permalink
Post by Christian Garbs
Post by Stefan+ (Stefan Froehlich)
Aber es gibt [in nft] ja extra den Type "inet", welcher auf V4
und V6 matcht. Das ist schon einfacher, finde ich.
Dort, wo ich es gerne hätte, fehlt es. Einer der Hauptpunkte, für
die ich nft verwende sind ein paar sets, die von fail2ban befüllt
werden (das Beste aus beiden Welten: Ein Regelverstoß irgendwo
bewirkt eine sich selbst verlängernde Sperre für den gesamten
Traffic). Und diese sets muss ich nun jeweils für IPv4 und IPv6
getrennt definieren, weil sich das dort nicht mischen lässt.
Hast Du da eine Sonderkonfiguration mit den Sets, so dass nftables
das an eine ganz bestimmte Stelle im Regelwerk schreiben muss?
Die Verbindung von fail2ban und iptables/nft ist bei mir eine
komplette Sonderkonfiguration, weil mir die ursprüngliche,
vorgefertigte Action nicht gefallen hat (AFAIK hat sich fail2ban um
die Dauer der Sperre gekümmert, anstatt das iptables tun zu lassen,
wo das IMO strukturell hingehört - keine Ahnung, ob das inzwischen
besser ist).
Post by Christian Garbs
Ich habe in meiner /etc/nftables.conf für fail2ban eine eigene
Table eingerichtet, die ist initial leer: [...]
...und wird gar nicht benötigt, wie sich im weiteren Verlauf gezeigt
hat :-)
Post by Christian Garbs
#v+
table inet f2b-table {
set addr-set-sshd {
type ipv4_addr
elements = { xx.xxx.xx.xx, xx.xxx.xx.xx,
xxx.xx.xxx.xx }
}
set addr6-set-sshd {
type ipv6_addr
elements = { xxxx:xxx:xxx:xxxx::x }
}
chain f2b-chain {
type filter hook input priority filter - 1; policy accept;
}
}
#v-
Ja, das ist immer noch so, wie ich es von damals im Kopf hatte.
Nicht schlecht, aber halt eher konservativ. Meine Blacklist sieht so
aus (IPv4 sinngemäß ident):

#v+
set blacklist_v6 {
type ipv6_addr
size 1024
timeout 1h
elements = { [...] }
}

chain input {
[...]
ip6 saddr @blacklist_v6 update @blacklist_v6 { ip6 saddr } jump reject_or_drop
[...]
}

#v-

...und fail2ban ist so konfiguriert, dass jeder Regelverstoß einfach
nur in blacklist_v[46] eingetragen und der Ban sofort danach wieder
aufgehoben wird.

Das ist halt die brachiale Variante - klopfe einmal auf Port 4711
an, und die Maschine ist solange nicht mehr für Dich erreichbar, bis
eine Stunde lang kein Zugriff mehr erfolgt. Das hält die
allermeisten Hosts dauerhaft fern; nur ein paar tasten sich
mit inkrementell wachsenden Zeitintervallen an das Limit heran und
probieren dann im Stundentakt irgendwelche Dinge. Wenn nftables
nicht nur fixe, sondern auch noch je Verbindung exponentiell
wachsende Timouts könnte, wäre ich die auch noch los, aber... naja,
so viele sind es nicht.
Post by Christian Garbs
Disclaimer: Ich bin nicht firm in fail2ban, ich habe das vor
Jahren einmalig eingerichtet und seitdem läuft das vor sich hin.
Das ist im Grund genommen hier nicht anders, bloß handgestrickt.

Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan, so weiss wie das Leben. Albern ist superb.
(Sloganizer)
Christian Garbs
2024-03-06 08:23:14 UTC
Permalink
Mahlzeit!
Post by Stefan+ (Stefan Froehlich)
Die Verbindung von fail2ban und iptables/nft ist bei mir eine
komplette Sonderkonfiguration, weil mir die ursprüngliche,
vorgefertigte Action nicht gefallen hat (AFAIK hat sich fail2ban um
die Dauer der Sperre gekümmert, anstatt das iptables tun zu lassen,
wo das IMO strukturell hingehört - keine Ahnung, ob das inzwischen
besser ist).
Zumindest in Debian stable ist das noch so: Es gibt ein Set an
gesperrten IPs, fail2ban legt die Regeln dazu an und kümmert sich um
die Verwaltung des Sets, inklusive Timeout.
Post by Stefan+ (Stefan Froehlich)
Ja, das ist immer noch so, wie ich es von damals im Kopf hatte.
Nicht schlecht, aber halt eher konservativ. Meine Blacklist sieht so
#v+
set blacklist_v6 {
type ipv6_addr
size 1024
timeout 1h
elements = { [...] }
}
chain input {
[...]
[...]
}
#v-
...und fail2ban ist so konfiguriert, dass jeder Regelverstoß einfach
nur in blacklist_v[46] eingetragen und der Ban sofort danach wieder
aufgehoben wird.
Interessant – das mit dem Timeout kannte ich noch gar nicht, da hat
sich der Thread ja schon gelohnt.

Man könnte jetzt argumentieren "aber wenn fail2ban sofort wieder
erlaubt, kannst Dir das ja gar nicht mitteilen, was gerade alles
gesperrt ist!"
Aber da fail2ban das sowieso nicht ordentlich kann und man sich da
selbst ein Skript für schreiben muss, ist das kein Verlust ;-)

Danke und Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de
"Das Usenet stumpft ab!"
"Och, sooo schlimm ist es nun auch nicht."
Stefan+ (Stefan Froehlich)
2024-03-06 11:01:24 UTC
Permalink
Post by Christian Garbs
Post by Stefan+ (Stefan Froehlich)
Die Verbindung von fail2ban und iptables/nft ist bei mir eine
komplette Sonderkonfiguration, weil mir die ursprüngliche,
vorgefertigte Action nicht gefallen hat (AFAIK hat sich fail2ban
um die Dauer der Sperre gekümmert, anstatt das iptables tun zu
lassen, wo das IMO strukturell hingehört - keine Ahnung, ob das
inzwischen besser ist).
Zumindest in Debian stable ist das noch so: Es gibt ein Set an
gesperrten IPs, fail2ban legt die Regeln dazu an und kümmert sich
um die Verwaltung des Sets, inklusive Timeout.
Ok, ja. Aus der Sicht von fail2ban ist das auch völlig logisch, weil
es sich für die gesamte Verwaltung der Sperren zuständig fühlt und
es ja andere, mögliche Actions gibt (die ich nicht nutze).

Ich hatte nftables (bzw. damals noch iptables) halt schon vor
fail2ban mit solchen Blacklists im Einsatz und empfand es als
naheliegend, die als gemeinsames Zentrum zu benutzen. Die zugehörige
Action ist trivial:

#v+
actioncheck = <nftables> list set <nftables_family> <nftables_table> <nftables_set>
actionban = <nftables> add element <nftables_family> <nftables_table> <nftables_set> { <ip> }

[Init]

nftables = nft
nftables_family = inet
nftables_table = filter
nftables_set = blacklist_v4

[Init?family=inet6]

nftables = nft
nftables_family = inet
nftables_table = filter
nftables_set = blacklist_v6
#v-
Post by Christian Garbs
Man könnte jetzt argumentieren "aber wenn fail2ban sofort wieder
erlaubt, kannst Dir das ja gar nicht mitteilen, was gerade alles
gesperrt ist!" Aber da fail2ban das sowieso nicht ordentlich kann
und man sich da selbst ein Skript für schreiben muss, ist das kein
Verlust ;-)
Besser noch, man kann mit:

$ nft list set inet filter blacklist_v4

...jederzeit nachsehen, wer sich in der Liste befindet und das set
im Notfall auch selber anpassen. Die Idee dahinter ist halt immer,
dass nftables das führende System und fail2ban nur (einer) der
Zuträger ist.

Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Begast und doch grün?! Stefan - immer wenn's Spaß gibt.
(Sloganizer)
Tim Ritberg
2024-02-20 09:28:08 UTC
Permalink
Post by Andreas Kohlbach
Das alte Debian hat iptables Aufrufe von mir in /etc/rc.local
bekommen. Wurde mir mal vor über 10 Jahren empfohlen.
Da das nicht der "beste" Ort sein kann, suchte ich und fand Seiten, die
/etc/iptables/rules.v4 empfahlen. Ich habe das Verzeichnis iptables und
die Datei rules.v4 selbst angelegt, und die iptables Zeile per Zeile dort
eingetragen.
Nach dem Booten aber wurden die Werte nicht übernommen. Dazu wurde der
Inhalt der Datei modifiziert. Und meine Einträge sind dort nicht mehr.
Wo trage ich in Debian die iptables-Zeilen ein?
Wie schon angesprochen netfilter-persistent. Das Teil kann auch IPsets
speichern.

Tim
Loading...