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: