Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
DynDNS und Paketfilter (nftables/iptables) (was: Debian 11: nft startet zu zeitig)
56 views
Skip to first unread message
Paul Muster
Jun 7, 2021, 1:02:03 PM6/7/21
to
Am 07.06.2021 um 18:11 schrieb Tim Ritberg:
> Am 07.06.21 um 15:20 schrieb Paul Muster:
>> Am 07.06.2021 um 14:29 schrieb Tim Ritberg:
>>> Am 07.06.21 um 13:01 schrieb Marc Haber:
>>>> Was erwartest Du von einem Paketfilter im Bereich dyndns?
>>> Den Hostmamen neu auflösen.
>> Hmm, ob sich dafür _jemals_ _irgendein_ Paketfilter(entwickler)
>> verantwortlich fühlen wird?
> Einen Resolver gibts im Kernel schon.
Ach, das übernimmt doch auch systemd. *SCNR*
>> Und wie oft soll deiner Meinung nach ein DNS-Name neu aufgelöst und
>> das Regelwerk angepasst werden? Soll der Paketfilter selbst die
>> DNS-Auflösung durchführen, sich die TTL merken und nach deren Ablauf
>> neu auflösen? Und ist der eigentliche Paketfilter nicht tief im Kernel
>> drin und wird nur von außen mit Regeln "betankt", müsste (bzw. könnte)
>> also ein externes Tool die Auflösung vornehmen und die Regeln
>> aktualisieren?
> Als nft neu rauskam, hieß es, das würde gehen, war wohl eine Ente.
Mal im Ernst: Ist es nicht ca. 2-3 Std Arbeit, hierfür ein Skript zu
bauen, das die Regeln (über welches Interface auch immer - iptables,
nftables, ...) aktualisiert? Mir ist gerade nicht klar, was das Problem
sein soll.
mfG Paul
> Am 07.06.21 um 15:20 schrieb Paul Muster:
>> Am 07.06.2021 um 14:29 schrieb Tim Ritberg:
>>> Am 07.06.21 um 13:01 schrieb Marc Haber:
>>>> Was erwartest Du von einem Paketfilter im Bereich dyndns?
>>> Den Hostmamen neu auflösen.
>> Hmm, ob sich dafür _jemals_ _irgendein_ Paketfilter(entwickler)
>> verantwortlich fühlen wird?
> Einen Resolver gibts im Kernel schon.
Ach, das übernimmt doch auch systemd. *SCNR*
>> Und wie oft soll deiner Meinung nach ein DNS-Name neu aufgelöst und
>> das Regelwerk angepasst werden? Soll der Paketfilter selbst die
>> DNS-Auflösung durchführen, sich die TTL merken und nach deren Ablauf
>> neu auflösen? Und ist der eigentliche Paketfilter nicht tief im Kernel
>> drin und wird nur von außen mit Regeln "betankt", müsste (bzw. könnte)
>> also ein externes Tool die Auflösung vornehmen und die Regeln
>> aktualisieren?
> Als nft neu rauskam, hieß es, das würde gehen, war wohl eine Ente.
Mal im Ernst: Ist es nicht ca. 2-3 Std Arbeit, hierfür ein Skript zu
bauen, das die Regeln (über welches Interface auch immer - iptables,
nftables, ...) aktualisiert? Mir ist gerade nicht klar, was das Problem
sein soll.
mfG Paul
Paul Muster
Jun 7, 2021, 2:22:03 PM6/7/21
to
On 07.06.21 19:32, Marc Haber wrote:
> Ich würde vermutlich mit einem Userspace-Daemon alle n Minuten
> abfragen ob sich der DNS-Eintrag geändert hat und dann den Paketfilter
> neu bauen.
Genau.
Bei iptables würde man mit -N <chain> eine eigene chain erstellen, in
dieser sehr gezielt mit -I <chain> <rulenum> ... eine bestimmte Position
für die betreffende Regel wählen und mit -R <chain> <rulenum> ... *genau
diese* Regel ändern.
Geht bei nftables sicherlich ähnlich.
<https://wiki.nftables.org/wiki-nftables/index.php/Simple_rule_management#Replacing_rules>
mfG Paul
> Ich würde vermutlich mit einem Userspace-Daemon alle n Minuten
> abfragen ob sich der DNS-Eintrag geändert hat und dann den Paketfilter
> neu bauen.
Genau.
Bei iptables würde man mit -N <chain> eine eigene chain erstellen, in
dieser sehr gezielt mit -I <chain> <rulenum> ... eine bestimmte Position
für die betreffende Regel wählen und mit -R <chain> <rulenum> ... *genau
diese* Regel ändern.
Geht bei nftables sicherlich ähnlich.
<https://wiki.nftables.org/wiki-nftables/index.php/Simple_rule_management#Replacing_rules>
mfG Paul
Marc Haber
Jun 8, 2021, 1:52:09 AM6/8/21
to
Paul Muster <exp-3...@news.muster.net> wrote:
>On 07.06.21 19:32, Marc Haber wrote:
>> Ich würde vermutlich mit einem Userspace-Daemon alle n Minuten
>> abfragen ob sich der DNS-Eintrag geändert hat und dann den Paketfilter
>> neu bauen.
>
>Genau.
>
>Bei iptables würde man mit -N <chain> eine eigene chain erstellen, in
>dieser sehr gezielt mit -I <chain> <rulenum> ... eine bestimmte Position
>für die betreffende Regel wählen und mit -R <chain> <rulenum> ... *genau
>diese* Regel ändern.
Ich verwende ferm und würde einfach das Regelwerk neu bauen. ferm
>On 07.06.21 19:32, Marc Haber wrote:
>> Ich würde vermutlich mit einem Userspace-Daemon alle n Minuten
>> abfragen ob sich der DNS-Eintrag geändert hat und dann den Paketfilter
>> neu bauen.
>
>Genau.
>
>Bei iptables würde man mit -N <chain> eine eigene chain erstellen, in
>dieser sehr gezielt mit -I <chain> <rulenum> ... eine bestimmte Position
>für die betreffende Regel wählen und mit -R <chain> <rulenum> ... *genau
>diese* Regel ändern.
erzeugt eine iptables-save Datei und prügelt die mit iptables-restore
atomar in den kernel hinein.
Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Sven Hartge
Jun 8, 2021, 2:44:17 AM6/8/21
to
Paul Muster <exp-3...@news.muster.net> wrote:
> On 07.06.21 19:32, Marc Haber wrote:
>> Ich würde vermutlich mit einem Userspace-Daemon alle n Minuten
>> abfragen ob sich der DNS-Eintrag geändert hat und dann den
>> Paketfilter neu bauen.
> Genau.
> Bei iptables würde man mit -N <chain> eine eigene chain erstellen, in
> dieser sehr gezielt mit -I <chain> <rulenum> ... eine bestimmte
> Position für die betreffende Regel wählen und mit -R <chain> <rulenum>
> ... *genau diese* Regel ändern.
Ich würde das via "ipset" machen, weil sich das aus Kernelsicht
> On 07.06.21 19:32, Marc Haber wrote:
>> Ich würde vermutlich mit einem Userspace-Daemon alle n Minuten
>> abfragen ob sich der DNS-Eintrag geändert hat und dann den
>> Paketfilter neu bauen.
> Genau.
> Bei iptables würde man mit -N <chain> eine eigene chain erstellen, in
> dieser sehr gezielt mit -I <chain> <rulenum> ... eine bestimmte
> Position für die betreffende Regel wählen und mit -R <chain> <rulenum>
> ... *genau diese* Regel ändern.
einfacher ändern läßt, ohne dass intern der Regelsatz neu kompiliert
werden muss.
S°
--
Sigmentation fault. Core dumped.
Paul Muster
Jun 8, 2021, 3:22:02 AM6/8/21
to
Naja, welcher Ansatz am besten passt, hängt davon ab, was genau Tim
vorhat. Da müsste er sich halt mal äußern.
mfG Paul
Sven Hartge
Jun 8, 2021, 10:20:59 AM6/8/21
to
Paul Muster <exp-3...@news.muster.net> wrote:
> Am 08.06.2021 um 08:44 schrieb Sven Hartge:
>> Paul Muster <exp-3...@news.muster.net> wrote:
>>> On 07.06.21 19:32, Marc Haber wrote:
>>>> Ich würde vermutlich mit einem Userspace-Daemon alle n Minuten
>>>> abfragen ob sich der DNS-Eintrag geändert hat und dann den
>>>> Paketfilter neu bauen.
>>
>>> Genau.
>>
>>> Bei iptables würde man mit -N <chain> eine eigene chain erstellen,
>>> in dieser sehr gezielt mit -I <chain> <rulenum> ... eine bestimmte
>>> Position für die betreffende Regel wählen und mit -R <chain>
>>> <rulenum> ... *genau diese* Regel ändern.
>>
>> Ich würde das via "ipset" machen, weil sich das aus Kernelsicht
>> einfacher ändern läßt, ohne dass intern der Regelsatz neu kompiliert
>> werden muss.
> Was es alles gibt. *staun*
ipset lohnt sich vor allem für sehr sehr große Regelsätze, die sich ohne
> Am 08.06.2021 um 08:44 schrieb Sven Hartge:
>> Paul Muster <exp-3...@news.muster.net> wrote:
>>> On 07.06.21 19:32, Marc Haber wrote:
>>>> Ich würde vermutlich mit einem Userspace-Daemon alle n Minuten
>>>> abfragen ob sich der DNS-Eintrag geändert hat und dann den
>>>> Paketfilter neu bauen.
>>
>>> Genau.
>>
>>> Bei iptables würde man mit -N <chain> eine eigene chain erstellen,
>>> in dieser sehr gezielt mit -I <chain> <rulenum> ... eine bestimmte
>>> Position für die betreffende Regel wählen und mit -R <chain>
>>> <rulenum> ... *genau diese* Regel ändern.
>>
>> Ich würde das via "ipset" machen, weil sich das aus Kernelsicht
>> einfacher ändern läßt, ohne dass intern der Regelsatz neu kompiliert
>> werden muss.
> Was es alles gibt. *staun*
großen CPU-Einsatz ändern können sollen und sind effizent für das
schnelle Matchen von Paketen gedacht.
Dinge wie "2.000.000 IP/Port-Kombinationen" sind mit einem ipset kein
Problem, rohes iptables/nft zeigt da schon erste Schwächen.
Dazu kann man jeden Eintrag noch mit einem Timeout versehen, nachdem er
automatisch entfernt wird und schon hat man eine Hälfte von fail2ban
(das Aufräumen der Einträge) in den Kernel verlagert und braucht sich
nicht selbst darum kümmern.
Olaf Jaehrling
Jun 11, 2021, 10:28:48 AM6/11/21
to
Hallo,
Sven Hartge <sh-...@svenhartge.de> wrote:
> Paul Muster <exp-3...@news.muster.net> wrote:
>> Am 08.06.2021 um 08:44 schrieb Sven Hartge:
>>> Paul Muster <
https://www.spinics.net/lists/netfilter/msg59085.html
Gruß
Olaf
Sven Hartge <sh-...@svenhartge.de> wrote:
> Paul Muster <exp-3...@news.muster.net> wrote:
>> Am 08.06.2021 um 08:44 schrieb Sven Hartge:
>>> Paul Muster <
> Dazu kann man jeden Eintrag noch mit einem Timeout versehen, nachdem er
> automatisch entfernt wird und schon hat man eine Hälfte von fail2ban
> (das Aufräumen der Einträge) in den Kernel verlagert und braucht sich
> nicht selbst darum kümmern.
>
> S°
>
Guck dir mal das hier an. Das könnte dein Problem lösen
> automatisch entfernt wird und schon hat man eine Hälfte von fail2ban
> (das Aufräumen der Einträge) in den Kernel verlagert und braucht sich
> nicht selbst darum kümmern.
>
> S°
>
https://www.spinics.net/lists/netfilter/msg59085.html
Gruß
Olaf
Olaf Jaehrling
Jun 11, 2021, 10:40:38 AM6/11/21
to
Nochmal hallo,
Um es mal besser auszudrücken.
IP=`dig +short DYN.DOMAIN`
Danach mitvder updatefunktion das nft-set updaten und schon lotte alles
hübsch sein
Das Script alle 5 Minuten aufrufen. Das passt auch mit dem Updateintervall
der meisten dyn-anbieter zusammen.
Gruß
Olaf
>
> Gruß
>
> Olaf
>
IP=`dig +short DYN.DOMAIN`
Danach mitvder updatefunktion das nft-set updaten und schon lotte alles
hübsch sein
Das Script alle 5 Minuten aufrufen. Das passt auch mit dem Updateintervall
der meisten dyn-anbieter zusammen.
Gruß
Olaf
>
> Gruß
>
> Olaf
>
Tim Ritberg
Jun 12, 2021, 7:12:03 AM6/12/21
to
Am 07.06.21 um 20:14 schrieb Paul Muster:
Sets scheinen wohl der letzte Schrei zu sein:
https://www.putorius.net/ipset-iptables-rules-for-hostname.html
Tim
https://www.putorius.net/ipset-iptables-rules-for-hostname.html
Tim
Günter Frenz
Jun 12, 2021, 8:30:03 AM6/12/21
to
regelmäßig geleert und wieder neu aufgesetzt wurden. Von der Funktion
her sollte das das Gleiche sein, die Frage ist nur die nach der
Effizienz.
Günter
Olaf Jaehrling
Jun 12, 2021, 9:46:03 AM6/12/21
to
Hallo Thomas,
Thomas Noll <-_tn...@web.de> wrote:
> und die Adresse ist bei dig im Payload, nicht im IP-Path, daher geht es auch
> nicht per rule.
Bei mir mache ich das so:
nft add set ip filter DYN "{type ipv4_addr; flags dynamic;}“
OLDIP= nft -a list set ip filter DYN
NEWIP= dig +short domain.de
If $OLDIP != $NEWIP
then
nft flush chain DYN
nft add element ip filter DYN { $NEWIP }
Sorry am Handy gibt es gerade keine Hochkomma. Ihr wisst aber bestimmt was
ich meine.
Achja hier einfach mal die Ausgabe von dig.
dig +short domain.de
188.64.63.43
Das komplette script kann ich frühestens morgen mal posten
Gruß
Olaf
>
>
>
>
Thomas Noll <-_tn...@web.de> wrote:
> Am Fri, 11 Jun 2021 14:40:37 +0000 schrieb Olaf Jaehrling:
>
>
>> Um es mal besser auszudrücken.
>>
>> IP=`dig +short DYN.DOMAIN`
>> Danach mitvder updatefunktion das nft-set updaten und schon lotte alles
>> hübsch sein
>
> Wie möchtest du das machen? Das Kommando nft kennt kein update für Elements,
>
>
>> Um es mal besser auszudrücken.
>>
>> IP=`dig +short DYN.DOMAIN`
>> Danach mitvder updatefunktion das nft-set updaten und schon lotte alles
>> hübsch sein
>
> und die Adresse ist bei dig im Payload, nicht im IP-Path, daher geht es auch
> nicht per rule.
Bei mir mache ich das so:
nft add set ip filter DYN "{type ipv4_addr; flags dynamic;}“
OLDIP= nft -a list set ip filter DYN
NEWIP= dig +short domain.de
If $OLDIP != $NEWIP
then
nft flush chain DYN
nft add element ip filter DYN { $NEWIP }
Sorry am Handy gibt es gerade keine Hochkomma. Ihr wisst aber bestimmt was
ich meine.
Achja hier einfach mal die Ausgabe von dig.
dig +short domain.de
188.64.63.43
Das komplette script kann ich frühestens morgen mal posten
Gruß
Olaf
>
>
>
>
Olaf Jaehrling
Jun 13, 2021, 4:37:08 AM6/13/21
to
Hallo Thomas,
Thomas Noll schrieb am 12.06.21 um 19:10:
> Und um die timeouts _im_ Paketfilter geht es ja.
Du meinst sowas?
set BFBTIMELIST {
type ipv4_addr
flags timeout
elements = { 31.210.21.172 timeout 12h expires
8h20m30s820ms }
}
chain BFBBLOCK {
ip saddr @BFBTIMELIST drop
}
Man muss dann statt drop accept nehmen und dann darf o.g. ip noch 8
Stunden auf den Server zugreifen.
Ich hatte das nur halt nicht so verstanden. Der Threat ist ja nicht ganz
vollständig. :)
Gruß
Olaf
>
Thomas Noll schrieb am 12.06.21 um 19:10:
> Am Sat, 12 Jun 2021 13:46:02 +0000 schrieb Olaf Jaehrling:
>
>
>> Bei mir mache ich das so:
>> [..]
>
>
>> Bei mir mache ich das so:
>>
>> Das komplette script kann ich frühestens morgen mal posten
>>
>
> Nicht nötig. Anscheinend nutzt du keinerlei timeout bei nftables.
>> Das komplette script kann ich frühestens morgen mal posten
>>
>
> Und um die timeouts _im_ Paketfilter geht es ja.
Du meinst sowas?
set BFBTIMELIST {
type ipv4_addr
flags timeout
elements = { 31.210.21.172 timeout 12h expires
8h20m30s820ms }
}
chain BFBBLOCK {
ip saddr @BFBTIMELIST drop
}
Man muss dann statt drop accept nehmen und dann darf o.g. ip noch 8
Stunden auf den Server zugreifen.
Ich hatte das nur halt nicht so verstanden. Der Threat ist ja nicht ganz
vollständig. :)
Gruß
Olaf
>
Sven Hartge
Jun 13, 2021, 1:24:09 PM6/13/21
to
Günter Frenz <usen...@guefz.de> wrote:
> Am Sat, 12 Jun 2021 13:12:01 +0200 schrieb Tim Ritberg:
>> Sets scheinen wohl der letzte Schrei zu sein:
>> https://www.putorius.net/ipset-iptables-rules-for-hostname.html
> Am Sat, 12 Jun 2021 13:12:01 +0200 schrieb Tim Ritberg:
>> Sets scheinen wohl der letzte Schrei zu sein:
>> https://www.putorius.net/ipset-iptables-rules-for-hostname.html
> Ich habe für so etwas bislang Sub-Chains verwendet, die dann per
> Skript regelmäßig geleert und wieder neu aufgesetzt wurden. Von der
> Funktion her sollte das das Gleiche sein, die Frage ist nur die nach
> der Effizienz.
ipsets skalieren enorm gut, das macht sie für enorm große Datenmengen
> Skript regelmäßig geleert und wieder neu aufgesetzt wurden. Von der
> Funktion her sollte das das Gleiche sein, die Frage ist nur die nach
> der Effizienz.
attraktiv bzw. sogar zwingend.
Wenn man eine Subchain mit zwei Regeln hat, die man alle 5 Minuten
ändert, macht sich das nicht bemerkbar.
Wenn die Subchain aber 2.000.000 Regeln beinhaltet, dann sieht das
anders aus.
Plus der ipset-Code ist wesentlich effizienter beim Matchen auf den
Inhalt des ipsets als nft/iptables, welche theoretisch bei einem
Regelset von 2.000.000 Regeln jede Regel einzeln auswerten müssen.
0 new messages