Einführung
Gearroom verleiht Geräte an lokale Kreative. Mitglieder melden sich an, um ihre Abhol-, Rückgabe- und Packinformationen zu lesen. Eine Anmeldegrenze soll wiederholtes Passwortraten unterbrechen, doch der aktuelle Zähler gilt gemeinsam für alle. Fehlversuche eines Mitglieds können ein anderes daran hindern, mit seiner Arbeit zu beginnen.
Erzeuge mit Hydra einen kleinen, wiederholbaren Test, ordne den Zähler dem Konto zu und weise Schutz sowie normalen Zugriff nach. Dein Ergebnis ist eine wirksame aktive Richtlinie mit echter Authentifizierung und unveränderten Ausleihdaten, kein Bericht. Du darfst nur das angegebene synthetische Testmitglied sperren. Verwende für das Referenzmitglied ausschließlich das bekannte richtige Passwort und ändere weder Server, Konten noch Originaldatensätze.
Du benötigst grundlegende Terminaleingaben, das Erkennen von Pfaden und den Wechsel zwischen Tabs. Die nötigen Hydra-Optionen, Formularfelder, Shell-Anführungszeichen und die JSON-Richtlinie werden hier erklärt. Das vorbereitete Terminal Workstation und die Website Equipment Desk sind zwei Oberflächen desselben isolierten Trainingscontainers. Diese Einheit startet unabhängig von anderen Übungen. Alle Personen, Passwörter und Datensätze sind synthetische lokale Trainingsdaten.
Plane etwa 55 Minuten einschließlich Lesen und gewöhnlicher Fehler ein. Das ist eine Autorenschätzung, keine mit Anfängern gemessene Dauer. Die kleine Grenze von drei Fehlern in 30 Sekunden mit anschließender Sperre von 12 Sekunden ist ein Trainingsvertrag, keine Sicherheitsempfehlung für den Produktivbetrieb.
Zwei funktionierende Mitgliederanmeldungen bestätigen
Öffne in diesem Schritt die beiden bekannten Mitgliedsdatensätze, bevor du die Grenze testest. Eine erfolgreiche Authentifizierung bedeutet, dass der Server eine bestimmte Identität angenommen hat. Diese bestimmt, welchen Datensatz du sehen kannst.
Öffne Equipment Desk. Wähle oben in der Navigation Review brief. Das erlaubte Testmitglied ist member mit dem Passwort Member24. Das normale Referenzmitglied ist reference mit Reference24. Diese Zugangsdaten sind bekannt; du musst ihre Passwörter nicht herausfinden.
Nutze die beiden beschrifteten Eingaben und die Schaltfläche Sign in. Die Zeile unter dem Formular nennt den tatsächlichen POST-Pfad und die übermittelten Feldnamen.
Wähle Member sign-in, gib die Testzugangsdaten ein und wähle Sign in. Du solltest Signed in as member sehen. Wähle Open your record. Prüfe Ausleihe LN-204, Mina Park, Compact projector kit, Abholung Thursday 14:00, Rückgabe Monday 10:00 sowie den Hinweis zum HDMI-Kabel in der Seitentasche. Wähle Sign out.
Vergleiche Member und Record mit Gerät, Abholung, Rückgabe und Packhinweis. Eine erfolgreiche Anmeldung allein beweist keinen unveränderten Originaldatensatz.
Wähle erneut Member sign-in, verwende die Referenzzugangsdaten und dann Open your record. Prüfe LN-119, Theo Bell, Portable audio recorder und den Hinweis zum Windschutz. Wähle wieder Sign out. Es sind unterschiedliche Datensätze; beide zu erhalten gehört zur Aufgabe. Nach erfolgreicher Anmeldung speichert der Browser normalerweise automatisch das Cookie, eine vom Server ausgegebene Sitzungskennung. Abmelden beendet diese Sitzung.
Wechsle zu Workstation. Das konfigurierte Startverzeichnis ist /home/labex/project/login-limits. pwd zeigt das aktuelle Verzeichnis:
pwd
Du solltest /home/labex/project/login-limits sehen. Falls du anderswo bist, wechselt cd das Verzeichnis:
cd /home/labex/project/login-limits
cat zeigt eine Datei an. Lies die vorbereitete Richtlinie:
cat policy.json
Das ist JSON, ein strukturiertes Textformat mit Feldnamen in doppelten Anführungszeichen. Doppelpunkte verbinden Namen und Werte, Kommas trennen Felder, geschweifte Klammern umfassen ein Objekt. Der Schlüssel key ist aktuell global, weshalb derselbe Zähler verschiedene Mitgliedskonten enthalten kann. failed_attempts, window_seconds und cooldown_seconds sind die vereinbarten drei Fehler, das 30-Sekunden-Fenster und die 12-Sekunden-Sperre. entry_groups listet die vorbereiteten Anmeldepfade auf. Erhalte diese Zuordnung in dieser Einheit; Einstiegsgruppen untersuchst du in der nächsten unabhängigen Übung.
deskctl ist der vorbereitete, begrenzte Wartungsbefehl. Seine Aktion status liest die tatsächlich aktive Richtlinie. Sie meldet niemanden an, leert keine Zähler und ändert den Dienst nicht:
deskctl status
Die aktive Richtlinie sollte der Datei entsprechen. Eine Revision kennzeichnet die gerade verwendete Richtlinie. Eine spätere Dateibearbeitung ändert die aktive Richtlinie erst, wenn du sie ausdrücklich anwendest.
Das Problem des gemeinsamen Zählers beobachten
Sende in diesem Schritt nur die bereitgestellten falschen Passwörter für das erlaubte Testmitglied. Beobachte dann, wie der globale Zähler auch das Referenzmitglied ablehnt.
Bleibe in Workstation. Lies die vollständige erlaubte Kandidatendatei:
cat wrong-passwords.txt
NotThis11
NotThis22
NotThis33
NotThis44
NotThis55
Alle fünf sind für das Testkonto absichtlich falsch. Ergänze keine echten Zugangsdaten und teste kein anderes Konto wiederholt. Hydra erzeugt die begrenzten Versuche; dies ist weder ein Geschwindigkeitswettbewerb noch eine Passwortsuche.
127.0.0.1 ist die Loopback-Adresse dieses Trainingscontainers; Port 8080 erreicht dessen vorbereiteten lokalen Dienst statt einer externen Website. Das Hauptformular sendet eine POST-Anfrage an /signin. POST übermittelt benannte Felder im Anfragekörper. Hier heißen sie username und password, getrennt durch &. Hydras Argument http-post-form besteht aus drei durch Doppelpunkte getrennten Teilen: Pfad, Felder und Antwortbedingung. ^USER^ und ^PASS^ sind Hydra-Platzhalter. S=Signed in as verlangt den tatsächlich authentifizierten Antworttext; eine begrenzte oder abgelehnte Seite darf nicht als funktionierende Anmeldung gelten.
Die Hydra-Optionen sind -I zum Ignorieren eines alten Wiederherstellungshinweises in diesem Arbeitsbereich, -l member für einen festen Benutzernamen, -P für dessen bereitgestellte Passwortdatei, -s für den Port und -t 1 für einen Worker. Ein Worker macht diese kleine Folge leicht beobachtbar. Er erzeugt keine serverseitige Grenze. Das letzte Argument in einfachen Anführungszeichen bleibt auch mit Leerzeichen und & ein einziges Argument.
Der nächste Block verwendet außerdem curl, einen HTTP-Client für das Terminal. Er ist vom Browser getrennt und übernimmt dessen Sitzung nicht automatisch. --data liefert POST-Felder, -s blendet die Fortschrittsanzeige aus, -o speichert den Antwortkörper und -w gibt den HTTP-Status aus. Das angeführte \n sorgt für eine neue Zeile nach dem Status. Einfache Anführungszeichen erhalten &, Leerzeichen und %{http_code} für curl, statt sie von der Shell auswerten zu lassen. Diese beiden Diagnoseanmeldungen verwenden bekannte richtige Passwörter.
Warte zuerst, bis frühere Versuche natürlich abgelaufen sind. deskctl wait beobachtet die Bereitschaft, ohne Zähler zurückzusetzen oder Versuche hinzuzufügen:
deskctl wait
Führe die folgenden drei Befehle zusammen als einen Block aus. Sie erfassen beide Diagnoseantworten innerhalb der 12-Sekunden-Sperre; du musst zwischen den Befehlen nicht lesen:
hydra -I -l member -P wrong-passwords.txt -s 8080 -t 1 127.0.0.1 http-post-form '/signin:username=^USER^&password=^PASS^:S=Signed in as'
curl -s -o test-login.html -w 'Test member HTTP %{http_code}\n' --data 'username=member&password=Member24' http://127.0.0.1:8080/signin
curl -s -o reference-login.html -w 'Reference member HTTP %{http_code}\n' --data 'username=reference&password=Reference24' http://127.0.0.1:8080/signin
Hydra sollte 0 valid password found melden, weil alle Kandidaten falsch sind. Beide Diagnosezeilen sollten HTTP 429 zeigen. 429 bedeutet, dass der Dienst Versuche begrenzt, nicht dass das Passwort falsch ist. Curl kann bei einer HTTP-Ablehnung normal enden. Lies deshalb Status und gespeicherten Antwortkörper, statt seinen Exit-Status als Authentifizierung zu behandeln. In diesem Szenario beginnt der dritte abgelehnte Versuch die Sperre; folgende Versuche werden begrenzt, bevor ihre Passwörter geprüft werden.
grep sucht Text. Seine Option -o gibt nur die passenden Wörter aus und nicht die umgebende HTML-Seite:
grep -o 'Too many attempts' reference-login.html
Auch das richtige Referenzpasswort wurde abgelehnt. Das ist das Geschäftsproblem: Ein globaler Zähler unterbricht die neue Anmeldung eines anderen Mitglieds.
Lies die vorhandenen Serverereignisse:
deskctl events
Suche member auf /signin mit den Ergebnissen rejected, threshold und danach limited, gefolgt von einer als limited markierten Anmeldung von reference. Dies sind echte Serverentscheidungen, keine Interpretation der Hydra-Ausgabe. Die Ereignisse bleiben nach der Sperrzeit lesbar; du musst keine kurz sichtbare Seite erwischen.
Falls eine Diagnose zu spät kam, lasse deskctl wait enden und wiederhole denselben kleinen Dreierblock. Meldet Hydra einen Syntax- oder Verbindungsfehler, korrigiere zuerst das angeführte Argument, die Adresse 127.0.0.1, Port 8080 oder den angegebenen Pfad, bevor du Ergebnisse interpretierst. Ein Verbindungsfehler ist kein erfolgreicher Schutztest. HTTP 400 zeigt falsche Formularfelder, 404 einen falschen Pfad. Korrigiere diese gewöhnlichen Fehler ohne Zurücksetzen der Umgebung.
Eine Richtlinie pro Konto anwenden
Ändere in diesem Schritt nur den Zählerschlüssel, damit jedes Mitglied eine unabhängige Grenze hat. Erhalte Trainingswerte und Einstiegszuordnung.
Bleibe in Workstation. Der folgende Befehl ersetzt deine lokale policy.json. cat > policy.json schreibt Text in die Datei; > überschreibt eine vorhandene Datei. Ein Here-Dokument liefert die Zeilen bis zur Abschlussmarke EOF. Die Anführungszeichen in 'EOF' erhalten den Inhalt wörtlich. Setze die Abschlussmarke allein auf ihre Zeile, ohne führende Leerzeichen:
cat > policy.json <<'EOF'
{
"key": "account",
"entry_groups": {
"/signin": "loans",
"/mobile/signin": "loans"
},
"failed_attempts": 3,
"window_seconds": 30,
"cooldown_seconds": 12
}
EOF
Der einzige geänderte Wert ist key: account gruppiert Versuche nach der übermittelten Mitgliedskennung statt nach allen Konten gemeinsam. Den Schwellenwert auf null zu senken, ein Konto zu löschen oder alle abzulehnen würde den normalen Dienst nicht erhalten.
Wende die Datei mit dem vorbereiteten Steuerbefehl an:
deskctl apply policy.json --wait
apply prüft die Datei und ändert die aktive Richtlinie ausdrücklich. --wait wartet vor einer geänderten Richtlinie auf das natürliche Ende vorhandener Sperren oder teilweiser Fehlerfenster. Ein teilweises Fenster kann bis zu 30 Sekunden brauchen. Währenddessen bleibt die alte Richtlinie aktiv. Der Befehl startet den Dienst nicht neu, verwirft keinen Verlauf und leert keine aktiven Zähler. Dieselbe Richtlinie erneut anzuwenden ist wirkungslos und kann kein Konto entsperren.
Erwarte bei der ersten Änderung ok: true, changed: true und eine neue Revision mit key auf account. Falls du dieselbe gültige Datei bereits angewendet hast, ist changed: false normal.
deskctl status
Lies die aktive Richtlinie, nicht nur die Datei. Ein JSON-Fehler bedeutet häufig ein fehlendes Komma, Anführungszeichen oder eine Klammer. Vergleiche die Datei mit dem vollständigen Block, korrigiere sie und wende sie erneut an. Eine ungültige Richtlinie lässt die aktive Richtlinie unverändert. Starte den Server nicht neu und bearbeite seine Implementierung nicht, um die Prüfung zu bestehen.
Schutz und normale Wiederherstellung nachweisen
Teste in diesem Schritt die wirksame Richtlinie, erhalte den Zugriff des Referenzmitglieds und bestätige die natürliche Wiederherstellung des begrenzten Testmitglieds.
Bleibe in Workstation. Beginne mit natürlich beruhigten Zählern:
deskctl wait
Führe diesen vollständigen Block erneut aus. Pfade, bekannte Diagnosepasswörter und falsche Kandidaten bleiben unverändert; der aktive Zählerschlüssel ist anders:
hydra -I -l member -P wrong-passwords.txt -s 8080 -t 1 127.0.0.1 http-post-form '/signin:username=^USER^&password=^PASS^:S=Signed in as'
curl -s -o test-login.html -w 'Test member HTTP %{http_code}\n' --data 'username=member&password=Member24' http://127.0.0.1:8080/signin
curl -s -o reference-login.html -w 'Reference member HTTP %{http_code}\n' --data 'username=reference&password=Reference24' http://127.0.0.1:8080/signin
Erwarte keine Hydra-Funde, Test member HTTP 429 und Reference member HTTP 200. Das geschützte Konto bleibt begrenzt, während das unabhängige Referenzkonto sich authentifizieren kann. HTTP 200 allein reicht nicht. Prüfe die Identität im gespeicherten Antwortkörper:
grep -o 'Signed in as reference' reference-login.html
grep -o 'Too many attempts' test-login.html
Lies die aufgezeichneten Entscheidungen unter der neuen Revision:
deskctl events
Du solltest einen Schwellenwert und eine begrenzte Anmeldung von member zusammen mit einer authentifizierten Anmeldung von reference sehen. Nur Ereignisse unter der aktuellen Richtlinie belegen diese Korrektur. Alte Belege der globalen Richtlinie bleiben erhalten, beweisen aber nicht die neue. Falls du zwischen Befehlen pausiert und die Sperrzeit verpasst hast, warte natürlich ab und wiederhole denselben begrenzten Block. Erweitere die Kandidaten nicht und leere keine Zähler.
Lasse nun die Sperrzeit des Testmitglieds enden:
deskctl wait
Wechsle zu Equipment Desk. Wähle Member sign-in, verwende member / Member24, dann Sign in und Open your record. Es muss weiterhin LN-204, Mina Park, Compact projector kit mit allen Originalangaben sein. Diese neue Anmeldung belegt die Wiederherstellung nach natürlichem Ablauf. Wähle Sign out, dann Member sign-in mit reference / Reference24 und öffne LN-119 erneut. Prüfe Audiorecorder und Windschutzhinweis und melde dich ab.
Wähle abschließend Visitor guide. Öffentliche Abholinformationen bleiben verfügbar. Deine curl-Anmeldungen im Terminal und dieser Browser verwenden getrennte Sitzungen. Die frühere curl-Antwort meldet den Browser nicht automatisch an. Liefert ein Datensatz 403, melde dich über das echte Formular an und nutze Open your record. Korrigiere einen gewöhnlichen Passwort- oder Pfadfehler, statt die VM neu zu starten.
Deine policy.json entspricht jetzt der tatsächlich aktiven Kontorichtlinie. Der Server besitzt echte Fakten der aktuellen Revision: wiederholte Fehler, einen begrenzten Versuch mit richtigem Passwort, eine normale Referenzauthentifizierung während der Grenze und eine natürlich wiederhergestellte Testanmeldung, während beide Originaldatensätze unverändert sind. Die Bewertung liest diese vorhandenen Fakten und öffentliche Seiten. Sie ergänzt keine Anmeldungen, setzt keine Grenzen zurück und übernimmt keine Wiederherstellung. Dieses kontrollierte Training mit einem Prozess beweist das erklärte lokale Verhalten, keine vollständige Produktionsabwehr gegen jeden Authentifizierungsangriff.
Zusammenfassung
Du hast mit einer begrenzten Hydra-Folge einen globalen Zähler aufgedeckt, eine Kontorichtlinie ohne Neustart oder Zurücksetzen angewendet und Ablehnung sowie Verfügbarkeit geprüft. Das Testmitglied blieb auch mit richtigem Passwort begrenzt, ein anderes Mitglied konnte sich authentifizieren und der natürliche Ablauf stellte den Zugriff auf unveränderte Datensätze wieder her. Die aktuelle Richtlinie und echte Serverentscheidungen belegen das Ergebnis, nicht allein eine leere Hydra-Ausgabe oder ein grüner Status.
