Ylläpidon kirjautumisten suojaaminen Brute Forcelta: Brute Force -suoja jokaiselle kirjautumiselle

Lyhyesti: Tehokas Brute Force -suoja kirjautumiselle koostuu useista kerroksista: kaksivaiheinen tunnistautuminen kaikille ylläpitäjille, kirjautumisyritysten jarru verkkopalvelimessa, automaattiset estot verkkotasolla ja turvallinen salasanojen tallennus koodissa. Jos mahdollista, ylläpitoalue on lisäksi tavoitettavissa vain tunnetuista verkoista.

Miten Brute Force -hyökkäykset kirjautumisiin etenevät

Jokaista julkisesti tavoitettavaa kirjautumissivua hyökätään ennemmin tai myöhemmin automaattisesti. Tämä koskee CMS-kirjautumisia, verkkokauppojen hallintapaneeleja, hosting-paneeleja, verkkopostia ja SSH:ta. Hyökkääjien ei tarvitse tietää, kenelle verkkosivusto kuuluu; heidän työkalunsa etsivät internetistä tunnettuja kirjautumisosoitteita.

Kolme muunnelmaa on yleisiä. Perinteisessä Brute Forcessa kokeillaan monia salasanoja yhtä tiliä vastaan. Password Sprayingissa yhtä yleistä salasanaa testataan monia tilejä vastaan lukitusten kiertämiseksi. Credential Stuffingissa käytetään tunnuksia, jotka on varastettu muista palveluista.

Omistajille ja johdolle tilanne tiivistyy yksinkertaisesti: kaapattu ylläpitäjän tili on yhtä vaarallinen kuin palvelimen tietoturva-aukko. Joka on ylläpitäjä, voi asentaa laajennuksia, muuttaa koodia ja viedä tietoja.

Tällaiset hyökkäykset tunnistaa epäonnistuneiden kirjautumisten kasaumasta, kirjautumisosoitteeseen suunnatuista POST-pyynnöistä monista eri IP-osoitteista sekä kirjautumisyrityksistä käyttäjänimillä kuten ”admin” tai tunnisteella, joka on peräisin yhteystiedoista. Myös havaittavasti kohonnut palvelimen kuormitus epätavallisina aikoina voi viitata siihen, koska jokainen kirjautuminen vaatii laskenta-aikaa salasanan tarkistukseen.

Brute Force -suoja kirjautumiselle: tehokkaimmat toimet

Kaikki toimet eivät sovi jokaiseen järjestelmään. Seuraava järjestys on osoittautunut toimivaksi, koska ensimmäiset kohdat yhdistävät eniten vaikutusta vähällä vaivalla:

• Kaksivaiheinen tunnistautuminen kaikille tileille, joilla on ylläpito-oikeudet. Silloin edes arvattu salasana ei riitä. Yksityiskohdat oppaassa Kaksivaiheinen tunnistautuminen ylläpitotunnuksille.
• Ainutkertaiset, pitkät salasanat salasanahallinnasta, ei jaettuja tilejä.
• Rate Limiting verkkopalvelimessa, jotta osoitetta kohden on mahdollista vain muutama yritys minuutissa.
• Automaattiset estot toistuvasti epäilyttäville osoitteille verkkotasolla, esimerkiksi Fail2banilla.
• Pienentäkää ylläpitoaluetta: pääsy vain yrityksen verkosta tai VPN:n kautta, tarpeettomat rajapinnat pois käytöstä.
• Yhdenmukaiset virheilmoitukset, jotka eivät paljasta, onko käyttäjänimi olemassa.
• Valvonta epäonnistuneista kirjautumisista ja ilmoitus poikkeamista.

Rate Limiting verkkopalvelimessa

Nginxillä kirjautumisosoitteeseen tulevien pyyntöjen määrää voi rajoittaa IP-osoitetta kohden. Esimerkki näyttää WordPressin kirjautumissivun; polun ja PHP-välityksen muokkaatte omaan järjestelmäänne sopiviksi.

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

# server-lohkossa
location = /wp-login.php {
    limit_req zone=login burst=3 nodelay;
    limit_req_status 429;
    # liitä tähän palvelimenne tavanomainen PHP-välitys
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php-fpm.sock;
}

Apachessa ylläpitoalueen rajaaminen tunnetuille osoitteille tarjoaa yksinkertaisen, tehokkaan suojan:

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

Osoite 192.0.2.0/24 on dokumentaatioalueen paikanvaraaja; asettakaa tilalle yrityksenne verkko tai VPN:n osoite. Jos verkkosivustonne on välityspalvelimen tai CDN:n takana, palvelimen on tunnettava kävijän todellinen osoite, muuten sääntö ei toimi toivotulla tavalla.

Fail2ban ja estot verkkotasolla

Fail2ban lukee lokitiedostoja ja estää toistuvasti huomiota herättävät osoitteet palomuurissa määrätyksi ajaksi. Nginxin Rate Limitingille Fail2banissa on valmiina sopiva suodatin:

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

Tarkistakaa uudelleenkäynnistyksen jälkeen komennolla fail2ban-client status, ovatko jailit aktiivisia. Muistakaa jättää omat kiinteät osoitteenne ignoreip-asetuksella pois, jotta ette sulje itseänne ulos. Yksittäisten CMS-järjestelmien kirjautumissivuille voi tehdä omia suodattimia, mutta niiden on sovittava todelliseen lokimuotoon ja ne on testattava ensin.

