DDoS HTTP aanval

[3raser]

Heeft iemand van jullie wel eens zo'n aanval gezien?

code:

185.122.170.186 - - [06/Feb/2021:15:08:46 +0100] "GET /?s=6%20l%20yi HTTP/1.0" 403 536 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.101 Safari/537.36"
104.227.146.124 - - [06/Feb/2021:15:08:46 +0100] "GET /?s=y%20u%208p HTTP/1.0" 403 536 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.101 Safari/537.36"
45.152.198.192 - - [06/Feb/2021:15:08:47 +0100] "GET /?s=q%204%20nt HTTP/1.0" 403 536 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.101 Safari/537.36"
5.157.55.142 - - [06/Feb/2021:15:08:47 +0100] "GET /?s=2%20s%20pa HTTP/1.0" 403 536 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.101 Safari/537.36"
45.120.50.122 - - [06/Feb/2021:15:08:47 +0100] "GET /?s=1%202%200b HTTP/1.0" 403 536 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.101 Safari/537.36"
185.104.217.149 - - [06/Feb/2021:15:08:47 +0100] "GET /?s=f%20b%201j HTTP/1.0" 403 536 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.101 Safari/537.36"
103.247.151.174 - - [06/Feb/2021:15:08:47 +0100] "GET /?s=6%20o%20pp HTTP/1.0" 403 536 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.101 Safari/537.36"
5.157.55.201 - - [06/Feb/2021:15:08:48 +0100] "GET /?s=c%20o%20db HTTP/1.0" 403 536 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.101 Safari/537.36"
45.120.51.28 - - [06/Feb/2021:15:08:48 +0100] "GET /?s=1%20g%204l HTTP/1.0" 403 536 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.101 Safari/537.36"
5.157.55.251 - - [06/Feb/2021:15:08:48 +0100] "GET /?s=5%20h%206a HTTP/1.0" 403 536 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.101 Safari/537.36"

Behalve het plat krijgen van de website zie ik er niets bijzonders in. Maar ik begrijp de aanvraag ook niet zo goed. Is die s query parameter simpelweg om de aanvraag te randomizen om caching te ontlopen?

Deze aanval is al meer dan 12 uur non-stop bezig. Via een RewriteRule heb ik alle aanvragen met ?s=* doorverwezen naar een 403 error. De server heeft er dus weinig last van. Maar de aanvaller lijkt er ook niet op te reageren door te stoppen of zich aan te passen.
Herkent iemand de aanvragen? Is dit een specifiek stukje software die deze aanpak gebruikt of zie ik iets bijzonders over het hoofd?

[Hero of Time]

Geen idee wat het moet doen, lijkt op een bekende exploit proberen te misbruiken. Maar je kan ook fail2ban installeren en alle IP adressen die dit opvraagt direct bannen. Dan wordt het al geblokkeerd voordat het bij je webserver aan komt en scheelt weer iets aan resources. Uiteindelijk zal er geen antwoord meer komen voor de aanvaller.

Dit soort zaken zal trouwens eerder geautomatiseerd worden uitgevoerd, zoals je ook ziet aan de verschillende bron adressen. Dit blijft dan een ingestelde tijd doorgaan of de software dat de aanval aanstuurt zal een ander bron adres proberen als het geen reply meer krijgt. Een 403 sturen is nog steeds de aanvraag afhandelen en dat wil je juist bij dit soort aanvallen niet. Dat wil je zo vroeg mogelijk afkappen.

[McKaamos]

Wat @Hero of Time zegt. Dit ziet er meer uit als een exploit.
Draai je toevallig een vrij bekend CMS pakket?

Beste wat je kan doen is inderdaad iets als Fail2ban gebruiken.
Andere optie is NginX als webserver gaan gebruiken (of als proxy tussen webserver en buitenwereld zetten) en dan dit soort requests beantwoorden met statuscode 444. Dat is een speciale code van NginX die niet veel anders betekent dan 'niks terugsturen en direct verbinding sluiten'.

[3raser]

Hero of Time schreef op zaterdag 6 februari 2021 @ 15:50:
Geen idee wat het moet doen, lijkt op een bekende exploit proberen te misbruiken. Maar je kan ook fail2ban installeren en alle IP adressen die dit opvraagt direct bannen. Dan wordt het al geblokkeerd voordat het bij je webserver aan komt en scheelt weer iets aan resources. Uiteindelijk zal er geen antwoord meer komen voor de aanvaller.

Daar ben ik een beetje trerughoudend in. Er lijken veel Nederlandse IP adressen bij te zitten en ik wil daarom geen complete netwerkblokken blokkeren.

