Einführung
Vor dem Einsatz eines Scanners musst du Adresse, Name, Netzwerkpfad und Dienstport unterscheiden. Das sind unterschiedliche Beobachtungen; Erfolg auf einer Ebene beweist keinen Erfolg auf einer anderen.
Dieses Lab stellt einen lokalen DNS-Server und Webdienst in deiner Kali-Umgebung bereit. Du prüfst das Netzwerk, löst den Übungsnamen auf und prüfst seinen TCP-Listener, ohne ein Gateway zu scannen oder von öffentlichen Zielen abhängig zu sein.
Adressen, Routen und Loopback-Erreichbarkeit prüfen
In diesem Schritt prüfst du das Netzwerk des Kali-Containers und testest einen begrenzten lokalen Verbindungspfad.
Öffne die vorbereitete Shell und wähle den Arbeitsbereich:
kali
cd /home/labex/project
Eine IP-Adresse identifiziert einen Netzwerkendpunkt. Eine Schnittstelle ist die Verbindung des Systems zu einem Netzwerk; eine Route beschreibt, wohin Verkehr für eine Adresse gelangen soll. Container haben eine eigene Netzwerksicht. Prüfe deshalb diese Umgebung, statt die Hosteinstellungen vorauszusetzen.
ip prüft Linux-Netzwerke. Die Option -brief fordert eine kompakte Ansicht der Schnittstellenadressen an:
ip -brief address
Suche lo, die Loopback-Schnittstelle, und 127.0.0.1. Loopback-Verkehr bleibt in dieser Netzwerkumgebung. Andere Schnittstellen und Adressen können variieren. Ein Präfix wie /8 oder /16 beschreibt den Netzwerkbereich der Adresse; es ist kein Dienstport.
Prüfe Routen:
ip route
Ein Eintrag default, sofern vorhanden, wird verwendet, wenn keine spezifischere Route passt. Du musst weder das Gateway scannen noch eine Route ändern.
ping sendet Erreichbarkeitsproben. -c 3 begrenzt den Test auf drei Proben, sodass er automatisch endet:
ping -c 3 127.0.0.1
Du solltest Antworten und eine abschließende Paketübersicht erhalten. Die genaue Dauer variiert. Eine ping-Antwort zeigt, dass diese Proben Antworten erhielten; sie belegt nicht, dass ein bestimmter TCP-Dienst lauscht.
Speichere deine Schnittstellenbeobachtung mit der bekannten Ausgabeumleitung:
ip -brief address > interfaces.txt
cat interfaces.txt
Die gespeicherte Ansicht sollte Loopback-Schnittstelle und Adresse enthalten.
Einen Namen mit dem Übungs-DNS-Server auflösen
In diesem Schritt unterscheidest du mit einem lokalen DNS-Server Namensauflösung von Dienstkonnektivität.
DNS übersetzt Namen in Datensätze. Ein A-Datensatz enthält eine IPv4-Adresse. Dieses Lab stellt einen DNS-Server unter 127.0.0.1 auf Port 5353 und den lokalen Namen training-web.test bereit; ein öffentlicher DNS-Dienst ist unnötig.
dig fragt DNS ab. @127.0.0.1 wählt den Server, -p 5353 dessen abweichenden DNS-Port, das nächste Argument ist der Name, und A fordert einen IPv4-Adressdatensatz an:
dig @127.0.0.1 -p 5353 training-web.test A
Der Antwortabschnitt sollte den Namen und die Adresse 127.0.0.1 zeigen. Auch DNS nutzt Ports: Port 5353 gehört hier zum Übungs-DNS-Server, nicht zum Webdienst, den seine Antwort benennt.
Die Anzeigeoption +short gibt nur die Antwortdaten aus. Speichere dieses kleinere Ergebnis:
dig @127.0.0.1 -p 5353 +short training-web.test A > dns-answer.txt
cat dns-answer.txt
Erwartete Ausgabe:
127.0.0.1
Eine Systemnamenssuche kann auch lokale Dateien verwenden, statt DNS direkt abzufragen. getent hosts fragt die konfigurierte Hostnamensauflösung des Systems nach einem Namen:
getent hosts localhost
Die Ausgabe ordnet localhost einer Loopback-Adresse zu, möglicherweise IPv6 ::1. Das unterscheidet sich von einer ausdrücklichen Abfrage des bereitgestellten DNS-Servers mit dig. Erfolgreiche Namensauflösung liefert eine Adresse; du musst weiterhin prüfen, ob der benötigte Dienst dort verfügbar ist.
Einen Listener prüfen und seinen TCP-Port testen
In diesem Schritt verbindest du eine Adresse mit einem bestimmten Transportprotokoll und Dienstport.
Ein Port identifiziert einen Transportendpunkt an einer Adresse. TCP stellt Verbindungen her; UDP sendet Datagramme ohne denselben Verbindungsaufbau. Die Portnummer allein beweist weder die vorhandene Anwendung noch eine Schwachstelle.
ss zeigt Socketinformationen. -l wählt lauschende Sockets, -t TCP, und -n behält numerische Adressen und Portnummern bei:
ss -ltn
Suche den lokalen Endpunkt 127.0.0.1:8080. Er gehört zum bereitgestellten Übungswebdienst. Die Adresse beschränkt ihn auf Loopback im Container. Prüfe UDP-Sockets separat mit -u statt -t:
ss -lun
Der Übungs-DNS-Endpunkt verwendet Port 5353. TCP und UDP haben getrennte Porträume; beide Protokolle können dieselbe Nummer verwenden.
Speichere nur die TCP-Listenerzeile des Übungsdienstes. Das Muster enthält den Doppelpunkt vor dem Port und ein abschließendes Leerzeichen, um ihn von längeren Zahlen zu unterscheiden:
ss -ltn | grep ':8080 ' > service-listener.txt
cat service-listener.txt
Die Zeile sollte LISTEN und 127.0.0.1:8080 nennen; Abstände und Warteschlangenwerte können abweichen.
Ncat kann eine TCP-Verbindung ohne Anwendungsdaten testen. -v gibt den Status aus, -z fordert eine Verbindungsprüfung statt einer interaktiven Datensitzung an:
ncat -vz 127.0.0.1 8080
Der Status sollte eine erfolgreiche Verbindung melden. Das beweist, dass der ausgewählte TCP-Port jetzt eine Verbindung annimmt; eine HTTP-Antwort wird damit noch nicht geprüft. HTTP selbst untersuchst du in einem späteren Lab.
Zusammenfassung
Du hast Schnittstellen und Routen geprüft, einen begrenzten Erreichbarkeitstest gesendet, lokales DNS abgefragt, TCP- und UDP-Listener geprüft und eine TCP-Verbindung getestet. Du hast erfolgreiche Auflösung und Netzwerkerreichbarkeit vom Verhalten auf Anwendungsebene unterschieden.
