Onderwerp: Linux kenner gezocht voor IPtables - synflood attacks

Ik zoek iemand die handig is met linux (centos 4.x) en mij een handje kan helpen met opzich een vrij simpele klus.

Betreft: syn flooding

Ik draai momenteel al iptables v1.4 alleen zoek ik iemand die voor mij een oplossing heeft tegen syn flooding. Ik heb APF al geinstalleerd en DoS deflate, mod_security en ooit mod_evasive maar dat is gewoon iets wat voor geen meter werkt en is ontworpen om pingers te bannen wat al voor de windows 95 tijd was.

Ik zoek iemand die via iptables synflooding kan tegenhouden en desnoods een leuke ban voor een dag geven in iptables.

Als het werkt kan je een biertje drinken of uitgaan met 120 euro ex. BTW in je zak!

Code:

iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP      #DROP NEW NOT SYN
iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP       #DROP SYN-FIN SCANS
iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP       #DROP SYN-RST SCANS
iptables -A INPUT -p tcp --tcp-flags ALL FIN,URG,PSH -j DROP       #DROP X-MAS SCANS
iptables -A INPUT -p tcp --tcp-flags ALL FIN -j DROP               #DROP NMAP FIN SCAN
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP              #DROP NULL SCANS
iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP               #DROP ALL/ALL SCANS

Dankjewel, zal thuis straks even testen of het ook echt werkt!

Hmm werkt helaas niet.
Ik zoek echt iemand die gewoon mijn iptables kan configureren en weet how to handle synfloods al die regeltjes heb ik al 1000x geprobeerd maar echter zonder resultaat.

suurbier, je moet de regels ook nog in iptables laden, alleen aan de config toevoegen werkt niet

ook het los installeren vna iptables is een beetje vergeefse moeite, deze doen namelijk standaard niets, nada noppes

kijk anders even met iptables -L welke regels geladen zijn

verder valt het me erg op dat jij degene bent die vaak zeer eenvoudig op te lossen vragen stelt, misschien een tip om even de sites te bookmarken waarop deze oplossing vaak te vinden zijn?

verder mag ik ook hopen dat geen van deze zaken nog op een productie server draaien, als je dergelijke basiskennis mist is dat (nog) niet aan te raden

om toch evne mijn goede bedoeling te laten blijken hier ene lijstje met checks waar je kan kijken voor een oplossing

http://www.fedora-linux.nl/wiki/index.php
www.howtoforge.com
www.google.com (en niet .nl gebruiken)

overigens kun je de regel laden dmv een bash script in de vorm van

Code:

#!/bin/bash
[ "${METHOD}" != loopback ] || exit 0
/sbin/iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP      #DROP NEW NOT SYN

dat /bin/iptables hoort dus voor iedere regel
als je dit bestand (voor debian) plaatst in /etc/network/if-up.d/ worden de regels altijd geladen zodra networking start

Probeer anders:

iptables -I INPUT -j DROP -p tcp --dport 9845 --tcp-flags SYN,ACK,FIN,RST SYN
of
iptables -I FORWARD -j DROP -p tcp --dport 9845 --tcp-flags SYN,ACK,FIN,RST SYN

Poort 9845 is een voorbeeld van de poort die je wilt beschermen.

dat gaat niet werken, want het gaat om poort 2222 bij suurbier
ik heb er deze avond even naar gekeken en helaas mist de hashlimit module

wat suurbier morgen nog even kan proberen is het volgende:
run updatedb
vervolgens: locate libipt_hashlimit.so
als hij dan niks output draai je een custom kernel zonder deze module
als hij wel een locatie aangeeft copy (duplicate) deze dan even naar /lib/iptables
met de volgende iptables regel worden vervolgens attackers automatishc toegvoegd

Code:

/sbin/iptables -A INPUT -m hashlimit -m tcp -p tcp --dport [poortnummer] --hashlimit 10/s --hashlimit-mode srcip --hashlimit-name HTTPD_DOS -m state --state NEW -j ACCEPT

veel succes er nog mee

Als het echt om een synflood gaat werkt #2 niet omdat dit alleen invalide packets blokkeert, #5 niet omdat dit valide tcp syn packets blokkeert waardoor er helemaal geen verbinding meer mogelijk is en #6 werkt half, alleen als de synflooder zo aardig is om source ip niet te spoofen (waar je niet van uit moet gaan).

Staan syncookies aan (cat /proc/sys/net/ipv4/tcp_syncookies)? Weet je zeker dat het een synflood is en niet je hele downstream volgetrokken wordt of dat er bijvoorbeeld resource intensieve scripts worden aangeroepen?

Suurbier,

