# Halduse sisselogimised toorjõurünnaku eest kaitsta: kaitse igale sisselogimisele

> Toorjõurünnaku kaitse sisselogimisele ja haldusalale: rate-limiting, Fail2ban, kaheastmeline autentimine ja turvaline paroolide salvestamine password_hash abil.

Allikas: https://phpsos.de/et/ratgeber/brute-force-login-schutz/  
Seis: 25.10.2026  
Pakkuja: PHP SOS, PHP hädaabi ja serveri turvalisus. Kohene abi WhatsAppis: https://wa.me/491736494914?text=Tere%2C%20PHP%20SOS%2C%20vajame%20abi%20oma%20PHP-serveriga.%20Ettev%C3%B5te%3A%20%E2%80%A6%20Veebisait%3A%20%E2%80%A6

**Lühidalt:** Tõhus toorjõurünnaku kaitse sisselogimisele koosneb mitmest kihist: kaheastmeline autentimine kõigile administraatoritele, sisselogimiskatsete pidur veebiserveris, automaatsed lukud võrgutasandil ja turvaline paroolide salvestamine koodis. Kui võimalik, on halduspiirkond lisaks kättesaadav ainult tuntud võrkudest.

## Kuidas sisselogimiste toorjõurünnakud kulgevad

Iga avalikult kättesaadavat sisselogimislehte rünnatakse varem või hiljem automatiseeritult. See puudutab sisuhaldussüsteemide sisselogimisi, poodide haldusalasid, hostingupaneele, veebiposti ja SSH-d. Selleks ei pea ründajad teadma, kellele veebisait kuulub; nende tööriistad otsivad internetist teadaolevaid sisselogimisaadresse.

Levinud on kolm varianti. Klassikalise **toorjõurünnaku** (Brute Force) puhul proovitakse ühe konto vastu palju paroole. **Password Sprayingu** puhul testitakse ühte sagedast parooli paljude kontode vastu, et lukkudest mööda minna. **Credential Stuffingu** puhul kasutatakse ligipääsuandmeid, mis on varastatud teistest teenustest.

Juhatuse ja omanike jaoks on olukord lihtsalt kokku võetud: üle võetud administraatori konto on sama ohtlik kui serveri turvaauk. Kes on administraator, saab paigaldada laiendusi, muuta koodi ja eksportida andmeid.

Selliseid rünnakuid tunneb ära ebaõnnestunud sisselogimiste kuhjumise, paljudelt erinevatelt IP-aadressidelt tulevate POST-päringute sisselogimisaadressile ja sisselogimiskatsete järgi kasutajanimedega nagu „admin“ või impressumist pärit nimed. Ka märgatavalt kõrgem serveri koormus ebatavalistel aegadel võib sellele viidata, sest iga sisselogimine nõuab paroolikontrolliks arvutusaega.

## Toorjõurünnaku kaitse sisselogimisel: tõhusamad meetmed

Mitte iga meede ei sobi igale süsteemile. Järgmine järjekord on end tõestanud, sest esimesed punktid ühendavad kõige rohkem mõju väikese vaevaga:

