Administravimo zonų apsauga per IP, VPN ar papildomą apsaugą

Trumpai: administravimo zoną veiksmingiausiai apsaugosite atverdami ją tik žinomiems tinklams: per IP leidimus žiniatinklio serveryje, per VPN su fiksuotu išeinančiu adresu arba su antru, išankstiniu prisijungimu. Svarbu turėti visų administravimo adresų sąrašą, teisingai tvarkyti tarpinius serverius ir CDN bei išbandyti iš išorės. Apsauga papildo dviejų veiksnių autentifikavimą ir atnaujinimus, bet jų nepakeičia.

Kodėl užpakalinė dalis apskritai atvira?

Daugelyje įmonių administratoriai pastarąją savaitę atnaujino PHP ir paleido darbinius procesus iš naujo. Kas po to peržiūri prieigos žurnalus, dažnai pastebi ką kita: CMS prisijungimo puslapis, duomenų bazės įrankis ir talpinimo valdymo skydelis kviečiami visą parą iš viso pasaulio. O reikia jų tik saujelei žmonių savo komandoje.

Kiekvienas iš šių adresų yra atakos paviršius. Prisijungimo formos perrenkamos, administravimo įrankiai turi savų spragų, o užpakalinės dalies papildiniai dažnai patikrinami prasčiau nei CMS branduolys. Kai svetimi šių zonų apskritai nepasiekia, daugelis atakų nueina veltui dar neprasidėjusios.

Sąžiningai įvertinus: nuo paties PHP2Shell tai padeda mažai. Spragos yra interpretatoriuje ir, pasak php.net, išnaudojamos be prisijungimo per viešus PHP puslapius. Užpakalinės dalies apsauga yra nuolatinis sutvirtinimas, o ne skubi pataisa.

Administravimo zonos apsauga per IP, VPN ar antrą prisijungimą

Vieno teisingo metodo nėra. Lemia, kaip dirba jūsų komanda ir kur veikia svetainė.

Praktikoje pasiteisina derinys: leidimas tik VPN ar įmonės tinklui, o papildomai antras prisijungimas kaip atsarginis lygmuo. Tikrasis CMS prisijungimas lieka su dviejų veiksnių metodu, kaip aprašyta vadove Dviejų veiksnių autentifikavimas administratoriaus prieigoms.

Kurie adresai iš tikrųjų priklauso užpakalinei daliai?

Dažniausias trūkumas yra ne technika, o neišsamus sąrašas. Todėl eikite tokia tvarka:

1. Surašykite CMS ar parduotuvės prisijungimo puslapius, įskaitant alternatyvius prisijungimo adresus, kuriuos sukuria papildiniai.
2. Ieškokite administravimo įrankių: duomenų bazių sąsajų, failų tvarkyklių, diegimo skriptų, būsenos ir stebėsenos puslapių.
3. Įtraukite talpinimo ir serverio valdymo skydelius, kurie dažnai veikia savo prievaduose.
4. Patikrinkite testines ir parengiamąsias (staging) aplinkas, kurios dažnai naudoja tuos pačius prisijungimo duomenis kaip gyva svetainė.
5. Atskirkite sąsajas: kai kuriuos užpakalinės dalies kelius kviečia ir viešoji priekinė dalis, pavyzdžiui, Ajax užklausoms. Jų aklai blokuoti negalima, kitaip nustos veikti formos ar krepšeliai.

Penktas punktas yra priežastis, kodėl apsaugą visada reikia išbandyti. Pavyzdžiui, WordPress administravimo aplanke esantis failas naudojamas ir viešoms funkcijoms.

Konfigūracija: IP leidimas plius antras prisijungimas

Su Nginx abi sąlygas galima derinti. Su satisfy all užklausa turi ateiti iš leidžiamo tinklo ir papildomai praeiti antrą prisijungimą. Kelias, adresai ir PHP perdavimas yra vietos žymekliai:

