Debuggen von Hydra-Angriffen

HydraHydraBeginner
Jetzt üben

💡 Dieser Artikel wurde von AI-Assistenten übersetzt. Um die englische Version anzuzeigen, können Sie hier klicken

Einführung

In diesem Lab lernen Sie, wie Sie Hydra-Angriffe debuggen können, indem Sie einen Telnet-Server einrichten und die Debug-Ausgabe von Hydra analysieren. Das Lab konzentriert sich darauf, das Verhalten von Hydra während eines Angriffs anhand detaillierter Debug-Informationen zu verstehen.

Zunächst richten Sie auf der LabEx-VM einen Telnet-Server ein, indem Sie xinetd verwenden, um den Telnet-Service zu verwalten. Dies umfasst die Installation von telnetd und xinetd, die Konfiguration von xinetd zur Verwaltung von Telnet-Verbindungen und das Neustarten des xinetd-Services. Anschließend führen Sie Hydra im Debug-Modus mit der Option -d aus, um detaillierte Ausgaben zu generieren. Abschließend analysieren Sie diese Debug-Ausgabe, um den Angriffsprozess zu verstehen und potenzielle Probleme zu identifizieren.


Skills Graph

%%%%{init: {'theme':'neutral'}}%%%% flowchart RL hydra(("Hydra")) -.-> hydra/HydraGroup(["Hydra"]) hydra/HydraGroup -.-> hydra/installation("Installation and Setup") hydra/HydraGroup -.-> hydra/verbose_mode("Verbose Mode Usage") hydra/HydraGroup -.-> hydra/troubleshooting("Basic Troubleshooting") subgraph Lab Skills hydra/installation -.-> lab-550766{{"Debuggen von Hydra-Angriffen"}} hydra/verbose_mode -.-> lab-550766{{"Debuggen von Hydra-Angriffen"}} hydra/troubleshooting -.-> lab-550766{{"Debuggen von Hydra-Angriffen"}} end

Einrichten eines Telnet-Servers

In diesem Schritt werden wir auf der LabEx-VM einen Telnet-Server einrichten. Telnet ist ein Netzwerkprotokoll, das verwendet wird, um eine bidirektionale, interaktive, textbasierte Kommunikationsmöglichkeit über eine virtuelle Terminalverbindung bereitzustellen. Obwohl Telnet aufgrund seiner fehlenden Verschlüsselung im Allgemeinen als unsicher angesehen wird, kann es für Test- und Demonstrationszwecke in einer kontrollierten Umgebung wie unserer LabEx-VM nützlich sein.

Da die LabEx-VM Docker-Container verwendet, können wir nicht direkt systemctl verwenden, um Dienste zu verwalten. Stattdessen verwenden wir xinetd, um den Telnet-Dienst zu verwalten. xinetd (extended Internet daemon) ist ein Super-Server-Daemon, der auf eingehende Netzwerkverbindungen lauscht und den entsprechenden Dienst startet.

Zunächst installieren wir die Pakete telnetd und xinetd. Öffnen Sie das Terminal in der LabEx-VM und führen Sie den folgenden Befehl aus:

sudo apt update
sudo apt install telnetd xinetd -y

Dieser Befehl aktualisiert die Paketlisten und installiert die Pakete telnetd (Telnet-Server-Daemon) und xinetd. Die Option -y beantwortet automatisch alle Abfragen während der Installation mit "ja".

Als Nächstes müssen wir xinetd konfigurieren, um den Telnet-Dienst zu verwalten. Erstellen Sie eine Konfigurationsdatei für Telnet im Verzeichnis /etc/xinetd.d/. Verwenden Sie nano, um die Datei zu erstellen und zu bearbeiten:

sudo nano /etc/xinetd.d/telnet

Fügen Sie die folgende Konfiguration in den nano-Editor ein:

service telnet
{
        flags           = REUSE
        socket_type     = stream
        wait            = no
        user            = root
        server          = /usr/sbin/in.telnetd
        log_on_failure  += USERID
        disable         = no
}

Diese Konfiguration teilt xinetd mit, auf Telnet-Verbindungen zu lauschen, den Server /usr/sbin/in.telnetd als Root auszuführen und Verbindungsfehler zu protokollieren. disable = no stellt sicher, dass der Dienst aktiviert ist.

Drücken Sie Ctrl+X, dann Y und anschließend Enter, um die Datei zu speichern und nano zu verlassen.

Jetzt starten wir den xinetd-Dienst neu, um die Änderungen anzuwenden. Da wir systemctl nicht verwenden können, verwenden wir einen Workaround, indem wir dem xinetd-Prozess ein HUP-Signal senden. Zunächst finden wir die Prozess-ID von xinetd:

ps -ef | grep xinetd

