# Admin-Logins gegen Brute Force schützen: Brute-Force-Schutz für jedes Login

> Brute-Force-Schutz für Login und Admin-Bereich: Rate-Limiting, Fail2ban, Zwei-Faktor-Anmeldung und sichere Passwortspeicherung mit password_hash umsetzen.

Quelle: https://phpsos.de/ratgeber/brute-force-login-schutz/  
Stand: 25.10.2026  
Anbieter: PHP SOS, PHP-Notfallhilfe und Server-Sicherheit. Soforthilfe per WhatsApp: https://wa.me/491736494914?text=Hallo%20PHP%20SOS%2C%20wir%20brauchen%20Hilfe%20mit%20unserem%20PHP-Server.%20Firma%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**Kurz gesagt:** Wirksamer Brute-Force-Schutz für ein Login besteht aus mehreren Schichten: Zwei-Faktor-Anmeldung für alle Admins, eine Bremse für Anmeldeversuche im Webserver, automatische Sperren auf Netzwerkebene und eine sichere Passwortspeicherung im Code. Wo möglich, ist der Admin-Bereich zusätzlich nur aus bekannten Netzen erreichbar.

## Wie Brute-Force-Angriffe auf Logins ablaufen

Jede öffentlich erreichbare Anmeldeseite wird früher oder später automatisiert angegriffen. Das betrifft CMS-Logins, Shop-Backends, Hosting-Panels, Webmail und SSH. Angreifer müssen dafür nicht wissen, wem die Website gehört; ihre Werkzeuge durchsuchen das Internet nach bekannten Login-Adressen.

Drei Varianten sind verbreitet. Beim klassischen **Brute Force** werden viele Passwörter gegen ein Konto probiert. Beim **Password Spraying** wird ein häufiges Passwort gegen viele Konten getestet, um Sperren zu umgehen. Beim **Credential Stuffing** werden Zugangsdaten verwendet, die bei anderen Diensten gestohlen wurden.

Für Geschäftsführung und Inhaber ist die Lage einfach zusammengefasst: Ein übernommenes Admin-Konto ist so gefährlich wie eine Sicherheitslücke im Server. Wer Admin ist, kann Erweiterungen installieren, Code ändern und Daten exportieren.

Erkennbar sind solche Angriffe an einer Häufung fehlgeschlagener Anmeldungen, an POST-Anfragen auf die Login-Adresse von vielen verschiedenen IP-Adressen und an Anmeldeversuchen mit Benutzernamen wie „admin“ oder Namen aus dem Impressum. Auch eine spürbar höhere Serverlast zu ungewöhnlichen Zeiten kann darauf hindeuten, weil jede Anmeldung Rechenzeit für die Passwortprüfung kostet.

## Brute-Force-Schutz am Login: die wirksamsten Maßnahmen

Nicht jede Maßnahme passt zu jedem System. Die folgende Reihenfolge hat sich bewährt, weil die ersten Punkte am meisten Wirkung mit wenig Aufwand verbinden:

- **Zwei-Faktor-Anmeldung** für alle Konten mit Admin-Rechten. Selbst ein erratenes Passwort reicht dann nicht. Einzelheiten im Ratgeber [Zwei-Faktor-Anmeldung für Admin-Zugänge](https://phpsos.de/ratgeber/zwei-faktor-admin/).
- **Einzigartige, lange Passwörter** aus einem Passwortmanager, keine geteilten Konten.
- **Rate-Limiting** im Webserver, damit pro Adresse nur wenige Versuche pro Minute möglich sind.
- **Automatische Sperren** wiederholt auffälliger Adressen auf Netzwerkebene, etwa mit Fail2ban.
- **Admin-Bereich verkleinern:** Zugriff nur aus dem Firmennetz oder per VPN, nicht benötigte Schnittstellen abschalten.
- **Einheitliche Fehlermeldungen,** die nicht verraten, ob der Benutzername existiert.
- **Überwachung** fehlgeschlagener Anmeldungen und Benachrichtigung bei Auffälligkeiten.

## Rate-Limiting im Webserver

Mit Nginx lässt sich die Zahl der Anfragen auf eine Login-Adresse pro IP-Adresse begrenzen. Das Beispiel zeigt eine WordPress-Anmeldeseite; Pfad und PHP-Übergabe passen Sie an Ihr System an.

```nginx
# im http-Block
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

# im server-Block
location = /wp-login.php {
    limit_req zone=login burst=3 nodelay;
    limit_req_status 429;
    # hier die übliche PHP-Übergabe Ihres Servers einbinden
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php-fpm.sock;
}
```

Unter Apache bietet die Beschränkung des Admin-Bereichs auf bekannte Adressen einen einfachen, wirksamen Schutz:

```apache
<Location "/admin">
    Require ip 192.0.2.0/24
</Location>
```

Die Adresse `192.0.2.0/24` ist ein Platzhalter aus dem Dokumentationsbereich; setzen Sie Ihr Firmennetz oder die Adresse Ihres VPN ein. Liegt Ihre Website hinter einem Proxy oder CDN, muss der Server die echte Besucheradresse kennen, sonst greift die Regel nicht wie gewünscht.

## Fail2ban und Sperren auf Netzwerkebene

Fail2ban liest Logdateien und sperrt Adressen, die wiederholt auffallen, für eine festgelegte Zeit in der Firewall. Für das Nginx-Rate-Limiting bringt Fail2ban bereits einen passenden Filter mit:

```ini
# /etc/fail2ban/jail.local
[nginx-limit-req]
enabled  = true
port     = http,https
logpath  = /var/log/nginx/error.log
maxretry = 10
findtime = 10m
bantime  = 1h

[sshd]
enabled  = true
maxretry = 5
bantime  = 1h
```

Prüfen Sie nach dem Neustart mit `fail2ban-client status`, ob die Jails aktiv sind. Achten Sie darauf, Ihre eigenen festen Adressen über `ignoreip` auszunehmen, damit Sie sich nicht selbst aussperren. Für Anmeldeseiten einzelner CMS sind eigene Filter möglich, sie müssen aber zum tatsächlichen Logformat passen und vorher getestet werden.

Steht vor dem Server ein CDN oder Proxy, sieht Fail2ban ohne weitere Einstellung nur dessen Adressen. Eine Sperre würde dann alle Besucher treffen. In diesem Fall muss der Webserver die echte Besucheradresse aus dem Header des vorgeschalteten Dienstes übernehmen, und Sperren werden besser direkt beim CDN gesetzt.

Sperren auf Netzwerkebene sind ein Werkzeug gegen Masse, nicht gegen gezielte Angriffe. Verteilte Angriffe aus sehr vielen Adressen mit wenigen Versuchen je Adresse unterlaufen jede Schwelle. Deshalb bleibt der zweite Faktor die wichtigste Schicht, und Fail2ban senkt vor allem Last und Lograuschen.

## Passwörter in eigener Software richtig speichern

Wer eigene Anmeldungen programmiert, sollte Passwörter nie im Klartext oder mit schnellen Hash-Funktionen wie MD5 oder SHA-1 speichern. PHP bringt mit `password_hash()` eine sichere Lösung mit, die Salt und Verfahren automatisch verwaltet.

```php
<?php
declare(strict_types=1);

// Bei Registrierung oder Passwortänderung
$hash = password_hash($passwort, PASSWORD_DEFAULT);

// Bei der Anmeldung
if (password_verify($eingabe, $hashAusDatenbank)) {
    if (password_needs_rehash($hashAusDatenbank, PASSWORD_DEFAULT)) {
        $neu = password_hash($eingabe, PASSWORD_DEFAULT);
        // $neu in der Datenbank speichern
    }
    // Anmeldung erfolgreich, Session-ID erneuern
} else {
    usleep(random_int(200000, 400000)); // gleichmäßige Antwortzeit
    // einheitliche Fehlermeldung ausgeben
}
```

`password_needs_rehash()` sorgt dafür, dass ältere Hashes beim nächsten Login automatisch auf das aktuelle Verfahren umgestellt werden. Fehlversuche protokollieren Sie mit Zeit, Konto und Adresse, damit Muster auffallen. Hinweise zur Auswertung stehen im Ratgeber [Webserver-Logs nach einem Angriff auswerten](https://phpsos.de/ratgeber/logfiles-auswerten/).

## Besonderheiten bei CMS, Shops und Panels

Viele Systeme haben neben der sichtbaren Anmeldeseite weitere Wege, über die Zugangsdaten geprüft werden. Diese Nebeneingänge werden beim Schutz oft vergessen.

- **WordPress:** Die Schnittstelle `xmlrpc.php` nimmt ebenfalls Anmeldungen entgegen. Wird sie nicht benötigt, etwa für ältere Apps, sperren Sie sie im Webserver. Prüfen Sie außerdem, ob Benutzernamen über Autorenseiten oder die REST-Schnittstelle sichtbar sind, und verwenden Sie für Admins Namen, die nicht öffentlich erscheinen.
- **Shops:** Neben dem Admin-Bereich sind Kundenkonten ein Ziel, besonders für Credential Stuffing. Hier helfen Rate-Limiting, Benachrichtigungen bei neuen Anmeldungen und ein optionaler zweiter Faktor für Kunden.
- **Hosting-Panels und Webmail:** Diese Oberflächen sind oft weltweit erreichbar und schützen den ganzen Server. Sie sollten nur aus bekannten Netzen oder per VPN erreichbar sein.
- **SSH:** Anmeldung mit Schlüssel statt Passwort macht klassisches Raten wirkungslos.

Welche Schutzfunktionen Ihr System selbst mitbringt, steht in der Dokumentation des Herstellers. Erweiterungen von Drittanbietern sollten aktiv gepflegt sein, sonst werden sie selbst zum Risiko. Für WordPress-Betreiber fasst die Seite [WordPress und PHP2Shell](https://phpsos.de/plattformen/wordpress/) die aktuellen Prioritäten zusammen.

## Wie hilft PHP SOS konkret?

- Wir erfassen alle erreichbaren Anmeldeseiten Ihrer Server, vom CMS bis zum Hosting-Panel, und bewerten deren Schutz.
- Wir richten Rate-Limiting, Fail2ban und Zugriffsbeschränkungen im Rahmen der [Server-Härtung](https://phpsos.de/leistungen/server-haertung/) ein und testen sie.
- Wir begleiten die Einführung der Zwei-Faktor-Anmeldung für Admins und dokumentieren Notfallzugänge.
- Mit dem [Security-Monitoring](https://phpsos.de/leistungen/security-monitoring/) behalten wir Fehlanmeldungen und neue Admin-Konten laufend im Blick.


## Häufige Fragen

**Woran erkenne ich einen Brute-Force-Angriff?**  
Typisch sind viele fehlgeschlagene Anmeldungen in kurzer Zeit, oft gegen dieselbe Anmeldeseite und mit wechselnden Benutzernamen. Im Access-Log zeigt sich das als Häufung von POST-Anfragen auf die Login-Adresse, häufig von vielen verschiedenen IP-Adressen.

**Sollte ein Konto nach mehreren Fehlversuchen gesperrt werden?**  
Vorsicht: Harte Sperren können Angreifer nutzen, um legitime Nutzer auszusperren. Besser sind steigende Verzögerungen, zeitlich begrenzte Sperren je IP-Adresse und eine Benachrichtigung des Kontoinhabers.

**Hilft es, die Login-Adresse umzubenennen?**  
Es reduziert automatisiertes Rauschen in den Logs, ist aber kein echter Schutz. Wer die Adresse kennt oder findet, kann weiter angreifen. Wirksam sind Zwei-Faktor-Anmeldung, Rate-Limiting und eine Beschränkung des Admin-Bereichs.

**Was ist Credential Stuffing?**  
Dabei probieren Angreifer Kombinationen aus E-Mail und Passwort aus, die bei anderen Diensten gestohlen wurden. Es funktioniert, wenn Nutzer dasselbe Passwort mehrfach verwenden. Einzigartige Passwörter und ein zweiter Faktor entziehen dieser Methode die Grundlage.

## Quellen

- [OWASP Cheat Sheet Series (Authentication)](https://cheatsheetseries.owasp.org/)
- [BSI: Empfehlungen zu sicheren Passwörtern und Zwei-Faktor-Anmeldung](https://www.bsi.bund.de/)
- [OWASP Top 10](https://owasp.org/www-project-top-ten/)