Stručně: Účinná ochrana přihlášení před brute force se skládá z několika vrstev: dvoufázové ověření pro všechny správce, brzda pokusů o přihlášení ve webovém serveru, automatické blokace na úrovni sítě a bezpečné ukládání hesel v kódu. Kde je to možné, je oblast administrace navíc dostupná jen ze známých sítí.
Jak útoky brute force na přihlášení probíhají
Každá veřejně dostupná přihlašovací stránka je dříve či později napadena automatizovaně. Týká se to přihlášení do CMS, administrace e-shopů, hostingových panelů, webmailu a SSH. Útočníci přitom nemusí vědět, komu web patří; jejich nástroje prohledávají internet kvůli známým adresám přihlášení.
Rozšířeny jsou tři varianty. U klasického brute force se proti jednomu účtu zkouší mnoho hesel. U password sprayingu se proti mnoha účtům zkouší jedno běžné heslo, aby se obešly blokace. U credential stuffingu se používají přístupové údaje odcizené u jiných služeb.
Pro vedení a majitele lze situaci shrnout jednoduše: převzatý účet správce je stejně nebezpečný jako bezpečnostní mezera na serveru. Kdo je správce, může instalovat rozšíření, měnit kód a exportovat data.
Takové útoky poznáte podle shluku neúspěšných přihlášení, podle požadavků POST na adresu přihlášení z mnoha různých IP adres a podle pokusů o přihlášení s uživatelskými jmény jako „admin“ nebo jmény z tiráže. Také znatelně vyšší zátěž serveru v neobvyklých časech může na to ukazovat, protože každé přihlášení stojí výpočetní čas na ověření hesla.
Ochrana přihlášení před brute force: nejúčinnější opatření
Ne každé opatření se hodí ke každému systému. Následující pořadí se osvědčilo, protože první body spojují nejvíce účinku s malým úsilím:
- Dvoufázové ověření pro všechny účty s právy správce. Ani uhodnuté heslo pak nestačí. Podrobnosti v příručce Dvoufázové ověření pro přístupy správců.
- Jedinečná, dlouhá hesla ze správce hesel, žádné sdílené účty.
- Rate limiting ve webovém serveru, aby bylo možné z jedné adresy jen několik pokusů za minutu.
- Automatické blokace opakovaně nápadných adres na úrovni sítě, například pomocí Fail2ban.
- Zmenšit oblast administrace: přístup jen z firemní sítě nebo přes VPN, nepotřebná rozhraní vypnout.
- Jednotná chybová hlášení, která neprozradí, zda uživatelské jméno existuje.
- Monitoring neúspěšných přihlášení a upozornění při nápadnostech.
Rate limiting ve webovém serveru
V Nginx lze počet požadavků na adresu přihlášení omezit podle IP adresy. Příklad ukazuje přihlašovací stránku WordPressu; cestu a předání PHP přizpůsobte svému systému.
# v bloku http
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
# v bloku server
location = /wp-login.php {
limit_req zone=login burst=3 nodelay;
limit_req_status 429;
# sem vložit obvyklé předání PHP vašeho serveru
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php-fpm.sock;
}
U Apache nabízí jednoduchou a účinnou ochranu omezení oblasti administrace na známé adresy:
<Location "/admin">
Require ip 192.0.2.0/24
</Location>
Adresa 192.0.2.0/24 je zástupná hodnota z dokumentační oblasti; dosaďte svou firemní síť nebo adresu svého VPN. Pokud je váš web za proxy nebo CDN, musí server znát skutečnou adresu návštěvníka, jinak pravidlo nepůsobí, jak má.
Fail2ban a blokace na úrovni sítě
Fail2ban čte soubory logů a adresy, které se opakovaně projeví, zablokuje ve firewallu na stanovenou dobu. Pro rate limiting v Nginx obsahuje Fail2ban již vhodný filtr:
# /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
Po restartu zkontrolujte pomocí fail2ban-client status, zda jsou jaily aktivní. Dbejte na to, abyste své vlastní pevné adresy vyňali přes ignoreip, aby se nestalo, že vyloučíte sami sebe. Pro přihlašovací stránky jednotlivých CMS jsou možné vlastní filtry, musí ale odpovídat skutečnému formátu logu a předem se otestovat.
Pokud před serverem stojí CDN nebo proxy, vidí Fail2ban bez dalšího nastavení jen jeho adresy. Blokace by pak zasáhla všechny návštěvníky. V takovém případě musí webový server převzít skutečnou adresu návštěvníka z hlavičky předřazené služby a blokace se lépe nastavují přímo u CDN.
Blokace na úrovni sítě jsou nástrojem proti masám, nikoli proti cíleným útokům. Distribuované útoky z velmi mnoha adres s malým počtem pokusů na adresu obejdou každý práh. Proto zůstává druhý faktor nejdůležitější vrstvou a Fail2ban snižuje hlavně zátěž a šum v lozích.
Jak správně ukládat hesla ve vlastním softwaru
Kdo programuje vlastní přihlášení, neměl by hesla nikdy ukládat v čitelné podobě ani pomocí rychlých hašovacích funkcí jako MD5 nebo SHA-1. PHP nabízí s password_hash() bezpečné řešení, které sůl a postup spravuje automaticky.
<?php
declare(strict_types=1);
// Při registraci nebo změně hesla
$hash = password_hash($passwort, PASSWORD_DEFAULT);
// Při přihlášení
if (password_verify($eingabe, $hashAusDatenbank)) {
if (password_needs_rehash($hashAusDatenbank, PASSWORD_DEFAULT)) {
$neu = password_hash($eingabe, PASSWORD_DEFAULT);
// $neu uložit do databáze
}
// Přihlášení úspěšné, obnovit ID session
} else {
usleep(random_int(200000, 400000)); // vyrovnaná doba odpovědi
// vypsat jednotné chybové hlášení
}
password_needs_rehash() zajišťuje, že se starší haše při dalším přihlášení automaticky převedou na aktuální postup. Neúspěšné pokusy protokolujte s časem, účtem a adresou, aby se vzory projevily. Pokyny k vyhodnocení najdete v příručce Vyhodnocení logů webového serveru po útoku.
Zvláštnosti u CMS, e-shopů a panelů
Mnoho systémů má vedle viditelné přihlašovací stránky další cesty, kterými se ověřují přístupové údaje. Na tyto vedlejší vchody se při ochraně často zapomíná.
- WordPress: Rozhraní
xmlrpc.phptaké přijímá přihlášení. Pokud ho nepotřebujete, například pro starší aplikace, zablokujte ho ve webovém serveru. Zkontrolujte také, zda nejsou uživatelská jména viditelná přes stránky autorů nebo rozhraní REST, a pro správce používejte jména, která se veřejně neobjevují. - E-shopy: Vedle administrace jsou cílem zákaznické účty, zejména pro credential stuffing. Pomáhají zde rate limiting, upozornění při nových přihlášeních a volitelný druhý faktor pro zákazníky.
- Hostingové panely a webmail: Tato rozhraní jsou často dostupná z celého světa a chrání celý server. Měla by být dostupná jen ze známých sítí nebo přes VPN.
- SSH: Přihlášení klíčem místo hesla činí klasické hádání neúčinným.
Jaké ochranné funkce váš systém nabízí sám, uvádí dokumentace výrobce. Rozšíření třetích stran by měla být aktivně udržována, jinak se stanou rizikem samotná. Pro provozovatele WordPressu shrnuje aktuální priority stránka WordPress a PHP2Shell.
Jak konkrétně pomáhá PHP SOS?
- Zjistíme všechny dostupné přihlašovací stránky vašich serverů, od CMS po hostingový panel, a ohodnotíme jejich ochranu.
- Rate limiting, Fail2ban a omezení přístupu nastavujeme v rámci zabezpečení serveru a testujeme je.
- Provázíme zavedení dvoufázového ověření pro správce a dokumentujeme nouzové přístupy.
- Pomocí security monitoringu průběžně sledujeme neúspěšná přihlášení a nové účty správců.
Časté dotazy
Podle čeho poznám útok brute force?
Typické je mnoho neúspěšných přihlášení v krátkém čase, často proti téže přihlašovací stránce a se střídajícími se uživatelskými jmény. V access logu se to projeví jako shluk požadavků POST na adresu přihlášení, často z mnoha různých IP adres.
Měl by se účet po několika neúspěšných pokusech zablokovat?
Pozor: tvrdé blokace mohou útočníci využít k vyřazení legitimních uživatelů. Lepší jsou rostoucí prodlevy, časově omezené blokace podle IP adresy a upozornění majitele účtu.
Pomůže přejmenovat adresu přihlášení?
Sníží to automatizovaný šum v lozích, ale není to skutečná ochrana. Kdo adresu zná nebo najde, může dál útočit. Účinné jsou dvoufázové ověření, rate limiting a omezení oblasti administrace.
Co je credential stuffing?
Útočníci při něm zkoušejí kombinace e-mailu a hesla, které byly odcizeny u jiných služeb. Funguje to, když uživatelé používají totéž heslo opakovaně. Jedinečná hesla a druhý faktor této metodě berou základ.