Administratoru pieteikšanās aizsardzība pret Brute Force: aizsardzība katrai pieteikšanās lapai

Īsi: Efektīva Brute Force aizsardzība pieteikšanās veidojas no vairākiem slāņiem: divu faktoru autentifikācija visiem administratoriem, bremze pieteikšanās mēģinājumiem tīmekļa serverī, automātiski bloķējumi tīkla līmenī un droša paroļu glabāšana kodā. Kur iespējams, administrēšanas zonai papildus jābūt pieejamai tikai no zināmiem tīkliem.

Kā norit Brute Force uzbrukumi pieteikšanās lapām

Katra publiski sasniedzama pieteikšanās lapa agrāk vai vēlāk tiek automatizēti uzbrukta. Tas attiecas uz CMS pieteikšanos, veikalu administrēšanas sadaļām, hostinga paneļiem, tīmekļa pastu un SSH. Uzbrucējiem šim nolūkam nav jāzina, kam pieder vietne; viņu rīki internetā meklē zināmas pieteikšanās adreses.

Izplatīti ir trīs varianti. Klasiskajā Brute Force pret vienu kontu tiek izmēģinātas daudzas paroles. Password Spraying gadījumā viena bieži lietota parole tiek pārbaudīta pret daudziem kontiem, lai apietu bloķējumus. Credential Stuffing gadījumā tiek izmantoti piekļuves dati, kas nozagti citos pakalpojumos.

Vadībai un īpašniekiem situāciju var vienkārši apkopot: pārņemts administratora konts ir tikpat bīstams kā drošības robs serverī. Kas ir administrators, tas var uzstādīt paplašinājumus, mainīt kodu un eksportēt datus.

Šādus uzbrukumus var atpazīt pēc neveiksmīgu pieteikšanos uzkrāšanās, pēc POST pieprasījumiem uz pieteikšanās adresi no daudzām dažādām IP adresēm un pēc pieteikšanās mēģinājumiem ar lietotājvārdiem, piemēram, „admin“ vai vārdiem no impresuma. Uz to var norādīt arī manāmi augstāka servera slodze neparastos laikos, jo katra pieteikšanās prasa skaitļošanas laiku paroles pārbaudei.

Brute Force aizsardzība pieteikšanās: efektīvākie pasākumi

Ne katrs pasākums der katrai sistēmai. Turpmākā secība ir sevi pierādījusi, jo pirmie punkti ar nelielu piepūli dod visvairāk:

• Divu faktoru autentifikācija visiem kontiem ar administratora tiesībām. Pat uzminēta parole tad nepietiek. Sīkāk ceļvedī Divu faktoru autentifikācija administratoru piekļuvēm.
• Unikālas, garas paroles no paroļu pārvaldnieka, nekādu koplietojamu kontu.
• Rate Limiting tīmekļa serverī, lai katrai adresei minūtē būtu iespējami tikai daži mēģinājumi.
• Automātiski bloķējumi atkārtoti uzkrītošām adresēm tīkla līmenī, piemēram, ar Fail2ban.
• Administrēšanas zonas sašaurināšana: piekļuve tikai no uzņēmuma tīkla vai caur VPN, nevajadzīgas saskarnes izslēgt.
• Vienveidīgi kļūdu paziņojumi, kas neatklāj, vai lietotājvārds pastāv.
• Neveiksmīgu pieteikšanos uzraudzība un paziņošana par novirzēm.

Rate Limiting tīmekļa serverī

Ar Nginx pieprasījumu skaitu uz pieteikšanās adresi katrai IP adresei var ierobežot. Piemērs rāda WordPress pieteikšanās lapu; ceļu un PHP nodošanu pielāgojiet savai sistēmai.

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

# server blokā
location = /wp-login.php {
    limit_req zone=login burst=3 nodelay;
    limit_req_status 429;
    # šeit iekļaut sava servera ierasto PHP nodošanu
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php-fpm.sock;
}

Apache administrēšanas zonas ierobežošana uz zināmām adresēm piedāvā vienkāršu, efektīvu aizsardzību:

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

Adrese 192.0.2.0/24 ir vietturis no dokumentācijas diapazona; ievietojiet savu uzņēmuma tīklu vai sava VPN adresi. Ja jūsu vietne atrodas aiz starpniekservera vai CDN, serverim jāzina īstā apmeklētāja adrese, citādi noteikums nedarbojas kā vēlams.

Fail2ban un bloķējumi tīkla līmenī

Fail2ban nolasa žurnālu failus un adreses, kas atkārtoti kļūst uzkrītošas, uz noteiktu laiku bloķē ugunsmūrī. Nginx Rate Limiting Fail2ban jau nes līdzi piemērotu filtru:

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

Pēc pārstartēšanas ar fail2ban-client status pārbaudiet, vai jail ir aktīvi. Pievērsiet uzmanību tam, lai savas fiksētās adreses izņemtu caur ignoreip, lai neizslēgtu sevi pašu. Atsevišķu CMS pieteikšanās lapām iespējami savi filtri, taču tiem jāatbilst faktiskajam žurnāla formātam un tie iepriekš jāpārbauda.

