Härtung und Schwachstellen

Angriffe zu blockieren ist die halbe Arbeit; die andere Hälfte ist, zu schließen, was sie hereingelassen hat. Jeder Server führt 10 Minuten nach dem Start des Agenten eine Härtungsprüfung und ein Software-Audit aus, danach einmal am Tag. Jetzt prüfen und Software jetzt prüfen im Tab Sicherheit des Servers starten sie sofort.

Die Härtungsprüfung#

Sie prüft:

• SSH: Root-Login, Passwort-Authentifizierung, den Standardport, X11-Weiterleitung, maximale Authentifizierungsversuche;
• Dateien: die Berechtigungen von /etc/shadow, /etc/passwd, sshd_config und der authorized_keys von root;
• Ports: Dienste, die im öffentlichen Netz lauschen;
• Benutzer: Konten mit UID 0 außer root, Konten ohne Passwort;
• Firewall und Prozesse (Zombies);
• Zugangsdaten: für alle lesbare .env-Dateien, in Web-Roots offenliegende .git-Verzeichnisse, die Berechtigungen von .ssh-Verzeichnissen;
• Webserver: Preisgabe der Version, Verzeichnislisting, die TRACE-Methode, TLS-Protokolle, Sicherheits-Header, Rate Limiting, Größe des Request-Body und Performance-Einstellungen;
• Versionen: Betriebssystem am Ende seines Lebenszyklus, Kernel, ausstehende Sicherheitsupdates, PHP, MySQL, OpenSSH und der Webserver;
• PHP: die Konfiguration jeder PHP-Runtime und jedes PHP-FPM-Pools (siehe PHP-Härtung weiter unten).

Jede Prüfung erklärt, was sie ist, warum sie wichtig ist und wie du das Problem behebst.

Die SSH-Prüfungen lesen die Konfiguration, die sshd wirklich verwendet: sshd -T oder, wenn das nicht laufen kann, die Dateien in der Reihenfolge, in der sshd sie selbst liest (Agent 1.0.35 oder neuer). sshd behält den ersten Wert, den es liest, und auf aktuellen Distributionen bindet sshd_config die Drop-ins aus /etc/ssh/sshd_config.d/ ganz oben ein, also gewinnt ein Drop-in: Auf einem frischen Cloud-Server schaltet die 50-cloud-init.conf von cloud-init den Passwort-Login oft wieder ein. Der Befund nennt die Datei und die Zeile, die den Wert setzen, zum Beispiel /etc/ssh/sshd_config.d/50-cloud-init.conf:1: Ändere ihn dort.

Wie viele Prüfungen ein Server bekommt, hängt vom Server ab: auf den meisten 40 bis 50. Die Webserver-Prüfungen hängen davon ab, ob nginx, Apache oder beide installiert sind, und die PHP-Prüfungen (sechs bis neun) laufen für jede PHP-Runtime und jeden PHP-FPM-Pool: Ein Server mit vielen Pools bekommt also mehr.

Korrekturen per Klick#

Zehn Prüfungen lassen sich mit Automatisch beheben korrigieren:

InfraFence schreibt jede Änderung in eine eigene Datei (/etc/ssh/sshd_config.d/00-infrafence-hardening.conf oder zz-infrafence-hardening.conf für nginx und Apache), testet die Konfiguration (sshd -t, nginx -t, apachectl configtest) und lädt den Dienst neu: Offene Sitzungen und Verbindungen werden nicht unterbrochen. Korrektur rückgängig machen nimmt sie zurück.

Manche Prüfungen sind nie automatisch, weil sie dich bei falscher Umsetzung aussperren oder das Verhalten deiner Websites ändern könnten: Root-Login, Passwort-Authentifizierung, der SSH-Port, Verzeichnislisting, TLS-Protokolle und die Sicherheits-Header. Die Seite jeder dieser Prüfungen erklärt, wie du sie von Hand behebst. Auf einem Server, dessen Konfiguration ein Hosting-Panel oder ein Tool für Konfigurationsmanagement verwaltet, sind nur die Korrekturen von Berechtigungen automatisch.

PHP-Härtung#

Die Prüfung liest die effektive Konfiguration jeder PHP-Runtime auf dem Server: das PHP der Distribution, ondrej, remi, cPanel EA4, Plesk und CloudLinux alt-php. Sie folgt php.ini und dem Scan-Verzeichnis in der Reihenfolge von PHP und prüft jeden PHP-FPM-Pool mit seinen Überschreibungen per php_value und php_admin_value. Das Kommandozeilen-PHP wird nicht geprüft.

