Zaščita skrbniških območij z IP, VPN ali dodatno zaščito

Na kratko: Skrbniško območje najučinkoviteje zaščitite tako, da ga odprete samo za znana omrežja: z dovoljenimi IP v spletnem strežniku, prek VPN s stalnim izhodnim naslovom ali z drugo, predhodno prijavo. Pomembni so popoln seznam vseh naslovov za upravljanje, pravilna obravnava proxyjev in CDN-jev ter preizkus od zunaj. Zaščita dopolnjuje dvofaktorsko prijavo in posodobitve, ne nadomešča jih.

Zakaj je zaledje sploh odprto?

V mnogih podjetjih so skrbniki prejšnji teden posodobili PHP in znova zagnali workerje. Kdor nato pogleda dnevnike dostopa, pogosto ugotovi nekaj drugega: prijavna stran CMS, orodje za bazo podatkov in nadzorna plošča gostovanja se dan in noč kličejo z vsega sveta. Potrebuje pa jih le peščica ljudi v lastni ekipi.

Vsak od teh naslovov je napadalna površina. Prijavni obrazci se preizkušajo z ugibanjem, upravljalska orodja imajo lastne ranljivosti, vtičniki za zaledje pa so pogosto slabše pregledani kot jedro CMS. Če tujci teh območij sploh ne dosežejo, mnogi napadi zaidejo v prazno, še preden se začnejo.

Pošteno ovrednoteno: proti PHP2Shell samemu to pomaga le malo. Ranljivosti so v interpreterju in jih je po navedbah php.net mogoče sprožiti brez prijave prek javnih strani PHP. Zaščita zaledja je trajno utrjevanje, ne nujen popravek.

Zaščita skrbniškega območja z IP, VPN ali drugo prijavo

Ni ene same prave metode. Odločilno je, kako dela vaša ekipa in kje teče spletna stran.

V praksi se obnese kombinacija: dovoljenje samo za VPN ali podjetniško omrežje, poleg tega druga prijava kot nadomestna raven. Prava prijava v CMS ostane z dvofaktorskim postopkom, kot je opisano v vodniku Dvofaktorska prijava za skrbniške dostope.

Kateri naslovi sploh sodijo v zaledje?

Najpogostejša šibkost ni tehnika, ampak nepopoln seznam. Zato ukrepajte v tem vrstnem redu:

1. Zajemite prijavne strani CMS ali spletne trgovine, vključno z nadomestnimi prijavnimi naslovi, ki jih ustvarijo vtičniki.
2. Poiščite upravljalska orodja: vmesnike za baze podatkov, upravitelje datotek, namestitvene skripte, strani s stanjem in nadzorom.
3. Vključite nadzorne plošče gostovanja in strežnika, ki pogosto tečejo na lastnih vratih.
4. Preverite testne in staging instance, ki pogosto uporabljajo enake dostopne podatke kot živa stran.
5. Razmejite vmesnike: nekatere poti zaledja kliče tudi javni frontend, na primer za zahteve Ajax. Teh ne smete slepo blokirati, sicer se pokvarijo obrazci ali košarice.

Peta točka je razlog, zakaj je treba zaščito vedno preizkusiti. Pri WordPressu se na primer ena datoteka v skrbniški mapi uporablja tudi za javne funkcije.

Konfiguracija: dovoljeni IP in druga prijava

Pri Nginxu je mogoče združiti oba pogoja. S satisfy all mora zahteva priti iz dovoljenega omrežja in poleg tega opraviti drugo prijavo. Pot, naslovi in predaja PHP so nadomestni znaki:

location ^~ /backend/ {
    satisfy all;

    allow 192.0.2.0/24;      # podjetniško omrežje (nadomestni znak)
    allow 198.51.100.10;     # izhod VPN (nadomestni znak)
    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;
    }
}

Gnezdena lokacija PHP je pomembna: zaradi ^~ se druga pravila za .php ne ovrednotijo več. Pri Apacheju enako dosežete z blokom, v katerem morata veljati oba pogoja:

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

Datoteka z gesli sodi zunaj korenske mape spletnega strežnika (webroot). Druga prijava ob vsaki zahtevi prenaša dostopne podatke, zato jo uporabljajte samo prek HTTPS.

Pasti: CDN, proxy, IPv6 in delo od doma

Če je vaša spletna stran za CDN-jem, kot je Cloudflare, ali load balancerjem, spletni strežnik sprva vidi samo njegove naslove. Dovoljenje po IP bi potem ali vse blokiralo ali vse spustilo skozi. Spletni strežnik mora pravi naslov prevzeti iz glave: pri Nginxu z set_real_ip_from in real_ip_header, pri Apacheju z mod_remoteip.

Pri tem velja: glavo sprejemajte samo z lastnih naslovov proxyja. Sicer lahko vsak obiskovalec zlaže poljuben izvor. Enako pomembno je, da izvorni strežnik ni neposredno dosegljiv, ker je sicer proxy skupaj s svojimi pravili mogoče obiti. Napotki so v prispevku Požarni zid za spletni strežnik.

Dve nadaljnji točki se pogosto spregledata. Če je strežnik dosegljiv prek IPv6, potrebujejo vnos tudi naslovi IPv6 vašega omrežja, sicer skrbniki z IPv6 obstanejo pred blokado. In zasebni internetni priključki redno menjajo naslov. Za delo od doma in zunanje ponudnike storitev je zato VPN praviloma stabilnejša rešitev.

Kako preverite, ali zaščita deluje

Pravilo, ki ni preizkušeno, ne velja za izvedeno. Preverite s priključka zunaj podjetniškega omrežja, na primer prek mobilnega omrežja:

# Pričakovano: 403 (blokirano) ali 401 (zahtevana druga prijava)
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/backend/
# Preverite tudi datoteke PHP neposredno, ne samo imenika
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/backend/index.php

Nato enake klice še iz podjetniškega omrežja ali prek VPN: tam mora biti stran dosegljiva. Nato preverite javni frontend, torej obrazce, iskanje in košarico. V dnevnikih naslednjih dni bi se morali dostopi do skrbniških naslovov skoraj izključno pojavljati s statusom 401 ali 403.

Če je bilo območje doslej odprto, se splača pogledati obstoječe račune. Kako najdete neznane skrbnike, opisuje Iskanje tujih skrbniških računov v CMS in na strežniku. Dodatno pomaga zaščita pred množičnim ugibanjem, glejte Zaščita skrbniških prijav pred brute force.

Kako konkretno pomaga PHP SOS?

• Zajamemo vse naslove za upravljanje vaših spletnih strani, nadzornih plošč in orodij ter jih ločimo od poti, ki jih javnost potrebuje.
• Z vami izberemo ustrezen postopek, odvisno od velikosti ekipe, dela od doma in gostovanja.
• Pravila uvedemo v spletnem strežniku, upoštevamo CDN, proxy in IPv6 ter pri tem ohranimo pot nazaj.
• Preizkusimo od zunaj in od znotraj ter predamo kratko dokumentacijo z dovoljenimi omrežji.

Zaščita skrbniških območij je del našega utrjevanja strežnikov PHP.

Pogosta vprašanja

Viri

• OWASP Cheat Sheet Series
• Dokumentacija Nginx
• Apache HTTP Server: dokumentacija