location ^~ /backend/ {
    satisfy all;

    allow 192.0.2.0/24;      # įmonės tinklas (vietos žymeklis)
    allow 198.51.100.10;     # VPN išėjimas (vietos žymeklis)
    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;
    }
}

Įdėtoji PHP location yra svarbi: dėl ^~ kitos .php taisyklės nebevertinamos. Su Apache to paties pasieksite bloku, kuriame turi galioti abi sąlygos:

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

Slaptažodžių failas turi būti už žiniatinklio šakninio katalogo ribų. Antras prisijungimas kiekvienos užklausos metu perduoda prisijungimo duomenis, todėl naudokite tik per HTTPS.

Spąstai: CDN, tarpinis serveris, IPv6 ir darbas iš namų

Jei jūsų svetainė už CDN, pavyzdžiui, Cloudflare, ar apkrovos paskirstytuvo, žiniatinklio serveris pirmiausia mato tik jų adresus. IP leidimas tuomet arba užblokuotų visus, arba praleistų visus. Žiniatinklio serveris tikrąjį adresą turi perimti iš antraštės: Nginx su set_real_ip_from ir real_ip_header, Apache su mod_remoteip.

Čia galioja taisyklė: antraštę priimkite tik iš savo tarpinių serverių adresų. Kitaip kiekvienas lankytojas gali apsimesti bet kokia kilme. Taip pat svarbu, kad kilmės serveris nebūtų tiesiogiai pasiekiamas, nes kitaip tarpinį serverį su visomis jo taisyklėmis galima apeiti. Nuorodos apie tai pateiktos straipsnyje Ugniasienė žiniatinklio serveriui.

Dar du dalykai dažnai nepastebimi. Jei serveris pasiekiamas per IPv6, ir jūsų tinklo IPv6 adresams reikia įrašo, kitaip administratoriai su IPv6 atsidurs prieš užraktą. O privatūs interneto ryšiai reguliariai keičia adresą. Todėl dirbantiems iš namų ir išoriniams paslaugų teikėjams VPN dažniausiai yra stabilesnis sprendimas.

Kaip patikrinti, ar apsauga veikia

Netestuota taisyklė laikoma neįgyvendinta. Tikrinkite iš ryšio už įmonės tinklo ribų, pavyzdžiui, per mobilųjį tinklą:

# Tikimasi: 403 (užblokuota) arba 401 (reikalaujamas antras prisijungimas)
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/backend/
# Tikrinkite ir tiesiogiai PHP failus, ne tik katalogą
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/backend/index.php

Po to tuos pačius kreipinius pakartokite iš įmonės tinklo ar VPN: ten puslapis turi būti pasiekiamas. Tada patikrinkite viešąją priekinę dalį, t. y. formas, paiešką ir krepšelį. Per kitų dienų žurnalus prieigos prie administravimo adresų turėtų beveik tik su būsena 401 arba 403.

Jei zona iki šiol buvo atvira, verta pažvelgti į esamas paskyras. Kaip rasti nežinomus administratorius, aprašo Svetimų administratorių paskyrų paieška CMS ir serveryje. Papildomai lėtina apsauga nuo masinio perrinkimo, žr. Administratoriaus prisijungimų apsauga nuo brute force.

Kaip PHP SOS padeda konkrečiai?

• Surenkame visus jūsų svetainių, skydelių ir įrankių administravimo adresus ir atskiriame juos nuo viešai reikalingų kelių.
• Kartu su jumis parenkame tinkamą metodą, priklausomai nuo komandos dydžio, darbo iš namų ir talpinimo.
• Taisykles įgyvendiname žiniatinklio serveryje, atsižvelgiame į CDN, tarpinį serverį ir IPv6 ir paliekame atvirą kelią atgal.
• Išbandome iš išorės ir iš vidaus ir perduodame trumpą dokumentaciją su leidžiamais tinklais.

Administravimo zonų apsauga yra mūsų PHP žiniatinklio serverių sutvirtinimo dalis.

Dažni klausimai

Šaltiniai

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