Zaštita admin prijava od brute forcea: zaštita svake prijave

Ukratko: Učinkovita zaštita prijave od brute forcea sastoji se od više slojeva: dvofaktorska prijava za sve administratore, kočnica za pokušaje prijave u web-poslužitelju, automatske blokade na mrežnoj razini i sigurna pohrana lozinki u kodu. Gdje je moguće, admin područje dodatno je dostupno samo iz poznatih mreža.

Kako teku brute force napadi na prijave

Svaka javno dostupna stranica za prijavu prije ili kasnije bude automatizirano napadnuta. To pogađa prijave u CMS, shop backendove, hosting panele, webmail i SSH. Napadači za to ne moraju znati kome web-stranica pripada; njihovi alati pretražuju internet za poznatim adresama prijave.

Raširene su tri varijante. Kod klasičnog brute forcea isprobava se mnogo lozinki na jednom računu. Kod password sprayinga jedna uobičajena lozinka testira se na mnogo računa kako bi se zaobišle blokade. Kod credential stuffinga koriste se pristupni podaci ukradeni kod drugih usluga.

Za upravu i vlasnike stanje je jednostavno sažeto: preuzet admin račun opasan je kao sigurnosna ranjivost na poslužitelju. Tko je admin, može instalirati ekstenzije, mijenjati kod i izvoziti podatke.

Takvi se napadi prepoznaju po nakupini neuspjelih prijava, po POST zahtjevima na adresu prijave s mnogo različitih IP adresa i po pokušajima prijave s korisničkim imenima poput „admin“ ili imenima iz impressuma. I osjetno veće opterećenje poslužitelja u neuobičajeno vrijeme može na to upućivati jer svaka prijava košta računalno vrijeme za provjeru lozinke.

Zaštita prijave od brute forcea: najučinkovitije mjere

Nije svaka mjera prikladna za svaki sustav. Sljedeći se redoslijed pokazao dobrim jer prve točke povezuju najviše učinka s malo truda:

• Dvofaktorska prijava za sve račune s admin pravima. Ni pogođena lozinka tada nije dovoljna. Pojedinosti u vodiču Dvofaktorska prijava za admin pristupe.
• Jedinstvene, duge lozinke iz upravitelja lozinki, bez zajedničkih računa.
• Rate limiting u web-poslužitelju, kako bi po adresi bilo moguće samo nekoliko pokušaja u minuti.
• Automatske blokade adresa koje se ponavljano ističu, na mrežnoj razini, primjerice s Fail2banom.
• Smanjiti admin područje: pristup samo iz mreže tvrtke ili putem VPN-a, isključiti nepotrebna sučelja.
• Jedinstvene poruke o pogrešci koje ne odaju postoji li korisničko ime.
• Nadzor neuspjelih prijava i obavijest kod upadljivosti.

Rate limiting u web-poslužitelju

S Nginxom se broj zahtjeva na adresu prijave po IP adresi može ograničiti. Primjer prikazuje WordPress stranicu za prijavu; putanju i predaju PHP-u prilagodite svom sustavu.

# u http bloku
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

# u server bloku
location = /wp-login.php {
    limit_req zone=login burst=3 nodelay;
    limit_req_status 429;
    # ovdje uključiti uobičajenu predaju PHP-u Vašeg poslužitelja
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php-fpm.sock;
}

Na Apacheu jednostavnu, učinkovitu zaštitu nudi ograničenje admin područja na poznate adrese:

<Location "/admin">
    Require ip 192.0.2.0/24
</Location>

Adresa 192.0.2.0/24 rezervirano je mjesto iz područja dokumentacije; upišite mrežu svoje tvrtke ili adresu svog VPN-a. Ako je Vaša web-stranica iza proxyja ili CDN-a, poslužitelj mora poznavati pravu adresu posjetitelja, inače pravilo ne djeluje kako je željeno.

Fail2ban i blokade na mrežnoj razini

Fail2ban čita log datoteke i adrese koje se ponavljano ističu blokira na određeno vrijeme u vatrozidu. Za Nginx rate limiting Fail2ban već donosi odgovarajući filtar:

# /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

Nakon ponovnog pokretanja s fail2ban-client status provjerite jesu li jailovi aktivni. Pripazite da vlastite stalne adrese izuzmete putem ignoreip kako se ne biste sami isključili. Za stranice prijave pojedinih CMS-ova moguće su vlastite filtri, ali moraju odgovarati stvarnom formatu loga i prethodno se testirati.

