IP-Adress-Filterung in IPTables

  • Thread starter Thread starter Deleted member 11691
  • Start date Start date
D

Deleted member 11691

Guest
Hallo,

an die Super-Duba-Extrem-Linux-Profis (:D) unter euch:
Wenn ich ca. 50 IP-Adressen in IPTables so eintrage
Code: 
#!/bin/bash

iptables -F spamhaus_drop
list=`curl -q http://www.spamhaus.org/drop/drop.lasso | awk -F';' '{print $1}'`
for i in $list
do
iptables -A spamhaus_drop -s $i -j DROP
done
, muss der Server dann mehr rechnen? Ich meine gehört zu haben, dass er dann mehr CPU-Last hat, da er ja durch mehrere Regeln durchgeht und jede einzeln prüft. Welche Methode wäre hier dann sinnvoller, falls das wirklich stimmt?

LG. PCFreund
 
Wieso rechnen?
Du hängst mit dem Skript doch nur die Regeln an.

Wie oft machst du das? Jede Sekunde, jede Minute?
Sicher braucht es Mikro- bis Millisekunden Zeit, Regeln zu aktualisieren, aber dazu ist iptables und die CPU doch da - zum Arbeiten.
 
Ich würde jetzt vermuten, daß der Rechenaufwand geringer ist, als diese IPs per RBL im SMTP-Server abzublocken (rein vom Gefühl her, keine belegte oder getestete Aussage).
 
iptables-Regelwerke werden Regel fuer Regel sequentiell geprueft. Jede der Prüfungen vereinfacht betrachtet kostet konstante (CPU)-Zeit. Ergo, mehr Regeln mehr CPU-Belastung.

Wirkliche Optionen hast Du in Deinem Fall wohl eher nicht.
 
Eine IP-Adresse zu matchen ist eine so primitive Aufgabe, das macht dir jede moderne CPU in wenigen Taktzyklen. Ich würde da nicht einen Gedanken verschwenden, ob du nun 50 oder 5000 IPs dort anhängst und behaupte kühn, dass der Unterschied nicht messbar ist.
 
In der Tat eine kühne Behauptung. Die Regeln sollten so sortiert sein, dass nach Möglichkeit nicht jedes Paket alle Rules durchlaufen muss.

IMHO, macht es sehr wohl einen Unterschied, ob jedes Paket 50 oder 5000 Rules durchlaufen muss (jaja, ist extremes Beispiel). Auch wenn die Abarbeitung einer Regel nur wenige Taktzyklen benötigt, die CPU muss sich dennoch damit beschäftigen und das jedes Mal mit jedem Paket.

Bei sehr umfangreichen Rulesets treten schon messbare Veränderungen in der Latenz auf - dafür bedarf es aber eines entsprechenden Traffic-Aufkommens und/oder einer bestimmten CPU-Gesamtbelastung (ausgehend davon, dass die CPU noch was anderes zu tun hat, außer ipTables-Regeln zu bearbeiten).

In der üblichen Praxis ist natürlich festzustellen, dass 'nem Server in aller Regel aus ganz anderen Gründen die Puste ausgehen wird als wegen ipTables-Regeln. Auch sind die üblicherweise eingesetzten Regelwerke noch relativ überschaubar. Bedeutsam ist das Thema eigentlich nur bei großen Netzknotenpunkten also bei Routern und Gateways.
 
Wobei man sich ja prinzipiell schon auch die Frage stellen muss, ob es überhaupt Sinn macht die besagte DROP-Liste lokal auf seinem Server zu implementieren?

In dieser Liste stehen doch IP-Ranges, die erst gar nicht gerouted werden sollen. Diese Liste sollte daher primär auf (Backbone-)Routern zum Einsatz kommen.

Hast du denn aktuell akute Probleme mit IPs, die auf dieser Liste stehen?
 
tomasini said:
In dieser Liste stehen doch IP-Ranges, die erst gar nicht gerouted werden sollen. Diese Liste sollte daher primär auf (Backbone-)Routern zum Einsatz kommen.
Click to expand...
Der Server steht bei Hetzner, dort machen die soetwas nicht...

tomasini said:
Hast du denn aktuell akute Probleme mit IPs, die auf dieser Liste stehen?
Click to expand...
Ja, habe ich leider :mad:
 
Du willst vermutlich Port25 eingehend von diesen IP's blockieren, also:

