Hogyan hárítottam el egy brute force támadást?

Mivel az általam kezelt oldalak nagy része Cloudflare mögött van, ezért a támadások egy jó hányada automatikusan "elhárítódik", azonban - ahogyan az iménti eset is mutatta - ez nem tökéletes védelem. A támadók ebben az esetben egész ügyesek voltak: keresztüljutottak a Cloudflare automatikus szűrésén, illetve folyamatosan változtatgatták az IP címeiket is (valószínűleg egy botnet volt), és eljutottak a CMS bejelentkező oldaláig, ahol a védelmi plugin megfogta őket. Persze, az a cucc erre van, de azért mégis rossz érzés, hogy egyedül azért nem jutottak be, mert az oldal jelszavát nem ismerték - ami, valljuk be, azért ahhoz hasonló, mintha a bejárati ajtón hallanánk a betörő szöszmötölését, és csak azért nem jutna be, mert éppen nincs nála a kulcsunk...

Az első ötletem rögtön az volt, hogy megemelem a Cloudflare-n a védelmi szintet I'm under attack-re, ami azért hosszútávon nem feltétlenül tartható, így egy jobb megoldás után néztem. A Cloudflare nemrég vezette be a Firewall opciót az admin felületén, ahol még az ingyenes csomagban is 5 szabályt használhatunk - és mint kiderült:

• NAGYON jól működik,
• ez az 5 szabály bőségesen elég egy "sima" oldalnak.

Mivel folyamatosan jöttek a támadásról szóló értesítések, ezért könnyű helyzetben voltam, rögtön láttam az intézkedések hasznát/haszontalanságát - ezúton is köszi Hanoi és Ho Chi Minh City! :)

Létrehoztam tehát egy tűzfal szabályt a bejelentkező URL-re (Field: URI) oly módon, hogy tartalmazzon (Operator: contains) egy, csak a bejelentkező felületen szóba jövő URL töredéket - ez ebben az esetben a wp-login.php (Value) volt. Intézkedésként pedig egy JS challenge-t kértem: ilyenkor a böngészővel egy JavaScript feladványt oldat meg a Cloudflare, amíg a látogató egy 5 másodperces köztes oldalt lát, valami ilyesmit:

Feljebb említettem, hogy ügyesek voltak a támadók (feltéve, hogy botok voltak - ha emberek, akkor nagyon türelmesek): azért írtam ezt, mert még ezen is átjöttek. Így egy kicsit szigorítottam a szabályon és Captcha Challenge-t kértem. Ezzel a látogatóknak egy Google-ös Nem vagyok robot-pipát kell bepipálniuk: ilyet már mindannyian láttunk, de azért megmutatom, hogyan néz ki ebben az esetben:

Ha ezek után nem kapunk több értesítést, akkor sikerült érdemben megnehezítenünk a támadást. Ha nem sikerült, akkor mehetünk tovább is a szabályokkal, például kombinálhatjuk az URL alapú szabályt ország alapú szabállyal (AND és OR) kialakítva ezzel olyan szabályrendszereket, mint: 

• az oldal egészét blokkoljuk a Kínából érkező kérésekre, 
• az oldal egészét tegyük Captcha mögé a Thaiföldről VAGY Kínából érkező kérések esetén, 
• kérjünk JS challenge-t, ha a kérés (Azerbajdzsánból érkezik ÉS a bejelentkező URL-re irányul) VAGY (Vietnámból jön és az oldal bármely területére vonatkozik)

A spórolós rendező elv a szabályok kialakítása során tehát a kért intézkedés minősége alapján lehet hatékony, így az ingyenes csomagban 5 ilyet alakíthatunk ki.

Fő megállapítások:

• nem rossz, ha van egy biztonsági plugin az oldalunkon, feltéve, hogy a tárhely szolgáltatónk nem gondoskodik az ilyen kérések automatikus szűréséről,
• ha van is ilyenünk, még jobb, ha már a szerverig sem jut el a kérés, ezért inkább már a kapcsolódáskor állítsuk meg őket: itt jön képbe a Cloudflare
• a plusz interaktivitás igény (kattintás), illetve az 5 másodperces várakozás miatt nem érdemes az egész oldalra aktiválni a védelmet, hanem csak azokra az URL-ekre, amiken bejelentkezési lehetőség van (Craft CMS esetén például a /<cpTrigger>/login, WordPress esetén a wp-login.php, Joomla! esetén pedig a /administrator jó szabályoknak tűnnek)

Remélem, hogy - követve az itt írtakat - sikerült biztonságosabbá tenned a weboldaladat. Ha bármilyen kérdésed, javaslatod van a cikk tartalmával kapcsolatban, esetleg segítségre van szükséged, keress bizalommal!