1
SynBlock Script - Abwehr von Synflood
Ein Script zum abwehren von Syn-Flood attacken.
SynBlock Version 0.1
Beschreibung:
Da einige User Probleme haben SynFlood manuell abzuwehren, habe ich ein Script geschrieben welches permanent weiterentwickelt wird. Zukünftig wird das ganze noch automatisiert u. verbessert. Wer sich das ganze mal anschauen möchte, für den geht es hier weiter:
Funktionsumfang:
Alle aktiven SYN Verbindungen anzeigen:
- Listet alle aktiven SYN Verbindungen auf und zeigt zusätzlich deren Ziel-IP (Falls ein Server
mehrere IP Adressen hat)
IPtables Einstellungen vornehmen:
- Leert alle vorgenommen IPtables-Einstellungen
- Legt grundlegende Regeln an
- Limitiert und verwirft fragwürdige Pakete
AntiSpoofing:
- Verwirft Pakete in denen Quell-und Ziel-IP-Adressen im Header keinen Sinn ergeben.
Sysctl.conf Tuning:
- Aktiviert Syncookies (SYN-Cookies – Wikipedia)
- Verhindert Smurf-Attacken (Smurf-Attacke – Wikipedia)
- Verhindert antwort auf Broadcast-Pings (Broadcast – Wikipedia)
- Ignoriert ungültige ICMP Antworten
- Deaktiviert ICMP-Routing
- Verwirft "Martian" Packets
- Wartet maximal 30 Sekunden auf einen FIN/ACK
- Sendet TCP-keepalive-Timeout alle 30 Minuten
- Deaktiviert tcp_window_scaling und tcp_sack
- Erhöht den SYN backlog auf 1280
- Unterbricht den Verbindungsaufbau nach 3 SYN/ACK Paketen
- Sendet RST-Pakete sobald der Buffer voll ist
- Antwortet nun maximal 3 Mal auf einen TCP-SYN
Logfile
- Speichert den Status aller wichtigen Aktionen in der Datei "log"
Installation:
wget http://www.Anti-Hack.net/scripts/synblock/install.sh
mv install.sh?drgn=1 install.sh
chmod 0700 install.sh
./install.sh
Entfernen:
wget http://www.Anti-Hack.net/scripts/synblock/uninstall.sh
mv uninstall.sh?drgn=1 uninstall.sh
chmod 0700 uninstall.sh
./uninstall.sh
Hinweis: Das Script wird mit dem Befehl synblock ausgeführt. Parameter werden folgendermaßen übergeben: synblock -PARAMETER (Beispiel: synblock -h)
Kritik u. Vorschläge bitte hier im Thread.
MfG Florian Reith
SynBlock Version 0.1
Beschreibung:
Da einige User Probleme haben SynFlood manuell abzuwehren, habe ich ein Script geschrieben welches permanent weiterentwickelt wird. Zukünftig wird das ganze noch automatisiert u. verbessert. Wer sich das ganze mal anschauen möchte, für den geht es hier weiter:
Funktionsumfang:
Alle aktiven SYN Verbindungen anzeigen:
- Listet alle aktiven SYN Verbindungen auf und zeigt zusätzlich deren Ziel-IP (Falls ein Server
mehrere IP Adressen hat)
IPtables Einstellungen vornehmen:
- Leert alle vorgenommen IPtables-Einstellungen
- Legt grundlegende Regeln an
- Limitiert und verwirft fragwürdige Pakete
AntiSpoofing:
- Verwirft Pakete in denen Quell-und Ziel-IP-Adressen im Header keinen Sinn ergeben.
Sysctl.conf Tuning:
- Aktiviert Syncookies (SYN-Cookies – Wikipedia)
- Verhindert Smurf-Attacken (Smurf-Attacke – Wikipedia)
- Verhindert antwort auf Broadcast-Pings (Broadcast – Wikipedia)
- Ignoriert ungültige ICMP Antworten
- Deaktiviert ICMP-Routing
- Verwirft "Martian" Packets
- Wartet maximal 30 Sekunden auf einen FIN/ACK
- Sendet TCP-keepalive-Timeout alle 30 Minuten
- Deaktiviert tcp_window_scaling und tcp_sack
- Erhöht den SYN backlog auf 1280
- Unterbricht den Verbindungsaufbau nach 3 SYN/ACK Paketen
- Sendet RST-Pakete sobald der Buffer voll ist
- Antwortet nun maximal 3 Mal auf einen TCP-SYN
Logfile
- Speichert den Status aller wichtigen Aktionen in der Datei "log"
Installation:
wget http://www.Anti-Hack.net/scripts/synblock/install.sh
mv install.sh?drgn=1 install.sh
chmod 0700 install.sh
./install.sh
Entfernen:
wget http://www.Anti-Hack.net/scripts/synblock/uninstall.sh
mv uninstall.sh?drgn=1 uninstall.sh
chmod 0700 uninstall.sh
./uninstall.sh
Hinweis: Das Script wird mit dem Befehl synblock ausgeführt. Parameter werden folgendermaßen übergeben: synblock -PARAMETER (Beispiel: synblock -h)
Kritik u. Vorschläge bitte hier im Thread.
MfG Florian Reith
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 150648
Url: https://administrator.de/knowledge/synblock-script-abwehr-von-synflood-150648.html
Ausgedruckt am: 24.12.2024 um 12:12 Uhr
1 Kommentar
Moin,
[quote]
- Leert alle vorgenommen IPtables-Einstellungen
- Legt grundlegende Regeln an
- Limitiert und verwirft fragwürdige Pakete
[/quote]
Kritik:
a) Leert vorgenommene IPTables-Einstellungen? D.h. ich bin zwar gegen nen Synflood geschützt aber dafür sind alle Dienste jetzt offen? DAS ist kein guter Tausch!
b) Legt grundlegende Regeln an: Die da wären? Wie ermittelst du wie die grundlegenden Regeln aussehen die für MEINEN Server nötig sind? Hint: Es kann bei mir z.B. wichtig sein das Port 25 / SMTP von aussen erreichbar ist - beim nächsten ist der explizit geschlossen worden weil der seinen Mailserver als offenes Relay betreiben würde. Was machst du jetzt mit dem Port? Aufmachen ist bei letzteren fatal (der sendet nahezu sofort spam raus), schließen wäre bei mir fatal weil ich keine Mails mehr bekomme...
c) Was sind für dich "fragwürdige Pakete"? Bei mir wäre das z.B. alles was IRC betrifft (da darüber oft die Steuerbefehle für Bot-Netze laufen). Dumm nur wenn der Server durchaus ins IRC sollte - für denjenigen wäre IRC sicher kein fragwürdiges Paket...
[quote]
- Deaktiviert ICMP-Routing
[/quote]
Da machst du dir dann viele Freunde mit wenn du dahinter geräte mit öffentlichen IPs hast... Dann ist es schon schlecht wenn der Router keinen Ping mehr durchlässt.
[quote]
- Wartet maximal 30 Sekunden auf einen FIN/ACK
[/quote]
Und dann? Was passiert bei Verbindungen die länger als 30 Sek laufen müssen? (d.h. kann man Ausnahmen festlegen?)
[quote
- Deaktiviert tcp_window_scaling und tcp_sack
[/quote]
*lufthol* - mein Lieblings-Thema
Window-Size Nun - fange ich mal locker an: WAS ist die Window-Size? Das ist doch der Wert bei dem ich sage nach wievielen Paketen ich ein ACK von der Gegenseite erwarte (und ggf. darauf warte). Nun - jetzt gibt es 2 Extremfälle:
a) VoIP: Ist hier die Window-Size zu hoch (und die Verbindung über TCP gesteuert!) dann hast du ein Problem. Denn die steht meinetwegen bei 30.000 - d.h. du musst 30.000 Pakete mit 1,5 kB senden bevor du ein "jup, alles vollständig erhalten" bekommst. Dummerweise wirst du soviele Pakete gar nicht in 30 Sekunden bekommen - d.h. der Sender liegt in einem Time-Out und sendet die Pakete nochmal bevor der Empfänger überhaupt ein ACK senden müsste. (Ok, VoIP läuft über UDP, aber z.B. nen Mailserver könnte solch eine Window-Size schon zimlich störern!).
b) Extrem niedrige Window-Size: 1. D.h. du sendest genau 1 Paket und verlangst vom Empfänger das er auch bestätigt das er das Paket empfangen hat. Jetzt lass uns folgendes annehmen: Du machst das mit den Staaten. D.h. du hast ne Kabelverbindung von dir zum Satelliten-Uplink. Ich nehme da mal 1500 km für an (da du ja nicht direkt gehst sondern über deinen Provider, da dann über nen Exchange-Knoten,...). Wir nehmen weiterhin an das du in den Staaten auch nochmal 1500 km hast. D.h. 3000 km mit einer Geschwindigkeit von ca. 200.000 km/s (Signalgeschwindigkeit im Kabel). Jetzt nehmen wir an das dein Sat-Signal ca. 15000 km zurücklegen muss (Erde -> Sat -> Sat über den Staaten -> Erde). Sind also insgesamt 18.000 km. Oder eine Zeit von ca. 0,1 Sekunde. Jetzt muss das ACK aber ja noch zurück zu dir: 0,1 Sekunde für den Rückweg. Hört sich ja nicht weiter wild an. Aber "let's do the math": Du hast genau 1 Paket gesendet (mit 1500 Byte Daten). Dafür hast du 0,2 Sek (inkl. ACK) benötigt. D.h. in einer Sekunde schaffst du 7500 Byte oder ca. 7 kByte. Wie du hier siehst - deine Bandbreite spielt dabei überhaupt keine Rolle -> du kannst ne 2,5 GBit-Leitung haben -> damit überträgst du bei einer Win-Size von 1 immernoch ca. 7 kByte/Sek. Nicht grad berauschend, oder?
Von daher: Du deaktivierst Window-Scaling und holst dir ganz schnell ne Menge Probleme ins Haus. Es macht idR. durchaus Sinn das die Anwendung selbst da entscheiden kann auf eine andere Größe zu gehen...
[quote]
- Unterbricht den Verbindungsaufbau nach 3 SYN/ACK Paketen
- Sendet RST-Pakete sobald der Buffer voll ist
- Antwortet nun maximal 3 Mal auf einen TCP-SYN
[/quote]
Nun - du wirfst die Pakete weg. DAMIT hast du aber nichts gewonnen - die Syn-Flood-Attacke geht munter weiter. Es ist dem Angreiffer vermutlich auch egal ob du die Pakete wegwirfst oder damit dir deinen Kamin anzündest - der möchte deine Leitung zumachen und deinen Server beschäftigen. DAS schafft er auch weiterhin.... Nur das deine Firewall die Pakete jetzt löscht - deine Leitung ist weiterhin voll, deine CPU ist weiterhin beschäftigt (immerhin muss das Paket trotzdem analysiert werden!). WENN dann würde ich hier eine Erweiterung einsetzen: Einen Counter: Hat ein Angreiffer z.B. 4-5x in 5 Minuten hier einen Alarm ausgelöst - dann wird dessen komplette IP für x Minuten geblockt. Denn zum einen wird das Paket da früher verworfen - und zum anderen hat der Angreiffer eben ggf. bereits bei den ersten Versuchen einen offenen Port gefunden. Da ich dessen IP für 60 Minuten (o.ä.) sperre kann er diesen aber nicht allzuschnell ausnutzen. Klar könnte der dann nach 60 Minuten wiederkommen - aber dies wird die meisten Script-Kiddys schon überfordern. Und nebenbei: Da könnte man auch wieder überlegen das man z:B. Dienste wie SSH o.ä. auch noch anders sichert....
[quote]
- Leert alle vorgenommen IPtables-Einstellungen
- Legt grundlegende Regeln an
- Limitiert und verwirft fragwürdige Pakete
[/quote]
Kritik:
a) Leert vorgenommene IPTables-Einstellungen? D.h. ich bin zwar gegen nen Synflood geschützt aber dafür sind alle Dienste jetzt offen? DAS ist kein guter Tausch!
b) Legt grundlegende Regeln an: Die da wären? Wie ermittelst du wie die grundlegenden Regeln aussehen die für MEINEN Server nötig sind? Hint: Es kann bei mir z.B. wichtig sein das Port 25 / SMTP von aussen erreichbar ist - beim nächsten ist der explizit geschlossen worden weil der seinen Mailserver als offenes Relay betreiben würde. Was machst du jetzt mit dem Port? Aufmachen ist bei letzteren fatal (der sendet nahezu sofort spam raus), schließen wäre bei mir fatal weil ich keine Mails mehr bekomme...
c) Was sind für dich "fragwürdige Pakete"? Bei mir wäre das z.B. alles was IRC betrifft (da darüber oft die Steuerbefehle für Bot-Netze laufen). Dumm nur wenn der Server durchaus ins IRC sollte - für denjenigen wäre IRC sicher kein fragwürdiges Paket...
[quote]
- Deaktiviert ICMP-Routing
[/quote]
Da machst du dir dann viele Freunde mit wenn du dahinter geräte mit öffentlichen IPs hast... Dann ist es schon schlecht wenn der Router keinen Ping mehr durchlässt.
[quote]
- Wartet maximal 30 Sekunden auf einen FIN/ACK
[/quote]
Und dann? Was passiert bei Verbindungen die länger als 30 Sek laufen müssen? (d.h. kann man Ausnahmen festlegen?)
[quote
- Deaktiviert tcp_window_scaling und tcp_sack
[/quote]
*lufthol* - mein Lieblings-Thema
Window-Size Nun - fange ich mal locker an: WAS ist die Window-Size? Das ist doch der Wert bei dem ich sage nach wievielen Paketen ich ein ACK von der Gegenseite erwarte (und ggf. darauf warte). Nun - jetzt gibt es 2 Extremfälle:a) VoIP: Ist hier die Window-Size zu hoch (und die Verbindung über TCP gesteuert!) dann hast du ein Problem. Denn die steht meinetwegen bei 30.000 - d.h. du musst 30.000 Pakete mit 1,5 kB senden bevor du ein "jup, alles vollständig erhalten" bekommst. Dummerweise wirst du soviele Pakete gar nicht in 30 Sekunden bekommen - d.h. der Sender liegt in einem Time-Out und sendet die Pakete nochmal bevor der Empfänger überhaupt ein ACK senden müsste. (Ok, VoIP läuft über UDP, aber z.B. nen Mailserver könnte solch eine Window-Size schon zimlich störern!).
b) Extrem niedrige Window-Size: 1. D.h. du sendest genau 1 Paket und verlangst vom Empfänger das er auch bestätigt das er das Paket empfangen hat. Jetzt lass uns folgendes annehmen: Du machst das mit den Staaten. D.h. du hast ne Kabelverbindung von dir zum Satelliten-Uplink. Ich nehme da mal 1500 km für an (da du ja nicht direkt gehst sondern über deinen Provider, da dann über nen Exchange-Knoten,...). Wir nehmen weiterhin an das du in den Staaten auch nochmal 1500 km hast. D.h. 3000 km mit einer Geschwindigkeit von ca. 200.000 km/s (Signalgeschwindigkeit im Kabel). Jetzt nehmen wir an das dein Sat-Signal ca. 15000 km zurücklegen muss (Erde -> Sat -> Sat über den Staaten -> Erde). Sind also insgesamt 18.000 km. Oder eine Zeit von ca. 0,1 Sekunde. Jetzt muss das ACK aber ja noch zurück zu dir: 0,1 Sekunde für den Rückweg. Hört sich ja nicht weiter wild an. Aber "let's do the math": Du hast genau 1 Paket gesendet (mit 1500 Byte Daten). Dafür hast du 0,2 Sek (inkl. ACK) benötigt. D.h. in einer Sekunde schaffst du 7500 Byte oder ca. 7 kByte. Wie du hier siehst - deine Bandbreite spielt dabei überhaupt keine Rolle -> du kannst ne 2,5 GBit-Leitung haben -> damit überträgst du bei einer Win-Size von 1 immernoch ca. 7 kByte/Sek. Nicht grad berauschend, oder?
Von daher: Du deaktivierst Window-Scaling und holst dir ganz schnell ne Menge Probleme ins Haus. Es macht idR. durchaus Sinn das die Anwendung selbst da entscheiden kann auf eine andere Größe zu gehen...
[quote]
- Unterbricht den Verbindungsaufbau nach 3 SYN/ACK Paketen
- Sendet RST-Pakete sobald der Buffer voll ist
- Antwortet nun maximal 3 Mal auf einen TCP-SYN
[/quote]
Nun - du wirfst die Pakete weg. DAMIT hast du aber nichts gewonnen - die Syn-Flood-Attacke geht munter weiter. Es ist dem Angreiffer vermutlich auch egal ob du die Pakete wegwirfst oder damit dir deinen Kamin anzündest - der möchte deine Leitung zumachen und deinen Server beschäftigen. DAS schafft er auch weiterhin.... Nur das deine Firewall die Pakete jetzt löscht - deine Leitung ist weiterhin voll, deine CPU ist weiterhin beschäftigt (immerhin muss das Paket trotzdem analysiert werden!). WENN dann würde ich hier eine Erweiterung einsetzen: Einen Counter: Hat ein Angreiffer z.B. 4-5x in 5 Minuten hier einen Alarm ausgelöst - dann wird dessen komplette IP für x Minuten geblockt. Denn zum einen wird das Paket da früher verworfen - und zum anderen hat der Angreiffer eben ggf. bereits bei den ersten Versuchen einen offenen Port gefunden. Da ich dessen IP für 60 Minuten (o.ä.) sperre kann er diesen aber nicht allzuschnell ausnutzen. Klar könnte der dann nach 60 Minuten wiederkommen - aber dies wird die meisten Script-Kiddys schon überfordern. Und nebenbei: Da könnte man auch wieder überlegen das man z:B. Dienste wie SSH o.ä. auch noch anders sichert....
