iptables-Regeln, um den häufigsten DoS-Angriffen entgegenzuwirken? [geschlossen]

7

In letzter Zeit habe ich viele kleine DoS-Angriffe. Ich frage mich, welche iptables-Regeln ich verwenden soll, um den häufigsten DoS-Angriffen entgegenzuwirken und meinen Webserver im Allgemeinen zu sichern.

Der Webserver ist mit Varnish -> nginx / php5 -> memcached -> mysql ausgestattet

Ich habe einige generische Belege ausprobiert, aber sie blockieren auch den Zugriff auf meinen Datenbankserver, der sich auf einem Remote-Server befindet. Deshalb habe ich nur die vorgeschlagenen Regeln gelöscht und fühle mich jetzt ein bisschen barhändig und unerschütterlich, wenn ich nur fail2ban auf iptables sehe.

Schätzen Sie also Ihre Regeln, um die häufigsten Angriffsmethoden zu blockieren.

iptables ddos

— Alfish
quelle

1

Kommt darauf an, welchen Angriffen du ausgesetzt bist. Alle effektiven DoS-Angriffe erfordern jedoch entweder S / RTBH oder Inhaltsinspektion, sodass die iptables-Regeln auf dem angegriffenen Server nicht von Nutzen sind.

— womble

Ich habe die Frage geändert, um Missverständnisse zu vermeiden. Ich suche einfach nach Regeln, um den häufigsten DoS-Angriffen entgegenzuwirken.

— Alfish

Sie sollten wissen, dass es sich bei den vermuteten "Angriffen" häufig um Bots handelt, die sich schlecht verhalten und auf zu viele URLs auf Ihrem Server gleichzeitig zugreifen und Ihren Server zum Absturz bringen. Der in meiner Antwort erwähnte Mod-Status sollte dabei helfen, dies zu identifizieren. Sehr selten hat jemand etwas zu gewinnen, wenn er Ihren Server absichtlich angreift. Viren und Skripte können den Zugriff über FTP und SSH erzwingen. Ich empfehle, dies einzuschränken.

— AdrianTNT

1

DROP All scheint der richtige Weg zu sein, um das zu tun, was Sie verlangen. Aber es scheint wirklich so, als ob Sie es nicht ganz "verstehen". Sie können einen DoS-Angriff auf dem Server einfach nicht blockieren. Wenn es Sie erreicht hat, werden Sie bereits DoSed.

— HopelessN00b

20

Hier sind einige Regeln, die ich verwende:

# Reject spoofed packets
iptables -A INPUT -s 10.0.0.0/8 -j DROP
iptables -A INPUT -s 169.254.0.0/16 -j DROP
iptables -A INPUT -s 172.16.0.0/12 -j DROP
iptables -A INPUT -i eth0 -s 127.0.0.0/8 -j DROP

iptables -A INPUT -s 224.0.0.0/4 -j DROP
iptables -A INPUT -d 224.0.0.0/4 -j DROP
iptables -A INPUT -s 240.0.0.0/5 -j DROP
iptables -A INPUT -d 240.0.0.0/5 -j DROP
iptables -A INPUT -s 0.0.0.0/8 -j DROP
iptables -A INPUT -d 0.0.0.0/8 -j DROP
iptables -A INPUT -d 239.255.255.0/24 -j DROP
iptables -A INPUT -d 255.255.255.255 -j DROP

# Stop smurf attacks
iptables -A INPUT -p icmp -m icmp --icmp-type address-mask-request -j DROP
iptables -A INPUT -p icmp -m icmp --icmp-type timestamp-request -j DROP
iptables -A INPUT -p icmp -m icmp -j DROP

# Drop all invalid packets
iptables -A INPUT -m state --state INVALID -j DROP
iptables -A FORWARD -m state --state INVALID -j DROP
iptables -A OUTPUT -m state --state INVALID -j DROP

# Drop excessive RST packets to avoid smurf attacks
iptables -A INPUT -p tcp -m tcp --tcp-flags RST RST -m limit --limit 2/second --limit-burst 2 -j ACCEPT

# Attempt to block portscans
# Anyone who tried to portscan us is locked out for an entire day.
iptables -A INPUT   -m recent --name portscan --rcheck --seconds 86400 -j DROP
iptables -A FORWARD -m recent --name portscan --rcheck --seconds 86400 -j DROP

# Once the day has passed, remove them from the portscan list
iptables -A INPUT   -m recent --name portscan --remove
iptables -A FORWARD -m recent --name portscan --remove

# These rules add scanners to the portscan list, and log the attempt.
iptables -A INPUT   -p tcp -m tcp --dport 139 -m recent --name portscan --set -j LOG --log-prefix "Portscan:"
iptables -A INPUT   -p tcp -m tcp --dport 139 -m recent --name portscan --set -j DROP

iptables -A FORWARD -p tcp -m tcp --dport 139 -m recent --name portscan --set -j LOG --log-prefix "Portscan:"
iptables -A FORWARD -p tcp -m tcp --dport 139 -m recent --name portscan --set -j DROP

— Bart De Vos
quelle

4

Bart, tötet 'iptables -A INPUT -s 127.0.0.0/8 -j DROP' nicht memcached?

— Alfish

1

Ich sehe, Sie haben die Adresse rfc1918, vermutlich nicht 192.168, weil Sie sie verwenden. Sie haben link-local. Sie können Ihrer Liste TEST-NET (192.0.2.0/24) von rfc3330, Benchmarktest (198.18.0 / 25) von rfc2544, Protokollzuweisung (192.0.0.0/24), testnet2 (198.51.100 / 24) und testnet3 hinzufügen (203.0.113 / 24) von rfc5736 und 5737 und schließlich Carrier Grade Nat (100.64 / 10) von rfc6598

— jrwren

3

Schätzen Sie also Ihre kugelsicheren Regeln.

Sie sollten sich an Ihren ISP wenden und den Datenverkehr auf dem Backbone ablegen lassen, bevor er Sie trifft. Wenn Sie an dem Punkt angelangt sind, an dem Ihre Firewall den Datenverkehr reduzieren muss, verbraucht sie bereits Ihre verfügbare Bandbreite und nutzt die Ressourcen Ihres Systems.

Das ist der einzige "kugelsichere" Weg.

— MDMarra
quelle

Der Bandbreitenverbrauch ist mir egal, da ich einen dedizierten Port habe und die Angriffe normalerweise nicht so groß sind, wie ich sagte.

— Alfish

2

Viele gängige DoS-Angriffe versuchen, die Verbindung eines Servers zum Internet zu überlasten. Wenn Sie eine andere Art von Angriff sehen, wie einen, der auf die Erschöpfung von Ressourcen abzielt, sollten Sie in Ihrer Frage viel spezifischer sein und die Antwort wird wahrscheinlich immer noch keine Iptables beinhalten.

— MDMarra

3

Diese Antwort ist absolut gültig. Wer diese Antwort notiert hat, hat keine Ahnung, wovon er spricht.

— Lucas Kauffman

1

Ich verwende IPtables, um den Zugriff auf FTP und SSH zu beschränken. Ich erlaube lediglich den IP-Adressen meines Computers, eine Verbindung zum Server herzustellen. Ich kann nicht sagen, dass ich Probleme mit DOS-Angriffen hatte.

/sbin/iptables -A INPUT -p tcp --dport 22 -s 86.106.0.0/16 -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 22 -s 89.122.0.0/16 -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 22 -j DROP

/sbin/iptables -A INPUT -p tcp --dport 21 -s 86.106.0.0/16 -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 21 -s 89.122.0.0/16 -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 21 -j DROP

Diese Regeln ermöglichen den Zugriff auf die Ports 22 und 21 auf zwei verschiedenen IPs. Sie können wahrscheinlich den MySQL-Port Ihres Datenbankservers hinzufügen und so andere Clients daran hindern, eine direkte Verbindung zu Ihrem Server herzustellen.

Bearbeiten: Wenn der Server überlastet ist, finde ich es hilfreich, Apache "Mod-Status" -Statistiken anzuzeigen. Die Ausgabe sieht folgendermaßen aus: http://www.apache.org/server-status Sie können alle Site-Besucher, Spider und URL-Anfragen sehen usw. Die Implementierung dauert weniger als 1 Minute: http://httpd.apache.org/docs/2.2/mod/mod_status.html

— adrianTNT
quelle

Wie verhindert dies einen DoS-Angriff? Es wird helfen, Brute-Force-Angriffe auf diese Protokolle zu eliminieren, aber es wird nicht viel dazu beitragen, ein DoS zu stoppen.

— MDMarra

Es war eher eine allgemeine oder erste Maßnahme, um den Server zu sichern (der FTP / SSH-Filter), dann hilft der Serverstatus dabei, den "Angriff" (per http) zu identifizieren, da es sich normalerweise nur um ein schlechtes Web handelt Crawler und kein Angriff. Eine iptables-Regel sollte auch beim Filtern / Blockieren seiner Datenbankportanforderungen helfen.

— AdrianTNT