Iptables rule mit -limit-burst auf prefix basis?
Hi,
kann mir jemand dabei helfen eine generische iptables regel zu schreiben, die so einen logspam wie das nachfolgende via --limit-burst filtert? Oder ist es schlicht nicht wirklich gut möglich und trotz des Aufwands einfacher solche Subnetze/Prefixe/ASe manuell in regeln zum herauszufiltern zu gießen?
AS210021 DIL Technology Limited geht mir aktuell bei der Logauswertung echt auf die Nerven. Kaum blockt man einen Prefix von denen kommen die wenige Tage später mit dem nächsten. Und da so ziemlich jeder request von einer anderen IP aus deren Netzen kommt, greifen meine aktuellen generischen Regeln um genau sowas zu filtern und nicht zu loggen nicht mehr...
alternativ (falls auf source subnet/prefix/AS basis nicht geht), kann man eine limit-burst regel auf einen bestimmten DPT spezifisch gruppieren lassen? Sprich wenn ein spezifischer port innerhalb von x Sekunden mehr als y Mal aufgerufen (insb. wenn dahinter nichts läuft) wird, dass dieser zur recent liste hinzugefügt wird (bzw. auch einfach nicht mehr auf die regel zum loggin matcht und direkt auf die Drop regel dahinter durch fällt?
Aktuell habe ich sowas in meinem Regelwerk (abweichende thresholds):
Beispiel log Auszug der Verbindungen die ich gerne filtern möchte:
kann mir jemand dabei helfen eine generische iptables regel zu schreiben, die so einen logspam wie das nachfolgende via --limit-burst filtert? Oder ist es schlicht nicht wirklich gut möglich und trotz des Aufwands einfacher solche Subnetze/Prefixe/ASe manuell in regeln zum herauszufiltern zu gießen?
AS210021 DIL Technology Limited geht mir aktuell bei der Logauswertung echt auf die Nerven. Kaum blockt man einen Prefix von denen kommen die wenige Tage später mit dem nächsten. Und da so ziemlich jeder request von einer anderen IP aus deren Netzen kommt, greifen meine aktuellen generischen Regeln um genau sowas zu filtern und nicht zu loggen nicht mehr...
alternativ (falls auf source subnet/prefix/AS basis nicht geht), kann man eine limit-burst regel auf einen bestimmten DPT spezifisch gruppieren lassen? Sprich wenn ein spezifischer port innerhalb von x Sekunden mehr als y Mal aufgerufen (insb. wenn dahinter nichts läuft) wird, dass dieser zur recent liste hinzugefügt wird (bzw. auch einfach nicht mehr auf die regel zum loggin matcht und direkt auf die Drop regel dahinter durch fällt?
Aktuell habe ich sowas in meinem Regelwerk (abweichende thresholds):
*mangle
-A PREROUTING -i eth0 -m recent --name honeypot --rcheck --seconds 86400 --rttl -m comment --comment "Drop all connections to destinations within the honneypot droplist" -j DROP
*filter
-A LOGDROP -j LOG --log-prefix "iptables: [DROP][filter] "
-A LOGDROP -j DROP -m limit --limit 1000/sec --limit-burst 2000
-A LOGDROP -m recent --name honeypot --set
-A LOGDROP -m recent --name honeypot --rcheck -j LOG --log-prefix "iptables: [Honeypot][filter] adding connection attempt: "
-A LOGDROP -j DROPBeispiel log Auszug der Verbindungen die ich gerne filtern möchte:
Apr 08 14:48:56 srv001.home.arpa kernel: iptables: [REJECT][filter] IN=eth0 OUT= MAC=<<<14-hex-blocks-of-the-gateway>>> SRC=185.206.83.108 DST=<<<myIPv4>>> LEN=44 TOS=0x00 PREC=0x00 TTL=247 ID=45648 DF PROTO=TCP SPT=27772 DPT=443 WINDOW=32768 RES=0x00 SYN URGP=0
Apr 08 14:48:57 srv001.home.arpa kernel: iptables: [REJECT][filter] IN=eth0 OUT= MAC=<<<14-hex-blocks-of-the-gateway>>> SRC=185.206.82.168 DST=<<<myIPv4>>> LEN=44 TOS=0x00 PREC=0x00 TTL=247 ID=47782 DF PROTO=TCP SPT=4334 DPT=443 WINDOW=32768 RES=0x00 SYN URGP=0
Apr 08 14:48:57 srv001.home.arpa kernel: iptables: [REJECT][filter] IN=eth0 OUT= MAC=<<<14-hex-blocks-of-the-gateway>>> SRC=185.206.83.227 DST=<<<myIPv4>>> LEN=44 TOS=0x00 PREC=0x00 TTL=243 ID=41725 DF PROTO=TCP SPT=49098 DPT=443 WINDOW=32768 RES=0x00 SYN URGP=0
Apr 08 14:48:57 srv001.home.arpa kernel: iptables: [REJECT][filter] IN=eth0 OUT= MAC=<<<14-hex-blocks-of-the-gateway>>> SRC=185.206.83.31 DST=<<<myIPv4>>> LEN=44 TOS=0x00 PREC=0x00 TTL=247 ID=43859 DF PROTO=TCP SPT=33823 DPT=443 WINDOW=32768 RES=0x00 SYN URGP=0
Apr 08 14:48:57 srv001.home.arpa kernel: iptables: [REJECT][filter] IN=eth0 OUT= MAC=<<<14-hex-blocks-of-the-gateway>>> SRC=185.206.82.91 DST=<<<myIPv4>>> LEN=44 TOS=0x00 PREC=0x00 TTL=247 ID=45993 DF PROTO=TCP SPT=47012 DPT=443 WINDOW=32768 RES=0x00 SYN URGP=0
Apr 08 14:48:57 srv001.home.arpa kernel: iptables: [REJECT][filter] IN=eth0 OUT= MAC=<<<14-hex-blocks-of-the-gateway>>> SRC=185.206.83.150 DST=<<<myIPv4>>> LEN=44 TOS=0x00 PREC=0x00 TTL=247 ID=48127 DF PROTO=TCP SPT=4152 DPT=443 WINDOW=32768 RES=0x00 SYN URGP=0
Apr 08 14:48:57 srv001.home.arpa kernel: iptables: [REJECT][filter] IN=eth0 OUT= MAC=<<<14-hex-blocks-of-the-gateway>>> SRC=185.206.82.210 DST=<<<myIPv4>>> LEN=44 TOS=0x00 PREC=0x00 TTL=247 ID=42070 DF PROTO=TCP SPT=1237 DPT=443 WINDOW=32768 RES=0x00 SYN URGP=0
Apr 08 14:48:57 srv001.home.arpa kernel: iptables: [REJECT][filter] IN=eth0 OUT= MAC=<<<14-hex-blocks-of-the-gateway>>> SRC=185.206.82.14 DST=<<<myIPv4>>> LEN=44 TOS=0x00 PREC=0x00 TTL=247 ID=44204 DF PROTO=TCP SPT=6489 DPT=443 WINDOW=32768 RES=0x00 SYN URGP=0
Apr 08 14:48:57 srv001.home.arpa kernel: iptables: [REJECT][filter] IN=eth0 OUT= MAC=<<<14-hex-blocks-of-the-gateway>>> SRC=185.206.83.73 DST=<<<myIPv4>>> LEN=44 TOS=0x00 PREC=0x00 TTL=247 ID=46338 DF PROTO=TCP SPT=1823 DPT=443 WINDOW=32768 RES=0x00 SYN URGP=0
Apr 08 14:48:57 srv001.home.arpa kernel: iptables: [REJECT][filter] IN=eth0 OUT= MAC=<<<14-hex-blocks-of-the-gateway>>> SRC=185.206.82.133 DST=<<<myIPv4>>> LEN=44 TOS=0x00 PREC=0x00 TTL=243 ID=48472 DF PROTO=TCP SPT=23237 DPT=443 WINDOW=32768 RES=0x00 SYN URGP=0
Apr 08 14:48:57 srv001.home.arpa kernel: iptables: [REJECT][filter] IN=eth0 OUT= MAC=<<<14-hex-blocks-of-the-gateway>>> SRC=185.206.83.192 DST=<<<myIPv4>>> LEN=44 TOS=0x00 PREC=0x00 TTL=243 ID=42415 DF PROTO=TCP SPT=22648 DPT=443 WINDOW=32768 RES=0x00 SYN URGP=0
Apr 08 14:48:57 srv001.home.arpa kernel: iptables: [REJECT][filter] IN=eth0 OUT= MAC=<<<14-hex-blocks-of-the-gateway>>> SRC=185.206.82.252 DST=<<<myIPv4>>> LEN=44 TOS=0x00 PREC=0x00 TTL=247 ID=44549 DF PROTO=TCP SPT=59979 DPT=443 WINDOW=32768 RES=0x00 SYN URGP=0
Apr 08 14:48:57 srv001.home.arpa kernel: iptables: [REJECT][filter] IN=eth0 OUT= MAC=<<<14-hex-blocks-of-the-gateway>>> SRC=185.206.82.56 DST=<<<myIPv4>>> LEN=44 TOS=0x00 PREC=0x00 TTL=247 ID=46683 DF PROTO=TCP SPT=38790 DPT=443 WINDOW=32768 RES=0x00 SYN URGP=0
Apr 08 14:48:57 srv001.home.arpa kernel: iptables: [REJECT][filter] IN=eth0 OUT= MAC=<<<14-hex-blocks-of-the-gateway>>> SRC=185.206.83.115 DST=<<<myIPv4>>> LEN=44 TOS=0x00 PREC=0x00 TTL=247 ID=48817 DF PROTO=TCP SPT=21520 DPT=443 WINDOW=32768 RES=0x00 SYN URGP=0
Apr 08 14:48:57 srv001.home.arpa kernel: iptables: [REJECT][filter] IN=eth0 OUT= MAC=<<<14-hex-blocks-of-the-gateway>>> SRC=185.206.82.175 DST=<<<myIPv4>>> LEN=44 TOS=0x00 PREC=0x00 TTL=247 ID=42760 DF PROTO=TCP SPT=1788 DPT=443 WINDOW=32768 RES=0x00 SYN URGP=0
Apr 08 14:48:57 srv001.home.arpa kernel: iptables: [REJECT][filter] IN=eth0 OUT= MAC=<<<14-hex-blocks-of-the-gateway>>> SRC=185.206.83.234 DST=<<<myIPv4>>> LEN=44 TOS=0x00 PREC=0x00 TTL=247 ID=44894 DF PROTO=TCP SPT=60864 DPT=443 WINDOW=32768 RES=0x00 SYN URGP=0
Apr 08 14:48:57 srv001.home.arpa kernel: iptables: [REJECT][filter] IN=eth0 OUT= MAC=<<<14-hex-blocks-of-the-gateway>>> SRC=185.206.83.38 DST=<<<myIPv4>>> LEN=44 TOS=0x00 PREC=0x00 TTL=247 ID=47028 DF PROTO=TCP SPT=16860 DPT=443 WINDOW=32768 RES=0x00 SYN URGP=0
Apr 08 14:48:57 srv001.home.arpa kernel: iptables: [REJECT][filter] IN=eth0 OUT= MAC=<<<14-hex-blocks-of-the-gateway>>> SRC=185.206.82.98 DST=<<<myIPv4>>> LEN=44 TOS=0x00 PREC=0x00 TTL=247 ID=40971 DF PROTO=TCP SPT=46270 DPT=443 WINDOW=32768 RES=0x00 SYN URGP=0
Apr 08 14:48:57 srv001.home.arpa kernel: iptables: [REJECT][filter] IN=eth0 OUT= MAC=<<<14-hex-blocks-of-the-gateway>>> SRC=185.206.83.157 DST=<<<myIPv4>>> LEN=44 TOS=0x00 PREC=0x00 TTL=247 ID=43105 DF PROTO=TCP SPT=33408 DPT=443 WINDOW=32768 RES=0x00 SYN URGP=0
Apr 08 14:48:57 srv001.home.arpa kernel: iptables: [REJECT][filter] IN=eth0 OUT= MAC=<<<14-hex-blocks-of-the-gateway>>> SRC=185.206.82.217 DST=<<<myIPv4>>> LEN=44 TOS=0x00 PREC=0x00 TTL=247 ID=45239 DF PROTO=TCP SPT=50944 DPT=443 WINDOW=32768 RES=0x00 SYN URGP=0
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 672393
Url: https://administrator.de/forum/iptables-rule-mit-limit-burst-auf-prefix-basis-672393.html
Ausgedruckt am: 04.05.2025 um 07:05 Uhr
8 Kommentare
Neuester Kommentar
Prefix von was?
Na von den Source IPs, von was sonst??? Dann könnte ich zumindest schon mal bessere regeln zum filtern der logs machen. Um log/no_log Entscheidungen zu treffen sollte ein wenn aus dem gleichen /22, /20, /18, /16, ... in aufsteigender Reihenfolge ausreichen.
Das recent module ist ja "diese IP habe ich schon mal gesehen", suche quasi aktuell was ähnliches nur für prei definierte prefixe, also "dieses /16 habe ich schon mal gesehen".
Geht hier primär um zu verhindern dass so ein Syn-flooding das log zu spammt. Aktuell logge ich halt je source die erste hand voll fehlgeschlagenen Verbindungen. Das ist halt dann nicht mehr ganz zielführend wenn jemand sein ganzes AS verwendet um mit allen IPs aus einem seiner Prefixe da gegen zu gehen.
Die premium lösung wäre in der RIR nachzusehen was das entsprechende delegierte netz ist und das zu sperren, aber sowas gibt es ganz bestimmt nicht nativ :D
Das recent module ist ja "diese IP habe ich schon mal gesehen", suche quasi aktuell was ähnliches nur für prei definierte prefixe, also "dieses /16 habe ich schon mal gesehen".
Geht hier primär um zu verhindern dass so ein Syn-flooding das log zu spammt. Aktuell logge ich halt je source die erste hand voll fehlgeschlagenen Verbindungen. Das ist halt dann nicht mehr ganz zielführend wenn jemand sein ganzes AS verwendet um mit allen IPs aus einem seiner Prefixe da gegen zu gehen.
Die premium lösung wäre in der RIR nachzusehen was das entsprechende delegierte netz ist und das zu sperren, aber sowas gibt es ganz bestimmt nicht nativ :D
classic iptables macht nichts automatisch. Das musst du mir Cron ein Auswerte-Script für das Log schreiben und dann Regeln erzeugen.
Oder du holst dir eine Liste der Netze/ASN (sind ca. 90k) und baust dir was mit ipset oder src-asn :
https://2ip.io/analytics/asn-list/
Oder: https://2ip.io/analytics/asn-list/
Oder etwas mit dem neuen nftables:
https://wiki.nftables.org/wiki-nftables/index.php/Netfilter_hooks
Oder du holst dir eine Liste der Netze/ASN (sind ca. 90k) und baust dir was mit ipset oder src-asn :
https://2ip.io/analytics/asn-list/
Oder: https://2ip.io/analytics/asn-list/
Oder etwas mit dem neuen nftables:
https://wiki.nftables.org/wiki-nftables/index.php/Netfilter_hooks
Ok, aber das alles zu schreiben ist dann doch etwas viel Aufwand.
ggf. forke ich (sobald ich die sourcen finde) einfach das recent modul und patche so, dass jede adresse erst noch durch eine maske durch geht bevor es in der internen liste landet. Das sollte reichen um zumindest regeln mit prefix matching anlegen zu können.
Zumindest theoretisch müsste es funktionieren, wenn ich dem Modul bei allen stellen wo eine IP übergeben wird die einfach durch die maske jage und es damit denkt 1.0.0.1 und 1.0.0.2 sind beide 1.0.0.0. Aber in theorie ist sowas auch immer leichter.
ggf. forke ich (sobald ich die sourcen finde) einfach das recent modul und patche so, dass jede adresse erst noch durch eine maske durch geht bevor es in der internen liste landet. Das sollte reichen um zumindest regeln mit prefix matching anlegen zu können.
Zumindest theoretisch müsste es funktionieren, wenn ich dem Modul bei allen stellen wo eine IP übergeben wird die einfach durch die maske jage und es damit denkt 1.0.0.1 und 1.0.0.2 sind beide 1.0.0.0. Aber in theorie ist sowas auch immer leichter.
Vielleicht tuts auch ulogd?
https://www.netfilter.org/projects/ulogd/index.html
https://www.netfilter.org/projects/ulogd/index.html
Muss ich mir ansehen, aber der eigentliche Punkt wieso ich das ganze in nf-/iptables machen wollte war eben damit es nicht im userspace passiert.
Aktuell läuft alles was ich öffentlich gestellt habe auf einem Kartoffel VPS. Und eben wegen solcher Optimierungen selbst während der heißesten Phasen meist bei sehr niedriger CPU last.
Einziges Problem ich hatte nicht damit gerechnet, dass jemand ein ganzes AS nutzen würde für SYN-flooding auf sämtlichen ports. Und ich hatte auch nicht damit gerechnet, dass der in dem VPS packet enthaltene "DDOS Schutz" SYN-flooding nicht mit abdeckt...
Befürchte dass so ein tool wie das von dir was dann im userspace läuft genau das gleiche problem mit solchen SYN-flooding attacken hat wie der server jetzt auch hat und es ihn komplett überlastet die logs dafür zu verarbeiten. Gut, ich würde nicht alles speichern wollen, also wäre es weniger disk IO, aber mit <10% CPU Auslastung insgesamt wäre es dann halt zu "stoßzeiten" vorbei :p
(aktuell ist mein fix, dass ich da immer mal wieder drauf kucke und die IP-Ranges von dem Syn-flooding AS manuell in der RAW table auf die drop no-log regel werfe...)
Aktuell läuft alles was ich öffentlich gestellt habe auf einem Kartoffel VPS. Und eben wegen solcher Optimierungen selbst während der heißesten Phasen meist bei sehr niedriger CPU last.
Einziges Problem ich hatte nicht damit gerechnet, dass jemand ein ganzes AS nutzen würde für SYN-flooding auf sämtlichen ports. Und ich hatte auch nicht damit gerechnet, dass der in dem VPS packet enthaltene "DDOS Schutz" SYN-flooding nicht mit abdeckt...
Befürchte dass so ein tool wie das von dir was dann im userspace läuft genau das gleiche problem mit solchen SYN-flooding attacken hat wie der server jetzt auch hat und es ihn komplett überlastet die logs dafür zu verarbeiten. Gut, ich würde nicht alles speichern wollen, also wäre es weniger disk IO, aber mit <10% CPU Auslastung insgesamt wäre es dann halt zu "stoßzeiten" vorbei :p
(aktuell ist mein fix, dass ich da immer mal wieder drauf kucke und die IP-Ranges von dem Syn-flooding AS manuell in der RAW table auf die drop no-log regel werfe...)
Dann block das böse Netz einfach statisch, wie alle anderen das auch tun.
Entweder darauf, oder auf patchen des recent moduls wird es wohl hinauslaufen so wie es aussieht.
