Röviden: A bejelentkezés hatékony brute force elleni védelme több rétegből áll: kétfaktoros bejelentkezés az összes adminnak, a bejelentkezési kísérletek lassítása a webszerverben, automatikus zárolások hálózati szinten, és biztonságos jelszótárolás a kódban. Ahol lehetséges, az admin terület ezen felül csak ismert hálózatokról érhető el.
Hogyan zajlanak a brute force támadások a bejelentkezések ellen
Minden nyilvánosan elérhető bejelentkezési oldalt előbb-utóbb automatizáltan támadnak. Ez érinti a CMS-bejelentkezéseket, a webshop-backendeket, a tárhelypaneleket, a webmailt és az SSH-t. A támadóknak ehhez nem kell tudniuk, kié a weboldal; az eszközeik az internetet ismert bejelentkezési címek után keresik.
Három változat elterjedt. A klasszikus brute force-nál sok jelszót próbálnak ki egy fiókkal szemben. A password spraying-nél egy gyakori jelszót tesztelnek sok fiókon, hogy megkerüljék a zárolásokat. A credential stuffing-nél más szolgáltatásoknál ellopott hozzáférési adatokat használnak.
A vezetőség és a tulajdonosok számára a helyzet egyszerűen összefoglalható: egy átvett rendszergazdai fiók ugyanolyan veszélyes, mint a szerver biztonsági rése. Aki rendszergazda, az bővítményeket telepíthet, kódot módosíthat és adatokat exportálhat.
Az ilyen támadások a sikertelen bejelentkezések halmozódásáról, a bejelentkezési címre irányuló, sok különböző IP-címről érkező POST-kérésekről, valamint az olyan felhasználónevekkel végzett próbálkozásokról ismerhetők fel, mint az „admin“, vagy a impresszumból származó nevek. A szokatlan időpontokban érezhetően megnövekedett szerverterhelés is utalhat rá, mert minden bejelentkezés számítási időt igényel a jelszóellenőrzéshez.
Brute force elleni védelem a bejelentkezésnél: a leghatékonyabb intézkedések
Nem minden intézkedés illik minden rendszerhez. A következő sorrend vált be, mert az első pontok viszik a legtöbb hatást kevés ráfordítással:
- Kétfaktoros bejelentkezés az összes rendszergazdai jogú fiókhoz. Még egy kitalált jelszó sem elég ekkor. A részleteket a Kétfaktoros bejelentkezés admin hozzáférésekhez útmutató tartalmazza.
- Egyedi, hosszú jelszavak jelszókezelőből, nincsenek megosztott fiókok.
- Rate limiting a webszerverben, hogy címenként percenként csak kevés próbálkozás lehetséges.
- Automatikus zárolások az ismételten feltűnő címekre hálózati szinten, például a Fail2bannel.
- Az admin terület szűkítése: hozzáférés csak a céges hálózatról vagy VPN-en keresztül, a nem szükséges interfészek kikapcsolása.
- Egységes hibaüzenetek, amelyek nem árulják el, hogy létezik-e a felhasználónév.
- Felügyelet: a sikertelen bejelentkezések megfigyelése és értesítés feltűnő jelenségeknél.
Rate limiting a webszerverben
Az Nginxszel egy bejelentkezési címre irányuló kérések száma IP-címenként korlátozható. A példa egy WordPress bejelentkezési oldalt mutat; az útvonalat és a PHP-átadást igazítsa a rendszeréhez.
# a http blokkban
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
# a server blokkban
location = /wp-login.php {
limit_req zone=login burst=3 nodelay;
limit_req_status 429;
# ide építse be a szerver szokásos PHP-átadását
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php-fpm.sock;
}
Apache alatt az admin terület ismert címekre korlátozása egyszerű, hatékony védelmet nyújt:
<Location "/admin">
Require ip 192.0.2.0/24
</Location>
A 192.0.2.0/24 cím a dokumentációs tartományból származó helyőrző; írja be a céges hálózatát vagy a VPN-je címét. Ha a weboldala proxy vagy CDN mögött van, a szervernek ismernie kell a látogató valódi címét, különben a szabály nem a kívánt módon érvényesül.
Fail2ban és zárolások hálózati szinten
A Fail2ban naplófájlokat olvas, és az ismételten feltűnő címeket meghatározott időre zárolja a tűzfalban. Az Nginx rate limitinghez a Fail2ban már hoz egy megfelelő szűrőt:
# /etc/fail2ban/jail.local
[nginx-limit-req]
enabled = true
port = http,https
logpath = /var/log/nginx/error.log
maxretry = 10
findtime = 10m
bantime = 1h
[sshd]
enabled = true
maxretry = 5
bantime = 1h
Az újraindítás után a fail2ban-client status paranccsal ellenőrizze, hogy a jailek aktívak-e. Ügyeljen arra, hogy a saját állandó címeit az ignoreip-pel kivegye, hogy ne zárja ki magát. Az egyes CMS-ek bejelentkezési oldalaihoz saját szűrők lehetségesek, de ezeknek illeszkedniük kell a tényleges naplóformátumhoz, és előtte tesztelni kell őket.
Ha a szerver előtt CDN vagy proxy áll, a Fail2ban további beállítás nélkül csak annak címeit látja. Egy zárolás ekkor az összes látogatót érintené. Ilyenkor a webszervernek az előtte álló szolgáltatás fejlécéből kell átvennie a látogató valódi címét, és a zárolásokat jobb közvetlenül a CDN-nél beállítani.
A hálózati szintű zárolások a tömeg elleni eszközök, nem a célzott támadások ellen. A nagyon sok címről érkező, címenként kevés próbálkozást tartalmazó elosztott támadások minden küszöböt alulmúlnak. Ezért a második faktor marad a legfontosabb réteg, és a Fail2ban főként a terhelést és a naplózajt csökkenti.
Jelszavak helyes tárolása saját szoftverben
Aki saját bejelentkezést programoz, a jelszavakat soha ne tárolja nyílt szövegként vagy olyan gyors hash-függvényekkel, mint az MD5 vagy az SHA-1. A PHP a password_hash()-sel biztonságos megoldást hoz, amely a sót és az eljárást automatikusan kezeli.
<?php
declare(strict_types=1);
// Regisztrációkor vagy jelszóváltoztatáskor
$hash = password_hash($passwort, PASSWORD_DEFAULT);
// Bejelentkezéskor
if (password_verify($eingabe, $hashAusDatenbank)) {
if (password_needs_rehash($hashAusDatenbank, PASSWORD_DEFAULT)) {
$neu = password_hash($eingabe, PASSWORD_DEFAULT);
// a $neu mentése az adatbázisba
}
// sikeres bejelentkezés, a session-azonosító megújítása
} else {
usleep(random_int(200000, 400000)); // egyenletes válaszidő
// egységes hibaüzenet kiadása
}
A password_needs_rehash() gondoskodik arról, hogy a régebbi hasheket a következő bejelentkezéskor automatikusan az aktuális eljárásra állítsák át. A sikertelen próbálkozásokat naplózza idővel, fiókkal és címmel, hogy a minták feltűnjenek. A kiértékeléshez útmutatást a Webszerver-naplók kiértékelése egy támadás után útmutató tartalmaz.
Sajátosságok CMS-eknél, webshopoknál és paneleknél
Sok rendszernek a látható bejelentkezési oldal mellett további útjai vannak, amelyeken keresztül hozzáférési adatokat ellenőriznek. Ezeket a mellékbejáratokat a védelemnél gyakran elfelejtik.
- WordPress: Az
xmlrpc.phpinterfész szintén fogad bejelentkezéseket. Ha nincs rá szükség, például régebbi alkalmazásokhoz, zárja le a webszerverben. Ellenőrizze emellett, hogy a felhasználónevek láthatók-e a szerzői oldalakon vagy a REST-interfészen keresztül, és az adminoknak olyan neveket használjon, amelyek nyilvánosan nem jelennek meg. - Webshopok: Az admin terület mellett az ügyfélfiókok is célpontok, különösen credential stuffing esetén. Itt a rate limiting, az új bejelentkezésekről szóló értesítések és az ügyfelek számára opcionális második faktor segít.
- Tárhelypanelek és webmail: Ezek a felületek gyakran világszerte elérhetők, és az egész szervert védik. Csak ismert hálózatokról vagy VPN-en keresztül szabadna elérhetőnek lenniük.
- SSH: A jelszó helyett kulccsal való bejelentkezés hatástalanná teszi a klasszikus találgatást.
Hogy a rendszere milyen védelmi funkciókat hoz magával, azt a gyártó dokumentációja tartalmazza. A harmadik felek bővítményeit aktívan gondozni kell, különben maguk is kockázattá válnak. A WordPress-üzemeltetőknek a WordPress és a PHP2Shell oldal foglalja össze az aktuális prioritásokat.
Hogyan segít konkrétan a PHP SOS?
- Felmérjük a szerverei összes elérhető bejelentkezési oldalát a CMS-től a tárhelypanelig, és értékeljük a védelmüket.
- A szerver-keményítés keretében beállítjuk a rate limitinget, a Fail2bant és a hozzáférési korlátozásokat, és teszteljük őket.
- Végigkísérjük a kétfaktoros bejelentkezés bevezetését az adminoknak, és dokumentáljuk a vészhozzáféréseket.
- A biztonsági monitoringgal folyamatosan szemmel tartjuk a sikertelen bejelentkezéseket és az új rendszergazdai fiókokat.
Gyakori kérdések
Miről ismerem fel a brute force támadást?
Tipikus a rövid idő alatt sok sikertelen bejelentkezés, gyakran ugyanazon bejelentkezési oldal ellen, változó felhasználónevekkel. Az access-naplóban ez a bejelentkezési címre irányuló POST-kérések halmozódásaként jelenik meg, gyakran sok különböző IP-címről.
Zárolni kell egy fiókot több sikertelen próbálkozás után?
Óvatosan: a kemény zárolásokat a támadók felhasználhatják jogos felhasználók kizárására. Jobbak a növekvő késleltetések, az IP-címenkénti időben korlátozott zárolások és a fióktulajdonos értesítése.
Segít a bejelentkezési cím átnevezése?
Csökkenti az automatizált zajt a naplókban, de nem valódi védelem. Aki ismeri vagy megtalálja a címet, tovább támadhat. Hatékony a kétfaktoros bejelentkezés, a rate limiting és az admin terület korlátozása.
Mi az a credential stuffing?
A támadók olyan e-mail és jelszó kombinációkat próbálnak ki, amelyeket más szolgáltatásoknál loptak el. Akkor működik, ha a felhasználók ugyanazt a jelszót többször használják. Az egyedi jelszavak és egy második faktor elveszik ennek a módszernek az alapját.