Interviewfragen zu Linux Internals

Nein. Der ganze Bereich 127.0.0.0/8 ist für Loopback reserviert, also lösen 127.0.0.2, 127.1.1.1 und so weiter alle zum lokalen Host auf. Das ist wichtig für SSRF und das Umgehen von Allow-Lists — ein Angreifer kann 127.0.0.2 oder andere Kodierungen nutzen, um eine naive Prüfung „127.0.0.1 blockieren“ zu umgehen — und für das Binden mehrerer lokaler Dienste. (In IPv6 ist Loopback die einzelne Adresse ::1.)

Eine Lücke in lokalen Protokollen während eines Vorfalls kann gelöschte oder manipulierte Protokolle bedeuten, ein verbreiteter Anti-Forensik-Schritt, behandeln Sie die Abwesenheit von Protokollen also nicht als Abwesenheit von Aktivität. Gleichen Sie mit zentralen/weitergeleiteten Protokollen, EDR und Netzwerkdaten ab, die der Angreifer wahrscheinlich nicht ändern konnte, und halten Sie die Integritätslücke als Befund fest. Anzunehmen, der Server sei untätig gewesen, vertraut Beweisen, die der Angreifer möglicherweise kontrolliert, die Lücke als Beweis dafür zu nehmen, dass nichts geschah, ist genau die Schlussfolgerung, die er will, und weitere Protokolle zu löschen zerstört, was übrig ist. Bestätigen Sie stattdessen mit unabhängiger Telemetrie.

Linux-Persistenz versteckt sich in geplanten Ausführungs- und Startpfaden: cron und systemd-Timer/-Units, hinzugefügte SSH-authorized_keys, veränderte Shell-rc-Dateien und Profilskripte sowie trojanisierte Dienst-Binärdateien oder vorab geladene Bibliotheken. Prüfen Sie diese systematisch. Browserverlauf und Hintergrundbild-Einstellungen sind keine Persistenzmechanismen, und ein Neustart entfernt nichts, was sich beim Booten wiederherstellt — er startet es nur neu. Der ganze Sinn von Persistenz ist es, Neustarts zu überleben, daher beweist ein Neustart nichts.

Eine SUID-root-Binärdatei läuft mit Root-Rechten, und wenn sie für alle beschreibbar ist, kann ein Angreifer sie ersetzen oder verändern, um beliebigen Code als root auszuführen — ein klassischer Pfad zur lokalen Rechteausweitung. Entfernen Sie das SUID-Bit, korrigieren Sie Eigentümer und Berechtigungen und untersuchen Sie, wie die Fehlkonfiguration entstanden ist, da sie auf eine Kompromittierung hindeuten kann. Das Verschlüsseln der Datei lässt den ausführbaren Pfad intakt, und das Umbenennen verschiebt das Problem nur, ohne die Ausweitung zu beseitigen. Keine dieser Optionen behebt die Ursache.

Die Reihenfolge der Flüchtigkeit ordnet Beweise danach, wie schnell sie verschwinden, sodass man das Fragilste zuerst sichert. Grob: CPU-Register/Cache, dann RAM und Laufzeitzustand (Prozesse, Netzwerkverbindungen, ARP), dann temporäre Dateien/Swap, dann Disk, dann Remote-Logging und Überwachungsdaten, und zuletzt Archivmedien und Backups. Außerdem arbeitet man auf forensischen Kopien, hasht sie und führt eine Beweiskette, damit Beweise zulässig bleiben.

Unter Windows liegen die Hashes lokaler Konten (NTLM) in der SAM-Hive unter C:\Windows\System32\config\SAM, geschützt solange das OS läuft; lebende Anmeldedaten sitzen im LSASS-Speicher, und Domänen-Hashes liegen in NTDS.dit auf einem Domänencontroller. Unter Linux liegen Hashes in /etc/shadow (nur für root lesbar), während /etc/passwd Kontometadaten enthält. Angreifer stehlen diese, um Passwörter offline zu knacken oder Pass-the-Hash zu betreiben.

Man beginnt mit einem vollständigen TCP-Portscan und enumeriert dann jeden offenen Dienst gründlich — Banner, Versionen, Standardanmeldedaten, anonymer Zugriff und Webinhalte — bevor man irgendeinen Exploit anrührt. Die meisten Maschinen fallen durch gründliche Enumerierung, nicht durch clevere Exploits, was den Kern der „try harder“-Haltung ausmacht.

Enumeriere systematisch: prüfe sudo -l, SUID/SGID-Binaries, Cronjobs, die Kernel- und OS-Version, beschreibbare Dateien in privilegierten Pfaden, Capabilities und gespeicherte Anmeldedaten. Werkzeuge wie LinPEAS automatisieren den Durchlauf, aber du verifizierst jede Erkenntnis weiterhin anhand von GTFOBins oder einer bekannten Technik.

Bestimme den genauen Dienst und die Version, suche auf Exploit-DB oder mit searchsploit nach einem passenden PoC und lies dann den Code Zeile für Zeile, bevor du ihn ausführst — korrigiere die Ziel-IP, den Port und die Reverse-Shell-Adresse, generiere jeglichen Shellcode neu und verstehe, was er tut, damit er sich nicht gegen dich wenden kann.

Man startet ein Pseudoterminal (meist python -c 'import pty; pty.spawn("/bin/bash")'), legt es mit Ctrl-Z in den Hintergrund, führt lokal stty raw -echo aus, holt es wieder in den Vordergrund und setzt TERM sowie die Zeilen-/Spaltenzahl zurück. Das ergibt ein vollständiges TTY mit Jobsteuerung, Tab-Vervollständigung und funktionierenden Editoren.

Enumerieren Sie zuerst: aktuelle Rechte, sudo-Rechte, SUID/SGID-Binaries, Cron-Jobs, beschreibbare Dateien im PATH, Kernel-Version und gespeicherte Zugangsdaten. Nutzen Sie dann den einfachsten zuverlässigen Weg — oft eine fehlkonfigurierte sudo-Regel oder ein SUID-GTFOBin — bevor Sie zu einem Kernel-Exploit greifen.

Eine Bind Shell öffnet einen lauschenden Port auf dem Ziel und wartet, dass Sie sich verbinden. Eine Reverse Shell lässt das Ziel ausgehend zu einem von Ihnen kontrollierten Listener verbinden. Reverse Shells gewinnen meist, weil ausgehender Verkehr eingehende Firewall-Regeln und NAT umgeht.

Angriffsfläche reduzieren (ungenutzte Pakete/Dienste entfernen), SSH nur per Schlüssel und ohne Root-Login erzwingen, das System gepatcht halten, eine Default-Deny-Firewall betreiben, die nur nötige Ports freigibt, geringste Rechte über sudo und Dateirechte durchsetzen, auditd und zentrales Logging aktivieren sowie Integritätsüberwachung plus ein MAC wie SELinux oder AppArmor ergänzen.