KeyHelp: Admin-Zugang absichern mit IP-Beschränkung, Passwort-Richtlinie und Sitzungseinstellungen

Das Admin-Konto ist der wertvollste Zugang zu einem KeyHelp-Server. KeyHelp bringt dafür unter „Konfiguration“ zwei Seiten mit, die oft übersehen werden: „Login & Sitzungen“ mit Brute-Force-Schutz, Leerlaufzeit, IP-Bindung und einer IP-Beschränkung für Administratorkonten sowie „Passwort-Richtlinie“. Diese Anleitung zeigt, was die Einstellungen ab Werk tun, wie Sie den Admin-Zugang auf Ihre Adressen beschränken, ohne sich auszusperren, und wie Sie sich mit der KeyHelp-Toolbox wieder hereinholen. Alles haben wir in einer Test-VM geprüft, die Client-Adressen per Network Namespace simuliert. Die Zwei-Faktor-Anmeldung behandelt die Anleitung KeyHelp: Zwei-Faktor-Anmeldung mit TOTP und Passkeys. Grundlage ist ein Server wie in KeyHelp installieren und absichern.

Voraussetzungen

• KeyHelp-Server mit Admin-Zugang, getestet mit KeyHelp 26.1.1 (Build 3698) auf Debian 12.15.
• Root-Zugang per SSH oder Konsole als Rückweg, falls Sie sich aussperren.
• Feste IP-Adresse oder festes Netz, wenn Sie die IP-Beschränkung nutzen wollen.
• Im Test haben wir auf dem Server einen Network Namespace mit den Adressen 198.51.100.10 (Admin-Arbeitsplatz) und 198.51.100.20 (fremde Adresse) angelegt und die Anmeldungen per curl geprüft. Das Passwort lasen die Testskripte aus einer Datei, es steht nicht im Protokoll.

Schritt 1: Die Werkseinstellungen kennen

Öffnen Sie „Konfiguration“, „Login & Sitzungen“. Ab Werk standen dort:

• „Brute-Force-Schutz“: 1 Minute. Laut Hilfetext werden Anmeldeversuche gedrosselt, „wenn das System zu viele ungültige Anfragen von einem IP-Subnetz erkannt hat“. Der Wert ist die maximale Drosselung.
• „Sitzungs-Leerlaufzeit“: 24 Minuten bis zur automatischen Abmeldung.
• „Sitzung an IP-Adresse binden“: aus.
• „Zugriffsbeschränkung auf Administratorkonten“: leer, „Liste fungiert als...“ auf „Blacklist“.

Unter „Konfiguration“, „Passwort-Richtlinie“ waren 12 Zeichen Mindestlänge, „Kleinbuchstaben [a-z]“, „Großbuchstaben [A-Z]“ und „Ziffern [0-9]“ gesetzt, „Sonderzeichen“ nicht. Beide Zusatzprüfungen waren aktiv: „Verbietet die 100.000 häufigsten Passwörter.“ und „Prüft, ob das Passwort in einem bekannten Datenleck enthalten ist.“

Verifizieren: Wir haben mit einem kleinen Skript (/root/badlogin.sh 198.51.100.20 8, je ein curl-POST auf index.php) acht Anmeldungen als keyadmin mit falschem Passwort von 198.51.100.20 geschickt und die Antwortzeit gemessen. Die Antwortzeit verdoppelte sich ungefähr mit jedem Versuch:

Versuch 1: HTTP 200, 0.353001 s
Versuch 2: HTTP 200, 0.542835 s
Versuch 3: HTTP 200, 0.941120 s
Versuch 4: HTTP 200, 1.736355 s
Versuch 5: HTTP 200, 3.348976 s
Versuch 6: HTTP 200, 6.551813 s
Versuch 7: HTTP 200, 12.936125 s
Versuch 8: HTTP 200, 25.757448 s

Jeder Versuch endete mit „Die Kombination aus Benutzernamen und Passwort ist falsch.“ Eine Sperre gab es nicht, die anschließende Anmeldung mit richtigem Passwort von derselben Adresse gelang. Die Bremse macht Passwortraten langsam, ersetzt aber kein starkes Passwort.

Schritt 2: Passwort-Richtlinie prüfen und anpassen

Die Richtlinie gilt, wenn im Panel ein Passwort gesetzt wird. Wir haben unter „Benutzerverwaltung“ beim Kunden kunde1 nacheinander mehrere Passwörter eingetragen:

• kurz und Abcdefghijkl: „Die geforderte Passwort-Komplexität wurde nicht erfüllt.“ mit der Liste der Anforderungen.
• abcdefghijkl: „Das von Ihnen eingegebene Kennwort ist in einer Datenbank mit den am häufigsten verwendeten Zugangsdaten aufgeführt. Bitte wählen Sie ein sichereres Passwort.“
• Passwort1234: gespeichert, aber mit dem Hinweis „Ihr gewähltes Passwort wurde in den Daten eines veröffentlichten Datenlecks gefunden. Das Passwort tauchte 19820 mal auf.“

Wichtig ist der letzte Fall: Die Datenleck-Prüfung hat das Passwort im Test nicht abgelehnt, sondern nur gewarnt. KeyHelp meldete zugleich „Der Benutzer kunde1 wurde aktualisiert.“ Ob eine strengere Richtlinie solche Passwörter abfängt und ob sich die Richtlinie auch auf bestehende Passwörter auswirkt, haben wir nicht geprüft.

Verifizieren: Ein Passwort mit 14 Zeichen aus Groß- und Kleinbuchstaben, Ziffern und Sonderzeichen wurde ohne Hinweis gespeichert, die Kundenanmeldung damit klappte (Kundenlogin kunde1 von 198.51.100.20: HTTP 302 -> https://198.51.100.1/index.php?page=client_dashboard).

Schritt 3: Leerlaufzeit und IP-Bindung der Sitzung

Für den Test haben wir die „Sitzungs-Leerlaufzeit“ auf 1 Minute gesetzt und „Sitzung an IP-Adresse binden“ aktiviert. Ein frisch angemeldeter Admin war direkt danach im Dashboard, nach 75 Sekunden ohne Aktion leitete KeyHelp auf die Anmeldung um:

Sitzung von 198.51.100.10: HTTP 200 -> 
Sitzung von 198.51.100.10: HTTP 302 -> https://198.51.100.1/index.php?event=4&open_page=admin_dashboard

Die Anmeldeseite meldete dann „Ihre Sitzung ist abgelaufen, bitte melden Sie sich erneut an.“

Zur IP-Bindung haben wir das Sitzungs-Cookie eines Logins von 198.51.100.10 kopiert und von 198.51.100.20 verwendet. KeyHelp verweigerte das. Danach war auch die Sitzung an der ursprünglichen Adresse beendet:

Gleiche Sitzung von .20: HTTP 302 -> https://198.51.100.1/index.php?event=4&open_page=admin_dashboard
Sitzung von .10 danach: HTTP 302 -> https://198.51.100.1/index.php?event=4&open_page=admin_dashboard

Im Test half das kopierte Cookie von einer anderen Adresse also nicht weiter. Der Hilfetext nennt den Preis: „Dies stellt zwar eine Sicherheitsverbesserung dar, doch leidet die Benutzerfreundlichkeit für Benutzer mit variablen IP-Adressen.“

Verifizieren: In der Datenbank von KeyHelp stand danach ip_lock 1 in der Tabelle settings.

Schritt 4: Admin-Zugang auf eigene Adressen beschränken

Tragen Sie unter „Zugriffsbeschränkung auf Administratorkonten“ Ihre IP-Adressen oder Netze ein, je eine pro Zeile, und wählen Sie „Whitelist - Gewährt Zugriff nur für aufgelistete Adressen.“ Die Einstellung betrifft laut Panel nur Administratorkonten: „Diese Einstellung hat keinen Einfluss auf die Anmeldung regulärer Benutzerkonten.“

KeyHelp schützt Sie beim Speichern vor dem häufigsten Fehler. Im Test haben wir im Browser die Whitelist mit 198.51.100.10 gespeichert, während der Browser über eine andere Adresse zugriff. KeyHelp übernahm die Einstellung nicht, sondern meldete „Mit Ihrer aktuellen IP“, gefolgt von der Adresse des Browsers und „würden Sie sich nicht mit einem Administratorkonto anmelden können.“ Die Liste blieb auf „Blacklist“.

Von 198.51.100.10 aus gespeichert, wurde die Whitelist übernommen („Die Einstellungen wurden aktualisiert.“). Danach galt:

Login von 198.51.100.20: HTTP 302 -> https://198.51.100.1/index.php?event=12
Login von 198.51.100.10: HTTP 302 -> https://198.51.100.1/index.php?page=admin_dashboard

Die gesperrte Adresse landet wieder auf der Anmeldeseite (event=12). Dort steht, wie im Blacklist-Test protokolliert, zum Beispiel „Der administrative Zugriff von Ihrer IP-Adresse 198.51.100.10 ist nicht gestattet.“ mit der jeweiligen Adresse. Der Kunde kunde1 konnte sich von derselben fremden Adresse weiter anmelden.

Verifizieren: Auch der Server selbst ist keine Ausnahme. Die Anmeldung über 127.0.0.1 scheiterte ebenso wie die Einmal-URL aus keyhelp login keyadmin:

Einmal-URL von 127.0.0.1: HTTP 302 -> https://server.example.de/index.php?event=12

Hinweis zum Testaufbau: Der Browser erreichte das Panel im Test über einen Proxy, deshalb zeigen die Meldungen in den Abbildungen dessen Adresse (anonymisiert als 203.0.113.10). Wie sich KeyHelp hinter einem Reverse Proxy verhält, haben wir nicht geprüft.

Schritt 5: Wieder hereinkommen mit der Toolbox

Haben Sie sich trotzdem ausgesperrt, etwa weil sich Ihre Adresse geändert hat, nennt das Panel selbst den Weg: „Wenn Sie sich aufgrund einer geänderten IP nicht mehr anmelden können, können Sie die Zugriffsbeschränkungen auch über die Konsole deaktivieren, indem Sie das folgende Programm aufrufen: keyhelp-toolbox“. Melden Sie sich per SSH oder Konsole als root an und starten Sie:

keyhelp-toolbox

Wählen Sie Punkt 6) Disable login restrictions for administrator accounts, bestätigen Sie mit C:

