Odstínění administrace pomocí IP, VPN nebo další ochrany

Stručně: Administraci nejúčinněji ochráníte tím, že ji otevřete jen známým sítím: povolením IP adres ve webovém serveru, přes VPN s pevnou výstupní adresou nebo druhým, předřazeným přihlášením. Důležitý je úplný seznam všech administračních adres, správné zacházení s proxy a CDN a test zvenčí. Odstínění doplňuje dvoufázové ověření a aktualizace, nenahrazuje je.

Proč je backend vůbec otevřený?

V mnoha firmách administrátoři minulý týden aktualizovali PHP a restartovali workery. Kdo se poté podívá do přístupových logů, často zjistí něco jiného: přihlašovací stránka CMS, databázový nástroj a panel hostingu jsou nepřetržitě volány z celého světa. Potřebuje je přitom jen hrstka lidí z vlastního týmu.

Každá z těchto adres je plocha pro útok. Přihlašovací formuláře se zkoušejí, administrační nástroje obsahují vlastní zranitelnosti a pluginy pro backend bývají hůře prověřené než jádro CMS. Pokud se cizí osoby k těmto oblastem vůbec nedostanou, mnoho útoků vyjde naprázdno dřív, než začnou.

Upřímně řečeno: proti samotnému PHP2Shell to pomáhá jen málo. Zranitelnosti jsou v interpretu a podle php.net je lze vyvolat bez přihlášení přes veřejné stránky PHP. Odstínění backendu je trvalé zpevnění, ne nouzová záplata.

Ochrana administrace pomocí IP, VPN nebo druhého přihlášení

Neexistuje jedna správná metoda. Rozhoduje, jak váš tým pracuje a kde web běží.

V praxi se osvědčuje kombinace: povolení jen pro VPN nebo firemní síť a druhé přihlášení jako záložní úroveň. Vlastní přihlášení do CMS zůstává s dvoufázovým ověřením, jak popisuje příručka Dvoufázové ověření pro administrátorské přístupy.

Které adresy vlastně patří k backendu?

Nejčastější slabinou není technika, ale neúplný seznam. Postupujte proto v tomto pořadí:

1. Zachyťte přihlašovací stránky CMS nebo e-shopu, včetně alternativních přihlašovacích adres, které zakládají pluginy.
2. Vyhledejte administrační nástroje: databázová rozhraní, správce souborů, instalační skripty, stavové a monitorovací stránky.
3. Zahrňte panely hostingu a serveru, které často běží na vlastních portech.
4. Zkontrolujte testovací a stagingové instance, které často používají stejné přístupové údaje jako ostrý web.
5. Vymezte rozhraní: Některé cesty backendu volá i veřejný frontend, například pro požadavky Ajax. Ty nesmíte slepě blokovat, jinak přestanou fungovat formuláře nebo košíky.

Bod pět je důvodem, proč je nutné odstínění vždy testovat. U WordPressu se například jeden soubor ve složce administrace používá i pro veřejné funkce.

Konfigurace: povolení IP plus druhé přihlášení

V Nginx lze obě podmínky zkombinovat. S satisfy all musí požadavek přijít z povolené sítě a navíc projít druhým přihlášením. Cesta, adresy a předání PHP jsou zástupné hodnoty:

location ^~ /backend/ {
    satisfy all;

    allow 192.0.2.0/24;      # firemní síť (zástupná hodnota)
    allow 198.51.100.10;     # výstup VPN (zástupná hodnota)
    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;
    }
}

Vnořená location pro PHP je důležitá: kvůli ^~ se ostatní pravidla pro .php už nevyhodnocují. V Apache dosáhnete téhož blokem, ve kterém musí platit obě podmínky:

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

Soubor s hesly patří mimo webroot. Druhé přihlášení přenáší přístupové údaje při každém požadavku, proto ho používejte jen přes HTTPS.

Úskalí: CDN, proxy, IPv6 a home office

Pokud web leží za CDN jako Cloudflare nebo za load balancerem, vidí webserver zpočátku jen jejich adresy. Povolení IP by pak buď zablokovalo všechny, nebo propustilo všechny. Webserver musí převzít skutečnou adresu z hlavičky, v Nginx pomocí set_real_ip_from a real_ip_header, v Apache pomocí mod_remoteip.

Přitom platí: hlavičku přijímejte jen z adres vlastních proxy. Jinak může každý návštěvník předstírat libovolný původ. Stejně důležité je, aby původní server nebyl přímo dostupný, protože jinak lze proxy včetně jejích pravidel obejít. Poznámky k tomu najdete v článku Firewall pro webserver.

Dva další body se často přehlížejí. Pokud je server dostupný přes IPv6, potřebují záznam i adresy IPv6 vaší sítě, jinak narazí administrátoři s IPv6 na blokaci. A soukromé internetové přípojky pravidelně mění adresu. Pro home office a externí dodavatele je proto VPN zpravidla stabilnější řešení.

Jak ověřit, že odstínění funguje

Pravidlo, které není otestováno, se nepovažuje za zavedené. Testujte z přípojky mimo firemní síť, například přes mobilní síť:

# Očekáváno: 403 (zablokováno) nebo 401 (vyžadováno druhé přihlášení)
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/backend/
# Zkontrolujte i soubory PHP přímo, nejen adresář
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/backend/index.php

Poté stejné požadavky z firemní sítě nebo z VPN: tam musí být stránka dostupná. Následně zkontrolujte veřejný frontend, tedy formuláře, vyhledávání a košík. V logu následujících dnů by se měly přístupy na administrační adresy objevovat téměř jen se stavem 401 nebo 403.

Pokud byla oblast dosud otevřená, vyplatí se podívat na existující účty. Jak najít neznámé administrátory, popisuje článek Jak najít cizí administrátorské účty v CMS a na serveru. Doplňkově pomáhá ochrana proti hromadnému zkoušení hesel, viz Ochrana přihlášení administrátorů před brute force.

Jak konkrétně pomáhá PHP SOS?

• Zaznamenáme všechny administrační adresy vašich webů, panelů a nástrojů a oddělíme je od cest, které jsou potřeba veřejně.
• S vámi vybereme vhodný postup podle velikosti týmu, home office a hostingu.
• Pravidla nastavíme ve webovém serveru, zohledníme CDN, proxy a IPv6 a přitom necháme otevřenou cestu zpět.
• Otestujeme zvenčí i zevnitř a předáme krátkou dokumentaci s povolenými sítěmi.

Odstínění administračních oblastí je součástí našeho hardeningu serveru pro webservery s PHP.

Časté dotazy

Zdroje

• OWASP Cheat Sheet Series
• Dokumentace Nginx
• Apache HTTP Server: dokumentace