[Debian] iptables Einträge wo speichern?

[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?
--
Andreas

[Paul Muster]

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

[Ralph Aichinger]

Andreas Kohlbach <a...@spamfence.net> wrote:
> 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.

/ralph

[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
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]

Am 20.02.2024 08:59 Uhr schrieb 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 ichschic...@cartoonies.org

[Ralph Aichinger]

Marc Haber <mh+usene...@zugschl.us> wrote:
> 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.

> 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.

> 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]

Marco Moock <mm+s...@dorfdsl.de> wrote:
>Am 20.02.2024 08:59 Uhr schrieb 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.

[Marco Moock]

Am 20.02.2024 09:44 Uhr schrieb 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.

[Marc Haber]

Ralph Aichinger <ra...@pi.h5.or.at> wrote:
>Marc Haber <mh+usene...@zugschl.us> wrote:
>> 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.

>> 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.

>> 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.

[Tim Ritberg]

Am 20.02.24 um 06:05 schrieb Andreas Kohlbach:

Wie schon angesprochen netfilter-persistent. Das Teil kann auch IPsets
speichern.

Tim

[Friedemann Stoyan]

Marc Haber wrote:

> 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

[Friedemann Stoyan]

Marco Moock wrote:

> 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

[Kay Martinen]

Am 20.02.24 um 09:44 schrieb Marc Haber:

> Marco Moock <mm+s...@dorfdsl.de> wrote:
>> Am 20.02.2024 08:59 Uhr schrieb 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?

> Dunkle Winterabende gibt es jetzt erstmal keine.

Mach's Licht aus! :)

Bye/
/Kay

--
nix

[Marc Haber]

Marco Moock <mm+s...@dorfdsl.de> wrote:
>Am 20.02.2024 09:44 Uhr schrieb 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

> damit kannst du dich auch an schönen Tagen Abends
>draußen hinsetzen.

ja, aber dann habe ich besseres zu tun.

[Marc Haber]

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

[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)

Servus,
Stefan

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

Zittern in Ewigkeit - Stefan!
(Sloganizer)

[Friedemann Stoyan]

Marc Haber wrote:
> Friedemann Stoyan <use...@ip6-mail.de> wrote:
>>Marc Haber wrote:
>>> 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

Folgendes Beispiel: Eine SSID soll nur Basisdienste bekommen (V4+V6), nichts
anderes:

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.

mfg Friedemann

[Marc Haber]

Andreas Kohlbach <a...@spamfence.net> wrote:

>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.

[Marc Haber]

Friedemann Stoyan <use...@ip6-mail.de> wrote:
>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.

Und genau das eins der Probleme, ja. Von einem userzentrierten Tool
würde ich erwarten dass es das für mich automatisch macht. Ich muss
das ja nicht nutzen.

[Marc Haber]

Stefan...@Froehlich.Priv.at (Stefan Froehlich) wrote:
>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.

[Marco Moock]

Am 20.02.2024 13:55 Uhr schrieb Marc Haber:

> Marco Moock <mm+s...@dorfdsl.de> wrote:
> >Am 20.02.2024 09:44 Uhr schrieb 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.

> > 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?

[Marco Moock]

Am 20.02.2024 13:35 Uhr schrieb Kay Martinen:

> Am 20.02.24 um 09:44 schrieb Marc Haber:
> > Marco Moock <mm+s...@dorfdsl.de> wrote:
> >> Am 20.02.2024 08:59 Uhr schrieb 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?

> 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.

> > Dunkle Winterabende gibt es jetzt erstmal keine.
>
> Mach's Licht aus! :)

Das hätte bei der Sonne gravierende Auswirkungen.

[Marco Moock]

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.

[Paul Muster]

On 20.02.24 19:03, Marc Haber wrote:
> Andreas Kohlbach <a...@spamfence.net> wrote:

>> 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.

> und bietet auch eine Möglichkeit diesen Prozess manuell
> anzustoßen.

Ja, siehe oben, plus 'dpkg-reconfigure iptables-persistent'.


mfG Paul

[Kay Martinen]

Am 20.02.24 um 17:25 schrieb Friedemann Stoyan:

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]

Kay Martinen wrote:

>>
>> 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

[Marc Haber]

Marco Moock <mm+s...@dorfdsl.de> wrote:
>Am 20.02.2024 13:55 Uhr schrieb Marc Haber:
>
>> Marco Moock <mm+s...@dorfdsl.de> wrote:
>> >Am 20.02.2024 09:44 Uhr schrieb 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.

Das würde ich eher mit VMs machen. Aber haben Zeit.

>> > 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?

DAS möchtest Du wohl gerne wissen. Zwei Abende im Monat sind zum
Beispiel mit der Unix User Group verplant. Da könntest Du vermutlich
auch ganz gut hinpassen. Örtlich nah genug isses ja.