Kurz gesagt: Ein CIS-Benchmark für Webserver liefert konkrete, versionsgenaue Einstellungen für Betriebssystem und Webserver, etwa für Ubuntu, Debian, RHEL, Nginx oder Apache. Die Bausteine des BSI-IT-Grundschutzes beschreiben dazu, welche Anforderungen an Webserver, Webanwendungen, Patch-Management und Protokollierung gelten. Zusammen ergeben sie eine prüfbare Härtungsvorgabe; PHP-spezifische Einstellungen ergänzen Sie selbst.
Warum „gut eingerichtet“ kein Maßstab ist
Nach einem Vorfall stellen Geschäftsführung, Versicherer oder Prüfer früher oder später dieselbe Frage: Nach welchem Standard war der Server eingerichtet? Die ehrliche Antwort lautet in vielen Unternehmen: nach bestem Wissen des Admins, der ihn damals aufgesetzt hat. Das ist nicht unbedingt schlecht, aber es ist weder nachvollziehbar noch wiederholbar.
PHP2Shell hat das sichtbar gemacht. Wer wissen wollte, welche Server betroffen sind, welche PHP-Betriebsart läuft und wann zuletzt gepatcht wurde, musste vielerorts erst einmal suchen. Ein Härtungsstandard ersetzt kein Update, schafft aber genau diese Ordnung: festgelegte Einstellungen, ein Inventar und regelmäßige Prüfungen.
Zwei Werke haben sich dafür bewährt: die CIS-Benchmarks des Center for Internet Security und der IT-Grundschutz des BSI.
Was ein CIS-Benchmark für Webserver enthält
CIS-Benchmarks sind konsensbasierte Konfigurationsempfehlungen, die Fachleute aus vielen Organisationen gemeinsam erarbeiten. Laut CIS gibt es sie für mehr als 25 Produktfamilien. Für PHP-Webserver sind vor allem diese relevant: Ubuntu Linux, Debian Linux und Red Hat Enterprise Linux für das Betriebssystem sowie Apache HTTP Server 2.4 und NGINX für den Webserver.
Jeder Benchmark ist eine Liste einzelner Empfehlungen mit Begründung, Prüfanweisung und Korrektur. Viele Benchmarks unterscheiden ein Grundprofil, das sich ohne große Nebenwirkungen umsetzen lässt, und ein strengeres Profil für höheren Schutzbedarf. Zur automatischen Prüfung bietet CIS Werkzeuge an, im Umfeld der Benchmarks unter dem Namen CIS-CAT.
Der Vorteil ist die Präzision: Statt „SSH absichern“ steht dort, welche Einstellung welchen Wert haben soll und wie Sie das prüfen. Der Nachteil ist der Umfang. Ein vollständiger Benchmark für ein Linux-System enthält sehr viele Punkte, und nicht jeder passt zu jedem Betrieb.
Achten Sie außerdem auf die Version. Benchmarks gelten jeweils für bestimmte Releases: Die CIS-Übersicht führt etwa getrennte Ausgaben für Ubuntu-LTS-Versionen bis 26.04, für Debian 9 bis 13 und für RHEL 8, 9 und 10. Wer einen Benchmark für eine ältere Version auf ein neues System anwendet, prüft teilweise Einstellungen, die es dort nicht mehr gibt, und übersieht neue. Läuft auf einem Server noch ein Betriebssystem ohne Herstellerunterstützung, ist das selbst schon der wichtigste Befund.
Die passenden BSI-Bausteine für PHP-Webserver
Der IT-Grundschutz des BSI arbeitet mit Bausteinen, die Anforderungen an Systeme und Abläufe beschreiben. Aktuell ist das IT-Grundschutz-Kompendium in der Edition 2023. Das BSI baut den IT-Grundschutz derzeit zu einem prozessorientierten, maschinenlesbaren Regelwerk um; das bisherige Kompendium bleibt laut BSI in einer mehrjährigen Übergangszeit anwendbar.
Für einen PHP-Webserver sind diese Bausteine am wichtigsten:
| Baustein | Inhalt | Bezug zum PHP-Webserver |
|---|---|---|
| APP.3.2 Webserver | Betrieb und Konfiguration des Webservers | Nginx, Apache, LiteSpeed |
| APP.3.1 Webanwendungen und Webservices | Anforderungen an die Anwendung | CMS, Shop, eigene PHP-Software |
| SYS.1.3 Server unter Linux und Unix | Betriebssystem-Härtung | Grundlage jedes Linux-Webservers |
| OPS.1.1.3 Patch- und Änderungsmanagement | geregeltes Einspielen von Updates | PHP-Updates, Neustarts, Nachweis |
| OPS.1.1.5 Protokollierung | Erfassen und Auswerten von Ereignissen | Zugriffs- und Fehlerprotokolle |
| CON.3 Datensicherungskonzept | Backups und Wiederherstellung | Sicherung von Code und Datenbank |
| CON.10 Entwicklung von Webanwendungen | sichere Entwicklung | eigene PHP-Projekte |
Der Grundschutz ist weniger konkret als ein CIS-Benchmark, deckt dafür aber Abläufe ab, die in keiner Konfigurationsdatei stehen: Wer patcht, wer prüft, wer wird informiert.
CIS oder BSI: Was passt zu Ihrem Unternehmen?
Die Wahl hängt weniger von der Technik ab als vom Umfeld. Eine Faustregel:
- Technische Basis für einzelne Server: CIS-Benchmark für Betriebssystem und Webserver, ergänzt um eine eigene PHP-Vorgabe.
- Öffentliche Verwaltung, Auftraggeber mit Grundschutz-Bezug, regulierte Bereiche: IT-Grundschutz als Rahmen, CIS-Benchmarks für die konkrete Umsetzung.
- Unternehmen mit ISO 27001 oder TISAX: Beide Werke eignen sich als technische Unterfütterung der eigenen Richtlinien, siehe ISO 27001 und TISAX: Was Webserver betrifft.
- Unternehmen, die unter NIS2 fallen: Ein dokumentierter Härtungsstandard hilft beim Nachweis angemessener Maßnahmen. Was die Richtlinie verlangt, fasst NIS2 und Webserver-Sicherheit zusammen; im Einzelfall entscheidet Ihre Rechtsberatung.
Für PHP selbst sollten Sie die Server-Vorgaben ergänzen: gesperrte Werte in der php.ini, getrennte FPM-Pools, keine Ausführung in Upload-Ordnern. Eine gute Grundlage bietet der Ratgeber php.ini sicher konfigurieren.
In sechs Schritten zur eigenen Härtungsvorgabe
Ein Standard nützt nur, wenn er im Betrieb ankommt. Bewährt hat sich dieses Vorgehen:
- Inventar anlegen: Welche Server, Betriebssysteme, Webserver und PHP-Versionen laufen wo?
- Benchmark und Bausteine auswählen, passend zu Version und Schutzbedarf.
- Ist-Zustand prüfen, möglichst automatisiert, und Abweichungen sammeln.
- Abweichungen bewerten: umsetzen, bewusst akzeptieren oder durch andere Maßnahmen ausgleichen, jeweils mit Begründung.
- Vorgabe festschreiben, idealerweise als Konfigurationsautomatisierung, damit neue Server von Anfang an gehärtet sind.
- Regelmäßig und nach größeren Updates erneut prüfen, denn neue Pakete bringen manchmal neue Standardwerte mit.
Schritt 6 verbindet die Härtung mit dem Patch-Prozess. Wie Sie Updates planbar statt hektisch einspielen, beschreibt Patch-Management als Prozess statt Feuerwehr.
Testen Sie strenge Profile zuerst auf einem Staging-System. Einige Empfehlungen, etwa zu Dateisystemen oder Netzwerkdiensten, können Anwendungen oder Fernzugriffe unterbrechen.
Wie hilft PHP SOS konkret?
- Wir erfassen Ihre Webserver und ordnen jedem den passenden CIS-Benchmark und die relevanten Grundschutz-Bausteine zu.
- Wir prüfen den Ist-Zustand und liefern eine priorisierte Liste der Abweichungen mit Aufwand und Nutzen.
- Wir ergänzen die Vorgabe um eine PHP-Basis für php.ini, FPM-Pools und Dateirechte.
- Wir dokumentieren bewusste Ausnahmen so, dass Prüfer und Versicherer sie nachvollziehen können.
Die Umsetzung übernehmen wir im Rahmen der Server-Härtung für PHP-Webserver.
Häufige Fragen
Muss ich jede Empfehlung eines CIS-Benchmarks umsetzen?
Nein. Benchmarks sind ein Maßstab, kein Gesetz. Manche Empfehlungen passen nicht zu Ihrem Betrieb oder würden Funktionen stören. Wichtig ist, Abweichungen bewusst zu entscheiden, zu begründen und zu dokumentieren.
Sind CIS-Benchmarks und IT-Grundschutz Konkurrenten?
Eher Ergänzungen. CIS-Benchmarks liefern konkrete Einstellungen je Produkt und Version. Der IT-Grundschutz beschreibt Anforderungen an Systeme und Prozesse, etwa Patch-Management und Protokollierung, und ordnet sie in ein Managementsystem ein.
Gibt es einen Härtungsstandard speziell für PHP?
PHP-Einstellungen sind in den gängigen Server-Standards meist nur am Rand enthalten. In der Praxis ergänzt man die Server-Vorgaben um eine eigene PHP-Basis, etwa für php.ini, FPM-Pools und Dateirechte, und orientiert sich für die Anwendung an den Bausteinen zu Webanwendungen.
Hätte ein CIS-Benchmark PHP2Shell verhindert?
Nein. PHP2Shell sind Lücken im PHP-Interpreter, gegen die nur das Update hilft. Ein gehärteter Server kann aber die Folgen eines Einbruchs begrenzen und durch ein geregeltes Patch-Management dafür sorgen, dass Updates schneller und nachweisbar eingespielt werden.
Ist der IT-Grundschutz für kleine Unternehmen zu groß?
Als vollständiges Managementsystem oft ja. Die einzelnen Bausteine lassen sich aber gut als Checkliste für Webserver und Webanwendungen nutzen, ohne gleich das gesamte Vorgehen zu übernehmen.