Administratoriaus prisijungimų apsauga nuo brute force: apsauga kiekvienam prisijungimui

Trumpai: Veiksminga brute force apsauga prisijungimui susideda iš kelių sluoksnių: dviejų veiksnių autentifikacija visiems administratoriams, prisijungimo bandymų stabdis žiniatinklio serveryje, automatinės blokadėlės tinklo lygiu ir saugus slaptažodžių saugojimas kode. Kur įmanoma, administravimo sritis papildomai pasiekiama tik iš žinomų tinklų.

Kaip vyksta brute force atakos prieš prisijungimus

Kiekvienas viešai pasiekiamas prisijungimo puslapis anksčiau ar vėliau automatizuotai atakuojamas. Tai liečia CMS prisijungimus, parduotuvių administravimo sritis, hostingo skydelius, internetinį paštą ir SSH. Užpuolikams tam nereikia žinoti, kam priklauso svetainė; jų įrankiai ieško žinomų prisijungimo adresų internete.

Paplitę trys variantai. Klasikinio brute force atveju prieš vieną paskyrą išbandoma daug slaptažodžių. Password spraying atveju vienas dažnas slaptažodis išbandomas prieš daug paskyrų, kad būtų apeitos blokadėlės. Credential stuffing atveju naudojami prisijungimo duomenys, pavogti iš kitų paslaugų.

Vadovybei ir savininkams padėtį galima apibendrinti paprastai: perimta administratoriaus paskyra yra tokia pat pavojinga kaip serverio saugumo spraga. Kas yra administratorius, gali diegti plėtinius, keisti kodą ir eksportuoti duomenis.

Tokias atakas atpažinsite iš nepavykusių prisijungimų kaupimosi, iš POST užklausų prisijungimo adresu iš daugelio skirtingų IP adresų ir iš prisijungimo bandymų su naudotojų vardais, tokiais kaip „admin“ ar pavadinimais iš rekvizitų. Apie tai gali liudyti ir pastebimai didesnė serverio apkrova neįprastu metu, nes kiekvienas prisijungimas kainuoja skaičiavimo laiko slaptažodžio patikrai.

Brute force apsauga prisijungimui: veiksmingiausios priemonės

Ne kiekviena priemonė tinka kiekvienai sistemai. Toliau pateikta tvarka pasiteisino, nes pirmieji punktai suteikia daugiausia poveikio su mažomis pastangomis:

• Dviejų veiksnių autentifikacija visoms paskyroms su administratoriaus teisėmis. Net atspėto slaptažodžio tuomet nepakanka. Smulkiau vadove Dviejų veiksnių autentifikacija administratorių prieigoms.
• Unikalūs, ilgi slaptažodžiai iš slaptažodžių tvarkyklės, jokių bendrų paskyrų.
• Užklausų ribojimas žiniatinklio serveryje, kad kiekvienu adresu per minutę būtų galima atlikti tik kelis bandymus.
• Automatinės blokadėlės pakartotinai įtartiniems adresams tinklo lygiu, pavyzdžiui, su Fail2ban.
• Sumažinti administravimo sritį: prieiga tik iš įmonės tinklo ar per VPN, nereikalingas sąsajas išjungti.
• Vienodi klaidų pranešimai, neatskleidžiantys, ar naudotojo vardas egzistuoja.
• Nepavykusių prisijungimų stebėsena ir pranešimas apie neįprastus atvejus.

Užklausų ribojimas žiniatinklio serveryje

Su Nginx užklausų skaičių prisijungimo adresu galima apriboti pagal IP adresą. Pavyzdys rodo WordPress prisijungimo puslapį; kelią ir PHP perdavimą pritaikykite savo sistemai.

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

# server bloke
location = /wp-login.php {
    limit_req zone=login burst=3 nodelay;
    limit_req_status 429;
    # čia įtraukti įprastą jūsų serverio PHP perdavimą
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php-fpm.sock;
}

Apache serveryje administravimo srities apribojimas žinomiems adresams yra paprasta, veiksminga apsauga:

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

Adresas 192.0.2.0/24 yra vietos žymeklis iš dokumentacijos srities; įrašykite savo įmonės tinklą ar VPN adresą. Jei jūsų svetainė už tarpinio serverio ar CDN, serveris turi žinoti tikrąjį lankytojo adresą, kitaip taisyklė neveiks taip, kaip norima.

Fail2ban ir blokadėlės tinklo lygiu

Fail2ban skaito žurnalo failus ir adresus, kurie pakartotinai krenta į akis, nustatytam laikui užblokuoja ugniasienėje. Nginx užklausų ribojimui Fail2ban jau turi tinkamą 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 paleidimo iš naujo su fail2ban-client status patikrinkite, ar kalėjimai (jails) aktyvūs. Pasirūpinkite, kad savo fiksuotus adresus išimtumėte per ignoreip, kad neužblokuotumėte savęs. Atskirų CMS prisijungimo puslapiams galimi savi filtrai, bet jie turi derėti su tikru žurnalo formatu ir būti iš anksto išbandyti.