Sie sollten eine Ausgabe ähnlich der folgenden sehen:

root       1234  1     0 10:00 ?        00:00:00 /usr/sbin/xinetd -stayalive -pidfile /run/xinetd.pid
labex      5678  5600  0 10:01 pts/0    00:00:00 grep --color=auto xinetd

Notieren Sie sich die Prozess-ID von xinetd (in diesem Beispiel ist es 1234). Ersetzen Sie 1234 in dem folgenden Befehl durch die tatsächliche Prozess-ID aus Ihrer Ausgabe:

sudo kill -HUP 1234

Dieser Befehl sendet ein HUP-Signal an den xinetd-Prozess, wodurch er seine Konfiguration neu lädt.

Schließlich überprüfen wir, ob der Telnet-Server läuft. Sie können versuchen, sich von demselben Rechner aus mit dem telnet-Befehl damit zu verbinden. Da der telnet-Client möglicherweise nicht standardmäßig installiert ist, verwenden wir netcat, um die Verbindung zu testen.

nc localhost 23

Wenn der Telnet-Server läuft, sollten Sie einen leeren Bildschirm oder eine Telnet-Eingabeaufforderung sehen. Sie können die Verbindung dann schließen, indem Sie Ctrl+] und anschließend quit eingeben. Wenn Sie "Connection refused" erhalten, überprüfen Sie die obigen Schritte noch einmal.

Mit -d im Debug-Modus ausführen

In diesem Schritt werden wir xinetd so konfigurieren, dass der Telnet-Server im Debug-Modus ausgeführt wird. Das Ausführen im Debug-Modus kann wertvolle Informationen über den Betrieb des Servers liefern, was für die Fehlerbehebung und das Verständnis seiner Funktionsweise hilfreich sein kann.

Um den Debug-Modus zu aktivieren, müssen wir die xinetd-Konfigurationsdatei für Telnet, die wir im vorherigen Schritt erstellt haben, ändern. Öffnen Sie die Datei /etc/xinetd.d/telnet mit nano:

sudo nano /etc/xinetd.d/telnet

Ändern Sie die server-Zeile, um die Option -d für den Debug-Modus hinzuzufügen. Die Zeile sollte nun wie folgt aussehen:

        server          = /usr/sbin/in.telnetd -d

Die Option -d teilt in.telnetd mit, im Debug-Modus auszuführen und somit eine ausführlichere Ausgabe zu liefern.

Drücken Sie Ctrl+X, dann Y und anschließend Enter, um die Datei zu speichern und nano zu verlassen.

Jetzt starten wir den xinetd-Dienst neu, um die Änderungen anzuwenden. Wie zuvor verwenden wir den Befehl kill -HUP. Zunächst finden wir die Prozess-ID von xinetd:

ps -ef | grep xinetd

Notieren Sie sich die Prozess-ID von xinetd (z.B. 1234). Ersetzen Sie 1234 in dem folgenden Befehl durch die tatsächliche Prozess-ID aus Ihrer Ausgabe:

sudo kill -HUP 1234

Dieser Befehl sendet ein HUP-Signal an den xinetd-Prozess, wodurch er seine Konfiguration neu lädt, nun mit dem Telnet-Server im Debug-Modus.

Um die Debug-Ausgabe zu beobachten, müssen wir die Standardausgabe von xinetd in eine Datei umleiten. Allerdings gibt xinetd selbst nicht direkt in eine Datei aus. Die Debug-Ausgabe von in.telnetd -d wird an die Systemprotokolle gesendet. Wir können diese Protokolle mit tail -f überwachen.

Öffnen Sie ein neues Terminalfenster oder -tab. In diesem neuen Terminal führen Sie den folgenden Befehl aus, um die Systemprotokolle zu überwachen:

sudo tail -f /var/log/syslog

Wechseln Sie nun zurück zu Ihrem ursprünglichen Terminal und versuchen Sie, sich mit netcat mit dem Telnet-Server zu verbinden:

nc localhost 23

Nachdem Sie sich verbunden haben (und die Verbindung mit Ctrl+] und anschließend quit getrennt haben), wechseln Sie zurück zum Terminal, in dem Sie tail -f /var/log/syslog ausführen. Sie sollten Debug-Ausgaben von in.telnetd in Bezug auf die Verbindung sehen. Diese Ausgabe wird Informationen über die Aktivitäten des Telnet-Servers liefern, wie z.B. die Herstellung und Beendigung von Verbindungen.

Analyse der Debug-Ausgabe

In diesem Schritt werden wir die Debug-Ausgabe analysieren, die der Telnet-Server im Debug-Modus erzeugt. Das Verständnis dieser Ausgabe kann Ihnen helfen, Probleme zu diagnostizieren, das Telnet-Protokoll zu verstehen und möglicherweise Sicherheitslücken zu identifizieren.

