Bekijk Volledige Versie : Server wordt aangevallen dmv erg veel page requests
Op willekeurige tijdstippen wordt mijn server aangevallen door een IP adres uit de cloud van Amazon EC2 (mail is al verstuurd en IP geblockt). Het is een soort DoS aanval waarbij er erg veel requests worden gedaan naar allemaal verschillende pagina's, een soort crawler die binnen enkele seconden tientallen pagina's probeert te openen. Dit resulteert in een onbereikbare server doordat het geheugen helemaal vol loopt, ook swap schiet vol. Het vervelende is dat het telkens andere IP adressen uit de cloud van Amazon zijn waardoor ik eigenlijk de hele tijd bezig ben met het bannen van IP adressen. Het lijkt dus op een gerichte aanval van iemand die het gemunt heeft op een van de websites op mijn server.
Wat kan ik hier het beste tegen doen? Het is een Directadmin server waarop een handjevol websites draaien van mezelf.
Hieronder een stukje uit mod_status:
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW W_S...........
.................................................. ..............
......................
Scoreboard Key:
"_" Waiting for Connection, "S" Starting up, "R" Reading Request,
"W" Sending Reply, "K" Keepalive (read), "D" DNS Lookup,
"C" Closing connection, "L" Logging, "G" Gracefully finishing,
"I" Idle cleanup of worker, "." Open slot with no current process
Srv PID Acc M CPU SS Req Conn Child Slot Client VHost Request
0-0 18838 1/22/128 W 1.79 1 0 2.2 0.20 1.54 54.242.92.244 www.x.nl:80 GET /index.php?option=com_mailto&tmpl=component&link=20fb04ede2
1-0 18848 0/25/158 W 0.83 0 0 0.0 0.30 1.44 54.242.92.244 www.x.nl:80 GET /component/tag/treinreis-utrecht HTTP/1.1
2-0 18826 1/27/142 W 1.02 4 0 0.7 0.10 1.40 54.242.92.244 www.x.nl:80 GET /component/tag/treinreis:belgi\xc3\xab:boeken HTTP/1.1
3-0 18814 1/51/186 W 1.33 0 0 5.6 0.60 1.47 54.242.92.244 www.x.nl:80 GET /component/tag/treinkaartjes-eindhoven HTTP/1.1
4-0 18849 1/13/146 W 0.55 4 0 0.7 0.02 1.23 54.242.92.244 www.x.nl:80 GET /component/tag/samenuitkorting:ns HTTP/1.1
5-0 18863 2/10/152 W 0.50 4 0 8.8 0.03 0.66 54.242.92.244 www.x.nl:80 GET /component/tag/treinkaartje:kopenhagen HTTP/1.1
6-0 18835 1/15/112 W 1.19 2 0 0.7 0.03 0.85 54.242.92.244 www.x.nl:80 GET /component/tag/treinkaartje:keulen HTTP/1.1
7-0 18869 0/2/103 W 0.49 4 0 0.0 0.01 1.19 54.242.92.244 www.x.nl:80 GET /ns-trein-nieuws/drugssmokkel-via-de-trein-mislukt/pdf HTTP
dennis0162
08/11/12, 17:38
Zo te zien valt de load nog mee. Zeker weten dat het aan Apache ligt?
Ik weet bijna zeker dat dit het probleem is. Toen de aanval net begon heb ik mod_status kunnen aanroepen daarna is het einde verhaal en zit de load over de 200 en is het geheugen inclusief swap helemaal vol.
Zijn die IP's echt 100% verschillend of is het eerste deel wel gelijk? Netjes is anders, maar als dat het geval is gewoon tijdelijk dat subnet in de firewall zetten. Zo te zien is het overigens Joomla, niet toevallig ergens een lek script?
De adressen zijn allemaal van Amazon EC2 en ja er draait joomla op maar dat moet niet uitmaken denk ik. Er komen allemaal verschillende paginas voor en die worden allemaal tegelijk geopend, iets wat je niet lukt met de hand maar echt gericht doet. Heb nu 3 ip adressen geblokkeerd en ik heb ook al zitten nadenken om de hele subnet een ban te geven maar het liefst heb ik een oplossing voor het probleem zodat ik zeker weet dat in de toekomst dit soort narigheid geen effect meer heeft.
Joomla wordt vrijwel dagelijks in grote hoeveelheden gehackt en misbruikt (zeker als het geen recente versie is) dus het maakt in die zin wel degelijk uit. Goed scannen om in iedergeval eventueel kwalijke scripts weg te kunnen halen. Ik zeg niet dat het probleem daar zit, wel dat je het moet uitsluiten.
Het klopt dat veel gebruikte systemen vaak opgezocht worden om te hacken maar ik weet zeker dat alles up to date is en er zover ik weet geen lekken zijn. Het vreemde is dat er tientallen verschillende paginas tegelijk worden geopend door 1 ip adres en dit laat de server helemaal vastlopen. Het lijkt me niet dat er exploits worden uitgevoerd want het zijn allemaal get requests met een normale url zonder gekke tekens of sql injection achtige zinnen achter de url. Ik vermoed dat iemand hierachter zit met de bedoeling om de server offline te krijgen.
dreamhost_nl
08/11/12, 19:55
Heb je CSF/LFD als firewall draaien? Wellicht dat je met de PORTFLOOD functie de hoeveelheid simultane connecties per IP-adres kunt in gaan stellen over poort 80?
Ik zou zeggen google eens op slow loris attack, dan zul je vanzelf wel een paar oplossingen vinden voor je probleem, van apache modules tot firewall rules of proxy's. Wil je een vlugge oplossing (of tijdelijke oplossing) zet dan in je firewall dat er maar x aantal connecties per ip toegelaten zijn.
Ik maak al gebruik van mod_reqtimeout en dat schijnt hetzelfde te werken als antiloris (volgens de DA help pagina). Ook maak ik al gebruik van csf maar weetniet precies wat ik dan moet instellen hiervoor. Als ik naar connlimit kijk binnen csf kan ik wel een rule opstellen die een x aantal connecties per poort per seconde bepaald maar dan kom ik alsnog op hetzelfde probleem dat dit iedere seconde mogelijk is. Css bestanden en afbeeldingen worden allemaal als nieuwe verbinding gezien dus als ik dit te laag instel kan een pagina trager laden. Wat is de beste oplossing voor dit probleem? Ik neem aan dat vele hier tegen bestendigd zijn op professionele webhosting omgevingen. Iig bedankt voor al jullie reacties!
Ik zie dat mod_antiloris niet meer sinds 2010 is geupdate en er met Apache 2.4 wat problemen zijn. Ook lees ik dat mod_reqtimeout beter is dan mod_antiloris maar dit gebruik ik al en stopt de aanvallen niet.
Wat is het beste wat ik kan doen? Een subnet blokkeren lost het probleem niet op maar stelt het uit tot de volgende keer... Ik draai ook CSF maar weet niet wat ik specifiek zou moeten instellen. Het probleem is eigenlijk dat er allemaal pagina's worden geopend door 1 IP adres wat ervoor zorgt dat de hele server vertraagd, ram en swap lopen vol en cpu load over de 200...
Als je CSF hebt draaien kun je toch heel gemakkelijk dat ene IP blokkeren ?
Dat heb ik ook al gedaan, 3 ip adressen, maar dat lost het probleem niet op maar stelt het uit tot het zich weer voordoet... Ik zoek een oplossing in de vorm van een limiet per ip of iets in die richting? De meeste mensen hier zullen daar meer over weten dan mij daarom vraag ik hier wat het beste is om te doen en wat jullie gebruiken om dit soort zaken te stoppen.
systemdeveloper
09/11/12, 00:27
Niet lastig doen; je kunt die hele /24 of zelfs /16 van amazon gewoon blokken aangezien een andere 'server' (die niet van google/bing is) in principe niks te zoeken heeft op je site. In 99-100 gevallen heeft een site alleen maar baat bij user connecties (ziggo, tele2, upc, etc) en die lopen echt niet via subnetten van amazon ec.
Enige waar je wellicht wat mee moet oppassen is dat je geen proxies van bv scholen, bedrijven uitsluit, maar de kans dat een school of bedrijf hun proxy bij amazon onderbrengt is zowat nihil (zo ook wel erg blöd zijn)
Ik wilde je advies opvolgen maar toen ik goed keek zag ik dat de IP adressen in verschillende subnetten zitten dus dan heeft niet ook niet veel nut om hele subnetten te blokkeren (de IP adressen begonnen al verschillend namelijk; 50.xx.xx.xx en 51.xx.xx.xx). Wel zijn de aanvallen al enkele uren gestopt :)
Maar hoe regelen jullie dit soort zaken? Hanteren jullie een maximaal aantal connecties per ip of bepaalde modules die dit soort 'aanvallen' tegenhouden?
systemdeveloper
09/11/12, 01:17
Ik wilde je advies opvolgen maar toen ik goed keek zag ik dat de IP adressen in verschillende subnetten zitten dus dan heeft niet ook niet veel nut om hele subnetten te blokkeren (de IP adressen begonnen al verschillend namelijk; 50.xx.xx.xx en 51.xx.xx.xx). Wel zijn de aanvallen al enkele uren gestopt :)
Maar hoe regelen jullie dit soort zaken? Hanteren jullie een maximaal aantal connecties per ip of bepaalde modules die dit soort 'aanvallen' tegenhouden?
Het eerste wat je moet doen is goed cachen. Dat zorgt niet alleen dat je wat meer bezoekers aankunt, maar zorgt ook dat je een goed onderscheid kunt maken tussen ipadressen die normale connecties maken en ipadressen die ruim boven de 'standaard' voor jouw site uitkomen.
Daarna kun je met een relatief eenvoudig scriptje (denk aan netstat -ntu) controleren welke ipadressen teveel connecties maken en deze (tijdelijk) blokkeren in de firewall.
CSF kan daarnaast ook nog veel leuke dingen doen natuurlijk.
Eventueel kun je ook nog een scriptje maken dat wanneer de load van de server te hoog wordt simpelweg de top 20% connecties even blocked en dit blijft doen totdat de load weer acceptabel is.
Wat je in elk geval wel moet zien te voorkomen is dat je server gaat swappen. Als ie dat eenmaal doet dan helpen de meeste toeters en bellen je niet meer. Een eenvoudige oplossing kan dan zijn om minder http processen toe te staan. Standaard staat dat ergens op 450 dacht ik, maar dat aantal moet in overeenstemming zijn met je RAM en de hoeveelheid geheugen dat 1 httpd process gebruikt. Het is best mogelijk dat je op zo'n moment dit naar 30-40-50 moet trappen om swapping te voorkomen.
Bovenstaande zijn in principe 'poor mans' oplossingen, maar die zijn wel gemakkelijk te realiseren, kicken vaak pas in op het moment dat er problemen zijn en ze kúnnen redelijk effectief zijn.
Een echte ddos ga je er niet altijd mee tegenhouden natuurlijk. Dat lukt vaak nog niet eens met speciale apparatuur van xx.xxx eurootjes.
Het eerste wat je moet doen is goed cachen. Dat zorgt niet alleen dat je wat meer bezoekers aankunt, maar zorgt ook dat je een goed onderscheid kunt maken tussen ipadressen die normale connecties maken en ipadressen die ruim boven de 'standaard' voor jouw site uitkomen.
Daarna kun je met een relatief eenvoudig scriptje (denk aan netstat -ntu) controleren welke ipadressen teveel connecties maken en deze (tijdelijk) blokkeren in de firewall.
CSF kan daarnaast ook nog veel leuke dingen doen natuurlijk.
Eventueel kun je ook nog een scriptje maken dat wanneer de load van de server te hoog wordt simpelweg de top 20% connecties even blocked en dit blijft doen totdat de load weer acceptabel is.
Wat je in elk geval wel moet zien te voorkomen is dat je server gaat swappen. Als ie dat eenmaal doet dan helpen de meeste toeters en bellen je niet meer. Een eenvoudige oplossing kan dan zijn om minder http processen toe te staan. Standaard staat dat ergens op 450 dacht ik, maar dat aantal moet in overeenstemming zijn met je RAM en de hoeveelheid geheugen dat 1 httpd process gebruikt. Het is best mogelijk dat je op zo'n moment dit naar 30-40-50 moet trappen om swapping te voorkomen.
Bovenstaande zijn in principe 'poor mans' oplossingen, maar die zijn wel gemakkelijk te realiseren, kicken vaak pas in op het moment dat er problemen zijn en ze kúnnen redelijk effectief zijn.
Een echte ddos ga je er niet altijd mee tegenhouden natuurlijk. Dat lukt vaak nog niet eens met speciale apparatuur van xx.xxx eurootjes.
Het komt vanaf een enkel IP adres en als ik kijk naar de grafieken zie ik geen dataverkeer pieken dus een DDoS kan ik het niet noemen. Misschien ligt het inderdaad aan de configuratie van mijn server, het is een server met 1GB ram en 2 cores. Het normale verbruik ligt tussen de 550/700MB RAM.
Op dit moment ziet mijn MPM prefork configuratie er zo uit.
<IfModule mpm_prefork_module>
StartServers 5
MinSpareServers 5
MaxSpareServers 10
ServerLimit 150
MaxClients 150
MaxRequestsPerChild 5000
Timeout 60
KeepAlive on
MaxKeepAliveRequests 55
KeepAliveTimeout 5
</IfModule>
Als het hier niet aan ligt moet ik misschien maar eens gaan kijken naar CONNLIMIT en PORTFLOOD in CSF, alhoewel ik me twijfels erbij heb want ik lees op verschillende forums dat dit soms ook legitieme gebruikers blokkeert. Maar dat is natuurlijk ook weer een kunst van goed afstellen, al lijkt me een 'poor man' oplossing met de Apache configuratie de mooiste oplossing hiervoor.
> Ik wil iedereen bedanken die heeft gereageerd :)
Jammer genoeg 15 minuten geleden weer hetzelfde verhaal maar dit keer leek de server het niet te begeven maar wel weer een hele lijst van 1 ipadres in mod_status. Iemand die mij de goede richting kan wijzen? Connlimit of iets anders wat zou "moeten" helpen. Het gaat erom dat een ip adres niet zoveel pagina requests mag doen binnen enkele seconden.
systemdeveloper
11/11/12, 18:40
Requests bijhouden kun je in een paar regels code in het begin van je website doen.
Je kunt het aantal CONNECTIES met iptables natuurlijk wel limiteren maar dan tel ie ook connecties naar images die meestal juist niet voor de load zorgen. Eén pagerequest kunnen dan tientallen (of meer) tcp connecties zijn.
Een php oplossing kan natuurlijk ook maar dan is een blanco pagina met een waarschuwing ook 1 request en dan zitten we alsnog met het punt dat de request doorkomt. Ik vrees dat ik niet anders kan dan het aantal connecties limiteren. Wat is in jullie ogen gangbaar? 20 max per seconde?
Arie Timmerman
12/11/12, 23:25
Een php oplossing kan natuurlijk ook maar dan is een blanco pagina met een waarschuwing ook 1 request en dan zitten we alsnog met het punt dat de request doorkomt. Ik vrees dat ik niet anders kan dan het aantal connecties limiteren. Wat is in jullie ogen gangbaar? 20 max per seconde?
Dat is voor normale bezoekers meer dan genoeg. Ik vrees alleen dat het voor je SEO minder goed is. Spiders willen wel eens sneller crawlen dan deze 20. Als tussenoplossing lijkt mij dit prima.
Ben je niet in de verkeerde hoek aan het zoeken? Een crawler, al dan niet goed geprogrammeerd, moet je server niet onderuit kunnen halen. Dat betekend dat iedere willekeurig persoon je server onderuit kan halen dmv 'ab'.
Ik zou eerder je configuratie nalopen.
/edit
Ik zie dat je Joomla 1.5 draait, is 1.5 niet verouderd?
Momenteel in CSF connlimit op 20 gezet voor port 80. Dat betekend dus dat er maximaal 20 open verbindingen op port 80 per IP zijn toegestaan. Lijkt mij dat crawlers hier wel mee overweg kunnen? Een request van een afbeelding is sneller dan een halve seconde gedaan dus dat moet dan toch binnen de marges vallen (lijkt mij).
De website draait inderdaad op Joomla 1.5 (de laatste versie van 1.5) en dat zal misschien wel altijd zo blijven mits er geen lekken worden gevonden en anders zal er gekeken moeten worden naar workarounds die niet via officiële kanalen lopen (site is van een vriend). Na wat speurwerk kom ik tot de conclusie dat de crawler 100 actieve verbindingen in stand houdt (tegelijk). Met connlimit moet ik nu al aardig op weg zijn en ik wacht dan ook rustig af tot de volgende 'attack'. Voor negatieve SEO resultaten ben ik niet zo bang want 20 open verbindingen tegelijk is toch aardig wat denk ik zo, al indexeer je 3 pagina's per seconden kom je hier moeilijk aan. Dan heb je van een minuut al bijna 200 pagina's geindexeerd en dat heb ik Google nog nooit zien doen (of ik moet fout zitten maar dan hoor ik dat graag :yes:)
@xaban, dan even specifiek op wat je zei over de configuratie. Wat zou er mis moeten zijn dan? Ik maak gebruik van mod_php en mpm prefork en dat is niet de meest zuinige engine qua memory verbruik maar een server van 1GB ram kan toch geen 100 actieve verbindingen aan binnen laten we zeggen 3 seconden? En anders ben ik benieuwd hoe jij dat dan doet..
Als iemand nog tips of ideeën heeft hoor ik dat graag :)
Welke crawler (en met name van welke zoekmachine) vormt het probleem? Er zijn verschillende zoekmachines waar je zelf op kan geven hoeveel requests ze in een bepaalde periode mogen doen. Mogelijk is het zinvol dat in te stellen.
Het is geen bekende crawler...
crossplatform
13/11/12, 12:14
- timeout in apache verlagen
- ga door je apache en php modules met een bijl en schakel uit wat niet nodig is
- mod_status is een resource killer, uitzetten scheelt
- als je geen stats draai apache access logging uitschakelen
hebben de bezoeken geen invloed op je mysql server? Standaard is deze totaal niet geoptimaliseerd.
Misschien valt daar ook nog (veel) winst te behalen.
Als je je zorgen maakt op SEO en crawlers etc dan zou ik cfs connecties verhogen. Mocht er geen aanval meer komen dan is deze waarde voldoende.
Anders kan je deze nadien nog verder beperken.
Succes!
Ik gebruik mysql-large als config en verder niet gesleuteld eraan. Er zitten grote websites tussen die wat resources opeisen maar als ik kijk naar piek uren zie ik het ram geheugen tot hooguit 75%. Ik heb connlimit op 20 gezet voor port 80 in csf denkt iemand dat dit te laag is voor "google" want dat is eigenlijk de enigste zoekmachine waar ik rekening mee wil houden. En nogmaals, hoe hebben jullie dit geregeld? Wat gebeurd er als een crawl bot 100 simultane verbindingen in stand houdt en allemaal verschillende paginas bezoekt?
Goed nieuws heren. Via CSF heb ik een manier gevonden om dit tegen te gaan. Eigenlijk heel simpel maar het stond nergens in de readme.txt dus ik zag het over het hoofd.
Ik heb connlimit uitgezet en ct_limit op max 40 connecties (per ip) met ct_ports op 80. Meteen even getest met wat iframes in een html bestand en flink ge-F5't, en de ban was er al snel, mooi :)
40 connecties per ip is iets te laag, ben nu aan het spelen met hogere waardes :)
70 lijkt prima te werken, tot nu toe nog geen false positives gezien! Hopelijk heeft iemand hier nog wat aan :)
ct_limit 70
ct_ports 80