PHP unter Windows Server und IIS sicher betreiben: php.ini härten Schritt für Schritt

PHP läuft auf Windows Server zuverlässig – vorausgesetzt, es ist richtig eingebunden und abgesichert. In der Praxis finden sich aber immer wieder XAMPP-Installationen auf Produktivservern, Fehlermeldungen mit vollständigen Pfaden im Browser, beschreibbare Webverzeichnisse und eine php.ini, die seit Jahren niemand angesehen hat. Dieser Beitrag zeigt Schritt für Schritt, wie Sie PHP unter IIS sicher betreiben: von der richtigen Architektur über NTFS-Rechte und eine gehärtete php.ini bis zu den IIS-Einstellungen und einem Prüfskript für den Soll-Ist-Vergleich.

Hintergrund: Was CVE-2024-4577 gelehrt hat

Im Juni 2024 wurde mit CVE-2024-4577 eine kritische Lücke in PHP unter Windows bekannt. Über die Windows-Zeichenkonvertierung „Best-Fit“ konnten Angreifer ohne Anmeldung Befehlszeilenargumente an php-cgi.exe einschleusen und so beliebigen Code ausführen – eine Umgehung des Schutzes gegen die alte Lücke CVE-2012-1823. Betroffen war vor allem PHP im klassischen CGI-Modus, wie er etwa bei XAMPP unter Windows mit Apache verwendet wird. Angriffsversuche wurden innerhalb von 24 Stunden beobachtet, und die Ransomware-Gruppe TellYouThePass nutzte die Lücke kurz darauf aktiv aus. Behoben wurde sie in PHP 8.3.8, 8.2.20 und 8.1.29.

Die Lehren daraus sind die Grundlage dieses Beitrags:

• PHP nie im CGI-Modus betreiben, sondern unter IIS über FastCGI.
• XAMPP und vergleichbare Entwicklungspakete gehören nicht auf Server.
• Nur unterstützte PHP-Versionen einsetzen und Updates zeitnah einspielen.
• Die Folgen einer Lücke durch minimale Rechte begrenzen.

Die Zielarchitektur

Schritt 1: IIS und PHP installieren

# IIS mit CGI/FastCGI, Request Filtering und Management-Tools
Install-WindowsFeature Web-Server, Web-CGI, Web-Filtering, Web-Http-Logging, `
    Web-Http-Redirect, Web-Mgmt-Console, Web-Scripting-Tools

# PHP-Verzeichnisse anlegen (ZIP vorher prüfen und nach C:\PHP\8.4 entpacken)
New-Item -ItemType Directory -Path C:\PHP\8.4, C:\PHP\temp, C:\PHP\logs, C:\PHP\sessions -Force | Out-Null
Copy-Item C:\PHP\8.4\php.ini-production C:\PHP\8.4\php.ini

# FastCGI-Anwendung registrieren
Import-Module WebAdministration
$php = 'C:\PHP\8.4\php-cgi.exe'
Add-WebConfiguration -Filter 'system.webServer/fastCgi' -Value @{
    fullPath = $php; instanceMaxRequests = 10000; activityTimeout = 600; requestTimeout = 120
}
Add-WebConfiguration -Filter "system.webServer/fastCgi/application[@fullPath='$php']/environmentVariables" -Value @(
    @{ name = 'PHP_FCGI_MAX_REQUESTS'; value = '10000' },
    @{ name = 'PHPRC'; value = 'C:\PHP\8.4' }
)

# Handler nur für die Site, die PHP braucht – nicht global auf Serverebene
New-WebHandler -PSPath 'IIS:\Sites\Intranet' -Name 'PHP_via_FastCGI' -Path '*.php' -Verb 'GET,HEAD,POST' `
    -Modules FastCgiModule -ScriptProcessor $php -ResourceType File

Schritt 2: NTFS-Rechte nach dem Minimalprinzip

Der wichtigste Schutz gegen die Folgen einer Lücke ist, dass PHP fast nichts schreiben darf. Die folgenden Befehle verwenden SIDs statt Gruppennamen und funktionieren deshalb auf deutschen und englischen Servern gleichermaßen (S-1-5-32-544 = Administratoren, S-1-5-18 = SYSTEM, S-1-5-32-568 = IIS_IUSRS).

# PHP-Programmverzeichnis: nur lesen und ausführen
icacls C:\PHP\8.4 /inheritance:r /grant:r "*S-1-5-32-544:(OI)(CI)F" "*S-1-5-18:(OI)(CI)F" "*S-1-5-32-568:(OI)(CI)RX"

# Temp-, Sitzungs- und Logverzeichnisse: nur der jeweilige Anwendungspool darf schreiben
foreach ($d in 'C:\PHP\temp','C:\PHP\sessions','C:\PHP\logs') {
    icacls $d /inheritance:r /grant:r "*S-1-5-32-544:(OI)(CI)F" "*S-1-5-18:(OI)(CI)F" "IIS AppPool\Intranet:(OI)(CI)M"
}