Ja pirms servera atrodas CDN vai starpniekserveris, Fail2ban bez papildu iestatījumiem redz tikai tā adreses. Bloķējums tad skartu visus apmeklētājus. Šādā gadījumā tīmekļa serverim īstā apmeklētāja adrese jāpārņem no pirms tā esošā pakalpojuma galvenes, un bloķējumus labāk iestatīt tieši CDN.

Bloķējumi tīkla līmenī ir līdzeklis pret masu, nevis pret mērķtiecīgiem uzbrukumiem. Izkliedēti uzbrukumi no ļoti daudzām adresēm ar nedaudziem mēģinājumiem katrai adresei apiet jebkuru slieksni. Tāpēc otrais faktors paliek svarīgākais slānis, un Fail2ban galvenokārt samazina slodzi un žurnālu troksni.

Paroles pašu programmatūrā pareizi glabāt

Kas programmē savas pieteikšanās, paroles nekad nedrīkst glabāt atklātā tekstā vai ar ātrām jaucējfunkcijām, piemēram, MD5 vai SHA-1. PHP ar password_hash() piedāvā drošu risinājumu, kas sāls un metodi pārvalda automātiski.

<?php
declare(strict_types=1);

// Reģistrējoties vai mainot paroli
$hash = password_hash($passwort, PASSWORD_DEFAULT);

// Pieteikšanās laikā
if (password_verify($eingabe, $hashAusDatenbank)) {
    if (password_needs_rehash($hashAusDatenbank, PASSWORD_DEFAULT)) {
        $neu = password_hash($eingabe, PASSWORD_DEFAULT);
        // $neu saglabāt datubāzē
    }
    // Pieteikšanās sekmīga, atjaunot sesijas ID
} else {
    usleep(random_int(200000, 400000)); // vienmērīgs atbildes laiks
    // izvadīt vienveidīgu kļūdas paziņojumu
}

password_needs_rehash() nodrošina, ka vecāki jaucējkodi nākamajā pieteikšanās reizē automātiski tiek pārslēgti uz aktuālo metodi. Neveiksmīgus mēģinājumus protokolējiet ar laiku, kontu un adresi, lai paraugi kristu acīs. Norādes izvērtēšanai ir ceļvedī Tīmekļa servera žurnālu izvērtēšana pēc uzbrukuma.

Īpatnības CMS, veikalos un paneļos

Daudzām sistēmām bez redzamās pieteikšanās lapas ir citi ceļi, pa kuriem tiek pārbaudīti piekļuves dati. Šīs blakus ieejas aizsardzībā bieži aizmirst.

• WordPress: Saskarne xmlrpc.php arī pieņem pieteikšanās. Ja tā nav vajadzīga, piemēram, vecākām lietotnēm, bloķējiet to tīmekļa serverī. Pārbaudiet arī, vai lietotājvārdi nav redzami caur autoru lapām vai REST saskarni, un administratoriem lietojiet vārdus, kas publiski neparādās.
• Veikali: Bez administrēšanas zonas mērķis ir klientu konti, īpaši Credential Stuffing gadījumā. Šeit palīdz Rate Limiting, paziņojumi par jaunām pieteikšanās reizēm un izvēles otrais faktors klientiem.
• Hostinga paneļi un tīmekļa pasts: Šīs saskarnes bieži ir pieejamas visā pasaulē un aizsargā visu serveri. Tām jābūt pieejamām tikai no zināmiem tīkliem vai caur VPN.
• SSH: Pieteikšanās ar atslēgu nevis paroli klasisko minēšanu padara bezjēdzīgu.

Kādas aizsardzības funkcijas jūsu sistēma nes līdzi pati, rakstīts ražotāja dokumentācijā. Trešo pušu paplašinājumiem jābūt aktīvi uzturētiem, citādi tie paši kļūst par risku. WordPress operatoriem aktuālās prioritātes apkopo lapa WordPress un PHP2Shell.

Kā PHP SOS palīdz konkrēti?

• Apzinām visas jūsu serveru sasniedzamās pieteikšanās lapas, no CMS līdz hostinga panelim, un vērtējam to aizsardzību.
• Ierīkojam Rate Limiting, Fail2ban un piekļuves ierobežojumus servera nostiprināšanas ietvaros un tos pārbaudām.
• Atbalstām divu faktoru autentifikācijas ieviešanu administratoriem un dokumentējam ārkārtas piekļuves.
• Ar Security Monitoring pastāvīgi sekojam neveiksmīgām pieteikšanās reizēm un jauniem administratoru kontiem.

Biežāk uzdotie jautājumi

Avoti

• OWASP Cheat Sheet Series (Authentication)
• BSI: ieteikumi drošām parolēm un divu faktoru autentifikācijai
• OWASP Top 10