Bekijk Volledige Versie : Dos attack op apache
no_player_4u
06/07/09, 18:00
Mijn server wordt al een tijdje 'gedost'. Het volgende gebeurt.
1) Apache neemt alle cpu in beslag.
2) Er wordt praktisch *niks* naar de acces of error log file geschreven.
Als ik check welke ip's veel connecties open hebben, zie ik niet één bepaalde ip die heel veel connecties opheeft.
Eerst dacht ik aan een Slowloris (http://ha.ckers.org/blog/20090617/slowloris-http-dos/) attack, maar als dat het geval was dan zou ik heel veel connecties van één bepaalde ip verwachten maar dat is dus niet het geval.
Wie weet wat voor attack het is en hoe te stoppen?
Output van atop:
PRC | sys 78.90s | user 1.13s | #proc 335 | #zombie 0 | #exit 0 |
CPU | sys 789% | user 11% | irq 0% | idle 0% | wait 0% |
cpu | sys 99% | user 1% | irq 0% | idle 0% | cpu000 w 0% |
cpu | sys 98% | user 2% | irq 0% | idle 0% | cpu001 w 0% |
cpu | sys 99% | user 1% | irq 0% | idle 0% | cpu002 w 0% |
cpu | sys 98% | user 2% | irq 0% | idle 0% | cpu003 w 0% |
cpu | sys 98% | user 2% | irq 0% | idle 0% | cpu004 w 0% |
cpu | sys 99% | user 1% | irq 0% | idle 0% | cpu005 w 0% |
cpu | sys 99% | user 1% | irq 0% | idle 0% | cpu006 w 0% |
cpu | sys 99% | user 1% | irq 0% | idle 0% | cpu007 w 0% |
CPL | avg1 18.14 | avg5 16.30 | avg15 13.47 | csw 2241 | intr 154 |
MEM | tot 3.9G | free 34.3M | cache 1.2G | buff 0.3M | slab 38.0M |
SWP | tot 2.1G | free 1.8G | | vmcom 4.1G | vmlim 4.0G |
PAG | scan 142880 | stall 0 | | swin 0 | swout 0 |
NET | transport | tcpi 93 | tcpo 32 | udpi 0 | udpo 0 |
NET | network | ipi 98 | ipo 34 | ipfrw 0 | deliv 93 |
NET | eth0 0% | pcki 127 | pcko 37 | si 21 Kbps | so 5 Kbps |
PID SYSCPU USRCPU VGROW RGROW RDDSK WRDSK ST EXC S CPU CMD 1/1
10693 4.94s 0.06s 0K 0K 0K 0K -- - R 50% apache2
10133 4.94s 0.06s 0K 0K 0K 0K -- - R 50% apache2
9658 4.92s 0.06s 0K 0K 0K 0K -- - R 50% apache2
9533 4.87s 0.11s 0K 0K 0K 0K -- - R 50% apache2
10362 4.88s 0.09s 0K 0K 0K 0K -- - R 50% apache2
10205 4.93s 0.03s 0K 0K 0K 0K -- - R 50% apache2
10424 4.63s 0.05s 0K 0K 0K 0K -- - R 47% apache2
10074 4.52s 0.07s 0K 0K 0K 0K -- - R 46% apache2
9734 4.02s 0.07s 0K 0K 0K 0K -- - R 41% apache2
10021 3.95s 0.12s 0K 0K 0K 0K -- - R 41% apache2
10669 3.98s 0.07s 0K 0K 0K 0K -- - R 40% apache2
10667 3.99s 0.05s 0K 0K 0K 0K -- - R 40% apache2
10589 3.92s 0.10s 0K 0K 0K 0K -- - R 40% apache2
10293 3.99s 0.01s 0K 0K 0K 0K -- - R 40% apache2
10091 3.92s 0.05s 0K 0K 0K 0K -- - R 40% apache2
9610 3.93s 0.03s 0K 0K 0K 0K -- - R 40% apache2
10410 3.87s 0.03s 0K 0K 0K 0K -- - R 39% apache2
10198 3.86s 0.03s 0K 0K 0K 0K -- - R 39% apache2
261 0.81s 0.00s 0K 0K 0K 0K -- - S 8% kswapd0
10858 0.03s 0.01s 0K 0K 0K 0K -- - R 0% atop
5765 0.00s 0.03s 0K 0K 0K 0K -- - S 0% mysqld
Heb je een firewall draaien? Zo ja, welke?
Hoeveel connecties heeft een IP gemiddeld?
Na een restart schiet hij ook direct weer de lucht in?
Raar, er wordt geen geheugen gebruikt en ook helemaal geen dataverkeer. Alle processen staan op running dus ook geen blocking disk IO. Misschien een database call die niet goed afgehandeld wordt of een of ander script dat vast loopt. Het lijkt er meer op dat het helemaal niet van buitenaf komt.
Zie je bij een netstat veel connecties in SYN_RECV staan? Zo ja, dan heb je wsl een SYN Flood attack te pakken.
no_player_4u
06/07/09, 22:31
Heb je een firewall draaien? Zo ja, welke?
Hoeveel connecties heeft een IP gemiddeld?
Ik heb Ubuntu hardy draaien, dus met iptables
dit comando geeft:
netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n
1 114.127.246.36
1 123.125.66.100
1 123.125.66.23
..
..
5 213.10.91.161
5 77.167.76.25
5 83.80.213.228
6 65.208.122.57
6 82.176.82.210
7 190.98.9.254
no_player_4u
06/07/09, 22:33
Na een restart schiet hij ook direct weer de lucht in?
Als ik apache opnieuw start gaat hij langzaam de lucht in, en dat lijkt op het gedrag van de
Slowloris attack.
no_player_4u
06/07/09, 22:38
Raar, er wordt geen geheugen gebruikt en ook helemaal geen dataverkeer. Alle processen staan op running dus ook geen blocking disk IO. Misschien een database call die niet goed afgehandeld wordt of een of ander script dat vast loopt. Het lijkt er meer op dat het helemaal niet van buitenaf komt.
Ik denk niet dat het van de database komt. Ik had laatst allerlei ip's met meer dan 5 connecties genull route en toen had ik er meer dan een week geen last van. Zelfs als de server heel druk is, is de load normaliter niet meer dan ca 10%. Maar omdat de server vanmorgen is gereboot zijn natuurlijk alle geblokte ip's weer geunblokt en zo te zien dus ook die van de attacker.
Als je apache restart gaat het een poosje goed, en langzamerhand gaat de load naar 100%, dus waarschijnlijk wordt langzamerhand alle connecties ofzo opgeslokt.
no_player_4u
06/07/09, 22:48
Zie je bij een netstat veel connecties in SYN_RECV staan? Zo ja, dan heb je wsl een SYN Flood attack te pakken.
Gecheckt met dit commando
netstat -n -p|grep SYN_REC | wc -l
Maar de uitkomst zit steeds tussen de 1 en 3
Het heeft wel met apache te maken, want als ik apache kill, zakt de load meteen naar praktisch 0%.
no_player_4u
06/07/09, 22:55
Gecheckt met dit commando
netstat -n -p|grep SYN_REC | wc -l
Maar de uitkomst zit steeds tussen de 1 en 3
Het heeft wel met apache te maken, want als ik apache kill, zakt de load meteen naar praktisch 0%.
Dit is niet helemaal waar, het maximum varieert. een poosje is het ca 2 en dan kan het inene oplopen naar wel 32..
Je zou voor de gein je poort 80 eens dicht kunnen gooien.. Kijken hoe apache dan reageert..
Even mod_evasive installeren?
# apt-get install libapache2-mod-evasive
en dan in /etc/apache2/conf.d/security iets als dit:
<ifmodule mod_evasive20.c>
DOSHashTableSize 3097
DOSPageCount 2
DOSSiteCount 40
DOSPageInterval 1
DOSSiteInterval 2
DOSBlockingPeriod 300
DOSLogDir /var/log/apache2/mod_evasive
DOSWhitelist 127.0.0.*
DOSSystemCommand "/sbin/iptables -I INPUT -s %s -j DROP"
DOSEmailNotify root@localhost
</ifmodule>
apache restarten, et voila; IP van de DDoS source komt fijn in iptables blocklist, works like a charm.
dit ligt vermoedelijk aan een slecht stukje code, en niet zozeer aan een "langzame dos"... Ga eens na met mod_info (hostname/server-status/ met extendedstatus aan) welke pagina's bezocht worden door de processen ...
no_player_4u
07/07/09, 14:22
Even mod_evasive installeren?
# apt-get install libapache2-mod-evasive
en dan in /etc/apache2/conf.d/security iets als dit:
<ifmodule mod_evasive20.c>
DOSHashTableSize 3097
DOSPageCount 2
DOSSiteCount 40
DOSPageInterval 1
DOSSiteInterval 2
DOSBlockingPeriod 300
DOSLogDir /var/log/apache2/mod_evasive
DOSWhitelist 127.0.0.*
DOSSystemCommand "/sbin/iptables -I INPUT -s %s -j DROP"
DOSEmailNotify root@localhost
</ifmodule>
apache restarten, et voila; IP van de DDoS source komt fijn in iptables blocklist, works like a charm.
Thanks, maar dit heb ik al geinstalleerd. Maar mod-evasive werkt niet tegen slow DOS en blijkbaar ook niet tegen hetgeen ik nu last van heb.
Op dit moment is de load weer continue 100%, terwijl er niet veel meer bezoekers dan anders zijn. Ik ben er ook niet zo happig op om ip's meteen permanent te blokken, omdat er verschillende reden zijn waarom er meerder connecties vanaf 1 ip worden geopend. Veel van mijn bezoekers zitten bijv in het buitenland in een internet café en die dupeer je dan.
no_player_4u
07/07/09, 16:17
dit ligt vermoedelijk aan een slecht stukje code, en niet zozeer aan een "langzame dos"... Ga eens na met mod_info (hostname/server-status/ met extendedstatus aan) welke pagina's bezocht worden door de processen ...
Het zou kunnen, maar dit betwijfel ik sterk. Mijn server heeft een hele tijd zonder een enkele probleeem gedraaid en nooit kwam de load boven 10%. Zelfs niet bij een 'slashdot' effect waarbij ik opeens een paar duizend bezoekers tegelijk kreeg. Ik had niks aan de configuratie veranderd of packages geupdate etc en van het ene op het andere moment gaat de load naar 100%. Rara hoe kan dat? Het valt me ook op dat op het moment dat het niet continue is. Dus ca 10 minuten, dan houd het ff op en is de load normaal. Ook op het moment dat de load naar 100% gaat, komt er geen enkele request meer binnen.
Ook op het moment dat de load naar 100% gaat, komt er geen enkele request meer binnen.
Dat kan komen omdat alle httpd processen bezet zijn natuurlijk.
Ik ben er ook niet zo happig op om ip's meteen permanent te blokken, omdat er verschillende reden zijn waarom er meerder connecties vanaf 1 ip worden geopend. Veel van mijn bezoekers zitten bijv in het buitenland in een internet café en die dupeer je dan.De blokkade via IPtables is echter niet permanent, dat heb je zelf in de hand (zoals met alles in linux). Volgende restart is zo'n block sowieso al flushed.
Bovendien is de kans dat juist jouw bezoekers vanaf dat ene IP-adres je server op willen dermate klein dat je je daar nu niet echt zorgen over hoeft te maken, ik denk dat de kans dat je door de bliksem geraakt wordt flink wat groter zal zijn.
Je kunt ook eens kijken naar psad of mod_security, lijken me beiden interessant voor je casus in dezen.
no_player_4u
07/07/09, 20:50
Bovendien is de kans dat juist jouw bezoekers vanaf dat ene IP-adres je server op willen dermate klein dat je je daar nu niet echt zorgen over hoeft te maken, ik denk dat de kans dat je door de bliksem geraakt wordt flink wat groter zal zijn.
Dat weet ik wel :-), maar dat bedoelde ik ook niet. Vaak zijn er meerder mensen in dezelfde internetcafes op mijn site, vandaar.
Je kunt ook eens kijken naar psad of mod_security, lijken me beiden interessant voor je casus in dezen.
mod_security gebruik ik al. psad ga ik ook maar installeren.
Net waren er vanaf 1 ip ca 12 connecties, nadat ik die had geblokt zakte de load onmiddelijk naar ca 1%....
Hoe vind je uit wat er precies tussen de connectie van een bepaalde ip en een service gebeurd? Welke ip's er verantwoordelijk voor zijn dat apache door het lint gaat?
Als je bijv met netstat kijk dan zie honderden connecties naar apache, maar hoe vind je uit welke van die paar honderd zich misdragen?
Hoe vind je uit wat er precies tussen de connectie van een bepaalde ip en een service gebeurd?
Snifferen.
Levert alleen erg veel data op.
Maar je kan bijvoorbeeld de HTTP requests er tussen uit plukken om te kijken of er wellicht een bepaald scriptje wordt aangeroepen:
tshark -nR http.request
Voeg -V toe voor meer details.
Als je bijv met netstat kijk dan zie honderden connecties naar apache, maar hoe vind je uit welke van die paar honderd zich misdragen?
Met "top" kijk je welk process ID veel CPU slurpt.
Stel dat dit 1234 is, dan doe je:
netstat -np | grep 80 |grep 1234
(indien de webserver nog enigzins te bereiken is kan je het ook in mod_status zien)
wat staat in je httpd.conf ?
kijk gewoon even naar mod_status, en bij problemen kijk je eerst maar eens even welke pagina's het probleem geven. Ik vermoed dat je dan snel naar een permanente oplossing zal gaan...
no_player_4u
08/07/09, 14:33
Snifferen.
Met "top" kijk je welk process ID veel CPU slurpt.
Stel dat dit 1234 is, dan doe je:
netstat -np | grep 80 |grep 1234
(indien de webserver nog enigzins te bereiken is kan je het ook in mod_status zien)
Ze zijn nu weer bezig. Maar ik kan met bovenstaande methode niet zien welk ips mijn server attacken, omdat apache alleen maar bezig is met het creeren van nieuwe processen?
comando werkt nu niet niet meer:
apache2ctl status
***:/etc/apache2# apache2ctl status
Looking up localhost
Making HTTP connection to localhost
Sending HTTP request.
HTTP request sent; waiting for response.
Retrying as HTTP0 request.
Looking up localhost
Making HTTP connection to localhost
Sending HTTP request.
HTTP request sent; waiting for response.
Alert!: Unexpected network read error; connection aborted.
Can't Access `http://localhost/server-status'
Alert!: Unable to access document.
lynx: Can't access startfile
Wat kan ik nu doen?
no_player_4u
08/07/09, 14:35
kijk gewoon even naar mod_status, en bij problemen kijk je eerst maar eens even welke pagina's het probleem geven. Ik vermoed dat je dan snel naar een permanente oplossing zal gaan...
mod_status, is nu ook niet meer te benaderen...zie hierboven
Maar ik kan met bovenstaande methode niet zien welk ips mijn server attacken, omdat apache alleen maar bezig is met het creeren van nieuwe processen?
Waar baseer je dat op?
Zodra het aantal verbindingen gelijk is aan MaxClients/ServerLimit, maakt Apache geen nieuwe processen meer aan.
Als je bedoelt dat de pid's in top steeds wisselen, dan zijn waarschijnlijk al je Apache processen druk bezig hetzelfde foutieve script aan het uitvoeren, dat veel CPU loopt te verbruiken.
Kijk met tshark welke scripts aangeroepen worden.
Apache schrijft pas naar de access_log als het script klaar is.
Als je dus met snifferen ziet dat scripts aangeroepen worden, die nooit in de access_log komen, dan zit dat script waarschijnlijk in een oneindige loop.
no_player_4u
08/07/09, 15:51
Waar baseer je dat op?
Zodra het aantal verbindingen gelijk is aan MaxClients/ServerLimit, maakt Apache geen nieuwe processen meer aan.
Ja maar wanneer ik een pid uit top neem en die grep op netstat dan is de pid alweer verdwenen..
Waar baseer je dat op?
Kijk met tshark welke scripts aangeroepen worden.
Apache schrijft pas naar de access_log als het script klaar is.
Als je dus met snifferen ziet dat scripts aangeroepen worden, die nooit in de access_log komen, dan zit dat script waarschijnlijk in een oneindige loop.
IK heb gecheckt met tshark, maar er worden gewoon topics aan geroepen. Zo op het eerste gezicht staat er niks bijzonders tussen.
Wat betekent dit '[TCP Retransmission]'?
Waar baseer je dat op?
Als je dus met snifferen ziet dat scripts aangeroepen worden, die nooit in de access_log komen, dan zit dat script waarschijnlijk in een oneindige loop.
Kijk ik draai alleen een forum en verder niks meer. Zoals ik al eerder zei normaliter zelfs als het heel druk is komt de load niet boven de 10%.
Als er een foutief script was, dan zou de load altijd heel hoog moeten zijn en dat is niet het geval het is iets van de laaste weken.
En zoals gisteravond toen ik een ip met veel connecties blokte daalde de load naar 1% tot vanochtend weer.
Ja maar wanneer ik een pid uit top neem en die grep op netstat dan is de pid alweer verdwenen..
"Verdwenen" uit het overzicht van "top" (wat ik "wisselende pid's" noem), of niet te vinden in netstat (geen verbinding meer)?
Wat betekent dit '[TCP Retransmission]'?
Dat er wat packet loss is, en dat een van de computers daarom het TCP pakketje nog een keer gestuurd heeft.
Dat kan ook aan de verbinding van de bezoeker liggen.
Kijk ik draai alleen een forum en verder niks meer. Zoals ik al eerder zei normaliter zelfs als het heel druk is komt de load niet boven de 10%.
Als er een foutief script was, dan zou de load altijd heel hoog moeten zijn en dat is niet het geval het is iets van de laaste weken.
Bugs hoeven niet altijd op te treden.
Is het verder een standaard forum pakket of heb je die zelf geschreven?
Geen rare extra modules die RSS feeds weergeven, of anderzijds van externe bronnen afhankelijk zijn?
Pas anders even je conifguratie aan zodat PHP als CGI wordt gedraait, i.p.v. via mod_php.
Dan staan PHP en Apache apart in "top" en kan je gemakkelijker zien wat CPU slurpt.
En zoals gisteravond toen ik een ip met veel connecties blokte daalde de load naar 1% tot vanochtend weer.
Tenzij het om honderden verbindingen gaat, hoeft dat niet te betekenen dat diegene wat kwaads in zijn zin had.
Kan zijn dat de browser het te lang vondt duren, een nieuwe verbinding opzette, en hetzelfde probleemscript nog een keer aanroept.
no_player_4u
08/07/09, 17:25
"Verdwenen" uit het overzicht van "top" (wat ik "wisselende pid's" noem), of niet te vinden in netstat (geen verbinding meer)?
Wel in top maar niet in netstat.
Is het verder een standaard forum pakket of heb je die zelf geschreven?
Een standaard pakket die ik al zo'n twee jaar probleemloos draai
Ik heb verder tshark een poosje laten capturen en vervolgens verschillende statistieken gegrept maar er is niets wat eruit springt