Härtung für Hoster #

Diese Seite ist für Systemadministratoren und Sicherheitsverantwortliche eines Hosters, die die Server-Vorlage bauen, aus der jede Exponential-Website angelegt wird. Sie geht die Schichten einer Website von außen nach innen durch, sagt, was Exponential standardmäßig tut, und nennt die Einstellung oder den Befehl, die der Hoster setzt oder prüft. Sie folgt der Reihenfolge von Kapitel 13 des Installationsbuchs, das jedes Detail enthält, und der Sicht Bedrohung für Bedrohung von Sicherheitshärtung.

Warnung .htaccess bremst jede Anfrage. Sind .htaccess-Dateien erlaubt (AllowOverride alles außer None), geschweige denn genutzt, sucht Apache sie bei jeder Anfrage in jedem Verzeichnis des Pfads und liest und wertet sie aus, und die Ladezeiten der Seiten steigen drastisch (gemessen). Die einzige wirkliche Abhilfe ist, die Funktion für den virtuellen Host abzuschalten: AllowOverride None im virtuellen HTTPS-Host, und die Regeln in der Konfiguration des virtuellen Hosts selbst als mod_rewrite-Regeln. Das ist in Geschwindigkeitstests im Produktivbetrieb weit schneller und die Zeit für die Optimierung einer Produktivkonfiguration unbedingt wert. Stellen Sie sofort um: Übernehmen Sie die Regeln des Beispiels für einen virtuellen HTTPS-Host in Ihren virtuellen Host (mit dem statischen Cache auch staticcache_offload.conf), setzen Sie AllowOverride None, führen Sie apachectl configtest aus, laden Sie Apache neu und testen Sie die Website. Dieselben Regeln für andere Server: nginx, LiteSpeed, Caddy, IIS, Velocity (eingebaut); wohin Regeln für virtuelle Hosts in einem Control Panel gehören: Plesk, cPanel, DirectAdmin, ISPConfig. Unter LiteSpeed oder OpenLiteSpeed kann zusätzlich der Seiten-Cache des Servers anonyme Besucher und Crawler ohne PHP bedienen: Seiten-Caching mit LiteSpeed und OpenLiteSpeed.

Hinweis Einstellungen werden in Überschreibungen geändert, nie in den mitgelieferten Dateien: settings/override/<file>.ini.append.php für die ganze Installation, settings/siteaccess/<siteaccess>/<file>.ini.append.php für einen Siteaccess. Leeren Sie nach einer Änderung den INI-Cache (php bin/php/ezcache.php --clear-tag=ini), und führen Sie unter Velocity exp:velocity deploy aus (Kapitel 13).

Inhalt #

1. Die Prinzipien
2. Ausgelieferte Dateien
3. Geheimnisse
4. Debug-Ausgabe
5. Administration, Passwörter und Sitzungen
6. Header, TLS und Proxys
7. Dateien, Benutzer und Prozesse
8. Beobachten
9. Ein Schutz davor
10. Updates
11. Checkliste für die Server-Vorlage

Die Prinzipien #

Sicherheitshärtung misst Exponential an der Arbeitsweise von OpenBSD: standardmäßig sicher, geringste Rechte, Trennung von Rechten, minimale Angriffsfläche, Audit und Korrektur nach vorn. Für einen Hoster heißt das vor allem eine Regel: Lockern Sie keinen Standard, damit etwas funktioniert; finden Sie die Ursache. Ein Support-Ticket, das damit endet, dass die Rewrite-Regel ausgeschaltet wurde, hat auf dieser Website eine Lücke geöffnet.

Ausgelieferte Dateien #

Der Document Root von Exponential ist das Wurzelverzeichnis der Installation, sodass settings/, var/, vendor/ und die SQLite-Datenbank darin liegen. Die Sicherheit kommt vom Routing: Nur eine feste Liste von Asset-Pfaden wird als Dateien ausgeliefert, alles andere geht an index.php (13.2).

Prüfen Sie nach jeder Änderung der Konfiguration des Webservers von außen:

for p in /.git/config /.env /settings/site.ini /composer.json /kernel/classes/ezini.php /var/log/error.log; do
  printf '%-32s %s\n' "$p" "$(curl -s -o /dev/null -w '%{http_code}' https://example.com$p)"
done

Jede Zeile muss 404 zeigen, oder 200 mit einer Exponential-Seite und nie dem Inhalt der Datei. Details zu Webservern: Einen Webserver wählen und Kapitel 8.

Geheimnisse #

settings/override/ enthält das Datenbankpasswort (site.ini.append.php), die Signatur- und Pseudonymschlüssel des Audits (audit.ini.append.php), das Website-Geheimnis der E-Mail-Einstellungen (mailpreferences.ini.append.php, das auch den Passwort-Stempel der Sitzung schlüsselt) und, wenn gesetzt, das Token des Dashboards von Velocity (13.3).

