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

> Zaštita prijave i admin područja od brute forcea: rate limiting, Fail2ban, dvofaktorska prijava i sigurna pohrana lozinki s password_hash.

Izvor: https://phpsos.de/hr/ratgeber/brute-force-login-schutz/  
Stanje: 25.10.2026  
Pružatelj: PHP SOS, PHP hitna pomoć i sigurnost poslužitelja. Hitna pomoć putem WhatsAppa: https://wa.me/491736494914?text=Pozdrav%20PHP%20SOS%2C%20trebamo%20pomo%C4%87%20s%20na%C5%A1im%20PHP%20poslu%C5%BEiteljem.%20Tvrtka%3A%20%E2%80%A6%20Web-stranica%3A%20%E2%80%A6

**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](https://phpsos.de/hr/ratgeber/zwei-faktor-admin/).
- **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.

```nginx
# 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:

```apache
<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:

```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
```

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
<?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](https://phpsos.de/hr/ratgeber/logfiles-auswerten/).

## 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](https://phpsos.de/hr/plattformen/wordpress/) 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](https://phpsos.de/hr/leistungen/server-haertung/) i testiramo ih.
- Pratimo uvođenje dvofaktorske prijave za administratore i dokumentiramo hitne pristupe.
- Uz [sigurnosni monitoring](https://phpsos.de/hr/leistungen/security-monitoring/) neprestano držimo na oku neuspjele prijave i nove admin račune.


## Česta pitanja

**Po čemu prepoznajem brute force napad?**  
Tipično je mnogo neuspjelih prijava u kratkom vremenu, često na istu stranicu za prijavu i s promjenjivim korisničkim imenima. U access logu to se vidi kao nakupina POST zahtjeva na adresu prijave, često s mnogo različitih IP adresa.

**Treba li račun blokirati nakon više neuspjelih pokušaja?**  
Oprez: tvrde blokade napadači mogu iskoristiti da isključe legitimne korisnike. Bolja su rastuća kašnjenja, vremenski ograničene blokade po IP adresi i obavijest vlasniku računa.

**Pomaže li preimenovanje adrese prijave?**  
Smanjuje automatizirani šum u logovima, ali nije prava zaštita. Tko adresu poznaje ili je pronađe, može dalje napadati. Učinkoviti su dvofaktorska prijava, rate limiting i ograničenje admin područja.

**Što je credential stuffing?**  
Pritom napadači isprobavaju kombinacije e-pošte i lozinke ukradene kod drugih usluga. Funkcionira ako korisnici koriste istu lozinku na više mjesta. Jedinstvene lozinke i drugi faktor oduzimaju toj metodi temelj.

## Izvori

- [OWASP Cheat Sheet Series (Authentication)](https://cheatsheetseries.owasp.org/)
- [BSI: preporuke za sigurne lozinke i dvofaktorsku prijavu](https://www.bsi.bund.de/)
- [OWASP Top 10](https://owasp.org/www-project-top-ten/)