# Webinhalt: Anwendungspool nur lesen
icacls D:\Web\Intranet /inheritance:r /grant:r "*S-1-5-32-544:(OI)(CI)F" "*S-1-5-18:(OI)(CI)F" "IIS AppPool\Intranet:(OI)(CI)RX"

# Ausnahme: Upload-Verzeichnis beschreibbar – dort aber KEINE Skriptausführung (siehe Schritt 4)
icacls D:\Web\Intranet\uploads /grant "IIS AppPool\Intranet:(OI)(CI)M"

Schritt 3: Die php.ini härten

Ausgangspunkt ist immer php.ini-production, die bereits sichere Grundwerte enthält. Die folgende Tabelle zeigt die sicherheitsrelevanten Direktiven, ihren Zielwert und den Grund.

Informationspreisgabe und Fehlerbehandlung

Entfernte Inhalte und Dateisystem

Ressourcen und Uploads

Sitzungen (Sessions)

IIS- und FastCGI-spezifische Werte

Leistung und Zeitzone

; --- Auszug php.ini (Produktivsystem, IIS) ---
expose_php = Off
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = "C:\PHP\logs\php_errors.log"
error_reporting = E_ALL
zend.exception_ignore_args = On

allow_url_include = Off
allow_url_fopen = Off
open_basedir = "D:\Web\Intranet;C:\PHP\temp;C:\PHP\sessions"
disable_functions = exec,passthru,shell_exec,system,proc_open,popen,show_source
upload_tmp_dir = "C:\PHP\temp"
sys_temp_dir = "C:\PHP\temp"

file_uploads = On
upload_max_filesize = 16M
post_max_size = 20M
max_file_uploads = 10
max_execution_time = 30
max_input_time = 60
memory_limit = 256M

session.save_path = "C:\PHP\sessions"
session.use_strict_mode = 1
session.use_only_cookies = 1
session.use_trans_sid = 0
session.cookie_httponly = 1
session.cookie_secure = 1
session.cookie_samesite = "Lax"

cgi.force_redirect = 0
cgi.fix_pathinfo = 1
fastcgi.impersonate = 1
fastcgi.logging = 0

date.timezone = "Europe/Berlin"
mail.add_x_header = Off

extension_dir = "C:\PHP\8.4\ext"
; nur benötigte Erweiterungen aktivieren, z. B.:
extension=curl
extension=mbstring
extension=openssl
extension=pdo_mysql

zend_extension=opcache
opcache.enable = 1
opcache.memory_consumption = 128
opcache.max_accelerated_files = 10000
opcache.validate_timestamps = 1
opcache.revalidate_freq = 60

Schritt 4: IIS absichern

Keine Skriptausführung im Upload-Verzeichnis

Das häufigste Muster bei kompromittierten Webanwendungen: Ein Angreifer lädt über ein Upload-Formular eine Datei bild.php hoch und ruft sie anschließend auf. Verhindern Sie das mit einer eigenen web.config im Upload-Verzeichnis:

<?xml version="1.0" encoding="UTF-8"?>
<!-- D:\Web\Intranet\uploads\web.config -->
<configuration>
  <system.webServer>
    <handlers accessPolicy="Read">
      <remove name="PHP_via_FastCGI" />
    </handlers>
    <security>
      <requestFiltering>
        <fileExtensions allowUnlisted="true">
          <add fileExtension=".php" allowed="false" />
          <add fileExtension=".phtml" allowed="false" />
          <add fileExtension=".phar" allowed="false" />
        </fileExtensions>
      </requestFiltering>
    </security>
  </system.webServer>
</configuration>

Request Filtering und Header für die Site

<?xml version="1.0" encoding="UTF-8"?>
<!-- D:\Web\Intranet\web.config (Auszug) -->
<configuration>
  <system.webServer>
    <security>
      <requestFiltering removeServerHeader="true" allowDoubleEscaping="false">
        <requestLimits maxAllowedContentLength="20971520" />
        <fileExtensions allowUnlisted="true">
          <add fileExtension=".ini" allowed="false" />
          <add fileExtension=".inc" allowed="false" />
          <add fileExtension=".bak" allowed="false" />
          <add fileExtension=".sql" allowed="false" />
          <add fileExtension=".log" allowed="false" />
          <add fileExtension=".env" allowed="false" />
        </fileExtensions>
        <hiddenSegments>
          <add segment=".git" />
          <add segment="vendor" />
          <add segment="config" />
        </hiddenSegments>
        <verbs allowUnlisted="false">
          <add verb="GET" allowed="true" />
          <add verb="HEAD" allowed="true" />
          <add verb="POST" allowed="true" />
        </verbs>
      </requestFiltering>
    </security>
    <httpProtocol>
      <customHeaders>
        <remove name="X-Powered-By" />
        <add name="X-Content-Type-Options" value="nosniff" />
        <add name="X-Frame-Options" value="SAMEORIGIN" />
        <add name="Referrer-Policy" value="strict-origin-when-cross-origin" />
        <add name="Strict-Transport-Security" value="max-age=31536000" />
      </customHeaders>
    </httpProtocol>
    <directoryBrowse enabled="false" />
    <httpErrors errorMode="DetailedLocalOnly" />
  </system.webServer>
