# Afskærm adminområder med IP, VPN eller ekstra beskyttelse

> Beskyt adminområdet med IP-frigivelse, VPN eller forudgående login: hvilken metode der passer, faldgruber bag CDN og proxy, med konfiguration og test.

Kilde: https://phpsos.de/da/blog/admin-bereiche-abschirmen/  
Status: 25.10.2026  
Udbyder: PHP SOS, PHP-nødhjælp og serversikkerhed. Akut hjælp på WhatsApp: https://wa.me/491736494914?text=Hej%20PHP%20SOS%2C%20vi%20har%20brug%20for%20hj%C3%A6lp%20med%20vores%20PHP-server.%20Firma%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**Kort sagt:** Adminområdet beskytter I mest effektivt ved kun at åbne det for kendte netværk: via IP-frigivelse i webserveren, via et VPN med fast udgangsadresse eller med et andet, forudgående login. Vigtigt er en fuldstændig liste over alle administrationsadresser, den rigtige håndtering af proxyer og CDN'er og en test udefra. Afskærmningen supplerer totrinslogin og opdateringer, den erstatter dem ikke.

## Hvorfor står backenden overhovedet åben?

I mange virksomheder har administratorer i den seneste uge opdateret PHP og genstartet workers. Den, der bagefter ser på adgangsloggene, konstaterer ofte noget andet: CMS'ets loginside, databaseværktøjet og hostingpanelet kaldes døgnet rundt fra hele verden. De bruges dog kun af en håndfuld mennesker i eget team.

Hver af disse adresser er angrebsflade. Loginformularer prøves igennem, administrationsværktøjer indeholder egne sårbarheder, og plugins til backenden er ofte mindre grundigt gennemgået end et CMS' kerne. Når fremmede slet ikke kan nå disse områder, løber mange angreb ud i sandet, før de begynder.

Ærligt vurderet: Mod selve PHP2Shell hjælper det kun lidt. Sårbarhederne ligger i fortolkeren og kan ifølge php.net udløses uden login via offentlige PHP-sider. Afskærmning af backenden er en varig hærdning, ikke en nødrettelse.

## Beskyt adminområdet med IP, VPN eller andet login

Der findes ikke én rigtig metode. Afgørende er, hvordan jeres team arbejder, og hvor websitet kører.

| Metode | Egnet til | Grænse |
|---|---|---|
| IP-frigivelse i webserveren | kontor med fast adresse, små teams | skiftende adresser på hjemmearbejde, vedligeholdelse af listen |
| VPN med fast udgangsadresse | fordelte teams, tjenesteudbydere | VPN'et skal selv være godt sikret og opdateret |
| Forudgående login (HTTP-autentificering) | supplement, når en fast adresse ikke er mulig | ekstra adgangskode, kun fornuftig sammen med TLS |
| Klientcertifikater | få, fast administrerede enheder | udstedelse og spærring af certifikater kræver disciplin |
| Eget hostnavn kun i det interne netværk | større miljøer med intern DNS | ombygning af applikationen, ikke alle CMS'er understøtter det |

