Einführung
Willkommen zu diesem Labor über Netzwerkanalyse und sicheren Fernzugriff unter Linux. Das Verständnis, wie man Netzwerkaktivitäten überwacht und die Kommunikation absichert, ist eine entscheidende Fähigkeit für jeden Systemadministrator, Entwickler oder Sicherheitsexperten.
In diesem Labor erhalten Sie praktische Erfahrung mit einer Reihe leistungsstarker Kommandozeilenwerkzeuge. Sie lernen, wie Sie:
- Aktive Netzwerkverbindungen und lauschende Dienste mit
netstatund seinem modernen Nachfolgerssinspizieren. - Live-Netzwerkpakete mit
tcpdumperfassen und analysieren. - Eine sichere Fernverbindung zu Ihrer eigenen Maschine mit
sshherstellen. - Die Integrität von DNS-Antworten mit
digund DNSSEC überprüfen.
Am Ende dieses Labors werden Sie ein praktisches Verständnis dieser wesentlichen Netzwerk-Utilities und ihrer Rolle bei der Verwaltung und Sicherung eines Linux-Systems haben.
Aktive Netzwerkverbindungen mit Netstat/SS inspizieren
In diesem Schritt lernen Sie, wie Sie aktive Netzwerkverbindungen und lauschende Ports auf Ihrem System anzeigen. Dies ist grundlegend, um zu verstehen, welche Dienste laufen und über das Netzwerk erreichbar sind. Wir werden zwei gängige Werkzeuge verwenden: netstat und ss.
Zuerst verwenden wir netstat, ein klassisches und weithin bekanntes Dienstprogramm. Das Paket net-tools, das netstat enthält, wurde während der Laboreinrichtung für Sie installiert.
Führen Sie den folgenden Befehl aus, um alle lauschenden TCP (-t) und UDP (-u) Ports in numerischer Form (-n) aufzulisten, ohne Namen aufzulösen, und sich nur auf lauschende Sockets (-l) zu konzentrieren:
netstat -tuln
Sie sollten eine Ausgabe ähnlich dieser sehen. Beachten Sie die Einträge für den SSH-Server (Port 22) und den Python-Webserver (Port 8000), die für Sie gestartet wurden, zusammen mit zusätzlichen Diensten auf den Ports 3001 und 3002:
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:3001 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:3002 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:8000 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.11:37199 0.0.0.0:* LISTEN
tcp6 0 0 :::22 :::* LISTEN
udp 0 0 127.0.0.11:60120 0.0.0.0:*
udp 0 0 0.0.0.0:3001 0.0.0.0:*
Nun verwenden wir ss, den modernen Ersatz für netstat. Es ist im Allgemeinen schneller und liefert detailliertere Informationen. Der Befehl und die Flags sind sehr ähnlich.
ss -tuln
Die Ausgabe wird im Format leicht unterschiedlich sein, zeigt aber die gleichen wesentlichen Informationen: die Dienste, die auf den Ports 22, 3001, 3002 und 8000 lauschen, zusammen mit einigen internen Docker-Diensten:
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
udp UNCONN 0 0 127.0.0.11:60120 0.0.0.0:*
udp UNCONN 0 0 0.0.0.0:3001 0.0.0.0:*
tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
tcp LISTEN 0 5 0.0.0.0:3001 0.0.0.0:*
tcp LISTEN 0 128 0.0.0.0:3002 0.0.0.0:*
tcp LISTEN 0 5 0.0.0.0:8000 0.0.0.0:*
tcp LISTEN 0 4096 127.0.0.11:37199 0.0.0.0:*
tcp LISTEN 0 128 [::]:22 [::]:*
Durch die Verwendung dieser Befehle können Sie schnell einen Überblick über die netzwerkbezogenen Dienste Ihres Systems erhalten.
Lokalen Netzwerkverkehr mit Tcpdump erfassen
In diesem Schritt verwenden Sie tcpdump, einen leistungsstarken Kommandozeilen-Paketanalysator, um Netzwerkverkehr in Echtzeit zu erfassen und zu inspizieren. Dies ist von unschätzbarem Wert für die Fehlersuche bei Netzwerkproblemen oder das Verständnis der Funktionsweise von Protokollen.
Zuerst sehen wir, welche Netzwerkschnittstellen für die Erfassung von Datenverkehr verfügbar sind.
sudo tcpdump -D
Die Ausgabe listet die verfügbaren Schnittstellen auf. lo ist die "Loopback"-Schnittstelle, die für die Netzwerkkommunikation innerhalb derselben Maschine verwendet wird (z. B. die Verbindung zu localhost). Sie sehen verschiedene Schnittstellen, einschließlich der primären Netzwerkschnittstelle eth1:
1.eth1 [Up, Running, Connected]
2.any (Pseudo-device that captures on all interfaces) [Up, Running]
3.lo [Up, Running, Loopback]
4.bluetooth-monitor (Bluetooth Linux Monitor) [Wireless]
5.nflog (Linux netfilter log (NFLOG) interface) [none]
6.nfqueue (Linux netfilter queue (NFQUEUE) interface) [none]
7.dbus-system (D-Bus system bus) [none]
8.dbus-session (D-Bus session bus) [none]
Wir werden den Verkehr auf der Loopback-Schnittstelle (lo) erfassen, um die Anfragen an unseren lokalen Webserver zu sehen. Dazu benötigen Sie zwei Terminals.
Führen Sie in Ihrem aktuellen Terminal den folgenden tcpdump-Befehl aus. Er lauscht auf der lo-Schnittstelle (-i lo) und stoppt nach der Erfassung von 5 Paketen (-c 5).
sudo tcpdump -i lo -c 5
Klicken Sie nun auf das +-Symbol in der Terminal-Tab-Leiste, um ein neues Terminal zu öffnen. Generieren Sie in diesem neuen Terminal etwas Netzwerkverkehr, indem Sie eine Anfrage an den lokalen Webserver mit curl senden.
curl http://localhost:8000
Wechseln Sie zurück zu Ihrem ersten Terminal. Sie werden sehen, dass tcpdump die Pakete im Zusammenhang mit Ihrer curl-Anfrage erfasst hat. Die Ausgabe wird in etwa so aussehen und den TCP-Handshake sowie die Datenübertragung zeigen:
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on lo, link-type EN10MB (Ethernet), snapshot length 262144 bytes
14:57:14.158058 IP localhost.57272 > localhost.8000: Flags [S], seq 2025143228, win 65495, options [mss 65495,sackOK,TS val 1006286113 ecr 0,nop,wscale 7], length 0
14:57:14.158072 IP localhost.8000 > localhost.57272: Flags [S.], seq 403368374, ack 2025143229, win 65483, options [mss 65495,sackOK,TS val 1006286113 ecr 1006286113,nop,wscale 7], length 0
14:57:14.158083 IP localhost.57272 > localhost.8000: Flags [.], ack 1, win 512, options [nop,nop,TS val 1006286113 ecr 1006286113], length 0
14:57:14.158129 IP localhost.57272 > localhost.8000: Flags [P.], seq 1:79, ack 1, win 512, options [nop,nop,TS val 1006286113 ecr 1006286113], length 78
14:57:14.158133 IP localhost.8000 > localhost.57272: Flags [.], ack 79, win 511, options [nop,nop,TS val 1006286113 ecr 1006286113], length 0
5 packets captured
24 packets received by filter
0 packets dropped by kernel
Beachten Sie, dass Sie, wenn Sie tcpdump ohne spezifischen Datenverkehr ausführen, möglicherweise Hintergrund-DNS-Abfragen und andere Systemkommunikationen sehen, wie in Ihren Protokollen gezeigt. Dies ist ein normales Systemverhalten und zeigt, dass Ihr System verschiedene Netzwerkkommunikationen aufrechterhält, auch wenn Sie nicht aktiv surfen.
Sie haben erfolgreich Live-Netzwerkverkehr erfasst und angezeigt.
Sicheren Fernzugriff mit SSH demonstrieren
In diesem Schritt lernen Sie, SSH (Secure Shell) für sicheren Fernzugriff zu verwenden. Wir werden die schlüsselbasierte Authentifizierung konfigurieren, die sicherer ist als die Verwendung von Passwörtern, um sich bei Ihrer eigenen Maschine (localhost) anzumelden. Der openssh-server wurde bereits für Sie gestartet.
Zuerst müssen Sie ein SSH-Schlüsselpaar (einen privaten Schlüssel und einen öffentlichen Schlüssel) generieren. Wir erstellen einen RSA-Schlüssel mit einer Schlüssellänge von 2048 Bit. Das Flag -f gibt die Datei an, in der der Schlüssel gespeichert werden soll, und -N "" setzt eine leere Passphrase für die Bequemlichkeit in diesem Lab.
ssh-keygen -t rsa -b 2048 -f ~/.ssh/id_rsa -N ""
Dieser Befehl erstellt id_rsa (Ihren privaten Schlüssel) und id_rsa.pub (Ihren öffentlichen Schlüssel) im Verzeichnis ~/.ssh.
Als Nächstes müssen Sie den öffentlichen Schlüssel zur Datei authorized_keys hinzufügen, damit Ihr eigener Benutzer sich mit diesem Schlüssel anmelden kann. Diese Datei listet alle öffentlichen Schlüssel auf, die zur Anmeldung berechtigt sind.
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
Aus Sicherheitsgründen erfordert SSH strenge Berechtigungen für das .ssh-Verzeichnis und seine Dateien. Stellen Sie sicher, dass diese korrekt gesetzt sind. Das Setup-Skript hat diese Dateien bereits mit den richtigen Berechtigungen erstellt, aber es ist gute Praxis, diese Befehle zu kennen.
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
Jetzt ist alles eingerichtet. Sie können die sichere Verbindung zu localhost testen. Der Befehl führt echo "Hello from SSH" auf dem entfernten Ende (was Ihre eigene Maschine ist) aus und gibt das Ergebnis aus.
ssh labex@localhost 'echo "Hello from SSH"'
Wenn Sie sich zum ersten Mal verbinden, werden Sie möglicherweise aufgefordert, den Fingerabdruck des Hosts zu überprüfen. Geben Sie yes ein und drücken Sie Enter. Anschließend sollten Sie die Ausgabe des Echo-Befehls sehen.
The authenticity of host 'localhost (127.0.0.1)' can't be established.
ED25519 key fingerprint is SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'localhost' (ED25519) to the list of known hosts.
Hello from SSH
Sie haben erfolgreich SSH für die sichere, schlüsselbasierte Authentifizierung konfiguriert und verwendet.
DNSSEC-Auflösung mit Dig überprüfen
In diesem Schritt verwenden Sie dig (Domain Information Groper), um DNS-Abfragen durchzuführen und mehr über DNSSEC (DNS Security Extensions) zu erfahren. DNSSEC schützt vor DNS-Spoofing, indem es kryptografische Signaturen zu DNS-Daten hinzufügt.
Zuerst führen wir eine Standard-DNS-Abfrage für labex.io durch, um dessen IP-Adresse zu ermitteln.
dig labex.io
Die Ausgabe zeigt Ihnen die Abfragedetails und, am wichtigsten, den ANSWER SECTION mit den A-Records (IP-Adressen). Beachten Sie, dass labex.io mehrere IP-Adressen für Load Balancing hat:
; <<>> DiG 9.18.24-0ubuntu0.22.04.1-Ubuntu <<>> labex.io
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9789
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;labex.io. IN A
;; ANSWER SECTION:
labex.io. 10 IN A 104.26.10.219
labex.io. 10 IN A 104.26.11.219
labex.io. 10 IN A 172.67.72.162
;; Query time: 0 msec
;; SERVER: 127.0.0.11#53(127.0.0.11) (UDP)
;; WHEN: Tue Aug 05 14:58:16 CST 2025
;; MSG SIZE rcvd: 85
Nun führen wir dieselbe Abfrage durch, bitten den DNS-Resolver jedoch, DNSSEC-bezogene Daten bereitzustellen, indem wir die Option +dnssec hinzufügen.
dig labex.io +dnssec
Die Ausgabe enthält zusätzliche DNSSEC-bezogene Informationen im OPT PSEUDOSECTION, die zeigen, dass DNSSEC angefordert wurde (das Flag do bedeutet "DNSSEC OK"). Beachten Sie jedoch, dass der Abschnitt flags kein ad (Authenticated Data) Flag enthält:
; <<>> DiG 9.18.24-0ubuntu0.22.04.1-Ubuntu <<>> labex.io +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1042
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 65494
; OPT=5: 05 07 08 0a 0d 0e 0f (".......")
; OPT=6: 01 02 04 ("...")
; OPT=7: 01 (".")
;; QUESTION SECTION:
;labex.io. IN A
;; ANSWER SECTION:
labex.io. 5 IN A 172.67.72.162
labex.io. 5 IN A 104.26.11.219
labex.io. 5 IN A 104.26.10.219
;; Query time: 0 msec
;; SERVER: 127.0.0.11#53(127.0.0.11) (UDP)
;; WHEN: Tue Aug 05 14:58:21 CST 2025
;; MSG SIZE rcvd: 108
Das Fehlen des ad-Flags zeigt an, dass zwar DNSSEC-Informationen angefordert wurden, der Resolver entweder die Signaturen nicht validieren konnte oder die Domain kein DNSSEC aktiviert hat.
Versuchen wir eine weitere bekannte Domain, die DNSSEC verwendet, icann.org, um dies erneut zu sehen.
dig icann.org +dnssec
Untersuchen Sie erneut den Header in der Ausgabe:
; <<>> DiG 9.18.24-0ubuntu0.22.04.1-Ubuntu <<>> icann.org +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54437
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 65494
; OPT=5: 05 07 08 0a 0d 0e 0f (".......")
; OPT=6: 01 02 04 ("...")
; OPT=7: 01 (".")
;; QUESTION SECTION:
;icann.org. IN A
;; ANSWER SECTION:
icann.org. 10 IN A 192.0.43.7
;; Query time: 72 msec
;; SERVER: 127.0.0.11#53(127.0.0.11) (UDP)
;; WHEN: Tue Aug 05 14:58:26 CST 2025
;; MSG SIZE rcvd: 77
Ähnlich wie bei der vorherigen Abfrage gibt es keine ad-Flag in der Antwort. Dies deutet darauf hin, dass der DNS-Resolver in dieser Umgebung keine DNSSEC-Validierung durchführt, was in containerisierten oder virtualisierten Umgebungen üblich ist, in denen der DNS-Resolver möglicherweise anders konfiguriert ist als ein Standard-Systemresolver.
Zusammenfassung
Herzlichen Glückwunsch zum Abschluss des Labs! Sie haben praktische Erfahrungen mit mehreren wichtigen Linux-Netzwerk- und Sicherheitstools gesammelt.
In diesem Lab haben Sie gelernt:
netstatundsszu verwenden, um zu überprüfen, welche Netzwerkdienste laufen und auf Verbindungen lauschen.- Live-Netzwerkpakete auf einer bestimmten Schnittstelle mit
tcpdumpzu erfassen, um den Datenverkehr zu analysieren. sshmit schlüsselbasierter Authentifizierung für sicheren Fernzugriff zu konfigurieren und zu verwenden.digzu nutzen, um das Domain Name System abzufragen und DNSSEC-Konzepte zu verstehen, einschließlich der Anforderung von DNSSEC-Informationen und der Interpretation der Ergebnisse.
Dies sind grundlegende Fähigkeiten, die für die Verwaltung, Fehlerbehebung und Sicherung jeder Linux-Umgebung unerlässlich sind. Wir ermutigen Sie, die vielen Optionen dieser leistungsstarken Tools weiter zu erkunden.
