# Admin bejelentkezések védelme brute force ellen: brute force védelem minden bejelentkezéshez > Brute force elleni védelem bejelentkezéshez és adminhoz: rate limiting, Fail2ban, kétfaktoros bejelentkezés és biztonságos jelszótárolás password_hash-sel. Forrás: https://phpsos.de/hu/ratgeber/brute-force-login-schutz/ Állapot: 2026. 10. 25. Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6 **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](https://phpsos.de/hu/ratgeber/zwei-faktor-admin/) ú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. ```nginx # 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: ```apache Require ip 192.0.2.0/24 ``` 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: ```ini # /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