Jei prieš serverį yra CDN ar tarpinis serveris, Fail2ban be papildomų nustatymų mato tik jo adresus. Blokadėlė tuomet paliestų visus lankytojus. Tokiu atveju žiniatinklio serveris tikrąjį lankytojo adresą turi perimti iš prieš tai esančios paslaugos antraštės, o blokadėles geriau nustatyti tiesiai CDN.

Blokadėlės tinklo lygiu yra priemonė prieš masę, o ne prieš tikslines atakas. Paskirstytos atakos iš labai daugelio adresų su keliais bandymais kiekvienu adresu apeina bet kokią ribą. Todėl antras veiksnys lieka svarbiausias sluoksnis, o Fail2ban visų pirma mažina apkrovą ir žurnalų triukšmą.

Kaip teisingai saugoti slaptažodžius savo programinėje įrangoje

Kas programuoja savus prisijungimus, slaptažodžių niekada neturėtų saugoti atviru tekstu ar greitomis maišos funkcijomis, tokiomis kaip MD5 ar SHA-1. PHP su password_hash() turi saugų sprendimą, kuris automatiškai valdo druską (salt) ir metodą.

<?php
declare(strict_types=1);

// Registruojantis arba keičiant slaptažodį
$hash = password_hash($passwort, PASSWORD_DEFAULT);

// Prisijungiant
if (password_verify($eingabe, $hashAusDatenbank)) {
    if (password_needs_rehash($hashAusDatenbank, PASSWORD_DEFAULT)) {
        $neu = password_hash($eingabe, PASSWORD_DEFAULT);
        // $neu išsaugoti duomenų bazėje
    }
    // Prisijungimas sėkmingas, atnaujinti sesijos ID
} else {
    usleep(random_int(200000, 400000)); // tolygus atsakymo laikas
    // pateikti vienodą klaidos pranešimą
}

password_needs_rehash() užtikrina, kad senesnės maišos reikšmės kito prisijungimo metu automatiškai būtų perkeltos į dabartinį metodą. Nesėkmingus bandymus registruokite su laiku, paskyra ir adresu, kad šablonai pasirodytų. Nuorodas dėl analizės rasite vadove Kaip išanalizuoti žiniatinklio serverio žurnalus po atakos.

CMS, parduotuvių ir skydelių ypatumai

Daugelis sistemų, be matomo prisijungimo puslapio, turi ir kitų kelių, per kuriuos tikrinami prisijungimo duomenys. Šie šoniniai įėjimai apsaugant dažnai pamirštami.

• WordPress: sąsaja xmlrpc.php taip pat priima prisijungimus. Jei jos nereikia, pavyzdžiui, senesnėms programėlėms, užblokuokite ją žiniatinklio serveryje. Be to, patikrinkite, ar naudotojų vardai matomi per autorių puslapius ar REST sąsają, ir administratoriams naudokite vardus, kurie viešai nerodomi.
• Parduotuvės: be administravimo srities, taikinys yra klientų paskyros, ypač credential stuffing atveju. Čia padeda užklausų ribojimas, pranešimai apie naujus prisijungimus ir pasirenkamas antras veiksnys klientams.
• Hostingo skydeliai ir internetinis paštas: šios sąsajos dažnai pasiekiamos visame pasaulyje ir saugo visą serverį. Jos turėtų būti pasiekiamos tik iš žinomų tinklų ar per VPN.
• SSH: prisijungimas su raktu vietoj slaptažodžio klasikinį spėliojimą daro neveiksmingu.

Kokias apsaugos funkcijas jūsų sistema turi pati, aprašyta gamintojo dokumentacijoje. Trečiųjų šalių plėtiniai turėtų būti aktyviai prižiūrimi, kitaip patys tampa rizika. WordPress operatoriams dabartinius prioritetus apibendrina puslapis WordPress ir PHP2Shell.

Kaip PHP SOS padeda konkrečiai?

• Užfiksuojame visus jūsų serverių pasiekiamus prisijungimo puslapius, nuo CMS iki hostingo skydelio, ir įvertiname jų apsaugą.
• Užklausų ribojimą, Fail2ban ir prieigos apribojimus įrengiame pagal serverio sutvirtinimą ir išbandome.
• Lydime dviejų veiksnių autentifikacijos įvedimą administratoriams ir dokumentuojame avarines prieigas.
• Su saugumo stebėsena nuolat stebime nepavykusius prisijungimus ir naujas administratoriaus paskyras.

Dažni klausimai

Šaltiniai

• OWASP Cheat Sheet Series (Authentication)
• BSI: rekomendacijos dėl saugių slaptažodžių ir dviejų veiksnių autentifikacijos
• OWASP Top 10