• Modus 0640 oder strenger, nie in der Versionsverwaltung, nie an einem öffentlichen Ort.
• Sichern Sie es als Geheimnis, verschlüsselt, mit der Datenbank (Was gesichert werden muss).
• Kopieren Sie es bei jedem Umzug der Website mit. Eine Kopie ohne mailpreferences.ini.append.php erzeugt ein neues Website-Geheimnis: Alte Abmeldelinks passen nicht mehr, und jeder Benutzer wird einmal abgemeldet.
• Entfernen Sie kickstart.ini und var/log/initial-admin-password nach der Bereitstellung (Erste Anmeldung und Standardpasswörter).

config.php im Wurzelverzeichnis der Installation kann das Passwort der Cluster-Datenbank enthalten (CLUSTER_STORAGE_PASS). Behandeln Sie sie wie settings/override/:

• Modus 0640 mit der Gruppe des Webservers (chmod 0640 config.php); spätere Änderungen mit exp:config:set behalten diesen Modus. Ein Geheimnis in einer für alle Benutzer lesbaren config.php erzeugt eine WARN:-Zeile.
• Nie in der Versionsverwaltung: /config.php gehört in die .gitignore des Projekts (das Repository von Exponential enthält nur config.php-RECOMMENDED).
• Die Konsole maskiert die Werte von Namen mit PASS, SECRET, KEY, TOKEN, CREDENTIAL oder PWD als ********; --show-secrets zeigt sie, fügen Sie solche Ausgaben also nicht in ein Ticket ein.
• exp:setup:* und exp:config:* sichern jede Datei, die sie ersetzen oder ändern, nach var/backup/setup/<zeit>/ oder var/backup/config/<zeit>/ (Verzeichnisse 0700, von den Befehlen nie gelöscht). Schützen Sie var/backup/ mit und räumen Sie es auf (.htaccess und config.php von der Konsole einrichten).

Debug-Ausgabe #

[DebugSettings] DebugOutput=disabled und [TemplateSettings] Debug=disabled werden ausgeschaltet ausgeliefert. Lassen Sie sie aus. Wenn der Support eine Live-Website debuggen muss, beschränken Sie es auf die Adresse des Support-Desks und entfernen den Eintrag wieder:

# settings/override/site.ini.append.php
[DebugSettings]
DebugOutput=enabled
DebugByIP=enabled
DebugIPList[]
DebugIPList[]=203.0.113.10

In der php.ini oder im Pool von PHP-FPM: display_errors=Off, log_errors=On, expose_php=Off (13.4). Hinter einem Proxy ist DebugByIP nur so verlässlich wie TrustedProxies[] (siehe TLS und HTTPS).

Administration, Passwörter und Sitzungen #

Eine Passwortänderung meldet jede andere Sitzung dieses Benutzers ab ([PasswordSettings] EndOtherSessions=enabled). Lassen Sie es an: Das macht eine Passwortänderung nützlich, nachdem ein Konto übernommen wurde.

Header, TLS und Proxys #

Fünf Sicherheitsheader gehen auf jeder Seite hinaus (X-Content-Type-Options, X-Frame-Options, Content-Security-Policy: frame-ancestors 'self', Referrer-Policy, Permissions-Policy); HSTS ist aus, bis es eingeschaltet wird. Apache und nginx fügen statischen Dateien von sich aus nichts hinzu. Der Teil des Hosters:

• HTTPS auf jedem Namen, HTTP umgeleitet, HSTS erhöht, sobald alles funktioniert: TLS und HTTPS.
• Die volle Richtlinie (script-src, style-src) ist in der Auslieferung auf der Administration im Berichtsmodus: Content Security Policy.
• Hinter einem Load Balancer, CDN oder Proxy eines Panels: Führen Sie genau Ihre Proxys in site.ini [HTTPHeaderSettings] TrustedProxies[] auf (Velocity: Q.webserver.proxy.trusted), und stellen Sie sicher, dass der Anwendungsserver nicht an ihnen vorbei erreichbar ist (13.10).

Dateien, Benutzer und Prozesse #

Wenn der PHP-Prozess nur var/ und settings/ ändern kann und der Webserver sich weigert, irgendetwas unterhalb der Wurzel auszuführen, kann eine Schwachstelle in einer Erweiterung keinen Code einschleusen (13.11).

• Ein Benutzer schreibt: PHP-FPM-Pool, Velocity-Worker, Cronjobs und Konsolenskripte laufen als Benutzer der Website.
• Der Code (kernel/, lib/, vendor/, index.php) gehört einem anderen Benutzer und ist für den Benutzer der Website nur lesbar.
• Keine für alle beschreibbaren Dateien. Die mitgelieferten Werte in [FileSettings] sind 0777 und 0666; setzen Sie die gehärteten:

# settings/override/site.ini.append.php
[FileSettings]
StorageDirPermissions=0770
StorageFilePermissions=0660
TemporaryPermissions=0770
LogFilePermissions=0660

