PHP Handler Sicherheit entscheidet, wie stark Websites in Shared-Umgebungen voneinander getrennt sind und welche Angriffsflächen ein Webserver preisgibt; im direkten FPM-vs-CGI-Vergleich zählen vor allem Prozess-Isolation, Nutzerrechte und harte Limits. Ich zeige, warum FPM mit dedizierten Pools das Risiko senkt, während klassisches CGI zwar strikt isoliert, aber durch hohen Overhead Latenz und CPU-Last erzeugt.
Zentrale Punkte
- Isolation entscheidet über Angriffsfläche und Cross-Account-Risiken.
- FPM-Pools trennen Nutzer, setzen Limits und schützen Ressourcen.
- CGI isoliert stark, kostet jedoch CPU und Zeit pro Request.
- OPcache braucht getrennte Speichersegmente je Account.
- Shared Hosting profitiert von dedizierten FPM-Instanzen.
Wie PHP-Handler die Sicherheit formen
Jeder Handler verbindet Webserver und PHP-Interpreter, doch die Ausführung unterscheidet sich erheblich. mod_php lädt PHP direkt in den Webserver-Prozess; das liefert Tempo, aber teilt denselben Benutzerkontext und erhöht das Hosting-Risiko. CGI startet pro Anfrage einen neuen Prozess unter dem Ziel-User, wodurch Rechte sauber getrennt bleiben, jedoch mit spürbarem Overhead. FastCGI hält Prozesse am Leben und reduziert Startkosten, bietet aber erst mit FPM die feine Steuerung, die moderne Multi-User-Setups verlangen. Ich bevorzuge FPM, weil es pro Account eigene Pools, getrennte UIDs und scharfe Limits zulässt, ohne die Effizienz zu verlieren.
FPM vs CGI: Sicherheitsabgrenzung im Alltag
Im direkten Vergleich trennt CGI zwar strikt, doch FPM setzt die Trennung dauerhaft durch und hält Latenz gering. FPM-Pools laufen unter dem jeweiligen Account-User, isolieren Pfade und kapseln Ressourcen; so verhindert ein Exploit in Site A den Zugriff auf Site B. Zusätzlich begrenze ich mit memory_limit, max_execution_time und request_terminate_timeout die Wirkung fehlerhafter Skripte. CGI beendet zwar jeden Prozess nach der Anfrage, verschwendet aber CPU-Zeit beim ständigen Starten und Laden von Erweiterungen. In Shared-Umgebungen überwiegt daher FPM, idealerweise als dedizierter Pool pro Domain oder Projekt.
Isolation in Shared Hosting: Risiken und Gegenmittel
In geteilten Umgebungen entsteht das größte hosting risiko, wenn Accounts Ressourcen oder Rechte ungewollt teilen. Angreifer zielen auf schwache Dateirechte, fehlerhafte Temp-Verzeichnisse oder ungetrennte Caches. Mit dedizierten FPM-Pools pro Account kapsle ich Prozesse, Dateipfade, Logs und OPcache-Segmente. Ergänzend trenne ich Upload-Pfade und verhindere Symlink-Angriffe durch restriktive Mount-Optionen und saubere Owner-Modelle. Mehrstufige Prozess-Isolation mit chroot, CageFS oder Jails senkt die Wirkung eines Einbruchs erheblich, weil der Angreifer das Hostsystem nicht erreicht.
Ressourcensteuerung: Pools, Limits und Timeouts
FPM punktet, weil ich Ressourcen gezielt zuteile und so Misbrauch eindämme. Über pm.max_children begrenze ich gleichzeitige PHP-Prozesse, während pm.max_requests langlebige Worker nach X Anfragen neu startet, um Memory-Leaks abzufangen. request_terminate_timeout beendet Hänger, die sonst RAM binden würden, und schützt vor Bremsangriffen. Für Uploads setze ich post_max_size und upload_max_filesize so, dass normale Workflows laufen, aber gigantische Dateien nicht akzeptiert werden. In Kombination mit systemweiten cgroups für CPU und RAM bleibt der Host auch bei Lastspitzen reaktionsfähig.
Performance und Sicherheit im Zahlenvergleich
Ein direkter Vergleich der Handler macht die praktischen Unterschiede greifbar. Ich verwende die folgende Übersicht, um Entscheidungen zu treffen und Erwartungen zu kalibrieren. Die Werte beschreiben typische Tendenzen in realen Setups und zeigen, warum FPM in Shared-Hosting-Szenarien die erste Wahl darstellt. CGI priorisiert Härte durch Neustart, FPM balanciert Isolation und Geschwindigkeit, LSAPI glänzt bei LiteSpeed-Stacks. Wichtig bleibt: Isolation ohne Limits hilft wenig, Limits ohne Isolation ebenso.
| Handler | Performance | Sicherheit | RAM-Verbrauch | Isolation | Ideal für |
|---|---|---|---|---|---|
| mod_php | Hoch | Niedrig | Niedrig | Niedrig | Kleine, einfache Sites |
| CGI | Niedrig | Hoch | Hoch | Hoch | Tests, strikte Trennung |
| FastCGI | Mittel | Mittel | Mittel | Mittel | Übergangsphase |
| PHP-FPM | Sehr hoch | Hoch | Niedrig | Hoch | Shared Hosting, CMS |
| suPHP | Niedrig | Sehr hoch | Hoch | Sehr hoch | Maximale Dateisicherheit |
| LSAPI | Sehr hoch | Mittel | Sehr niedrig | Mittel | High-Traffic mit LiteSpeed |
Aus dieser Gegenüberstellung ziehe ich eine klare Konsequenz: Für Multi-User-Hostings liefert FPM die beste Gesamtsicherheit pro Leistungseinheit. CGI bleibt eine Option für Spezialfälle mit maximaler Trennung und wenig Requests. mod_php vermeide ich in Umgebungen mit mehreren Kundinnen und Kunden. LSAPI verdient Beachtung, wenn LiteSpeed eingesetzt wird und RAM äußerst knapp ist. In den meisten Szenarien überwiegen jedoch die Vorteile separater FPM-Pools mit klaren Grenzwerten.
Konfigurationsfallen: sichere Defaults für FPM-Stacks
Viele Einbrüche entstehen durch Fehlkonfiguration, nicht durch exotische Exploits. Zwei Schalter sind für mich Pflicht: Ich setze cgi.fix_pathinfo=0, um PATH_INFO-Traversalen zu vermeiden, und begrenze mit security.limit_extensions die ausführbaren Endungen (etwa .php,.php8,.phtml). In Nginx-Setups prüfe ich, dass SCRIPT_FILENAME korrekt gesetzt ist und keine Requests auf willkürliche Pfade durchrutschen. Zusätzlich deaktiviere ich selten benötigte Funktionen wie exec, shell_exec, proc_open und popen über disable_functions. Das ist kein Allheilmittel, aber reduziert die Wirkung einfacher Webshells deutlich. open_basedir nutze ich sehr selektiv: Es kann helfen, führt aber leicht zu Nebenwirkungen bei CLI-Jobs, Bildmanipulationsbibliotheken oder Composer. Besser ist konsistente Pfadtrennung pro Account und saubere Besitzerrechte.
Sessions, Uploads und temporäre Verzeichnisse richtig isolieren
Gemeinsame Temp-Pfade sind ein Klassiker für Privilege Escalation. Pro FPM-Pool definiere ich session.save_path und upload_tmp_dir in ein account-eigenes Verzeichnis unterhalb des Home, mit restriktiven Rechten und Sticky-Bit nur dort, wo nötig. noexec, nodev und nosuid auf den Mounts reduzieren die Angriffsfläche weiterer Stufen. Für Session-GC setze ich session.gc_probability/gc_divisor so, dass Dateien innerhalb des Accounts altern und gelöscht werden; globale Session-Buckets quer über User lehne ich ab. Wer Redis für Sessions nutzt, trennt Namespaces strikt und vergibt pro Account eigene Credentials und Limits. So verhindern wir, dass fehlerhafter Code Sessions anderer Projekte beeinflusst.
Socket-Design, Berechtigungen und systemd-Härtung
FPM-Pools kommunizieren über Sockets. Ich bevorzuge UNIX-Sockets für lokale Kommunikation und lege sie in ein account-eigenes Verzeichnis mit 0660 und passender Gruppe. Globale 0666-Sockets sind Tabu. Alternativ nutze ich TCP nur mit Bind auf 127.0.0.1 oder auf ein internes Interface und Firewalls. Auf Service-Ebene härtet systemd zuverlässig ab: NoNewPrivileges=true, ProtectSystem=strict, ProtectHome=true, PrivateTmp=true, CapabilityBoundingSet= (leer), Limits für MemoryMax, CPUQuota, TasksMax und LimitNOFILE. Damit sind viele Eskalationswege aus dem Weg geräumt, auch wenn eine Web-App-Schwachstelle getroffen wird. Ich platziere Pools zudem in eigene Slices, um laute Nachbarn zu dämpfen und Budgets durchzusetzen.
CLI, Cron und Queue-Worker: dieselbe Isolation wie im Web
Ein häufiger Blindspot: php-cli läuft nicht durch FPM. Deshalb starte ich Cronjobs, Indexer und Queue-Worker explizit als der zugehörige Account-User und verwende eine eigene php.ini pro Projekt (oder php_value-Overrides), die Limits, Extensions und open_basedir-Äquivalente spiegelt. Queue-Worker (etwa von gängigen CMS und Frameworks) bekommen dieselben RAM-/CPU-Budgets wie Webprozesse, inklusive Restart-Strategie bei Leaks. Für wiederkehrende Jobs setze ich Backoff und Rate-Limits, damit ein defekter Feed-Importer nicht den Host blockiert. Wichtig ist Parität: Was im Webpool verboten ist, sollte auf der CLI nicht plötzlich erlaubt sein.
Logging, Slowlogs und Backpressure
Sichtbarkeit entscheidet, wie schnell ich einen Angriff oder eine Fehlkonfiguration erkenne. Pro Pool schreibe ich eigene Error-Logs und aktiviere request_slowlog_timeout samt slowlog, um Stacktraces bei Hängern zu erhalten. log_limit verhindert, dass einzelne Requests Logs fluten. Mit pm.status_path und einem Ping-Endpunkt überwache ich Prozesse, Wartezeiten und Auslastung. Auf Webserver-Ebene setze ich Rate-Limits, Request-Body-Limits und Timeouts (Header- und Body-Read), damit Backends gar nicht erst in Überlast geraten. Eine WAF-Regelbasis kann zusätzlich triviale Angriffsvektoren abfangen; entscheidend bleibt aber, dass FPM die Angriffsfläche pro Account klein hält und Limits zuverlässig greifen.
Multi-PHP-Versionen und Erweiterungen sauber trennen
Gerade im Shared Hosting sind mehrere PHP-Versionen parallel üblich. Ich halte pro Version eigene FPM-Binaries, Extensions und Konfigurationen bereit und binde sie pro Account zu. Die Sockets landen in getrennten Verzeichnissen, sodass kein Versehen Requests in den falschen Pool leitet. OPcache bleibt je Version und je Account separiert; revalidate_freq und validate_timestamps setze ich bewusst je nach Release-Strategie. Beim JIT lasse ich Vorsicht walten: Er beschleunigt selten typische CMS-Workloads und erhöht die Komplexität – oft ist er deaktiviert die sicherere und stabilere Wahl. Extensions lade ich minimal; alles, was nicht zwingend nötig ist (z. B. pdo_mysql vs. ungenutzte Treiber), bleibt draußen.
Bedrohungsmodell: typische Angriffswege und Handler-Einfluss
In der Praxis sehe ich immer dieselben Muster: Datei-Uploads mit ausführbaren Endungen, unsichere Deserialisierung, unsaubere PATH_INFO-Weiterleitung, Local File Inclusion und Symlink-Tricks. FPM löst das nicht automatisch, aber es begrenzt die Reichweite: Ein kompromittierter Pool sieht nur seinen eigenen Namespace. Mit security.limit_extensions und korrekter Webserver-Konfiguration verhindere ich, dass Bilder-Uploads als PHP interpretiert werden. Getrennte Temp- und Session-Pfade unterbinden Cross-Account-Sessions und Tempfile-Rennen. Zusammen mit restriktiven Dateirechten, umask und noexec-Mounts sinkt die Erfolgsquote einfacher Exploits spürbar.
Dateirechte, Umask und Eigentümerkonzepte
Dateisysteme bleiben eine häufige Schwachstelle, wenn Rechte falsch gesetzt sind. Mit umask reguliere ich Standardrechte, sodass Uploads nicht global beschreibbar landen. suPHP oder FPM mit richtiger UID/GID-Zuordnung stellen sicher, dass der Script-Owner mit dem Dateieigentümer übereinstimmt. So verhindere ich, dass ein Fremdprozess Dateien verändert oder Logs ausliest. Zusätzlich sperre ich sensible Pfade, setze noexec auf /tmp-Mounts und reduziere Angriffsfläche durch konsequente Trennung von Schreib- und Lesepfaden.
OPcache sicher einsetzen
Caching bringt Tempo, doch ohne saubere Trennung erzeugt gemeinsamer Speicher Seiteneffekte. Für FPM-Pools halte ich OPcache je Account separat, damit Keys und Code nicht übergreifen. Ich aktiviere validate_timestamps im Entwicklungsmodus und senke es in Produktion nur bei stabilen Deployments, damit Code-Änderungen korrekt greifen. Zusätzlich prüfe ich file_cache nur innerhalb des Home-Verzeichnisses des Accounts, nicht global. Wer Shared-Memory nutzt, sollte die Shared-Memory-Risiken kennen und die Sichtbarkeit strikt begrenzen.
Webserver-Kombinationen: Apache, Nginx, LiteSpeed
Die Wahl des Frontends beeinflusst Latenz, TLS-Handshakes und Request-Handling spürbar. Apache mit mpm_event harmoniert gut mit FPM, wenn Keep-Alive und Proxy-Puffer stimmen. Nginx vor FPM überzeugt bei Static-Assets und kann Belastung wegschieben, während PHP nur dynamische Pfade erhält. LiteSpeed mit LSAPI liefert sehr niedrige Overheads, bleibt aber an ein anderes Ökosystem gebunden. In jedem Stack gilt: FPM-Pools sauber trennen, Limits definieren, Logs überwachen und Cache-Schichten bewusst konfigurieren.
Härtung: chroot, CageFS und Jails
Neben Handlern entscheidet die Betriebssystem-Isolation über die Wirkung eines Einbruchs. Mit chroot, CageFS oder Jails sperre ich den Account in ein eigenes Dateisystem-Universum. Damit verliert ein Angreifer Zugriff auf Host-Binaries und sensible Gerätepfade. Kombiniert mit FPM pro Account entsteht eine mehrschichtige Verteidigung, die auch bei Plugin-Schwächen in CMS-Systemen trägt. Wer Optionen vergleichen will, findet im PHP-Handler Vergleich wertvolle Orientierung zur Einordnung der Stacks.
Container, SELinux/AppArmor und realistische Erwartungen
Container und MAC-Frameworks wie SELinux oder AppArmor ergänzen FPM wirkungsvoll. Containerisieren hilft, Abhängigkeiten pro Projekt zu binden und den Root-Filesystem-Zugriff zu begrenzen. Ich halte Images minimal, entziehe unnötige Capabilities und mounte nur die wirklich benötigten Verzeichnisse. SELinux/AppArmor-Profile schränken Systemaufrufe ein und verhindern, dass ein Prozess außerhalb seines Kontextes wirkt. Wichtig bleibt: Container sind kein Ersatz für FPM-Isolation und saubere Dateirechte – sie bilden eine zusätzliche Schicht, die Fehler abfängt, nicht die Basis ersetzt.
Praxis-Checkliste für Hostende und Teams
In Projekten beginne ich mit einer klaren Reihenfolge: Erst trenne ich Accounts technisch, dann rolle ich FPM-Pools pro Domain aus. Anschließend setze ich Limits realistisch, messe Lastspitzen und passe pm.max_children sowie pm.max_requests an. Danach überprüfe ich Dateirechte, sichere Upload-Verzeichnisse und entferne unnötige Schreibrechte. OPcache konfiguriere ich pro Pool, damit Code, Sessions und Caches isoliert bleiben. Abschließend teste ich Failover: Ich simuliere Hänger, DoS-Muster und Out-of-Memory-Lagen, bis die Schutzmechanismen zuverlässig greifen.
Kurz zusammengefasst
Für mich steht fest: FPM bietet die beste Balance aus Sicherheit und Leistung, besonders im fpm vs cgi Vergleich. CGI bleibt nützlich, wenn absolute Trennung Vorrang vor Geschwindigkeit hat, doch FPM erreicht ähnliche Sicherheitsziele mit deutlich weniger Overhead. Dedizierte Pools, harte Limits und getrennte Caches reduzieren das hosting risiko in Shared-Umgebungen spürbar. Ergänzt durch Prozess-Isolation, saubere Dateirechte und kontrollierte OPcache-Nutzung setzt ein Host die entscheidenden Leitplanken. Wer diese Bausteine konsequent kombiniert, schützt Projekte wirksam und hält gleichzeitig die Antwortzeiten niedrig.
