Röviden: Az admin felületet akkor védi a leghatékonyabban, ha csak ismert hálózatok számára nyitja meg: IP-engedélyezéssel a webszerverben, rögzített kimenő címmel rendelkező VPN-en keresztül vagy egy második, előtét-bejelentkezéssel. Fontos az összes adminisztrációs cím teljes listája, a proxyk és CDN-ek helyes kezelése, és a kívülről végzett teszt. Az elzárás kiegészíti a kétfaktoros bejelentkezést és a frissítéseket, de nem helyettesíti őket.
Miért van egyáltalán nyitva a backend?
Sok vállalatnál az adminok az elmúlt héten frissítették a PHP-t és újraindították a workereket. Aki ezután megnézi a hozzáférési naplókat, gyakran mást talál: a CMS bejelentkezési oldalát, az adatbázis-eszközt és a tárhelypanelt éjjel-nappal hívogatják a világ minden részéről. Szükségük viszont csak a saját csapat néhány tagjának van rájuk.
Ezek mindegyike támadási felület. A bejelentkezési űrlapokat végigpróbálgatják, az adminisztrációs eszközök saját hibákat tartalmaznak, a backend bővítményeit pedig gyakran kevésbé ellenőrzik, mint a CMS magját. Ha idegenek ezeket a területeket egyáltalán nem érik el, sok támadás célt téveszt, még mielőtt elkezdődne.
Őszintén besorolva: magával a PHP2Shell-lel szemben ez keveset segít. A rések az értelmezőben vannak, és a php.net szerint bejelentkezés nélkül kiválthatók nyilvános PHP-oldalakon keresztül. A backend elzárása tartós keményítés, nem vészfoltozás.
Admin felület védelme IP-címmel, VPN-nel vagy második bejelentkezéssel
Nincs egyetlen helyes módszer. Az dönt, hogyan dolgozik a csapata, és hol fut a weboldal.
| Módszer | Kinek megfelelő | Határ |
|---|---|---|
| IP-engedélyezés a webszerverben | irodák rögzített címmel, kis csapatok | változó címek home office-ban, a lista karbantartása |
| VPN rögzített kimenő címmel | elosztott csapatok, szolgáltatók | magát a VPN-t is jól kell védeni és naprakészen tartani |
| Előtét-bejelentkezés (HTTP-hitelesítés) | kiegészítés, ha nem lehetséges rögzített cím | további jelszó, csak TLS-sel együtt van értelme |
| Kliens-tanúsítványok | néhány, rögzítetten kezelt eszköz | a tanúsítványok kiadása és visszavonása fegyelmet igényel |
| Saját hosztnév csak a belső hálózaton | nagyobb környezetek belső DNS-sel | az alkalmazás átalakítása, nem minden CMS támogatja |
A gyakorlatban a kombináció válik be: engedélyezés csak a VPN-nek vagy a céges hálózatnak, mellé egy második bejelentkezés tartalék szintként. Magának a CMS-nek a bejelentkezése kétfaktoros eljárással marad meg, ahogyan a Kétfaktoros bejelentkezés admin hozzáférésekhez útmutatóban le van írva.
Mely címek tartoznak egyáltalán a backendhez?
A leggyakoribb gyengeség nem a technika, hanem a hiányos lista. Ezért ebben a sorrendben járjon el:
- A CMS vagy a webshop bejelentkezési oldalainak felvétele, beleértve a bővítmények által létrehozott alternatív bejelentkezési címeket.
- Adminisztrációs eszközök keresése: adatbázis-felületek, fájlkezelők, telepítő szkriptek, státusz- és monitoringoldalak.
- Tárhely- és szerverpanelek bevonása, amelyek gyakran saját portokon futnak.
- Teszt- és staging-példányok ellenőrzése, amelyek gyakran ugyanazokat a hozzáférési adatokat használják, mint az éles oldal.
- Az interfészek elhatárolása: egyes backend-útvonalakat a nyilvános frontend is hív, például Ajax-kérésekhez. Ezeket nem szabad vakon letiltania, különben az űrlapok vagy a kosarak elromlanak.
Az ötödik pont az oka annak, hogy az elzárást mindig tesztelni kell. A WordPressnél például az admin mappában lévő egyik fájlt nyilvános funkciókhoz is használják.
Konfiguráció: IP-engedélyezés plusz második bejelentkezés
Az Nginx alatt mindkét feltétel kombinálható. A satisfy all esetén a kérésnek engedélyezett hálózatból kell érkeznie, és ezenkívül a második bejelentkezésnek is sikerülnie kell. Az útvonal, a címek és a PHP-átadás helyőrzők:
location ^~ /backend/ {
satisfy all;
allow 192.0.2.0/24; # Céges hálózat (helyőrző)
allow 198.51.100.10; # VPN kimenet (helyőrző)
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;
}
}
A beágyazott PHP-location fontos: a ^~ miatt a .php-re vonatkozó többi szabályt már nem értékeli ki. Az Apache alatt ugyanezt egy olyan blokkal éri el, amelyben mindkét feltételnek teljesülnie kell:
<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>
A jelszófájl a webroton kívülre való. A második bejelentkezés minden kérésnél továbbítja a hozzáférési adatokat, ezért csak HTTPS-en keresztül használja.
Minden módosítás előtt tartson nyitva egy második utat a szerverre, például egy meglévő SSH-munkamenetet. Aki kizárja magát, különben a tárhelyszolgáltatóra szorul.
A csapdák: CDN, proxy, IPv6 és home office
Ha a weboldala egy CDN, például a Cloudflare, vagy egy terheléselosztó mögött van, a webszerver először csak annak címeit látja. Az IP-engedélyezés ilyenkor vagy mindenkit kizárna, vagy mindenkit átengedne. A webszervernek a valódi címet egy fejlécből kell átvennie, az Nginx alatt a set_real_ip_from és a real_ip_header segítségével, az Apache alatt a mod_remoteip modullal.
Itt érvényes: a fejlécet csak a saját proxycímektől fogadja el. Különben bármely látogató tetszőleges eredetet színlelhet. Ugyanilyen fontos, hogy az origin szerver ne legyen közvetlenül elérhető, mert különben a proxy és a szabályai megkerülhetők. Erről a Tűzfal webszerverekhez cikkben talál tudnivalókat.
Két további pontot gyakran figyelmen kívül hagynak. Ha a szerver IPv6-on is elérhető, a hálózata IPv6-címeinek is kell bejegyzés, különben az IPv6-tal csatlakozó adminok elzárva találják magukat. A magán internetkapcsolatok pedig rendszeresen címet váltanak. Home office és külső szolgáltatók esetén ezért a VPN általában a stabilabb megoldás.
Így ellenőrzi, hogy az elzárás működik-e
Egy nem tesztelt szabály nem számít megvalósítottnak. Ellenőrizzen a céges hálózaton kívüli csatlakozásról, például a mobilhálózaton keresztül:
# Várt eredmény: 403 (letiltva) vagy 401 (második bejelentkezés szükséges)
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/backend/
# A PHP-fájlokat is közvetlenül ellenőrizze, ne csak a könyvtárat
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/backend/index.php
Utána ugyanezeket a hívásokat a céges hálózatból vagy a VPN-ből: ott az oldalnak elérhetőnek kell lennie. Ezután ellenőrizze a nyilvános frontendet, vagyis az űrlapokat, a keresést és a kosarat. A következő napok naplóiban az admin címekre irányuló hozzáférések szinte már csak 401-es vagy 403-as állapottal jelenhetnek meg.
Ha a terület eddig nyitva volt, érdemes megnézni a meglévő fiókokat. Hogyan találhat ismeretlen adminisztrátorokat, azt a Idegen admin fiókok megtalálása a CMS-ben és a szerveren írja le. Kiegészítésként lassítja a tömeges próbálgatást egy védelem, lásd Admin bejelentkezések védelme a brute force ellen.
Hogyan segít konkrétan a PHP SOS?
- Felmérjük a weboldalai, panelei és eszközei összes adminisztrációs címét, és elválasztjuk őket a nyilvánosan szükséges útvonalaktól.
- Önnel együtt kiválasztjuk a megfelelő eljárást a csapat méretétől, a home office-tól és a tárhelytől függően.
- A szabályokat a webszerverben valósítjuk meg, figyelembe vesszük a CDN-t, a proxyt és az IPv6-ot, és közben visszaút marad nyitva.
- Kívülről és belülről is tesztelünk, és rövid dokumentációt adunk át az engedélyezett hálózatokkal.
Az admin felületek elzárása része a PHP-webszerverek keményítésének.
Gyakori kérdések
Nem elég egy biztonságos jelszó a CMS-bejelentkezéshez?
Az erős jelszó és a kétfaktoros bejelentkezés kötelező, de csak magát a bejelentkezést védi. A bejelentkezési oldalak, bővítmények vagy adminisztrációs eszközök hibái ettől még mindenki számára elérhetők. A hálózati vagy webszerver-szintű elzárás gondoskodik arról, hogy idegenek egyáltalán ne jussanak el odáig.
Mit tegyek, ha a munkatársaim IP-címe változik?
Ilyenkor a rögzített kimenő címmel rendelkező VPN általában jobb megoldás, mint az egyes címek listája. Minden admin először a VPN-hez csatlakozik, a webszerver pedig csak annak címét engedélyezi. Alternatívaként egy előtét-bejelentkezés is megfelelő.
Működik az IP-tiltás a Cloudflare vagy egy terheléselosztó mögött is?
Csak akkor, ha a webszerver a látogató valódi címét egy megbízható fejlécből veszi át, és ezt a fejlécet kizárólag a saját proxyjától fogadja el. Különben csak a proxy címeit látja, vagy megbízik a hamisított adatokban. Emellett az origin szerver ne legyen közvetlenül elérhető az internetről.
Véd a PHP2Shell ellen egy elzárt admin felület?
Csak nagyon korlátozottan. A PHP2Shell rései a PHP-értelmezőben vannak, és bejelentkezés nélkül, bármely nyilvános PHP-oldalon keresztül támadhatók. A PHP2Shell ellen a PHP-frissítés és az összes worker azt követő újraindítása segít, az elzárás csupán a fennmaradó támadási felületet csökkenti.