- **Kaheastmeline autentimine** kõigile administraatoriõigustega kontodele. Isegi äraarvatud parool ei piisa siis. Üksikasjad juhendis [Kaheastmeline autentimine halduse ligipääsudele](https://phpsos.de/et/ratgeber/zwei-faktor-admin/).
- **Unikaalsed, pikad paroolid** paroolihaldurist, jagatud kontosid ei ole.
- **Rate-limiting** veebiserveris, et aadressi kohta on võimalik vaid mõni katse minutis.
- **Automaatsed lukud** korduvalt silma torganud aadressidele võrgutasandil, näiteks Fail2baniga.
- **Haldusala vähendada:** juurdepääs ainult ettevõtte võrgust või VPN-iga, mittevajalikud liidesed välja lülitada.
- **Ühtsed veateated,** mis ei reeda, kas kasutajanimi on olemas.
- **Ebaõnnestunud sisselogimiste jälgimine** ja teavitus kõrvalekallete korral.

## Rate-limiting veebiserveris

Nginxiga saab sisselogimisaadressile tehtavate päringute arvu IP-aadressi kohta piirata. Näide näitab WordPressi sisselogimislehte; tee ja PHP üleandmise kohandage oma süsteemile.

```nginx
# http-plokis
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

# server-plokis
location = /wp-login.php {
    limit_req zone=login burst=3 nodelay;
    limit_req_status 429;
    # siia lisada oma serveri tavaline PHP üleandmine
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php-fpm.sock;
}
```

Apache'is pakub haldusala piiramine tuntud aadressidele lihtsat ja tõhusat kaitset:

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

Aadress `192.0.2.0/24` on dokumentatsioonivahemikust pärit kohatäide; pange asemele oma ettevõtte võrk või VPN-i aadress. Kui teie veebisait asub proksi või CDN-i taga, peab server teadma külastaja tegelikku aadressi, muidu ei toimi reegel soovitud viisil.

## Fail2ban ja lukud võrgutasandil

Fail2ban loeb logifaile ja lukustab korduvalt silma torganud aadressid kindlaks ajaks tulemüüris. Nginxi rate-limitingu jaoks tuleb Fail2banil sobiv filter juba kaasa:

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

Kontrollige pärast taaskäivitust käsuga `fail2ban-client status`, kas jail'id on aktiivsed. Jälgige, et jätate oma püsivad aadressid `ignoreip` kaudu välja, et end mitte ise välja lukustada. Üksikute sisuhaldussüsteemide sisselogimislehtede jaoks on võimalikud oma filtrid, kuid need peavad sobima tegeliku logivorminguga ja neid tuleb enne testida.

Kui serveri ees on CDN või proksi, näeb Fail2ban ilma lisaseadeta ainult selle aadresse. Lukk tabaks siis kõiki külastajaid. Sel juhul peab veebiserver võtma külastaja tegeliku aadressi eelneva teenuse päisest ja lukud seatakse paremini otse CDN-is.

Võrgutasandi lukud on tööriist massi vastu, mitte sihipäraste rünnakute vastu. Hajutatud rünnakud väga paljudelt aadressidelt väheste katsetega aadressi kohta alistavad iga lävendi. Seetõttu jääb teine faktor tähtsaimaks kihiks ja Fail2ban vähendab eelkõige koormust ja logimüra.

## Paroolide õige salvestamine oma tarkvaras

Kes programmeerib oma sisselogimisi, ei tohiks paroole kunagi salvestada selge tekstina ega kiirete räsifunktsioonidega nagu MD5 või SHA-1. PHP toob kaasa `password_hash()` abil turvalise lahenduse, mis haldab soola ja meetodit automaatselt.

```php
<?php
declare(strict_types=1);

// Registreerimisel või parooli muutmisel
$hash = password_hash($passwort, PASSWORD_DEFAULT);

// Sisselogimisel
if (password_verify($eingabe, $hashAusDatenbank)) {
    if (password_needs_rehash($hashAusDatenbank, PASSWORD_DEFAULT)) {
        $neu = password_hash($eingabe, PASSWORD_DEFAULT);
        // salvestada $neu andmebaasi
    }
    // Sisselogimine õnnestus, uuendada sessiooni ID
} else {
    usleep(random_int(200000, 400000)); // ühtlane vastuseaeg
    // väljastada ühtne veateade
}
```

`password_needs_rehash()` tagab, et vanemad räsid viiakse järgmisel sisselogimisel automaatselt praegusele meetodile. Ebaõnnestunud katseid logige ajaga, konto ja aadressiga, et mustrid silma jääksid. Vihjed analüüsiks on kirjas juhendis [Veebiserveri logide analüüs pärast rünnakut](https://phpsos.de/et/ratgeber/logfiles-auswerten/).

## Erijooned sisuhaldussüsteemides, poodides ja paneelides

Paljudel süsteemidel on lisaks nähtavale sisselogimislehele muid teid, mille kaudu ligipääsuandmeid kontrollitakse. Neid kõrvalsissepääse unustatakse kaitsmisel sageli.

- **WordPress:** Liides `xmlrpc.php` võtab samuti sisselogimisi vastu. Kui seda ei vajata, näiteks vanemate rakenduste jaoks, lukustage see veebiserveris. Kontrollige lisaks, kas kasutajanimed on nähtavad autorilehtede või REST-liidese kaudu, ning kasutage administraatoritele nimesid, mis avalikult ei ilmu.
- **Poed:** Haldusala kõrval on sihtmärgiks kliendikontod, eriti Credential Stuffingu puhul. Siin aitavad rate-limiting, teavitused uute sisselogimiste kohta ja valikuline teine faktor klientidele.
- **Hostingupaneelid ja veebipost:** Need liidesed on sageli kogu maailmast kättesaadavad ja kaitsevad kogu serverit. Need peaksid olema kättesaadavad ainult tuntud võrkudest või VPN-iga.
- **SSH:** Võtmega sisselogimine parooli asemel muudab klassikalise arvamise mõjutuks.

Milliseid kaitsefunktsioone teie süsteem ise kaasa toob, on kirjas tootja dokumentatsioonis. Kolmandate osapoolte laiendused peaksid olema aktiivselt hooldatud, muidu muutuvad need ise riskiks. WordPressi haldajatele võtab praegused prioriteedid kokku leht [WordPress ja PHP2Shell](https://phpsos.de/et/plattformen/wordpress/).

## Kuidas PHP SOS konkreetselt aitab?

- Kaardistame kõik teie serverite kättesaadavad sisselogimislehed, sisuhaldussüsteemist hostingupaneelini, ja hindame nende kaitset.
- Seame rate-limitingu, Fail2bani ja juurdepääsupiirangud üles [serveri karastamise](https://phpsos.de/et/leistungen/server-haertung/) raames ning testime neid.
- Toetame administraatoritele kaheastmelise autentimise kasutuselevõttu ja dokumenteerime hädajuurdepääsud.
- [Turvaseirega](https://phpsos.de/et/leistungen/security-monitoring/) hoiame ebaõnnestunud sisselogimised ja uued administraatorikontod pidevalt silmas.


## Korduma kippuvad küsimused

**Millest ma toorjõurünnakut ära tunnen?**  
Tüüpilised on paljud ebaõnnestunud sisselogimised lühikese aja jooksul, sageli sama sisselogimislehe vastu ja vahelduvate kasutajanimedega. Juurdepääsulogis väljendub see POST-päringute kuhjumisena sisselogimisaadressile, sageli paljudelt erinevatelt IP-aadressidelt.

**Kas konto tuleks pärast mitut ebaõnnestunud katset lukustada?**  
Ettevaatust: karmid lukud võivad ründajad ära kasutada, et legitiimseid kasutajaid välja lukustada. Paremad on kasvavad viivitused, IP-aadressi kaupa ajaliselt piiratud lukud ja konto omaniku teavitamine.

**Kas sisselogimisaadressi ümbernimetamine aitab?**  
See vähendab logides automatiseeritud müra, kuid ei ole päris kaitse. Kes aadressi teab või leiab, saab rünnata edasi. Tõhusad on kaheastmeline autentimine, rate-limiting ja halduspiirkonna piiramine.

**Mis on Credential Stuffing?**  
Seal proovivad ründajad e-posti ja parooli kombinatsioone, mis on varastatud teistest teenustest. See toimib, kui kasutajad kasutavad sama parooli mitmes kohas. Unikaalsed paroolid ja teine faktor võtavad sellelt meetodilt aluse.

## Allikad

- [OWASP Cheat Sheet Series (Authentication)](https://cheatsheetseries.owasp.org/)
- [BSI: soovitused turvaliste paroolide ja kaheastmelise autentimise kohta](https://www.bsi.bund.de/)
- [OWASP Top 10](https://owasp.org/www-project-top-ten/)