Hackertool voor platleggen Apache webservers
Een bekende beveiligingsonderzoeker heeft een programma online gezet waarmee het kinderspel is om Apache webservers plat te leggen. Apache is de populairste webserver voor het hosten van websites en wordt door talloze bekende sites gebruikt. Slowloris, zoals de tool heet, houdt alle verbindingen open door gedeeltelijke HTTP requests te sturen. De server wacht tot de volledige header binnenkomt, maar Slowloris stuurt die niet en blijft de nep-headers sturen, die de verbinding openhouden. Hierdoor raakt de webserver uiteindelijk overbelast en is er sprake van een Denial of Service.
Volgens Robert "RSnake" Hansen die de tool ontwikkelde, zijn met name servers met threading kwetsbaar. Dit komt omdat ze de hoeveelheid threading die ze toestaan proberen te beperken. De DoS-tool moet wachten totdat alle sockets beschikbaar zijn, voordat die ze allemaal in beslag kan nemen. In het geval van een druk bezochte website kan het dus even duren voordat dit het geval is. Slowloris is verder van een aantal stealth features voorzien. Zo kan het verschillende host headers sturen, in het geval het doelwit een virtuele host is en de logs apart per virtuele host worden opgeslagen. Als de aanval echter plaatsvindt, worden de logs pas geschreven als de request is voltooid. "Het is dus mogelijk om een server voor minuten uit de lucht te halen, zonder dat het log wordt bijgewerkt om iemand te waarschuwen."
Scriptkiddies
Hansen krijgt het verwijt dat hij hiermee een "leger van scriptkiddies" bewapent. De onderzoeker ontkent dat. Het probleem is namelijk de manier waarop Apache werkt. Volgens het Internet Storm Center, dat bewust niet naar de pagina van Hansen linkt, zijn er geen instellingen in Apache die de aanval voorkomen. Het verhogen van MaxClients maakt het alleen iets lastiger voor een aanvaller. Wie voor zijn webserver de Perlbal reverse proxy neerzet zou de aanval echter kunnen afslaan.
Hansen hoopt dat ontwikkelaars beter gaan nadenken over de architectuur van webservers. Met name als het gaat om het "verwachte" gedrag van de webserver. Daarnaast zou er een standaard configuratie moeten zijn om tegen dit soort aanvallen bescherming te bieden. "Als het geen probleem is, dan maakt het ook niet uit als scriptkiddies het hebben, niet waar? Of het nu wel of geen groot probleem is, het is de moeite waard om erover te praten, aangezien de aanbevelingen van Apache waardeloos zijn." Beheerders van een IIS-webserver hoeven zich geen zorgen te maken, Microsoft's webserver is niet kwetsbaar voor de aanval.
Frans.
Jammer dat Hansen de tool zomaar plaatst. Dit kan voor veel problemen zorgen. Hopelijk zal er snel een oplossing komen voor het probleem waar de tool op in speelt.
Opzettelijk verstuurde halve requests zouden dan minder effectief zijn.
- Unomi -
yea right... wat denk je te doen ? Apeldoorn bellen?
Nu kan het aan mij liggen, maar volgens mij klopt dit niet.
Heb het net getest tegen een server met limitipconn maar bij mij word hij gewoon onbereikbaar. Volgens mij werkt limitipconn alleen maar bij volledige connectie zodat hij netjes een 503 terug kan sturen. Aangezien deze tool geen volledige connectie maakt zal limitipconn hier nooit iets tegen kunnen doen....
Heb het net getest tegen een server met limitipconn maar bij mij word hij gewoon onbereikbaar. Volgens mij werkt limitipconn alleen maar bij volledige connectie zodat hij netjes een 503 terug kan sturen. Aangezien deze tool geen volledige connectie maakt zal limitipconn hier nooit iets tegen kunnen doen....
Je hebt gelijkt. De ap_hook_quick_handler() en ap_hook_access_checker() vuren waarschijnlijk pas af als het gehele verzoek gedaan is. Erg jammer. Dan toch maar op je firewall het aantal connecties per ip limiteren. Daar hoort het ook eigenlijk thuis natuurlijk.
-A RH-Firewall-1-INPUT -p tcp --dport 80 -m state --state NEW -m recent --set
-A RH-Firewall-1-INPUT -p tcp --dport 80 -m state --state NEW -m recent --update --seconds 60 --hitcount 20 -j LOG
-A RH-Firewall-1-INPUT -p tcp --dport 80 -m state --state NEW -m recent --update --seconds 60 --hitcount 20 -j DROP
-A RH-Firewall-1-INPUT -p tcp --dport 80 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp --dport 443 -m state --state NEW -m recent --set
-A RH-Firewall-1-INPUT -p tcp --dport 443 -m state --state NEW -m recent --update --seconds 60 --hitcount 20 -j LOG
-A RH-Firewall-1-INPUT -p tcp --dport 443 -m state --state NEW -m recent --update --seconds 60 --hitcount 20 -j DROP
-A RH-Firewall-1-INPUT -p tcp --dport 443 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp --dport 80 -m state --state NEW -m recent --set
-A RH-Firewall-1-INPUT -p tcp --dport 80 -m state --state NEW -m recent --update --seconds 60 --hitcount 20 -j LOG
-A RH-Firewall-1-INPUT -p tcp --dport 80 -m state --state NEW -m recent --update --seconds 60 --hitcount 20 -j DROP
-A RH-Firewall-1-INPUT -p tcp --dport 80 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp --dport 443 -m state --state NEW -m recent --set
-A RH-Firewall-1-INPUT -p tcp --dport 443 -m state --state NEW -m recent --update --seconds 60 --hitcount 20 -j LOG
-A RH-Firewall-1-INPUT -p tcp --dport 443 -m state --state NEW -m recent --update --seconds 60 --hitcount 20 -j DROP
-A RH-Firewall-1-INPUT -p tcp --dport 443 -j ACCEPT
Mzls
Patrick Noblesse
ik heb het getest vanmiddag, op het moment dat je het script start stopt de webserver al met reageren.
wat ik heb ingebouwd is een logwatch die monitort op een foutmelding die voorkomt op het moment dat apache de limiet bereikt. mijn apache wordt dan gestopt en een paar seconden later weer gestart, tevens wordt er een drop uitgevoerd van alle active verbindingen die er zijn. zo ben je even veilig. het werkt niet vlekkeloos helaas maar zolang er geen oplossing is kan het helpen
Je ziet ook een verschuiving plaats vinden. Hackers en dergelijke hebben het nu ook op andere OS gemund. M$ is lang niet meer "the only target".
Apache gaat niet plat alleen tijdelijk zijn er geen connecties meer beschikbaar.
Oplossing o.a. mod_limitipconn.
Naast tcp/ip stack hardening en FW/IDS/IPS.
Nee hoor.
Apache heeft NCSA webserver opgevolgt... je zou kunnen zeggen dat sinds het begin van het WWW, Apache/NCSA de #1 webserver is geweest. Apache is altijd doelwit geweest voor hackers.
In de code van Apache worden trouwens bijzonder weinig ernstige lekken gevonden. Daarom is er ook meteen paniek in de keet, als er eens een keer wel een tamelijk ernstig security probleem word aangetroffen.
ik heb het getest vanmiddag, op het moment dat je het script start stopt de webserver al met reageren.
wat ik heb ingebouwd is een logwatch die monitort op een foutmelding die voorkomt op het moment dat apache de limiet bereikt. mijn apache wordt dan gestopt en een paar seconden later weer gestart, tevens wordt er een drop uitgevoerd van alle active verbindingen die er zijn. zo ben je even veilig. het werkt niet vlekkeloos helaas maar zolang er geen oplossing is kan het helpen
Laat de volgende commando maar een draaien op de server terwijl je slowloris uittest:
while [ true ]; do netstat -anp |grep 'tcp\|udp' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n; echo "Aantal verbindingen poort 80: "; lsof -i :80| grep ESTA | wc -l; echo '---------------------'; sleep 1; done
Dat iptables commando werkt wel. Ook met deze tool. Kijk maar eens voordat je dit iptables commando gebruikt met die voorgaande commando regel en ernaa.
Je kunt er ook een reverse proxy voor je Apache neerzetten, zoals Perlbal of Varnish ofzo. Die hebben er ook geen last van.
Ah, Hugo loopt weer eens z'n eigen brouwsel te pluggen :')
Een andere webserver gebruiken is geen oplossing maar een workaround.
#kldload accf_http
# kldstat
Id Refs Address Size Name
1 4 0xc0400000 97f870 kernel
2 1 0xc0d80000 6a2c4 acpi.ko
3 1 0xc350c000 2000 accf_http.ko
Als je server herstart is deze module niet meer geladen. Voeg daarom het volgende toe aan /boot/loader.conf:
accf_http_load=”YES”
Uit de manual (man accf_http):
This is a filter to be placed on a socket that will be using accept() to
receive incoming HTTP connections.
It prevents the application from receiving the connected descriptor via
accept() until either a full HTTP/1.0 or HTTP/1.1 HEAD or GET request has
been buffered by the kernel.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