Ik gebruik zelf iptables om het aantal connecties per seconde te limiteren op een webserver die ik beheer. Komen er meer conncties binnen dan toegestaan, dan begint de kernel die pakketjes te loggen en te droppen. Een helper executable leest /var/log/messages uit en voegt een IP toe, aan de firewall, die meer dan 20 maal in /var/log/messages staat.

Met o.a. ab (apache bench) kan je een kleine praktijk test doen. Als je het volgende commando geeft:

# Heb ik weg moeten halen, mag nog geen links posten. Kan ik je evt. mailen

op een linux bak. Dan kan je, als het goed is, voordat ab klaar is niet meer browsen op die webserver.

Als je dit wil hebben, kan ik het wel voor je instaleren. Ik kan, als je tevreden bent, een factuurtje maken voor die 120 ex BTW.

Ronald

Oorspronkelijk geplaatst door derksen-its

Ik gebruik zelf iptables om het aantal connecties per seconde te limiteren op een webserver die ik beheer. Komen er meer conncties binnen dan toegestaan, dan begint de kernel die pakketjes te loggen en te droppen. Een helper executable leest /var/log/messages uit en voegt een IP toe, aan de firewall, die meer dan 20 maal in /var/log/messages staat.

Nogmaals: dit werkt niet omdat het aannemelijk is dat srcip van de synfloodpackets willekeurig is; het maakt de bak alleen maar meer dosable door een synflood uit te voeren met srcip van een bekende gebruiker van de bak.

Als iemand IP spoofing gebruikt om een syn attack uit te voeren, dan vindt er iig geen 3-way handshake plaats. Die syn-flood connecties komen dan in een aparte backlog buffer terecht. Als deze buffer vol is dan worden connecties recycled. Op deze manier heb je geen last van die ip spoofed syn pakketjes.
Gaat men het tempo van spoofed ip pakketjes opvoeren naar absurde waardes in de hoop dat de buffer sneller overloopt dan reguliere connecties een 3-way handshake kunnen uitvoeren, dan zorgt de rate limit ervoor dat die buffer niet zo snel gevuld wordt en reguliere connecties tijd genoeg hebben voor de 3-way handshake.

Op het moment dat de rate limit actief is, dan worden er ook mogelijk regulieren connecties gedropped. Echter in de praktijk heb ik ondervonden dat dat best mee valt. Als bijf. 1 op de 100 syn pakketjes regulier is dan worden de meeste niet reguliere pakketjes gedropt, zonder buffer oid te vullen. Als er dan ook nog eens bijf. 300 gebruikers actief zijn dan wordt het aantal dropped pakketjes waar 1 speciefieke gebruiker last van heeft zeer acceptabel.

Je hebt volkomen gelijk dat je iemand, waarvan je zijn IP weet, kan buiten sluiten door een syn flood te doen met zijn IP. Als je dat niet wilt dan hoef je de helper applicatie niet te gebruiken. Het systeem werkt ook zonder helper applicatie.

Ronald

Oorspronkelijk geplaatst door derksen-its

Als iemand IP spoofing gebruikt om een syn attack uit te voeren, dan vindt er iig geen 3-way handshake plaats.

Volgens mijn definitie van een syn flood vindt er nooit een three-way handshake plaats, wellicht vandaar de verwarring.

Is het probleem al opgelost voor topicstarter, of is Suurbier van internet af ge(d)dossed?

Oorspronkelijk geplaatst door dirk939

Volgens mijn definitie van een syn flood vindt er nooit een three-way handshake plaats, wellicht vandaar de verwarring.

Is het probleem al opgelost voor topicstarter, of is Suurbier van internet af ge(d)dossed?

een SYN flood is wel een three-way-handshake alleen stuurt geen FIN's maar je ziet eerder RST's voorbij komen (zogeheten half-open-connectie) waar door je buffer overflowed.

Deze is makkelijk op te lossen met ratelimiting (en genoeg andere opties die in eerdere posts binnen deze thread is gedaan).

Oorspronkelijk geplaatst door dirk939

Is het probleem al opgelost voor topicstarter, of is Suurbier van internet af ge(d)dossed?

Het probleem is nog niet opgelost. Ik ben nog niet verder gekomen dan het systeem te bekijken en een klein begin te maken.

Op een gegeven moment deed ik een iptables -F om alles te flushen. En sindsdien geen communicatie meer op het systeem. Ik vermoed dat het systeem gecrashed is. De kernel klaagde over iptables modules van mogelijk een andere architecture. Vlak daarvoor zag ik nog, met dmesg, kernel debug messages, zoals je ziet bij een kernel oops.

Als het systeem weer op is kijk ik verder.

Ronald

Dank aan Ronald, alles is inmiddels opgelost en werkt perfectó!

en met welke oplossing?
misschien handig om te vermelden voor anderen die hier last van zouden krijgen