• TemporaryDir wird als /tmp/ ausgeliefert, mit jedem Benutzer der Maschine geteilt; geben Sie jeder Website ein eigenes unter var/.
• Velocity: [ServerSettings] Host=127.0.0.1, wenn ein Proxy davor ist, User und Group auf den Benutzer der Website gesetzt, AllowRootWorkers=disabled, Token des Dashboards und Passwort des Kontrollzentrums gesetzt oder die Ansichten lokal gehalten (13.12).

Wie das auf viele Kunden skaliert: Benutzer und Pools pro Kunde und Beschreibbare Verzeichnisse und Berechtigungen.

Beobachten #

Härtung ohne Beobachtung verzögert nur den Moment, in dem Sie von einem Angriff erfahren.

Führen Sie die Cronjob-Gruppe frequent aus, damit die Alarmregeln des Audits laufen, leiten Sie das Protokoll mit einer Senke von der Maschine weg und lesen Sie security.log wöchentlich (Sicherheitshärtung).

Ein Schutz davor #

Request Shield, eine kleine Web Application Firewall für PHP vom CJW Network, weist Scanner und Fluten ab, bevor der Kernel startet. Seit 6.0.15 ist er Teil der Standardinstallation: Die Erweiterung exp_request_shield bringt ihn mit, und eine Hook-Zeile in config.php führt ihn aus, wie installiert durchsetzend, unter PHP-FPM und Velocity gleichermaßen. Eine aktualisierte Installation trägt die Hook-Zeile selbst in config.php ein, da ein Update diese Datei nie überschreibt. Ein Hoster kann ihn auf jeder Website unter Setup > Request Shield prüfen und seine Abstimmung als Teil eines verwalteten Tarifs anbieten: request-shield und Request-Regeln, Request Shield.

Updates #

Nur die Linie 6.0 erhält Sicherheitskorrekturen, veröffentlicht als nächstes Release 6.0.x. Verfolgen Sie Releases, aktualisieren Sie zuerst eine Kopie, prüfen Sie nach jedem Update die Konsistenz der Dateien, und halten Sie auch PHP, den Datenbankserver, das Betriebssystem und die Engine von Velocity aktuell: Sicherheitsupdates und Offenlegung.

Checkliste für die Server-Vorlage #

• To do: Rewrite-Regeln: eine aktuelle Kopie von .htaccess_root, der abgeleitete nginx-Block oder Velocity; die Prüfung von außen liefert keine Datei.
• To do: SOAP nur, wo ein Kunde es braucht: index_soap.php durchgelassen (vor 6.0.15 hieß es soap.php) und auf die Adressen der Aufrufer beschränkt; soap.php abgelehnt, sobald es niemand mehr aufruft (Das SOAP-Einstiegsskript heißt jetzt index_soap.php).
• To do: settings/override/ mit Modus 0640 oder strenger, außerhalb der Versionsverwaltung, verschlüsselt gesichert.
• To do: config.php mit Modus 0640, außerhalb der Versionsverwaltung; var/backup/ geschützt und aufgeräumt.
• To do: Die Bereitstellung entfernt kickstart.ini und var/log/initial-admin-password und hinterlässt nie ein bekanntes Passwort.
• To do: DebugOutput=disabled; PHP display_errors=Off, expose_php=Off.
• To do: Administration auf einem eigenen Hostnamen, eingeschränkt durch Netzwerk, VPN oder die Browserprüfung des Schutzes.
• To do: CheckValidity=false, AllowWizardOnInstalledSite=disabled.
• To do: ezformtoken aktiv; EndOtherSessions=enabled.
• To do: HTTPS auf jedem Namen, HTTP umgeleitet, CookieSecure=true, HSTS erhöht, sobald es stabil ist.
• To do: TrustedProxies[] nennt genau Ihre Proxys oder bleibt beim Standard Loopback.
• To do: Ein Benutzer des Betriebssystems pro Website; Code für ihn nur lesbar; gehärtete [FileSettings]; eigenes TemporaryDir.
• To do: Velocity hinter einem Proxy an 127.0.0.1 gebunden; Worker nie als root.
• To do: Cronjob-Gruppe frequent läuft als Benutzer der Website; Empfänger der Alarme des Audits geprüft; eine Senke konfiguriert.
• To do: Eine Routine für Updates mit benannten Verantwortlichen.

Die Go-Live-Liste Einstellung für Einstellung ist 13.16; die wiederkehrende Prüfung ist die Checkliste für die Sicherheitsprüfung.

Der Demomodus bleibt aus. EXP_DEMO_MODE=1 installiert und behält ein bekanntes Administratorpasswort; setzen Sie es nur für den eigenen Pool, virtuellen Host oder die eigene Unit einer öffentlichen Demo, nie serverweit oder in einer Vorlage, und lösen Sie bei Zeilen demo/mode in security.log von Kunden-Websites einen Alarm aus. Demomodus für Hoster.

Verwandte Seiten #

• Sicherheit für Hoster: Überblick
• Sicherheitshärtung
• Kapitel 13: Sicherheitshärtung für die Produktion
• Checkliste für einen neuen Server
• Kompromittierte Website
• .htaccess und config.php von der Konsole einrichten
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.