Lühidalt: Admin-ala kaitsete kõige tõhusamalt, kui avate selle ainult tuntud võrkudele: IP-lubamisega veebiserveris, fikseeritud väljuva aadressiga VPN-i kaudu või teise, eelneva sisselogimisega. Olulised on kõigi haldusaadresside täielik nimekiri, proksite ja CDN-ide õige käsitlemine ning test väljastpoolt. Varjamine täiendab kaheastmelist sisselogimist ja uuendusi, kuid ei asenda neid.
Miks on taustasüsteem üldse avatud?
Paljudes ettevõtetes uuendasid administraatorid eelmisel nädalal PHP-d ja taaskäivitasid töölisprotsessid. Kes vaatab pärast seda juurdepääsulogisid, märkab sageli midagi muud: sisuhaldussüsteemi sisselogimislehte, andmebaasitööriista ja hostingupaneeli avatakse ööpäevaringselt kogu maailmast. Vajavad neid aga ainult käputäis inimesi oma meeskonnast.
Iga selline aadress on ründepind. Sisselogimisvorme proovitakse läbi, haldustööriistades on omad augud ning taustasüsteemi pistikprogrammid on sageli vähem hoolikalt kontrollitud kui sisuhaldussüsteemi tuum. Kui võõrad neid alasid üldse kätte ei saa, jäävad paljud rünnakud tühja, enne kui need algavad.
Ausalt hinnates: PHP2Shelli enda vastu see aitab vähe. Augud asuvad interpretaatoris ja neid saab php.net-i andmetel ilma sisselogimiseta avalike PHP-lehtede kaudu vallandada. Taustasüsteemi varjamine on püsiv kõvendamine, mitte hädapaik.
Admin-ala kaitsmine IP, VPN-i või teise sisselogimisega
Ühte õiget meetodit ei ole. Otsustav on, kuidas teie meeskond töötab ja kus veebisait asub.
| Meetod | Sobib | Piir |
|---|---|---|
| IP-lubamine veebiserveris | kontor fikseeritud aadressiga, väikesed meeskonnad | vahelduvad aadressid kodukontoris, nimekirja hooldus |
| VPN fikseeritud väljuva aadressiga | hajutatud meeskonnad, teenusepakkujad | VPN ise peab olema hästi kaitstud ja ajakohane |
| Eelnev sisselogimine (HTTP-autentimine) | täiendus, kui fikseeritud aadress ei ole võimalik | lisaparool, mõistlik ainult koos TLS-iga |
| Kliendisertifikaadid | mõned fikseeritult hallatavad seadmed | sertifikaatide väljastamine ja tühistamine nõuab distsipliini |
| Oma hostinimi ainult sisevõrgus | suuremad keskkonnad sisemise DNS-iga | rakenduse ümberehitus, kõik sisuhaldussüsteemid ei toeta seda |
Praktikas on end tõestanud kombinatsioon: luba ainult VPN-ile või ettevõtte võrgule, lisaks teine sisselogimine varutasandina. Sisuhaldussüsteemi tegelik sisselogimine jääb kaheastmelise meetodiga alles, nagu kirjeldab juhend Kaheastmeline sisselogimine admin-ligipääsudele.
Millised aadressid taustasüsteemi tegelikult kuuluvad?
Sagedaseim nõrkus ei ole tehnika, vaid puudulik nimekiri. Tegutsege seetõttu selles järjekorras:
- Sisuhaldussüsteemi või poe sisselogimislehed üles lugeda, sealhulgas pistikprogrammide loodud alternatiivsed sisselogimisaadressid.
- Haldustööriistu otsida: andmebaasiliidesed, failihaldurid, paigaldusskriptid, oleku- ja monitooringulehed.
- Hostingu- ja serveripaneelid kaasata, mis töötavad sageli oma portidel.
- Test- ja staging-keskkonnad kontrollida, mis kasutavad sageli samu ligipääsuandmeid mis toodangusait.
- Liidesed piiritleda: Mõnda taustasüsteemi teed kutsub ka avalik esiosa, näiteks Ajax-päringute jaoks. Neid ei tohi pimesi blokeerida, muidu lähevad vormid või ostukorvid katki.
Viies punkt on põhjus, miks varjamist tuleb alati testida. WordPressis kasutatakse näiteks ühte admin-kausta faili ka avalike funktsioonide jaoks.
Konfiguratsioon: IP-lubamine pluss teine sisselogimine
Nginxis saab mõlemat tingimust kombineerida. Valikuga satisfy all peab päring tulema lubatud võrgust ja läbima lisaks teise sisselogimise. Tee, aadressid ja PHP-le üleandmine on kohatäitjad:
location ^~ /backend/ {
satisfy all;
allow 192.0.2.0/24; # Ettevõtte võrk (kohatäide)
allow 198.51.100.10; # VPN-i väljund (kohatäide)
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;
}
}
Pesastatud PHP-location on oluline: ^~ tõttu ei hinnata teisi .php reegleid enam. Apache'is saavutate sama plokiga, kus peavad kehtima mõlemad tingimused:
<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>
Paroolifail kuulub veebijuurkataloogist väljapoole. Teine sisselogimine edastab ligipääsuandmeid igal päringul, seetõttu kasutage seda ainult HTTPS-i kaudu.
Hoidke enne iga muudatust serverisse avatud teine tee, näiteks olemasolev SSH-seanss. Kes end ise välja lukustab, vajab muidu hostingupakkujat.
Lõksud: CDN, proksi, IPv6 ja kodukontor
Kui teie veebisait asub CDN-i, näiteks Cloudflare'i, või koormusjaoturi taga, näeb veebiserver esialgu ainult nende aadresse. IP-lubamine lukustaks siis kas kõik või laseks kõik läbi. Veebiserver peab tegeliku aadressi võtma päisest, Nginxis valikutega set_real_ip_from ja real_ip_header, Apache'is mooduliga mod_remoteip.
Seejuures kehtib: aktsepteerige päist ainult oma proksi aadressidelt. Muidu saab iga külastaja teeselda suvalist päritolu. Sama oluline on, et lähteserver ei oleks otse kättesaadav, sest muidu saab proksi koos selle reeglitega mööda minna. Vihjeid leiate artiklist Tulemüür veebiserverile.
Kaks muud punkti jäävad sageli märkamata. Kui server on IPv6 kaudu kättesaadav, vajavad kirje ka teie võrgu IPv6-aadressid, muidu jäävad IPv6-ga administraatorid blokeeringu taha. Ja eraviisilised internetiühendused vahetavad aadressi regulaarselt. Kodukontori ja väliste teenusepakkujate jaoks on seetõttu VPN tavaliselt stabiilsem lahendus.
Nii kontrollite, kas varjamine toimib
Reegel, mida pole testitud, ei loe rakendatuks. Kontrollige ühenduselt väljaspool ettevõtte võrku, näiteks mobiilivõrgu kaudu:
# Oodatud: 403 (blokeeritud) või 401 (nõutakse teist sisselogimist)
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/backend/
# Kontrollige ka PHP-faile otse, mitte ainult kataloogi
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/backend/index.php
Seejärel samad päringud ettevõtte võrgust või VPN-ist: seal peab leht olema kättesaadav. Kontrollige pärast seda avalikku esiosa, see tähendab vorme, otsingut ja ostukorvi. Järgmiste päevade logides peaksid juurdepääsud admin-aadressidele esinema peaaegu ainult olekuga 401 või 403.
Kui ala on seni olnud avatud, tasub vaadata olemasolevaid kontosid. Kuidas tundmatuid administraatoreid leida, kirjeldab Võõraste admin-kontode leidmine sisuhaldussüsteemis ja serveris. Täiendavalt pidurdab massilist läbiproovimist kaitse, vt Admin-sisselogimiste kaitsmine jõhkra jõu (brute force) rünnakute vastu.
Kuidas PHP SOS konkreetselt aitab?
- Me kaardistame kõik teie veebisaitide, paneelide ja tööriistade haldusaadressid ning eraldame need avalikult vajalikest teedest.
- Me valime teiega sobiva meetodi, olenevalt meeskonna suurusest, kodukontorist ja hostingust.
- Me rakendame reeglid veebiserveris, arvestame CDN-i, proksi ja IPv6-ga ning hoiame seejuures avatud tagasitee.
- Me testime väljast ja seest ning anname üle lühikese dokumentatsiooni lubatud võrkudega.
Admin-alade varjamine on osa meie PHP veebiserverite kõvendamisest.
Korduma kippuvad küsimused
Kas turvaline parool sisuhaldussüsteemi sisselogimiseks ei piisa?
Tugev parool ja kaheastmeline sisselogimine on kohustuslikud, kuid kaitsevad ainult sisselogimist ennast. Augud sisselogimislehtedes, pistikprogrammides või haldustööriistades on siiski igaühele kättesaadavad. Varjamine võrgu- või veebiserveri tasemel tagab, et võõrad ei jõuagi sinnamaani.
Mida teha, kui minu töötajatel on vahelduvad IP-aadressid?
Siis on fikseeritud väljuva aadressiga VPN tavaliselt parem lahendus kui üksikute aadresside nimekiri. Kõik administraatorid ühendavad esmalt VPN-iga ja veebiserver lubab ainult selle aadressi. Alternatiivina sobib eelnev teine sisselogimine.
Kas IP-blokeering töötab ka Cloudflare'i või koormusjaoturi taga?
Ainult siis, kui veebiserver võtab külastaja tegeliku aadressi usaldusväärsest päisest ja aktsepteerib seda päist ainult oma proksilt. Muidu näeb see ainult proksi aadresse või usaldab võltsitud andmeid. Lisaks ei tohiks lähteserver olla internetist otse kättesaadav.
Kas varjatud admin-ala kaitseb PHP2Shelli eest?
Ainult väga piiratud ulatuses. PHP2Shelli augud asuvad PHP interpretaatoris ja neid saab ilma sisselogimiseta ära kasutada iga avaliku PHP-lehe kaudu. PHP2Shelli vastu aitab PHP uuendus koos kõigi töölisprotsesside taaskäivitamisega, varjamine vähendab ainult ülejäänud ründepinda.