# Admin felületek elzárása IP-címmel, VPN-nel vagy kiegészítő védelemmel

> Admin felület védelme IP-engedélyezéssel, VPN-nel vagy előtét-bejelentkezéssel: melyik módszer illik, CDN- és proxycsapdák, konfiguráció és teszt.

Forrás: https://phpsos.de/hu/blog/admin-bereiche-abschirmen/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

**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](https://phpsos.de/hu/ratgeber/zwei-faktor-admin/) ú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:

1. **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.
2. **Adminisztrációs eszközök** keresése: adatbázis-felületek, fájlkezelők, telepítő szkriptek, státusz- és monitoringoldalak.
3. **Tárhely- és szerverpanelek** bevonása, amelyek gyakran saját portokon futnak.
4. **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.
5. **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:

```nginx
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:

```apache
<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.

> **Fontos:**
> 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](https://phpsos.de/hu/blog/firewall-fuer-webserver/) 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:

```bash
# 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](https://phpsos.de/hu/blog/fremde-admin-konten-finden/) í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](https://phpsos.de/hu/ratgeber/brute-force-login-schutz/).

## 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](https://phpsos.de/hu/leistungen/server-haertung/).


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

## Források

- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)
- [Nginx dokumentáció](https://nginx.org/en/docs/)
- [Apache HTTP Server: dokumentáció](https://httpd.apache.org/docs/)