Einführung
Sicherheitswerkzeuge können lange Ausgaben mit Notizen, wiederholten Beobachtungen und Diagnosemeldungen erzeugen. Ein nützliches Ergebnis ist eine kleine Menge relevanter Befunde, deren Herkunft du verstehst.
In diesem Lab übst du mit einer bereitgestellten Textdatei, bevor du ein Scan-Werkzeug ausführst. Du liest ihren Inhalt, filterst und deduplizierst Datensätze offener Dienste, zählst sie und hältst Fehler von nützlichen Ausgaben getrennt.
Eine vorbereitete Ausgabedatei lesen
In diesem Schritt prüfst du eine vorbereitete Textdatei auf mehrere Arten, bevor du Befunde extrahierst. Das sind Beispieldaten und keine Ausgabe eines Scans, den du ausführen musst.
Öffne die vorbereitete Kali-Shell:
kali
Wähle das gemeinsame Arbeitsverzeichnis über einen absoluten Pfad:
cd /home/labex/project
Die Datei observations.txt enthält kurze Zeilen, die mit NOTE, OPEN oder CLOSED beginnen. OPEN bedeutet hier, dass die Beispielbeobachtung einen Dienst als offen aufführt; es beweist keine Schwachstelle. Gib die vollständige kleine Datei aus:
cat observations.txt
Du siehst wiederholte Zeilen offener Dienste sowie Notizen und Zeilen geschlossener Dienste. Die Quelle zuerst zu lesen hilft, einen Filter zu wählen, der die vorgesehenen Informationen bewahrt.
Bei einer langen Datei zeigt less jeweils eine Seite an, ohne die Datei zu ändern:
less observations.txt
Bewege dich bei Bedarf mit den Pfeiltasten und drücke dann q, um zur Shell zurückzukehren. Das Beispiel passt auf einen Bildschirm; derselbe Pager funktioniert auch für größere Werkzeugausgaben.
head liest den Anfang einer Datei, tail ihr Ende. Die Option -n legt die Zahl angezeigter Zeilen fest. Prüfe die ersten drei Zeilen:
head -n 3 observations.txt
Erwartete Ausgabe:
NOTE supplied training observations
OPEN training-web:8080 http
CLOSED training-db:5432 postgresql
Prüfe jetzt die letzten beiden Zeilen:
tail -n 2 observations.txt
Die letzte Zeile lautet NOTE end of sample. Speichere die dreizeilige Vorschau mit dem im ersten Lab eingeführten Operator >:
head -n 3 observations.txt > preview.txt
cat preview.txt
Die Vorschau sollte dieselben drei Zeilen wie oben enthalten. Du hast die Quelle unversehrt gelassen und eine nützliche Ansicht davon gespeichert.
Befunde filtern, sortieren und Wiederholungen entfernen
In diesem Schritt baust du eine Pipeline, die Datensätze offener Dienste behält und Duplikate entfernt.
Bleibe in Kali und kehre zum gemeinsamen Arbeitsbereich zurück:
cd /home/labex/project
grep gibt passende Zeilen aus. Das Muster unten steht in einfachen Anführungszeichen, damit die Shell es wörtlich übergibt. Der Anker ^ bezeichnet den Zeilenanfang, und das Leerzeichen nach OPEN trennt den Datensatztyp von seinen Daten:
grep '^OPEN ' observations.txt
Die Ausgabe enthält jede Beobachtung eines offenen Dienstes, einschließlich wiederholter Zeilen. Notizen und CLOSED-Zeilen fehlen.
Das Pipe-Symbol | verbindet die Standardausgabe eines Befehls mit der Standardeingabe des nächsten. sort ordnet Zeilen so, dass identische Zeilen nebeneinanderstehen:
grep '^OPEN ' observations.txt | sort
Die wiederholten Zeilen sind nun gruppiert. uniq entfernt benachbarte identische Zeilen. Wenn doppelte Zeilen getrennt vorkommen können, gehört es deshalb hinter die Sortierung:
grep '^OPEN ' observations.txt | sort | uniq
Erwartete Ausgabe:
OPEN training-dns:5353 dns
OPEN training-ssh:2222 ssh
OPEN training-web:8080 http
Jeder Befehl hat eine Aufgabe: Datensätze auswählen, ordnen und Wiederholungen zusammenfassen. Speichere den resultierenden Datenstrom in einer separaten Ausgabedatei:
grep '^OPEN ' observations.txt | sort | uniq > open-services.txt
cat open-services.txt
Du solltest dieselben drei eindeutigen Datensätze sehen. Die Umleitung betrifft die endgültige Ausgabe der Pipeline; die ursprünglichen Beobachtungen werden nicht bearbeitet.
Ergebnisse zählen und Fehlerausgaben trennen
In diesem Schritt zählst du die ausgewählten Befunde und unterscheidest normale Ausgaben von einer Fehlermeldung.
Beginne im gemeinsamen Arbeitsbereich:
cd /home/labex/project
wc zählt Text. Seine Option -l zählt durch Zeilenumbrüche abgeschlossene Zeilen. Da die gespeicherte Datei einen Befund pro Zeile enthält, entspricht die Anzahl der Zahl unterschiedlicher Datensätze offener Dienste:
wc -l open-services.txt
Die Ausgabe meldet 3 und den Dateinamen; Abstände können abweichen. Eine Pipeline liefert Text ohne Dateinamenargument. So lässt sich bequem nur die Anzahl speichern:
cat open-services.txt | wc -l > finding-count.txt
cat finding-count.txt
Der Wert ist 3, möglicherweise mit führenden Leerzeichen.
Programme senden nützliche Daten normalerweise an die Standardausgabe und Diagnosemeldungen an die Standardfehlerausgabe. Der Shell-Operator > leitet die Standardausgabe um; 2> dagegen die Standardfehlerausgabe. Lies zur Veranschaulichung eine absichtlich fehlende Datei und speichere ihre Diagnosemeldung. Der nächste Befehl soll fehlschlagen, weil missing-observations.txt nicht existiert. Das ist eine beabsichtigte Demonstration; fahre danach fort:
cat missing-observations.txt 2> read-error.txt
Auf dem Bildschirm sollte nichts erscheinen, weil die Fehlermeldung in read-error.txt gelandet ist. Prüfe diese separate Diagnosemeldung:
cat read-error.txt
Die Meldung nennt missing-observations.txt und erklärt, dass die Datei nicht gelesen werden kann, weil sie nicht existiert. Deine tatsächlichen Befunde bleiben getrennt:
cat open-services.txt
Die drei gültigen Datensätze bleiben unverändert. Getrennte Diagnosemeldungen verhindern, dass eine Fehlermeldung mit einem Werkzeugbefund verwechselt wird.
Zusammenfassung
Du hast Text mit cat, less, head und tail gelesen, Zeilen mit grep ausgewählt, eine Pipeline mit sort und uniq aufgebaut, Datensätze mit wc gezählt und Ausgabe- sowie Fehlerumleitung verwendet. Diese Fähigkeiten machen aus umfangreichen Werkzeugausgaben kleine, überprüfbare Ergebnisse.