Dit soort zaken zal trouwens eerder geautomatiseerd worden uitgevoerd, zoals je ook ziet aan de verschillende bron adressen. Dit blijft dan een ingestelde tijd doorgaan of de software dat de aanval aanstuurt zal een ander bron adres proberen als het geen reply meer krijgt. Een 403 sturen is nog steeds de aanvraag afhandelen en dat wil je juist bij dit soort aanvallen niet. Dat wil je zo vroeg mogelijk afkappen.

Eens. Maar door het type aanval is dat lastig.

McKaamos schreef op zaterdag 6 februari 2021 @ 19:27:
Wat @Hero of Time zegt. Dit ziet er meer uit als een exploit.
Draai je toevallig een vrij bekend CMS pakket?

Het is een Wordpress website met Nginx als reverse proxy. De serverload is gelukkig extreem laag.

De aanval is overigens nog steeds gaande.

[DiedX]

Toch fail2ban maar eens overwegen. Die deblokkeerd ook vanzelf na $minuten.

[DJMaze]

Ik keek net naar een paar IP adressen.
Het zijn Proxy servers.

[Hero of Time]

3raser schreef op zondag 7 februari 2021 @ 08:46:
[...]

Daar ben ik een beetje trerughoudend in. Er lijken veel Nederlandse IP adressen bij te zitten en ik wil daarom geen complete netwerkblokken blokkeren.

Je blokkeert geen hele subnetten, alleen de adressen. Dus als je 10.0.0.1 zou blokkeren, kan 10.0.0.2 er nog gewoon bij.

[...]

Het is een Wordpress website met Nginx als reverse proxy. De serverload is gelukkig extreem laag.

De aanval is overigens nog steeds gaande.

Dit is precies de reden waarom je het dus direct moet blokkeren. Al het verkeer droppen en verder gaan met je leven.

Kijk trouwens wel even extra op je systeem of er niet iets ongewenst aanwezig is. Zeker bij zoiets als Wordpress zijn er talloze lekken die misbruikt worden.

[Kabouterplop01]

Kun je die nginx (ik heb er niet veel kennis van) niet als een waf inzetten en er bijvoorbeeld URL encoded strings mee filteren? Dan is het van je server af. Met zo'n filter kun je ook de meest voorkomende sqli stoppen.
(de sql queries wil je vanaf de webserver naar de db sturen en niet vanaf het interwebz)

[McKaamos]

Hero of Time schreef op zondag 7 februari 2021 @ 10:24:
[...]

Je blokkeert geen hele subnetten, alleen de adressen. Dus als je 10.0.0.1 zou blokkeren, kan 10.0.0.2 er nog gewoon bij.

Dit. Dat is waar Fail2Ban voor gemaakt is.

Korte samenvatting: Fail2Ban monitort logs van applicaties die je zelf kiest.
Ziet hij te vaak bepaalde requests langs komen van 1 IP, dan maakt hij een firewall regel voor dat ene specifeke IP adres.
Bij X foute requests in X minuten zet hij het IP voor X minuten in de firewall.
Dat mechanisme kan je ook nog weer terug loopen zodat je automatisch langere ban-tijden kan instellen voor repeat offenders.
En uiteraard gaat het IP automatisch weer uit de firewall zodra het weer windstil is.

[...]

Dit is precies de reden waarom je het dus direct moet blokkeren. Al het verkeer droppen en verder gaan met je leven.

Yes. Hoe langer je systeem aangeeft bereikbaar te zijn, hoe langer de 'aanvaller' (waarschijnlijk een of ander automatisch scanner script) denkt dattie gewoon door kan gaan en de boel niet overbelast oid.

Fail2Ban is de oplossing. Of zelf regeltjes maken in NginX en statuscode 444 terug geven.

Kijk trouwens wel even extra op je systeem of er niet iets ongewenst aanwezig is. Zeker bij zoiets als Wordpress zijn er talloze lekken die misbruikt worden.

[Hero of Time]

Kabouterplop01 schreef op zondag 7 februari 2021 @ 12:31:
Kun je die nginx (ik heb er niet veel kennis van) niet als een waf inzetten en er bijvoorbeeld URL encoded strings mee filteren? Dan is het van je server af. Met zo'n filter kun je ook de meest voorkomende sqli stoppen.
(de sql queries wil je vanaf de webserver naar de db sturen en niet vanaf het interwebz)

De TS geeft al een 403 terug. Maar wat je ook doet met je webserver, die moet nog steeds het verzoek behandelen. Zelfs als dit 'uit de handen laten vallen' is. Dit soort ongein wil je stoppen vóórdat het bij je webserver komt.

[Kabouterplop01]

dank voor de info, weer wat geleerd \o/

[3raser]