Here you can revert any login restrictions for administrator accounts.
- Available actions ------------------------------------------------------
  C) Continue
  R) Return to main menu
  Q) Quit
Choose action: C
 All tasks completed. 

Verifizieren: Danach war die Liste leer und wieder auf „Blacklist“, die fremde Adresse kam wieder herein:

administrative_access	
administrative_access_behavior	blacklist
Login von 198.51.100.20: HTTP 302 -> https://198.51.100.1/index.php?page=admin_dashboard

Die Liste ist danach leer. Tragen Sie Ihre Adressen neu ein.

Typische Fehler

Meldung „Mit Ihrer aktuellen IP“ mit Ihrer Adresse, gefolgt von „würden Sie sich nicht mit einem Administratorkonto anmelden können.“ Ihre aktuelle Adresse fehlt in der Whitelist. KeyHelp speichert dann nicht. Ergänzen Sie die angezeigte Adresse oder Ihr Netz.

„Der administrative Zugriff von Ihrer IP-Adresse 198.51.100.10 ist nicht gestattet.“ (mit Ihrer Adresse) Die Adresse steht nicht in der Whitelist oder in der Blacklist. Im Test kam diese Meldung auch nach einem richtigen Passwort. Helfen Sie sich mit keyhelp-toolbox, Punkt 6.

Bestehende Sitzung bleibt trotz neuer Sperre offen. Wir haben 198.51.100.10 auf die Blacklist gesetzt, während dort ein Admin angemeldet war. Neue Anmeldungen von dieser Adresse scheiterten, die laufende Sitzung lud aber weiter Seiten, auch „Login & Sitzungen“. Das Gleiche galt für die Browsersitzung nach dem Aktivieren der Whitelist. Eine kurze Leerlaufzeit (Schritt 3) begrenzt, wie lange eine untätige Sitzung offen bleibt. Ein Sitzungsende durch die neue Sperre selbst gab es im Test nicht.

Geleaktes Passwort wurde trotzdem gespeichert. Die Datenleck-Prüfung hat im Test nur gewarnt. Abgelehnt wurde nur, was gegen Länge, Zeichenklassen oder die Liste häufiger Passwörter verstößt.

Häufige Fragen

Wie viele Fehlversuche erlaubt KeyHelp, bevor es sperrt?

Im Test hat KeyHelp nach acht falschen Admin-Passwörtern nicht gesperrt, sondern jede Antwort verzögert, zuletzt dauerte die Antwort rund 26 Sekunden.

Gilt die IP-Beschränkung auch für Kunden?

Nein. Im Test konnte sich kunde1 von einer Adresse anmelden, die für Admins gesperrt war.

Wie lang sollte die Leerlaufzeit sein?

Das hängt von Ihrer Arbeitsweise ab. Getestet haben wir nur, dass die eingestellte Zeit wirkt. Ab Werk sind es 24 Minuten.

Testumfang

Wir haben in KeyHelp 26.1.1 Whitelist und Blacklist für Admins, Leerlaufzeit, IP-Bindung, Brute-Force-Drosselung und Passwort-Richtlinie geprüft, Anmeldungen per curl von zwei simulierten Client-Adressen auf dem Server, Einstellungen teils im Browser. Auffällig: Laufende Sitzungen überstehen eine neue IP-Sperre, geleakte Passwörter erzeugen nur eine Warnung. Nicht geprüft: IPv6, Netzmasken in der Liste, Betrieb hinter einem Reverse Proxy, Auswirkung der Richtlinie auf bestehende Passwörter und Zugriffe über das Internet. Testen Sie die Whitelist nach dem Speichern von einer fremden Adresse aus.

Fazit

Mit wenigen Feldern machen Sie den Admin-Zugang deutlich schwerer angreifbar: Whitelist für Ihre festen Adressen, IP-Bindung der Sitzung und eine strenge Passwort-Richtlinie. KeyHelp verhindert beim Speichern, dass Sie sich mit der Whitelist sofort selbst aussperren, und die Toolbox holt Sie zurück, wenn sich Ihre Adresse später ändert. Planen Sie dafür immer einen Konsolenzugang ein. Und verlassen Sie sich nicht darauf, dass eine neue Sperre bereits angemeldete Sitzungen beendet.

Weiterführende Anleitungen und Quellen

• KeyHelp installieren und absichern
• KeyHelp: Zwei-Faktor-Anmeldung mit TOTP und Passkeys
• Zwei-Faktor-Authentifizierung richtig einführen
• Keyweb: KeyHelp, alle Funktionen im Überblick
• Have I Been Pwned: Pwned Passwords