Kurz gesagt: Ein IT-Inventar für Webserver ist eine Liste aller Websites, Portale, Shops und Server mit den Angaben, die man bei einer Sicherheitsmeldung sofort braucht: wo es läuft, mit welcher PHP-Version und Betriebsart, welche Anwendung, wer zuständig ist und welche Daten betroffen wären. Ohne diese Liste beginnt jede Reaktion mit Suchen. Mit ihr dauert der Abgleich bei einer Meldung wie PHP2Shell Minuten statt Tage.
Die erste Frage war: Wo läuft bei uns überhaupt PHP?
Als das PHP-Projekt am 21.10.2026 die Patches veröffentlichte und das BSI sofortiges Handeln empfahl, war die Anweisung eindeutig: PHP aktualisieren, alle Prozesse neu starten. Für viele Unternehmen war der erste Schritt trotzdem nicht das Update, sondern eine Inventur. Die Hauptwebsite war bekannt. Aber das Händlerportal? Die Karriereseite bei einem anderen Anbieter? Die Landingpage aus einer Kampagne vor drei Jahren? Das interne Wiki?
Die Fachpresse und Messdienste haben die Größenordnung des Problems sichtbar gemacht. Palo Alto Networks (Unit 42) zählte mehr als 22,6 Millionen exponierte, potenziell verwundbare Instanzen. Darunter dürften viele Systeme sein, an die ihre Betreiber schlicht nicht mehr denken.
Was in ein IT-Inventar für Webserver gehört
Ein brauchbares Inventar ist eine Tabelle mit einer Zeile je Website oder Anwendung. Diese Spalten haben sich bewährt:
| Spalte | Beispiel | Wozu |
|---|---|---|
| Adresse | shop.beispiel.de | eindeutige Zuordnung |
| Zweck und Bedeutung | Onlineshop, umsatzkritisch | Priorisierung |
| Hoster oder Standort | Managed Server bei Anbieter X | wen man anruft |
| Server und Betriebssystem | vServer, Debian | Updateweg, Sicherheitsquellen |
| Webserver und PHP-Betriebsart | Nginx mit PHP-FPM | Risiko, z. B. mod_php |
| PHP-Version und Paketstand | 8.3, Paket mit Datum | Abgleich mit Meldungen |
| Anwendung und Version | Shopware, Plugins | Herstellermeldungen |
| Zuständig intern / extern | IT-Leitung / Agentur Y | wer handelt |
| Verarbeitete Daten | Kundenkonten, Bestellungen | Meldepflichten, Dringlichkeit |
| Backups | täglich, extern, zuletzt getestet am … | Wiederherstellung |
| Letzter Patch-Nachweis | Datum und Beleg | Nachweis gegenüber Dritten |
Die Betriebsart verdient besondere Aufmerksamkeit. Bei PHP2Shell stufte das PHP-Team das Risiko bei Apache mit mod_php am höchsten ein. Wer weiß, welche Systeme so betrieben werden, kann sie zuerst angehen. Die Spalte zum Paketstand ist wichtig, weil die angezeigte Versionsnummer nach Backports oft gleich bleibt; Hinweise dazu stehen unter PHP-Version und Patchstand richtig prüfen.
Vergessene Systeme finden: so gehen Sie vor
Die bekannten Systeme sind schnell eingetragen. Die eigentliche Arbeit sind die unbekannten. Diese Quellen helfen, sie aufzuspüren:
- Domains und DNS: Alle Domains des Unternehmens und ihre Subdomains durchgehen. Jeder Eintrag, der auf einen Webserver zeigt, ist ein Kandidat.
- Rechnungen: Die Buchhaltung kennt jeden Hoster, Registrar und Cloud-Anbieter, der Geld bekommt. Das ist oft die vollständigste Liste.
- Agenturen und Fachabteilungen: Marketing, Vertrieb und Personal beauftragen Websites gern direkt. Fragen Sie nach.
- Bekannte Server: Auf jedem Server zeigt die Konfiguration, welche Websites er tatsächlich ausliefert.
- Geräte mit Weboberfläche: NAS, Router und Appliances bringen teils eigenes PHP mit, siehe PHP auf NAS, Routern und Appliances.
Für Schritt 4 helfen auf Linux-Servern einige lesende Befehle. Sie zeigen konfigurierte Websites, PHP-Dienste und FPM-Pools:
# Konfigurierte Websites (Apache bzw. Nginx)
apachectl -S 2>/dev/null
nginx -T 2>/dev/null | grep -E "^\s*server_name" | sort -u
# Laufende PHP-Dienste und Prozesse
systemctl list-units --type=service | grep -iE "php|fpm|lsws|litespeed"
ps -eo user,cmd | grep -E "php-fpm|php-cgi|lsphp" | grep -v grep | sort | uniq -c
# FPM-Pools unter Debian und Ubuntu
ls /etc/php/*/fpm/pool.d/ 2>/dev/null
Laufen auf einem Server mehrere PHP-Versionen nebeneinander, gehört jede in die Liste. Jede muss einzeln aktualisiert und neu gestartet werden.
Tragen Sie auch Systeme ein, die eigentlich abgeschaltet werden sollten. Gerade sie laufen oft noch, sind seit Jahren nicht aktualisiert und werden vergessen. Mit einem Eintrag „abschalten bis …“ bleibt die Aufgabe sichtbar.
Das Inventar aktuell halten
Ein Inventar ist nur so gut wie seine letzte Aktualisierung. Drei Regeln halten es lebendig. Erstens: Eine Person ist verantwortlich und wird bei jeder neuen Website, jedem Umzug und jeder Abschaltung informiert, auch wenn eine Agentur die Arbeit erledigt. Zweitens: Einmal im Quartal wird die Liste mit DNS, Rechnungen und Serverkonfiguration abgeglichen. Drittens: Das Inventar ist Teil des Notfallplans und liegt auch außerhalb der eigenen IT vor, etwa ausgedruckt.
Für Unternehmen mit vielen verteilten Systemen, etwa Händlerportalen, Konfiguratoren und Lieferantenzugängen, beschreibt IT-Sicherheit für Mittelstand und Industrie typische Fundstellen. Wie das Inventar in den Notfallplan eingebunden wird, steht unter IT-Notfallplan für Webserver erstellen.
Häufige Fehler beim Inventar von Webservern
Viele Inventare existieren, helfen im Ernstfall aber nicht. Die Ursachen ähneln sich:
- Nur Server, keine Websites: Die Liste nennt Maschinen, aber nicht, welche Websites darauf laufen und wer sie fachlich verantwortet. Bei einer Lücke weiß dann niemand, welche Abteilung betroffen ist.
- Version statt Paketstand: „PHP 8.3“ sagt nach PHP2Shell wenig. Erst Paketstand und Datum zeigen, ob die Korrektur enthalten ist.
- Externe Systeme fehlen: Was bei einer Agentur oder einem Plattformdienst läuft, wird weggelassen, weil man „dort nicht zuständig“ sei. Die Verantwortung für die Daten bleibt trotzdem im Haus.
- Keine Ansprechpartner: Ein Eintrag ohne Namen und Telefonnummer der zuständigen Stelle verliert im Notfall Zeit.
- Einmalige Aktion: Das Inventar wird in einer Krisenwoche erstellt und danach nie wieder geöffnet. Nach einem Jahr stimmt ein guter Teil nicht mehr.
Wer diese fünf Punkte vermeidet, hat bei der nächsten Meldung eine Liste, mit der sich tatsächlich arbeiten lässt.
Wie hilft PHP SOS konkret?
- Wir erfassen gemeinsam mit Ihnen alle Websites und Server, auch die vergessenen, über DNS, Rechnungen, Dienstleister und Serverkonfiguration.
- Wir ermitteln für jedes System Betriebsart, PHP-Version und tatsächlichen Paketstand.
- Wir priorisieren die Systeme nach Erreichbarkeit, Daten und Betriebsart und sagen, wo zuerst gehandelt werden muss.
- Wo PHP2Shell noch offen ist, schließen wir die Lücke über die PHP2Shell-Soforthilfe und tragen den Nachweis ins Inventar ein.
Fazit: Ein Inventar ist die unscheinbarste und zugleich wirksamste Sicherheitsmaßnahme. Wer weiß, was läuft, kann bei der nächsten Meldung sofort handeln, statt erst zu suchen.
Häufige Fragen
Welche Angaben braucht ein Inventar für Webserver mindestens?
Adresse der Website, Server oder Hoster, Betriebsart von PHP, PHP-Version mit Paketstand, Anwendung mit Version, verantwortliche Person intern und extern, Art der verarbeiteten Daten und Ort der Backups. Mit diesen Angaben lässt sich jede neue Sicherheitsmeldung schnell abgleichen.
Wie finde ich Websites, von denen niemand mehr weiß?
Über mehrere Wege zugleich: Domainverwaltung und DNS-Zonen, Rechnungen von Hostern und Registraren, Fragen an Agenturen und Fachabteilungen sowie die Konfiguration der bekannten Server. Alte Kampagnenseiten, Testsysteme und Subdomains tauchen so meist auf.
Wer sollte das Inventar pflegen?
Eine benannte Person, meist in der IT oder bei der IT-Leitung. Wichtig ist, dass jede Änderung an Websites und Servern dort gemeldet wird, auch wenn eine Fachabteilung oder Agentur sie veranlasst.
Reicht eine Tabelle oder braucht man eine Software?
Für die meisten mittelständischen Unternehmen reicht eine gut gepflegte Tabelle. Eine Software lohnt sich, wenn viele Systeme automatisch erfasst werden sollen. Entscheidend ist die Aktualität, nicht das Werkzeug.