Ako ispred poslužitelja stoji CDN ili proxy, Fail2ban bez daljnjih postavki vidi samo njihove adrese. Blokada bi tada pogodila sve posjetitelje. U tom slučaju web-poslužitelj mora pravu adresu posjetitelja preuzeti iz zaglavlja prethodne usluge, a blokade je bolje postavljati izravno kod CDN-a.

Blokade na mrežnoj razini su alat protiv mase, a ne protiv ciljanih napada. Distribuirani napadi iz vrlo mnogo adresa s malo pokušaja po adresi podbacuju svaki prag. Zato drugi faktor ostaje najvažniji sloj, a Fail2ban ponajprije smanjuje opterećenje i šum u logovima.

Ispravna pohrana lozinki u vlastitom softveru

Tko programira vlastite prijave, lozinke nikad ne bi smio pohranjivati u čistom tekstu ni brzim hash funkcijama poput MD5 ili SHA-1. PHP uz password_hash() donosi sigurno rješenje koje automatski upravlja saltom i postupkom.

<?php
declare(strict_types=1);

// Pri registraciji ili promjeni lozinke
$hash = password_hash($passwort, PASSWORD_DEFAULT);

// Pri prijavi
if (password_verify($eingabe, $hashAusDatenbank)) {
    if (password_needs_rehash($hashAusDatenbank, PASSWORD_DEFAULT)) {
        $neu = password_hash($eingabe, PASSWORD_DEFAULT);
        // $neu pohraniti u bazu podataka
    }
    // Prijava uspjela, obnoviti ID sesije
} else {
    usleep(random_int(200000, 400000)); // ujednačeno vrijeme odgovora
    // ispisati jedinstvenu poruku o pogrešci
}

password_needs_rehash() osigurava da se stariji hashevi pri sljedećoj prijavi automatski prebace na aktualni postupak. Neuspjele pokušaje bilježite s vremenom, računom i adresom kako bi se obrasci uočili. Napomene o analizi nalaze se u vodiču Analiza logova web-poslužitelja nakon napada.

Posebnosti kod CMS-ova, shopova i panela

Mnogi sustavi uz vidljivu stranicu za prijavu imaju i druge puteve kojima se provjeravaju pristupni podaci. Ti se sporedni ulazi pri zaštiti često zaborave.

• WordPress: Sučelje xmlrpc.php također prima prijave. Ako nije potrebno, primjerice za starije aplikacije, blokirajte ga u web-poslužitelju. Provjerite i vide li se korisnička imena putem stranica autora ili REST sučelja te za admine koristite imena koja se ne pojavljuju javno.
• Shopovi: Uz admin područje, korisnički računi su meta, osobito za credential stuffing. Tu pomažu rate limiting, obavijesti o novim prijavama i opcionalan drugi faktor za klijente.
• Hosting paneli i webmail: Ta su sučelja često dostupna cijelom svijetu i štite cijeli poslužitelj. Trebala bi biti dostupna samo iz poznatih mreža ili putem VPN-a.
• SSH: Prijava ključem umjesto lozinkom čini klasično pogađanje bezučinkovitim.

Koje zaštitne funkcije Vaš sustav sam donosi, navedeno je u dokumentaciji proizvođača. Ekstenzije trećih strana trebaju biti aktivno održavane, inače same postaju rizik. Za operatere WordPressa stranica WordPress i PHP2Shell sažima aktualne prioritete.

Kako PHP SOS konkretno pomaže?

• Bilježimo sve dostupne stranice za prijavu na Vašim poslužiteljima, od CMS-a do hosting panela, i ocjenjujemo njihovu zaštitu.
• Postavljamo rate limiting, Fail2ban i ograničenja pristupa u okviru ojačavanja poslužitelja i testiramo ih.
• Pratimo uvođenje dvofaktorske prijave za administratore i dokumentiramo hitne pristupe.
• Uz sigurnosni monitoring neprestano držimo na oku neuspjele prijave i nove admin račune.

Česta pitanja

Izvori

• OWASP Cheat Sheet Series (Authentication)
• BSI: preporuke za sigurne lozinke i dvofaktorsku prijavu
• OWASP Top 10