Legst du eine neue Kette in Iptables an und leitest die Verbindungsaufbau-Pakete (SYN) von Port25 incoming dahin:
Code: 
iptables -N BLOCKSMTP
iptables -A INPUT -p tcp -m state --state NEW --dport 25 -j BLOCKSMTP

Dann modifiziert du dein Skript leicht:
Code: 
iptables -F BLOCKSMTP
list=`curl -q http://www.spamhaus.org/drop/drop.lasso | awk -F';' '{print $1}'`
for i in $list
do
iptables -A BLOCKSMTP -s $i -j DROP
done

Voila, jetzt werden nur noch neue Verbindungen auf Port25 statt alle Pakete aller Verbindungen analysiert.
Kombiniert mit einer Drosslung der maximalen neuen Verbindungen/Zeitintervall ist die Belastung selbst unter einem Synflood nicht ueberwaeltigend.
 
Äh, und wie lösche ich die Chain nun wieder?
Code: 
root@46-4-120-47 ~ # iptables -D spamhaus_drop
iptables: Bad rule (does a matching rule exist in that chain?).
root@46-4-120-47 ~ # iptables -F spamhaus_drop
root@46-4-120-47 ~ # iptables -D spamhaus_drop
iptables: Bad rule (does a matching rule exist in that chain?).
root@46-4-120-47 ~ # iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain spamhaus_drop (0 references)
target     prot opt source               destination
Edit:
Außerdem:
Code: 
root@46-4-120-47 ~ # iptables -A INPUT -p tcp -m state --state NEW --dport 25 -j BLOCKSMTP
iptables v1.4.8: Couldn't load target `BLOCKSMTP':/lib/xtables/libipt_BLOCKSMTP.so: cannot open shared object file: No such file or directory

Try `iptables -h' or 'iptables --help' for more information.

Edit: hat sich erledigt. -X war der Para., nicht -D :D
 
Ist auch "Couldn't load target `BLOCKSMTP'" erledigt?
In deiner "iptables -L" sehe ich zumindest keine Chain BLOCKSMTP, hast du sie korrekt angelegt?

PS: die Chain muss nicht BLOCKSMTP heissen sondern kann auch HinzKunzTralala heissen, allerdings finde ich es lesbarer, sehr kurze und grossgeschriebene Namen zu waehlen.
 
PCFreund said:
Der Server steht bei Hetzner, dort machen die soetwas nicht...
Click to expand...

Doch machen sie. Eine Email mit einem entsprechend aufbereiteten Auszug aus den Logfiles an den Support genügt. Ich muss dabei natürlich unterscheiden können, was lediglich Hintergundrauschen und was ein echter Angriff ist.

Es liegt nämlich auch im Interesse des RZ-Betreibers derartigen Traffic möglichst früh abzufangen, um potentielle negative Auswirkungen auf andere Kunden zu minimieren.

Und btw., bei einem richtigen Angriff kann man mit "Iptables-Gefrickel" eh nicht viel ausrichten:

http://blog.fefe.de/?ts=b0043bae
 
tomasini said:
Doch machen sie. Eine Email mit einem entsprechend aufbereiteten Auszug aus den Logfiles an den Support genügt.
Click to expand...

Ist mir neu. Wurde das diese Woche neu eingeführt, weil letzte Woche kam noch die Aussage vom Support, dass keine fremden IP's gesperrt werden können.

Root-Server oder Colocation Kunde?
 
tomasini said:
Doch machen sie. Eine Email mit einem entsprechend aufbereiteten Auszug aus den Logfiles an den Support genügt. Ich muss dabei natürlich unterscheiden können, was lediglich Hintergundrauschen und was ein echter Angriff ist.
Click to expand...
Nein, da Hetzner keine Firewalls o.Ä. einsetzt, wird der dementsprechende Dedicated Server vom Netz genommen, um andere Kunden nicht zu beeinflussen.

nevakee said:
Ist mir neu. Wurde das diese Woche neu eingeführt, weil letzte Woche kam noch die Aussage vom Support, dass keine fremden IP's gesperrt werden können.[/nevakee]
mir auch!
Click to expand...
 
Jenstheclown said:
Wozu ne Firewall? IP-Adressen kannst du auch auf nen Router droppen.
Click to expand...
Machen die trotzdem nicht. Ich war ja derjenige hier, der nen hetzner dedi hat und der gesperrt worden ist, eben genau weil er von einem botnetz geflutet wurde und andere auch davon betroffen waren :mad:
btw: hallo jens :D
 
You must log in or register to reply here.
Back
Top