</configuration>

HTTPS und TLS

Ohne HTTPS sind session.cookie_secure und HSTS wirkungslos. Binden Sie ein gültiges Zertifikat an die Site, leiten Sie HTTP auf HTTPS um und deaktivieren Sie auf Serverebene veraltete Protokolle wie TLS 1.0/1.1 und schwache Cipher Suites über die Schannel-Konfiguration.

Schritt 5: Konfiguration prüfen

Ein Soll-Ist-Vergleich gehört nach jeder Änderung und jedem Update dazu. Das folgende Skript liest die wirksamen Werte mit derselben php.ini aus und meldet Abweichungen:

$phpDir = 'C:\PHP\8.4'
$soll = [ordered]@{
    'expose_php'='';            'display_errors'='';        'log_errors'='1'
    'allow_url_include'='';     'allow_url_fopen'=''
    'session.use_strict_mode'='1'; 'session.cookie_httponly'='1'; 'session.cookie_secure'='1'
    'session.use_only_cookies'='1'; 'cgi.force_redirect'='0';     'zend.exception_ignore_args'='1'
}
# PHP-Code ohne doppelte Anführungszeichen, damit Windows PowerShell 5.1 nichts verschluckt
$code = 'foreach ($argv as $i => $k) { if ($i) echo $k, ''='', ini_get($k), PHP_EOL; }'
$ist = & "$phpDir\php.exe" -c "$phpDir\php.ini" -r $code -- @($soll.Keys) |
       Out-String | ConvertFrom-StringData

foreach ($k in $soll.Keys) {
    $ok = ($ist[$k] -eq $soll[$k]) -or ($soll[$k] -eq '' -and $ist[$k] -in '', '0', 'Off')
    '{0,-28} Soll: {1,-4} Ist: {2,-4} {3}' -f $k, $soll[$k], $ist[$k], ($(if ($ok) {'OK'} else {'ABWEICHUNG'}))
}

# disable_functions und open_basedir zusätzlich anzeigen
& "$phpDir\php.exe" -c "$phpDir\php.ini" -r 'echo ini_get(''disable_functions''), PHP_EOL, ini_get(''open_basedir'');'

# Header von außen prüfen: X-Powered-By und Server dürfen nicht erscheinen
(Invoke-WebRequest -Uri 'https://intranet.firma.local/' -Method Head -UseBasicParsing).Headers

Schritt 6: Betrieb, Protokolle und Updates

• Protokolle auswerten: PHP-Fehlerprotokoll und IIS-Protokolle regelmäßig sichten, auf Spitzen bei Fehler 404/500 und auf Aufrufe nicht existierender .php-Dateien achten – ein typisches Zeichen für Scans.
• Log-Rotation: php_errors.log wächst unbegrenzt. Per geplanter Aufgabe archivieren oder kürzen.
• Updates: Sicherheitsankündigungen auf php.net verfolgen. PHP-Updates unter Windows erfolgen nicht über Windows Update, sondern manuell oder per Softwareverteilung.
• Update-Verfahren: Neue Patchversion parallel entpacken, php.ini übernehmen, FastCGI-Pfad umstellen, testen, alte Version entfernen.
• Webanwendungen aktuell halten: Die beste php.ini schützt nicht vor einer Lücke im CMS oder Plugin.

Fallstricke aus der Praxis

Compliance-Bezug

• BSI IT-Grundschutz: APP.3.2 Webserver (sichere Konfiguration, Schutz vor unerlaubtem Zugriff, keine Informationspreisgabe), APP.3.1 Webanwendungen und Webservices, SYS.1.2.3 Windows Server sowie OPS.1.1.3 Patch- und Änderungsmanagement.
• NIS2: Art. 21 Abs. 2 der NIS2-Richtlinie verlangt angemessene technische Maßnahmen, u. a. zur Sicherheit bei Erwerb, Entwicklung und Wartung von Systemen sowie zum Umgang mit Schwachstellen.
• CIS Controls v8: Control 4 (Secure Configuration of Enterprise Assets and Software) und Control 7 (Continuous Vulnerability Management).
• OWASP: Die Härtung adressiert direkt Kategorien der OWASP Top 10 wie „Security Misconfiguration“.

Fazit

PHP auf Windows Server ist kein Sicherheitsrisiko an sich – riskant sind CGI-Betrieb, Entwicklungspakete auf Produktivsystemen, veraltete Versionen und zu großzügige Rechte. Mit FastCGI und NTS-Build, eigenen Anwendungspools, restriktiven NTFS-Rechten, einer gehärteten php.ini, Request Filtering und einem festen Update-Verfahren erreichen Sie ein Niveau, das auch einer Prüfung nach IT-Grundschutz standhält. Planen Sie für die Umsetzung pro Anwendung einen halben Tag inklusive Test ein – und prüfen Sie die Werte nach jedem Update erneut mit dem Skript.

Quellen: PHP-Handbuch – Installation unter IIS · PHP-Handbuch – php.ini-Direktiven · php.net – Supported Versions · The Hacker News – CVE-2024-4577 · Microsoft Learn – IIS Request Filtering