„Mit Freigabe“ erfordert Zwei-Faktor-Authentifizierung. Die Korrekturen für cgi.fix_pathinfo und disable_functions wendet nur ein Inhaber oder Administrator an, der mit Zwei-Faktor-Authentifizierung angemeldet ist: mit Prüfen und anwenden im Tab Sicherheit des Servers oder unter Freigaben, wenn AutoMode anfragt. Ohne 2FA wendet das Dashboard sie nicht an. Schalte sie unter Einstellungen › Sicherheit ein.

Jeder Befund nennt die Runtime, den Pool, den Wert und die Datei und Zeile, aus der er stammt. Bevor du eine Korrektur von disable_functions freigibst, listet das Dashboard die Website-Dateien auf, die diese Funktionen aufrufen (bis zu 20).

Korrekturen kommen in eine Datei, die InfraFence gehört, zz-infrafence-hardening.ini im Scan-Verzeichnis der Runtime; php.ini und deine Pool-Dateien werden nie bearbeitet. Setzt ein Pool den Wert in seiner eigenen Datei, kann ein Drop-in ihn nicht überschreiben: Der Befund nennt dann die genaue Zeile, die du in dieser Datei von Hand änderst. Der Agent testet die Konfiguration (php-fpm -t), prüft, dass der neue Wert der wirksame ist, lädt PHP-FPM sanft neu (nie ein Neustart) und führt dieselbe Website-Prüfung aus wie bei den anderen Korrekturen: Antwortet eine Website nicht mehr, wird die Änderung zurückgenommen. Eine Korrektur in der Datei der Runtime gilt für jeden Pool dieser Runtime, der den Wert nicht selbst setzt.

Der Agent überwacht diese Dateien auch. Wird allow_url_include oder display_errors eingeschaltet, nennt das Ereignis Riskante PHP-Einstellung aufgetaucht die Datei, einmal pro Änderung. Ändert jemand anderes die Datei von InfraFence (ein Panel, ein Paket, eine Person), erhältst du ebenfalls ein Ereignis.

Auf cPanel, Plesk und CloudLinux wird die PHP-Konfiguration gemeldet, nie geändert, und die Dateien pro Website (die php.ini von Plesk, die .user.ini von cPanel) werden nur gemeldet.

Das ist Härtung und Überwachung der Konfiguration. Nichts wird in PHP geladen, und ein Angriff innerhalb deiner Anwendung wird dadurch nicht gestoppt: Das übernehmen die Web-Firewall und der Malware-Scanner.

Prüfung und Rücknahme#

Vor einer Korrektur notiert der Agent, welche SSH-Ports Verbindungen annehmen und welche Websites ohne Serverfehler antworten, über HTTP und HTTPS (bis zu 20 Websites). Nach dem Neuladen prüft er sie bis zu 20 Sekunden lang erneut. Antwortet eine nicht mehr, nimmt er die Änderung selbst zurück, und das Ergebnis lautet Vom Server zurückgenommen. Korrekturen von Berechtigungen haben keine Rücknahme: Ein strengerer Modus macht keinen Dienst kaputt.

Dieselbe Prüfung schützt das Schließen von Ports, ausgehende Sperren und virtuelle Patches.

Schwachstellen (CVE)#

Das Software-Audit sendet die Liste der installierten Pakete an das Dashboard, das sie mit der Datenbank OSV abgleicht. Das funktioniert auf Debian, Ubuntu, AlmaLinux und Rocky Linux. Das Panel Schwachstellen (CVE) listet die Pakete auf, für die eine Korrektur verfügbar ist, und markiert die, die auf der CISA-Liste der bekanntermaßen ausgenutzten Schwachstellen stehen (Aktiv ausgenutzt (CISA KEV)): Aktualisiere diese zuerst.

Sicherheitsupdates#

Alle aktualisieren oder Dieses Paket aktualisieren installiert die korrigierten Versionen. Der Agent aktualisiert nur diese Pakete (es wird nichts Neues installiert oder entfernt), behält deine Konfigurationsdateien, startet nicht, solange ein anderer Paketvorgang läuft, und startet den Server nie neu. Das Upgrade eines Pakets kann dessen Dienst kurz neu starten. Wenn ein Neustart nötig ist oder ein Dienst noch alten Code ausführt, sagt das Ergebnis es dir.

Sicherheitswert#

Die Ergebnisse fließen in den Sicherheitswert des Servers ein, von 0 bis 100, mit den wichtigsten Korrekturen zuerst. Siehe Server.