Wie Sie im vorherigen Schritt gesehen haben, wird die Debug-Ausgabe in das Systemprotokoll (/var/log/syslog) geschrieben. Betrachten wir nun einige typische Debug-Ausgaben und deren Bedeutung.

Stellen Sie zunächst sicher, dass Sie weiterhin das Systemprotokoll in einem separaten Terminalfenster überwachen:

sudo tail -f /var/log/syslog

Verbinden Sie sich dann in Ihrem ursprünglichen Terminal mit dem Telnet-Server über netcat:

nc localhost 23

Geben Sie einige Zeichen ein und trennen Sie die Verbindung, indem Sie Ctrl+] und anschließend quit eingeben.

Betrachten Sie nun die Ausgabe im syslog-Terminal. Sie sollten Zeilen ähnlich den folgenden sehen (die genaue Ausgabe kann variieren):

Oct 26 14:30:00 labex in.telnetd[1234]: connect from ::1
Oct 26 14:30:00 labex in.telnetd[1234]: telnetd: sock_host_addr: ::1
Oct 26 14:30:05 labex in.telnetd[1234]: ttloop: client wrote 5 bytes
Oct 26 14:30:05 labex in.telnetd[1234]: recv: got IAC
Oct 26 14:30:05 labex in.telnetd[1234]: recv: IAC SB
Oct 26 14:30:05 labex in.telnetd[1234]: recv: got IAC SE
Oct 26 14:30:10 labex in.telnetd[1234]: ttloop: client wrote 6 bytes
Oct 26 14:30:10 labex in.telnetd[1234]: recv: got IAC
Oct 26 14:30:10 labex in.telnetd[1234]: recv: IAC SB
Oct 26 14:30:10 labex in.telnetd[1234]: recv: got IAC SE
Oct 26 14:30:15 labex in.telnetd[1234]: Exit on signal 15

Lassen Sie uns einige dieser Zeilen analysieren:

  • connect from ::1: Dies zeigt an, dass eine Verbindung von der IPv6-Loopback-Adresse (::1) hergestellt wurde, was der IPv4-Adresse 127.0.0.1 entspricht.
  • telnetd: sock_host_addr: ::1: Dies bestätigt die Quelladresse der Verbindung.
  • ttloop: client wrote 5 bytes: Dies zeigt, dass der Client (Ihre netcat-Sitzung) 5 Bytes Daten an den Server gesendet hat.
  • recv: got IAC: IAC steht für "Interpret As Command" (als Befehl interpretieren). Telnet verwendet spezielle Steuerzeichen, und IAC ist das Präfix für diese Zeichen.
  • recv: IAC SB und recv: got IAC SE: SB steht für "Subnegotiation Begin" (Beginn der Sub-Negotiation) und SE für "Subnegotiation End" (Ende der Sub-Negotiation). Diese Zeilen zeigen an, dass Client und Server Optionen aushandeln.
  • Exit on signal 15: Dies zeigt an, dass der telnetd-Prozess nach Empfang des Signals 15 beendet wurde, was das Standard-Signal ist, das von kill gesendet wird, wenn keine Signalnummer angegeben wird. Dies geschah, als Sie die netcat-Verbindung schlossen.

Durch die Analyse dieser Debug-Ausgabe können Sie Einblicke in das Telnet-Protokoll und in die Art und Weise gewinnen, wie der Server Verbindungen und Daten verarbeitet. Diese Informationen können für die Sicherheitsanalyse, die Fehlerbehebung und das Verständnis der Netzwerkkommunikation von Wert sein.

Beispielsweise könnten Sie, wenn Sie versuchen, eine Sicherheitslücke im Telnet-Server auszunutzen, diese Debug-Ausgabe nutzen, um zu verstehen, wie Ihr Angriff verarbeitet wird und potenzielle Schwachstellen zu identifizieren.

Zusammenfassung

In diesem Lab haben wir zunächst einen Telnet-Server auf der LabEx-VM eingerichtet, indem wir xinetd zur Verwaltung des telnetd-Dienstes genutzt haben. Dies beinhaltete die Installation der erforderlichen Pakete (telnetd und xinetd) und die Konfiguration von xinetd, um auf Telnet-Verbindungen zu lauschen und den Telnet-Server-Daemon auszuführen.

Die Konfigurationsdatei /etc/xinetd.d/telnet wurde erstellt und mit Einstellungen gefüllt, um den Telnet-Dienst zu aktivieren, das Server-Programm anzugeben und die Protokollierung von Verbindungen zu verwalten. Schließlich wurde der xinetd-Dienst neu gestartet, um die Konfigurationsänderungen anzuwenden und den Telnet-Server für Tests vorzubereiten.