1. Einleitung Grüße, der Post geht mal wieder in Richtung Infrastruktur statt „Crime“ und knüpft direkt an mein letztes Thema an. Dort ging es um WAFs mit ModSecurity. Problem: Wenn der Server selbst Müll ist, hilft die beste WAF nicht viel. Sobald jemand Initial Access hat, sind SQLi egal. Dann geht es um Privilege Escalations und Persistence, um den Server komplett zu übernehmen. Wichtig: Dieser Artikel ist vor allem für Leute relevant, die langfristig Infrastruktur betreuen – Marktplätze, Shops, SaaS (Suites, Mailer, weiß der Geier was). Wer nur ein paar Wochen ein Panel bei einem shady Russenhost laufen lässt, kann das hier ignorieren. Viele bauen fancy Shops, Bots oder self-hosten Projekte, denken aber, Security heißt nur: Cloudflare davor + Reverse Proxy, Auto-Updates, Firewall irgendwie aktiv. Ganz vergessen werden Filesystem-Rechte, SUID+GUID Bits, Logging, unnötige Services oder saubere Systemkonfiguration. 2. Warum System-Hardening wichtig ist Default-Linux ist nicht unsicher, aber generisch. Die meisten Images sind auf „läuft überall“ ausgelegt, nicht darauf, es Angreifern möglichst schwer zu machen. Genau hier setzen die CIS-Benchmarks vom Center for Internet Security an. Angriffe hören selten bei der ersten Lücke auf. Wer einmal drin ist, versucht, Rechte zu erhöhen, Persistenz aufzubauen und Daten auszuleiten. Default-Systeme sind dafür oft zu großzügig: unnötige Dienste laufen, Rechte sind zu weit, bekannte PrivEsc-Tricks funktionieren sofort. System-Hardening macht das Angreiferleben deutlich anstrengender: Es reduziert die Angriffsfläche, erschwert Privilege Escalations und macht Post-Exploitation auffälliger und aufwändiger. ^^ 3. Was sind die CIS Benchmarks? Die Benchmarks vom Center for Internet Security sind im Grunde eine Sammlung von konkreten Empfehlungen, wie ein System sicherer laufen sollte – basierend auf echten Angriffen und entwickelt mithilfe der Auswertung von Incident-Response-Berichten aus echten Breaches. Deshalb setzen Unternehmen, Behörden und Cloud-Provider sie weltweit ein und sie sind der De-facto-Industrie-Standard in Europa, wenn es um Infrastruktur-Hardening geht. Sie decken Dinge ab wie: SSH-Settings, Passwort- und Authentifizierungsrichtlinien, Logging, Netzwerk-, Rechte- und Filesystem-Hardening. Es gibt zwei für uns relevante Level: Level 1: solide Baseline, ohne viel kaputt zu machen (kann relativ gut auf bestehende Systeme angewendet werden, trotzdem vorher in der Testumgebung bitte testen) Level 2: restriktiver, eher für sensible Umgebungen Wer sich in das Thema mehr einlesen will, kann das hier machen : https://www.cisecurity.org/cis-benchmarks 4. System-Hardening Als erstes installieren wir uns alle Pakete, die wir benötigen. Ich mache das jetzt auf einem Debian 12. Solltet ihr ein anderes Linux verwenden, prüft bitte vorher hier, ob es bereits ein fertiges Ansible-Playbook für euer OS gibt. Aktuell unterstützt werden in der Free-Version: RHEL 7-9 Ubuntu 18-24 Debian 11-12 Windows 10-11 Windows Server 2016-2025 (wobei euch auch nicht mehr zu helfen ist, wenn ihr da auf ernst irgendwas Kritisches laufen habt ^^) RHEL 10 und Debian 13 werden mittelfristig ebenfalls kostenlos zur Verfügung gestellt werden. Bis es soweit ist, empfehle ich entweder Debian 12 zu nutzen oder Ubuntu 24 ohne SNAP. 4.2 Vorbereitung Nun zurück zu den Paketen, die ihr installieren müsst: Bash: apt install ansible git sshpass -y # Installiert das Konfigurationstool Ansible sowie die Abhängigkeit sshpass und einen Git-Client. Anschließend klonen wir das Debian-12-Ansible-Lockdown-Playbook, welches die Benchmarks auf unseren Server anwenden wird: Bash: git clone https://github.com/ansible-lockdown/DEBIAN12-CIS.git # Klont das Repository auf euren Server.
cd DEBIAN12-CIS # Gehe in das eben geklonte Repository 4.3 Das Playbook anwenden Um den Benchmark nun anzuwenden, erstellen wir in dem Verzeichnis DEBIAN12-CIS einfach eine hosts.ini mit dem folgenden Inhalt: Bash: [hardening] # Statt Hardening könnt ihr hier alles reinschreiben, das ist nur der Name der Hostgruppe, die gehärtet werden soll.
localhost ansible_connection=local Wenn ihr mehrere Server auf einmal härten wollt, klont ihr das DEBIAN12-CIS-Repo nicht auf euren Server, sondern auf euren Computer und legt eine hosts.ini an, die ungefähr so aussieht: Bash: [hardening]
169.40.CENSORED.CENSORED ansible_user=root
28.15.CENSORED.CENSORED ansible_user=root Jetzt setzen wir im DEBIAN12-CIS-Ordner den folgenden Befehl ab: Bash: ansible-playbook -i hosts.ini site.yml --tags level2-server
# > -i sagt Ansible, es soll unser Hardening-Playbook auf die Hosts anwenden, die wir in der hosts.ini angegeben haben.
# > site.yml initialisiert einfach das Playbook
# > --tags level2-server sagt, dass auf den Server Hardening Level 2 angewendet werden soll
# > --ask-pass (optional, wenn ihr Remote-Server konfiguriert und keine SSH-Schlüssel verwendet) 4.3 Probleme debuggen Wir werden beim Ausführen fast immer auf Probleme stoßen, wie auf diesem Screenshot ganz unten in Rot gut zu sehen ist. Der Fehler sagt uns, dass eine SSH-Hardening-Regel 5.1.8 nicht angewendet werden konnte, weil kein SSH-Server auf meinem Testserver installiert ist. Jetzt haben wir zwei Optionen, dieses Problem zu beheben: Wir installieren einen SSH-Server und die Benchmarks härten den für uns. Wir deaktivieren alle Regeln, welche versuchen, auf die Datei /etc/ssh/sshd_confi aus dem Bild zuzugreifen. Um alle Tasks zu identifizieren, welche versuchen werden, auf diese File zuzugreifen, öffnen wir die folgende File: Bash: nano tasks/section_5/cis_5.1.x.yml Auf welche File ihr jeweils zugreifen müsst, könnt ihr euch recht leicht erschließen. Der Task 5.1.8 wirft einen Fehler, also müsst ihr in den Ordner tasks/ gehen, dort section_5 und so weiter. Nun müsst ihr euch nur noch alle Tasks merken, die auf die besagte File versuchen zuzugreifen. Diese Tasks könnt ihr dann in dieser File deaktivieren: Bash: nano defaults/main.yml Wenn ihr dann alle Fehler behoben habt und das Playbook einmal durchgelaufen ist, habt ihr dasselbe Sicherheitsniveau auf diesem Server wie so gut wie alles, was in Deutschland unter KRITIS fällt (Banken, Strom, Bahn, ...). Wenn ihr ganz hart seid, richtet ihr noch einen Log-Server ein, der eure Audit-Logs entgegennimmt und euch auf Matrix oder TG live über komische Vorkommnisse auf eurem Server informiert. ^^ WICHTIG: Wendet so ein Hardening niemals auf eine Produktivumgebung an, ohne vorher ausführliche Tests in einer Testumgebung durchzuführen – die Gefahr, dass ihr etwas kaputt macht, ist real. Ihr werdet wahrscheinlich auf andere Fehler als ich stoßen, deaktiviert die Regel, die den Fehler wirft, einfach oder implementiert den Fix. Meistens geht aus dem Error oder der Tasks-File recht gut hervor, was das Problem ist. 5. Nachwort Ihr solltet natürlich nicht nur euer Linux härten, auf dem bspw. euer Shop läuft, sondern auch alle Software, die ihr nachträglich dazu installiert, wie z.B. Apache, Postgres etc. Glücklicherweise gibt es dafür auch fertige Benchmarks. ^^ Hoffe, der ein oder andere nimmt hier etwas mit und es ist halbwegs informativ. Der Text wurde mit der folgenden Prompt überarbeitet, da ich zu dumm zum Schreiben bin: „Entferne Rechtschreibfehler und formuliere so, dass es runder klingt“, das Fachliche stammt zu 100% aus meiner Feder. Falls jemand Fragen zu dem Thema hat, kann ich diese gerne im Detail beantworten. Freue mich auch über weitere Themenvorschläge. Habe bereits ein Paar Themen in der Pipeline wie: "FastFlux DIY", "Halbwegs Takedown sicher hosten", jetzt nichts super komplexes und NP ist es erst recht nicht aber vielleicht für den einen oder anderen Anfänger ganz hilfreich. ^^