I praksis har en kombination vist sig at fungere: Frigivelse kun til VPN'et eller virksomhedens netværk, dertil et andet login som fallback. Selve loginnet i CMS'et består med totrinsmetode, som beskrevet i vejledningen [Totrinslogin til adminadgange](https://phpsos.de/da/ratgeber/zwei-faktor-admin/).

## Hvilke adresser hører egentlig til backenden?

Den hyppigste svaghed er ikke teknikken, men en ufuldstændig liste. Gå derfor frem i denne rækkefølge:

1. **Registrér CMS'ets eller shoppens loginsider**, herunder alternative loginadresser, som plugins opretter.
2. **Find administrationsværktøjer:** databasegrænseflader, filhåndtering, installationsscripts, status- og overvågningssider.
3. **Medtag hosting- og serverpaneler**, som ofte kører på egne porte.
4. **Kontrollér test- og staging-instanser**, som ofte bruger de samme adgangsdata som live-websitet.
5. **Afgræns grænseflader:** Nogle backend-stier kaldes også fra den offentlige frontend, f.eks. til Ajax-forespørgsler. Dem må I ikke spærre blindt, ellers går formularer eller indkøbskurve i stykker.

Punkt fem er grunden til, at en afskærmning altid skal testes. I WordPress bruges f.eks. en fil i admin-mappen også til offentlige funktioner.

## Konfiguration: IP-frigivelse plus andet login

Under Nginx kan begge betingelser kombineres. Med `satisfy all` skal en forespørgsel komme fra et frigivet netværk og desuden bestå det andet login. Sti, adresser og PHP-overdragelse er pladsholdere:

```nginx
location ^~ /backend/ {
    satisfy all;

    allow 192.0.2.0/24;      # virksomhedens netværk (pladsholder)
    allow 198.51.100.10;     # VPN-udgang (pladsholder)
    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;
    }
}
```

Den indlejrede PHP-location er vigtig: På grund af `^~` bliver andre regler for `.php` ikke længere evalueret. Under Apache opnår I det samme med en blok, hvor begge betingelser skal gælde:

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

Adgangskodefilen hører hjemme uden for webroot. Det andet login overfører adgangsdata ved hver forespørgsel, så brug det kun over HTTPS.

> **Vigtigt:**
> Hold før hver ændring en anden vej ind på serveren åben, f.eks. en eksisterende SSH-session. Den, der låser sig selv ude, har ellers brug for hostingudbyderen.

## Faldgruberne: CDN, proxy, IPv6 og hjemmearbejde

Ligger jeres website bag et CDN som Cloudflare eller en load balancer, ser webserveren først kun dennes adresser. En IP-frigivelse ville så enten spærre alle eller lukke alle igennem. Webserveren skal overtage den rigtige adresse fra en header, under Nginx med `set_real_ip_from` og `real_ip_header`, under Apache med `mod_remoteip`.

Her gælder: Accepter kun headeren fra de egne proxy-adresser. Ellers kan enhver besøgende foregive en vilkårlig oprindelse. Lige så vigtigt er det, at oprindelsesserveren ikke kan nås direkte, for ellers kan proxyen med sine regler omgås. Henvisninger hertil findes under [Firewall til webservere](https://phpsos.de/da/blog/firewall-fuer-webserver/).

To yderligere punkter overses ofte. Kan serveren nås via IPv6, skal også jeres netværks IPv6-adresser have en post, ellers havner administratorer med IPv6 foran en spærring. Og private internetforbindelser skifter jævnligt adresse. Til hjemmearbejde og eksterne tjenesteudbydere er et VPN derfor som regel den mere stabile løsning.

## Sådan kontrollerer I, om afskærmningen virker

En regel, der ikke er testet, tæller ikke som gennemført. Kontrollér fra en forbindelse uden for virksomhedens netværk, f.eks. via mobilnettet:

```bash
# Forventet: 403 (spærret) eller 401 (andet login kræves)
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/backend/
# Kontrollér også PHP-filer direkte, ikke kun mappen
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/backend/index.php
```

Derefter de samme kald fra virksomhedens netværk eller VPN'et: Dér skal siden kunne nås. Kontrollér bagefter den offentlige frontend, altså formularer, søgning og indkøbskurv. I loggene de følgende dage bør adgange til adminadresserne næsten kun optræde med status 401 eller 403.

Har området hidtil været åbent, er det værd at se på de eksisterende konti. Hvordan I finder ukendte administratorer, beskriver [Find fremmede adminkonti i CMS og server](https://phpsos.de/da/blog/fremde-admin-konten-finden/). Supplerende bremser en beskyttelse mod massivt gætteri, se [Beskyt admin-logins mod brute force](https://phpsos.de/da/ratgeber/brute-force-login-schutz/).

## Hvordan hjælper PHP SOS konkret?

- Vi registrerer alle administrationsadresser på jeres websites, paneler og værktøjer og adskiller dem fra stier, der skal være offentlige.
- Vi vælger sammen med jer den passende fremgangsmåde afhængigt af teamstørrelse, hjemmearbejde og hosting.
- Vi gennemfører reglerne i webserveren, tager højde for CDN, proxy og IPv6 og holder samtidig en vej tilbage åben.
- Vi tester udefra og indefra og afleverer en kort dokumentation med de frigivne netværk.

Afskærmning af adminområder er en del af vores [serverhærdning til PHP-webservere](https://phpsos.de/da/leistungen/server-haertung/).


## Ofte stillede spørgsmål

**Er en sikker adgangskode til CMS-login ikke nok?**  
En stærk adgangskode og totrinslogin er et krav, men beskytter kun selve loginnet. Sårbarheder i loginsider, plugins eller administrationsværktøjer kan stadig nås af alle. En afskærmning på netværks- eller webserverniveau sikrer, at fremmede slet ikke når så langt.

**Hvad gør jeg, hvis mine medarbejdere har skiftende IP-adresser?**  
Så er et VPN med fast udgangsadresse som regel en bedre løsning end en liste med enkeltadresser. Alle administratorer forbinder først til VPN'et, og webserveren frigiver kun dettes adresse. Alternativt egner sig et forudgående andet login.

**Virker en IP-spærring også bag Cloudflare eller en load balancer?**  
Kun hvis webserveren overtager den rigtige besøgsadresse fra en betroet header og udelukkende accepterer denne header fra den egen proxy. Ellers ser den kun proxyens adresser eller stoler på forfalskede oplysninger. Desuden bør oprindelsesserveren ikke kunne nås direkte fra internettet.

**Beskytter et afskærmet adminområde mod PHP2Shell?**  
Kun meget begrænset. PHP2Shell-sårbarhederne ligger i PHP-fortolkeren og kan angribes uden login via enhver offentlig PHP-side. Mod PHP2Shell hjælper PHP-opdateringen med efterfølgende genstart af alle workers; afskærmningen mindsker blot den øvrige angrebsflade.

## Kilder

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