Jos palvelimen edessä on CDN tai välityspalvelin, Fail2ban näkee ilman lisäasetuksia vain niiden osoitteet. Esto osuisi silloin kaikkiin kävijöihin. Tässä tapauksessa verkkopalvelimen on otettava kävijän todellinen osoite edeltävän palvelun otsakkeesta, ja estot asetetaan paremmin suoraan CDN:ssä.

Verkkotason estot ovat työkalu massaa vastaan, eivät kohdennettuja hyökkäyksiä vastaan. Hajautetut hyökkäykset hyvin monesta osoitteesta muutamalla yrityksellä osoitetta kohden alittavat jokaisen kynnyksen. Siksi toinen tekijä pysyy tärkeimpänä kerroksena, ja Fail2ban vähentää ennen kaikkea kuormaa ja lokien kohinaa.

Salasanojen oikea tallennus omassa ohjelmistossa

Joka ohjelmoi omia kirjautumisia, ei saa koskaan tallentaa salasanoja selkokielisinä eikä nopeilla tiivistefunktioilla kuten MD5 tai SHA-1. PHP tuo mukanaan turvallisen ratkaisun password_hash(), joka hallitsee suolan ja menetelmän automaattisesti.

<?php
declare(strict_types=1);

// Rekisteröitymisessä tai salasanan vaihdossa
$hash = password_hash($passwort, PASSWORD_DEFAULT);

// Kirjautumisessa
if (password_verify($eingabe, $hashAusDatenbank)) {
    if (password_needs_rehash($hashAusDatenbank, PASSWORD_DEFAULT)) {
        $neu = password_hash($eingabe, PASSWORD_DEFAULT);
        // tallenna $neu tietokantaan
    }
    // Kirjautuminen onnistui, uusi istuntotunnus
} else {
    usleep(random_int(200000, 400000)); // tasainen vastausaika
    // tulosta yhdenmukainen virheilmoitus
}

password_needs_rehash() huolehtii siitä, että vanhemmat tiivisteet siirretään seuraavassa kirjautumisessa automaattisesti nykyiseen menetelmään. Kirjatkaa epäonnistuneet yritykset ajan, tilin ja osoitteen kera, jotta kuviot huomataan. Analysointivinkit ovat oppaassa Verkkopalvelimen lokien analysointi hyökkäyksen jälkeen.

CMS-järjestelmien, verkkokauppojen ja paneelien erityispiirteet

Monissa järjestelmissä näkyvän kirjautumissivun lisäksi on muitakin reittejä, joiden kautta tunnuksia tarkistetaan. Nämä sivuovet unohtuvat suojauksessa usein.

• WordPress: Rajapinta xmlrpc.php ottaa myös vastaan kirjautumisia. Jos sitä ei tarvita, esimerkiksi vanhoja sovelluksia varten, estäkää se verkkopalvelimessa. Tarkistakaa lisäksi, näkyvätkö käyttäjänimet kirjoittajasivujen tai REST-rajapinnan kautta, ja käyttäkää ylläpitäjille nimiä, jotka eivät näy julkisesti.
• Verkkokaupat: Hallintapaneelin lisäksi asiakastilit ovat kohteita, etenkin Credential Stuffingille. Apua tuovat Rate Limiting, ilmoitukset uusista kirjautumisista ja asiakkaille valinnainen toinen tekijä.
• Hosting-paneelit ja verkkoposti: Nämä käyttöliittymät ovat usein tavoitettavissa maailmanlaajuisesti ja suojaavat koko palvelinta. Niiden pitäisi olla tavoitettavissa vain tunnetuista verkoista tai VPN:n kautta.
• SSH: Kirjautuminen avaimella salasanan sijaan tekee perinteisestä arvaamisesta tehotonta.

Mitä suojatoimintoja järjestelmänne tarjoaa itse, kerrotaan valmistajan dokumentaatiossa. Kolmansien osapuolten laajennusten pitäisi olla aktiivisesti ylläpidettyjä, muuten ne muuttuvat itse riskiksi. WordPressin ylläpitäjille sivu WordPress ja PHP2Shell tiivistää ajankohtaiset prioriteetit.

Miten PHP SOS auttaa konkreettisesti?

• Kartoitamme palvelimienne kaikki tavoitettavat kirjautumissivut CMS:stä hosting-paneeliin ja arvioimme niiden suojauksen.
• Otamme käyttöön Rate Limitingin, Fail2banin ja pääsyrajoitukset osana palvelimen koventamista ja testaamme ne.
• Tuemme kaksivaiheisen tunnistautumisen käyttöönottoa ylläpitäjille ja dokumentoimme varapääsyt.
• Tietoturvavalvonnalla pidämme epäonnistuneet kirjautumiset ja uudet ylläpitäjätilit jatkuvasti silmällä.

Usein kysytyt kysymykset

Lähteet

• OWASP Cheat Sheet Series (Authentication)
• BSI: suositukset turvallisista salasanoista ja kaksivaiheisesta tunnistautumisesta
• OWASP Top 10