Kurz gesagt: Den Admin-Bereich schützen Sie am wirksamsten, indem Sie ihn nur für bekannte Netze öffnen: per IP-Freigabe im Webserver, über ein VPN mit fester Ausgangsadresse oder mit einer zweiten, vorgeschalteten Anmeldung. Wichtig sind eine vollständige Liste aller Verwaltungsadressen, die richtige Behandlung von Proxys und CDNs und ein Test von außen. Die Abschirmung ergänzt Zwei-Faktor-Anmeldung und Updates, sie ersetzt sie nicht.
Warum steht das Backend überhaupt offen?
In vielen Unternehmen haben Admins in der vergangenen Woche PHP aktualisiert und Worker neu gestartet. Wer danach die Zugriffsprotokolle ansieht, stellt oft etwas anderes fest: Die Anmeldeseite des CMS, das Datenbankwerkzeug und das Hosting-Panel werden rund um die Uhr aus aller Welt aufgerufen. Gebraucht werden sie aber nur von einer Handvoll Menschen im eigenen Team.
Jede dieser Adressen ist Angriffsfläche. Anmeldeformulare werden durchprobiert, Verwaltungswerkzeuge enthalten eigene Lücken, und Plugins für das Backend sind oft weniger gut geprüft als der Kern eines CMS. Wenn Fremde diese Bereiche gar nicht erreichen, laufen viele Angriffe ins Leere, bevor sie beginnen.
Ehrlich eingeordnet: Gegen PHP2Shell selbst hilft das nur wenig. Die Lücken liegen im Interpreter und lassen sich laut php.net ohne Anmeldung über öffentliche PHP-Seiten auslösen. Die Abschirmung des Backends ist eine dauerhafte Härtung, kein Notfallpatch.
Admin-Bereich schützen per IP, VPN oder zweiter Anmeldung
Es gibt nicht die eine richtige Methode. Entscheidend ist, wie Ihr Team arbeitet und wo die Website läuft.
| Methode | Geeignet für | Grenze |
|---|---|---|
| IP-Freigabe im Webserver | Büro mit fester Adresse, kleine Teams | wechselnde Adressen im Homeoffice, Pflege der Liste |
| VPN mit fester Ausgangsadresse | verteilte Teams, Dienstleister | VPN muss selbst gut gesichert und aktuell sein |
| Vorgeschaltete Anmeldung (HTTP-Authentifizierung) | Ergänzung, wenn keine feste Adresse möglich ist | zusätzliches Passwort, nur zusammen mit TLS sinnvoll |
| Client-Zertifikate | wenige, fest verwaltete Geräte | Ausgabe und Sperrung der Zertifikate erfordern Disziplin |
| Eigener Hostname nur im internen Netz | größere Umgebungen mit internem DNS | Umbau der Anwendung, nicht jedes CMS unterstützt das |
In der Praxis bewährt sich eine Kombination: Freigabe nur für das VPN oder das Firmennetz, dazu eine zweite Anmeldung als Rückfallebene. Die eigentliche Anmeldung im CMS bleibt mit Zwei-Faktor-Verfahren bestehen, wie im Ratgeber Zwei-Faktor-Anmeldung für Admin-Zugänge beschrieben.
Welche Adressen gehören eigentlich zum Backend?
Die häufigste Schwäche ist nicht die Technik, sondern eine unvollständige Liste. Gehen Sie deshalb in dieser Reihenfolge vor:
- Anmeldeseiten des CMS oder Shops erfassen, einschließlich alternativer Login-Adressen, die Plugins anlegen.
- Verwaltungswerkzeuge suchen: Datenbank-Oberflächen, Dateimanager, Installationsskripte, Status- und Monitoring-Seiten.
- Hosting- und Server-Panels einbeziehen, die oft auf eigenen Ports laufen.
- Test- und Staging-Instanzen prüfen, die häufig dieselben Zugangsdaten wie die Live-Seite nutzen.
- Schnittstellen abgrenzen: Manche Backend-Pfade werden auch vom öffentlichen Frontend aufgerufen, etwa für Ajax-Anfragen. Diese dürfen Sie nicht blind sperren, sonst brechen Formulare oder Warenkörbe.
Punkt fünf ist der Grund, warum eine Abschirmung immer getestet werden muss. Bei WordPress etwa wird eine Datei im Admin-Ordner auch für öffentliche Funktionen genutzt.
Konfiguration: IP-Freigabe plus zweite Anmeldung
Unter Nginx lassen sich beide Bedingungen kombinieren. Mit satisfy all muss eine Anfrage aus einem freigegebenen Netz kommen und zusätzlich die zweite Anmeldung bestehen. Pfad, Adressen und PHP-Übergabe sind Platzhalter:
location ^~ /backend/ {
satisfy all;
allow 192.0.2.0/24; # Firmennetz (Platzhalter)
allow 198.51.100.10; # VPN-Ausgang (Platzhalter)
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;
}
}
Die verschachtelte PHP-Location ist wichtig: Durch ^~ werden andere Regeln für .php nicht mehr ausgewertet. Unter Apache erreichen Sie dasselbe mit einem Block, in dem beide Bedingungen gelten müssen:
<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>
Die Passwortdatei gehört außerhalb des Webroots. Die zweite Anmeldung überträgt Zugangsdaten bei jeder Anfrage, deshalb nur über HTTPS einsetzen.
Halten Sie vor jeder Änderung einen zweiten Weg auf den Server offen, etwa eine bestehende SSH-Sitzung. Wer sich selbst aussperrt, braucht sonst den Hoster.
Die Fallen: CDN, Proxy, IPv6 und Homeoffice
Liegt Ihre Website hinter einem CDN wie Cloudflare oder einem Load Balancer, sieht der Webserver zunächst nur dessen Adressen. Eine IP-Freigabe würde dann entweder alle sperren oder alle durchlassen. Der Webserver muss die echte Adresse aus einem Header übernehmen, unter Nginx mit set_real_ip_from und real_ip_header, unter Apache mit mod_remoteip.
Dabei gilt: Den Header nur von den eigenen Proxy-Adressen akzeptieren. Sonst kann jeder Besucher eine beliebige Herkunft vortäuschen. Ebenso wichtig ist, dass der Ursprungsserver nicht direkt erreichbar ist, denn sonst lässt sich der Proxy samt seiner Regeln umgehen. Hinweise dazu stehen unter Firewall für Webserver.
Zwei weitere Punkte werden oft übersehen. Ist der Server per IPv6 erreichbar, brauchen auch die IPv6-Adressen Ihres Netzes einen Eintrag, sonst landen Admins mit IPv6 vor einer Sperre. Und private Internetanschlüsse wechseln ihre Adresse regelmäßig. Für Homeoffice und externe Dienstleister ist ein VPN deshalb meist die stabilere Lösung.
So prüfen Sie, ob die Abschirmung wirkt
Eine Regel, die nicht getestet ist, gilt nicht als umgesetzt. Prüfen Sie von einem Anschluss außerhalb des Firmennetzes, zum Beispiel über das Mobilfunknetz:
# Erwartet: 403 (gesperrt) oder 401 (zweite Anmeldung verlangt)
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/backend/
# Auch PHP-Dateien direkt prüfen, nicht nur das Verzeichnis
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/backend/index.php
Danach dieselben Aufrufe aus dem Firmennetz oder dem VPN: Dort muss die Seite erreichbar sein. Kontrollieren Sie anschließend das öffentliche Frontend, also Formulare, Suche und Warenkorb. In den Protokollen der folgenden Tage sollten Zugriffe auf die Admin-Adressen fast nur noch mit Status 401 oder 403 erscheinen.
Ist der Bereich bisher offen gewesen, lohnt ein Blick auf die vorhandenen Konten. Wie Sie unbekannte Administratoren finden, beschreibt Fremde Admin-Konten in CMS und Server finden. Ergänzend bremst ein Schutz gegen massenhaftes Durchprobieren, siehe Admin-Logins gegen Brute Force schützen.
Wie hilft PHP SOS konkret?
- Wir erfassen alle Verwaltungsadressen Ihrer Websites, Panels und Werkzeuge und trennen sie von öffentlich benötigten Pfaden.
- Wir wählen mit Ihnen das passende Verfahren, abhängig von Teamgröße, Homeoffice und Hosting.
- Wir setzen die Regeln im Webserver um, berücksichtigen CDN, Proxy und IPv6 und halten dabei einen Rückweg offen.
- Wir testen von außen und von innen und übergeben eine kurze Dokumentation mit den freigegebenen Netzen.
Die Abschirmung von Admin-Bereichen ist Teil unserer Server-Härtung für PHP-Webserver.
Häufige Fragen
Reicht ein sicheres Passwort für den CMS-Login nicht aus?
Ein starkes Passwort und eine Zwei-Faktor-Anmeldung sind Pflicht, schützen aber nur die Anmeldung selbst. Lücken in Login-Seiten, Plugins oder Verwaltungswerkzeugen sind trotzdem für jeden erreichbar. Eine Abschirmung auf Netzwerk- oder Webserverebene sorgt dafür, dass Fremde gar nicht erst bis dorthin kommen.
Was mache ich, wenn meine Mitarbeitenden wechselnde IP-Adressen haben?
Dann ist ein VPN mit fester Ausgangsadresse meist die bessere Lösung als eine Liste einzelner Adressen. Alle Admins verbinden sich zuerst mit dem VPN, und der Webserver gibt nur dessen Adresse frei. Alternativ eignet sich eine vorgeschaltete zweite Anmeldung.
Funktioniert eine IP-Sperre auch hinter Cloudflare oder einem Load Balancer?
Nur, wenn der Webserver die echte Besucheradresse aus einem vertrauenswürdigen Header übernimmt und diesen Header ausschließlich vom eigenen Proxy akzeptiert. Sonst sieht er nur die Adressen des Proxys oder vertraut gefälschten Angaben. Zusätzlich sollte der Ursprungsserver nicht direkt aus dem Internet erreichbar sein.
Schützt ein abgeschirmter Admin-Bereich vor PHP2Shell?
Nur sehr eingeschränkt. Die PHP2Shell-Lücken liegen im PHP-Interpreter und sind ohne Anmeldung über jede öffentliche PHP-Seite angreifbar. Gegen PHP2Shell hilft das PHP-Update mit anschließendem Neustart aller Worker, die Abschirmung verkleinert lediglich die übrige Angriffsfläche.