Avskärma adminområden med IP, VPN eller extra skydd

Kort sagt: Adminområdet skyddar ni mest verksamt genom att bara öppna det för kända nät: via IP-spärr i webbservern, via ett VPN med fast utgångsadress eller med en andra, förinställd inloggning. Viktiga är en fullständig lista över alla administrationsadresser, rätt hantering av proxyer och CDN:er och ett test utifrån. Avskärmningen kompletterar tvåfaktorsinloggning och uppdateringar, den ersätter dem inte.

Varför står backend över huvud taget öppen?

I många företag har administratörer under den gångna veckan uppdaterat PHP och startat om workers. Den som därefter tittar i åtkomstloggarna upptäcker ofta något annat: CMS:ets inloggningssida, databasverktyget och webbhotellets panel anropas dygnet runt från hela världen. De behövs dock bara av en handfull personer i det egna teamet.

Varje sådan adress är angreppsyta. Inloggningsformulär prövas på måfå, administrationsverktyg har egna sårbarheter, och tillägg för backend är ofta sämre granskade än kärnan i ett CMS. När obehöriga inte når de här områdena alls går många angrepp i tomma luften innan de börjar.

Ärligt bedömt: mot själva PHP2Shell hjälper det här bara lite. Sårbarheterna ligger i tolken och kan enligt php.net utlösas utan inloggning via offentliga PHP-sidor. Avskärmningen av backend är en varaktig härdning, inte en akutpatch.

Skydda adminområdet med IP, VPN eller andra inloggning

Det finns ingen enskild rätt metod. Avgörande är hur ert team arbetar och var webbplatsen körs.

I praktiken fungerar en kombination bra: frigivning bara för VPN:et eller företagsnätet, dessutom en andra inloggning som reservnivå. Själva inloggningen i CMS:et finns kvar med tvåfaktorsmetod, som beskrivs i guiden Tvåfaktorsinloggning för adminåtkomst.

Vilka adresser hör egentligen till backend?

Den vanligaste svagheten är inte tekniken utan en ofullständig lista. Gå därför fram i den här ordningen:

1. Registrera inloggningssidor för CMS eller butik, inklusive alternativa inloggningsadresser som tillägg skapar.
2. Leta upp administrationsverktyg: databasgränssnitt, filhanterare, installationsskript, status- och övervakningssidor.
3. Ta med webbhotells- och serverpaneler, som ofta körs på egna portar.
4. Kontrollera test- och staging-instanser, som ofta använder samma inloggningsuppgifter som den skarpa webbplatsen.
5. Avgränsa gränssnitt: Vissa backend-sökvägar anropas också av den offentliga frontend, till exempel för Ajax-förfrågningar. De får ni inte spärra blint, annars slutar formulär eller varukorgar fungera.

Punkt fem är anledningen till att en avskärmning alltid måste testas. I WordPress används till exempel en fil i admin-mappen också för offentliga funktioner.

Konfiguration: IP-spärr plus andra inloggning

Under Nginx går båda villkoren att kombinera. Med satisfy all måste en förfrågan komma från ett frigivet nät och dessutom klara den andra inloggningen. Sökväg, adresser och PHP-överlämning är platshållare:

location ^~ /backend/ {
    satisfy all;

    allow 192.0.2.0/24;      # företagsnät (platshållare)
    allow 198.51.100.10;     # VPN-utgång (platshållare)
    deny  all;

    auth_basic           "Interner Bereich";
    auth_basic_user_file /etc/nginx/htpasswd-backend;

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php-fpm.sock;
    }
}

Den nästlade PHP-location är viktig: Genom ^~ utvärderas inte längre andra regler för .php. Under Apache uppnår ni detsamma med ett block där båda villkoren måste gälla:

<Location "/backend">
    AuthType Basic
    AuthName "Interner Bereich"
    AuthUserFile /etc/apache2/htpasswd-backend
    <RequireAll>
        Require ip 192.0.2.0/24 198.51.100.10
        Require valid-user
    </RequireAll>
</Location>

Lösenordsfilen hör hemma utanför webbroten. Den andra inloggningen överför inloggningsuppgifter vid varje förfrågan, använd den därför bara över HTTPS.

Fällorna: CDN, proxy, IPv6 och hemmakontor

Ligger er webbplats bakom ett CDN som Cloudflare eller en lastbalanserare ser webbservern till en början bara dess adresser. En IP-spärr skulle då antingen stänga ute alla eller släppa in alla. Webbservern måste hämta den verkliga adressen från en header, under Nginx med set_real_ip_from och real_ip_header, under Apache med mod_remoteip.

Då gäller: Acceptera headern bara från de egna proxyadresserna. Annars kan varje besökare låtsas ha vilket ursprung som helst. Lika viktigt är att ursprungsservern inte är nåbar direkt, för annars går proxyn med sina regler att kringgå. Anvisningar finns under Brandvägg för webbservrar.

Ytterligare två punkter förbises ofta. Är servern nåbar via IPv6 behöver även IPv6-adresserna i ert nät en post, annars hamnar administratörer med IPv6 framför en spärr. Och privata internetanslutningar byter adress regelbundet. För hemmakontor och externa tjänsteleverantörer är ett VPN därför oftast den stabilare lösningen.

Så kontrollerar ni att avskärmningen fungerar

En regel som inte är testad räknas inte som genomförd. Kontrollera från en anslutning utanför företagsnätet, till exempel via mobilnätet:

# Väntat: 403 (spärrad) eller 401 (andra inloggning krävs)
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/backend/
# Kontrollera även PHP-filer direkt, inte bara katalogen
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/backend/index.php

Gör därefter samma anrop från företagsnätet eller VPN:et: Där måste sidan vara nåbar. Kontrollera sedan den offentliga frontend, alltså formulär, sökning och varukorg. I loggarna de följande dagarna bör åtkomster till adminadresserna nästan bara visas med status 401 eller 403.

Har området tidigare varit öppet är det värt att titta på de befintliga kontona. Hur ni hittar okända administratörer beskriver Hitta främmande adminkonton i CMS och server. Som komplement bromsar ett skydd mot massiv trial and error, se Skydda admininloggningar mot brute force.

Hur hjälper PHP SOS konkret?

• Vi registrerar alla administrationsadresser för era webbplatser, paneler och verktyg och skiljer dem från sökvägar som behövs offentligt.
• Vi väljer tillsammans med er lämpligt förfarande, beroende på teamstorlek, hemmakontor och hosting.
• Vi genomför reglerna i webbservern, tar hänsyn till CDN, proxy och IPv6 och håller samtidigt en återväg öppen.
• Vi testar utifrån och inifrån och lämnar över en kort dokumentation med de frigivna näten.

Avskärmning av adminområden är en del av vår serverhärdning för PHP-webbservrar.

Vanliga frågor

Källor

• OWASP Cheat Sheet Series
• Nginx-dokumentation
• Apache HTTP Server: dokumentation