McKaamos schreef op zondag 7 februari 2021 @ 13:29:
[...]

Dit. Dat is waar Fail2Ban voor gemaakt is.

Korte samenvatting: Fail2Ban monitort logs van applicaties die je zelf kiest.
Ziet hij te vaak bepaalde requests langs komen van 1 IP, dan maakt hij een firewall regel voor dat ene specifeke IP adres.
Bij X foute requests in X minuten zet hij het IP voor X minuten in de firewall.
Dat mechanisme kan je ook nog weer terug loopen zodat je automatisch langere ban-tijden kan instellen voor repeat offenders.
En uiteraard gaat het IP automatisch weer uit de firewall zodra het weer windstil is.

[...]

Yes. Hoe langer je systeem aangeeft bereikbaar te zijn, hoe langer de 'aanvaller' (waarschijnlijk een of ander automatisch scanner script) denkt dattie gewoon door kan gaan en de boel niet overbelast oid.

Fail2Ban is de oplossing. Of zelf regeltjes maken in NginX en statuscode 444 terug geven.

[...]

Maar dan moet ik fail2ban dus leren dat deze verzoeken niet normaal zijn? Bovendien is ieder verzoek vrijwel uniek dankzij de onzin parameter dus van herhalingen is eigenlijk geen sprake. Hoe pakt fail2ban zoiets op zonder legitiem verkeer te hinderen?

[McKaamos]

3raser schreef op zondag 7 februari 2021 @ 21:50:
[...]

Maar dan moet ik fail2ban dus leren dat deze verzoeken niet normaal zijn? Bovendien is ieder verzoek vrijwel uniek dankzij de onzin parameter dus van herhalingen is eigenlijk geen sprake. Hoe pakt fail2ban zoiets op zonder legitiem verkeer te hinderen?

Fail2Ban wordt geleverd met standaard configuraties voor o.a. Apache en NginX.
Daar staat b.v. in dat requests die worden beantwoord met 401 (foute login) na X aantal pogingen een IP ban krijgen voor X minuten.

Voor dingen die specifiek gericht zijn op Wordpress, bestaan er ook configuraties. Er bestaan er genoeg van, kwestie van even zoeken en toevoegen.
Ik verwacht dat dergelijke configuraties wel regels bevatten voor de bekende issues/CVE's op Wordpress.
Dat zou genoeg moeten zijn.

En anders kan je altijd nog je eigen config schrijven.

Hoe het werkt is dat er simpelweg dingen als regular expressions worden gebruikt om de request URL te evalueren. Alles wat standaard wordpress is wordt doorgelaten en alles wat niet in de 'happy flow' past wordt gemarkeerd als fout en krijgt na X pogingen een IP ban.

[Yarisken]

3raser schreef op zondag 7 februari 2021 @ 21:50:
[...]

Maar dan moet ik fail2ban dus leren dat deze verzoeken niet normaal zijn? Bovendien is ieder verzoek vrijwel uniek dankzij de onzin parameter dus van herhalingen is eigenlijk geen sprake. Hoe pakt fail2ban zoiets op zonder legitiem verkeer te hinderen?

Niet, met fail2ban ga je niet veel zijn. De aanvaller gebruikt verschillende ip's maar heel kort.

Het enige wat in dit geval werkt is het schrijven van custom rules zoals je al zelf gedaan hebt.
Voor de rest is er niks aan te doen tenzij je risico wil lopen om gewoon verkeer te blokkeren.

[3raser]

De aanval is gisterenavond afgebroken.

Weet iemand trouwens hoe je een .htaccess RewriteRule maakt die niet wordt geredirect naar een custom error page? Mijn huidige rewriterule is:

code:

RewriteCond %{QUERY_STRING} (s=)(.*) [NC]
RewriteRule .* - [F,L]

Alle aanvragen met parameter S krijgen hierdoor een 403 error. De F zou normaal gesproken ook direct een L zijn dus die extra L is misschien dubbelop. Maar op de website krijg ik met deze error dus een custom page te zien wat extra laadtijd kost. Hoe voorkom ik dit?

[edit] Ik heb mijn htaccess nu iets aangepast zodat ik een eigen custom error page laat zien.

code:

ErrorDocument 403 403.html

RewriteCond %{QUERY_STRING} (s=)(.*) [NC]
RewriteRule .* - [F,L]

Aanvallers worden hierdoor doorverwezen naar 403.html waarin ik met een enkele tekstregel "403 Forbidden" de aanval afhandel. Omdat dit een statisch document is kan Nginx deze op hoge snelheid afhandelen waardoor minimale server capaciteit nodig is.

[Voor 30% gewijzigd door 3raser op 08-02-2021 09:07]