Checkliste für die Sicherheitsprüfung #

Diese Checkliste ist für den Sicherheitsprüfer oder Systemadministrator des Hosters. Nutzen Sie sie, bevor eine Website live geht, nach einem Sicherheitsvorfall und mindestens einmal im Quartal. Die Gründe für jeden Punkt stehen auf Sicherheitshärtung und in Kapitel 13 des Installationsbuchs; die Sicht des Hosters steht auf Härtung für Hoster.

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.

Site: <domain>        Reviewer: <name>        Date: <date>        Reason: <go-live | incident | quarterly>

Versionen #

• To do: Exponential ist auf dem neuesten Release 6.0.x, oder der Abstand ist mit einem Datum zum Schließen dokumentiert. Nur die Linie 6.0 erhält Sicherheitskorrekturen (SECURITY.md).
• To do: Erweiterungen sind auf aktuellen Releases.
• To do: PHP und das Betriebssystem erhalten Sicherheitsupdates.

Konten #

• To do: Kein Standard- oder gemeinsames Administratorpasswort (Das Standard-Administratorpasswort).
• To do: Administratoren nutzen die zweistufige Anmeldung, wo der Kunde zugestimmt hat (Zweistufige Anmeldung).
• To do: Jedes Konto mit Rechten in der Administration gehört einer benannten Person, die es noch braucht.
• To do: Anonymous hat keine Richtlinien über das hinaus, was die öffentliche Website braucht.

Einstellungen und ausgelieferte Dateien #

• To do: Die Debug-Ausgabe ist auf öffentlichen Siteaccesses aus.
• To do: Nur die Asset-Pfade werden als Dateien ausgeliefert; settings/, var/log, var/cache und Quelldateien sind aus dem Web nicht erreichbar. Testen Sie es: Eine Anfrage nach einer Datei unter settings/ darf sie nicht liefern.
• To do: Der Setup-Assistent bleibt geschlossen: settings/override/site.ini.append.php hat [SiteAccessSettings] CheckValidity=false (Kapitel 13, Erste Anmeldung und Standardpasswörter).
• To do: Uploads werden unter var/ gespeichert und nicht als PHP ausgeführt.

Transport und Header #

• To do: Überall HTTPS, Zertifikat gültig, HTTP leitet um (TLS und HTTPS).
• To do: Die Content Security Policy wird in der Administration durchgesetzt und erzeugt keine unerwarteten Meldungen (Content Security Policy).
• To do: Die Administration ist wie vereinbart über das Netzwerk oder einen zweiten Faktor eingeschränkt (Die Administration einschränken).

Logs und Erkennung #

• To do: security.log wird geschrieben und durchgesehen (Sicherheitslog).
• To do: Hinter einem Proxy oder Load Balancer ist TrustedProxies[] konfiguriert, sodass die Logs die echten Client-Adressen sehen (Sicherheitshärtung).
• To do: Über einen Schutz vor der Website entschieden: request-shield oder die Request-Regeln des Kernels (request-shield und Request-Regeln).
• To do: Das Prüfprotokoll ist an und für den Prüfer lesbar (Prüfprotokoll).

Abschottung und Geheimnisse #

• To do: Die Website läuft als eigener Systembenutzer, mit eigenem PHP-FPM-Pool oder eigener Velocity-Instanz (Trennung von Mandanten).
• To do: settings/override und Backups, die es enthalten, sind nur für den Benutzer der Website und das Backup-System lesbar.
• To do: Keine Geheimnisse in Git-Repositories, Tickets oder geteilten Ordnern.
• To do: Der Datenbankbenutzer der Website erreicht nur die Datenbank der Website.

Backups und Wiederherstellung #

• To do: Backups sind außerhalb der Maschine gespeichert und können nicht aus dem Konto der Website gelöscht werden.
• To do: Eine Wiederherstellung wurde innerhalb des vereinbarten Zeitraums getestet (Wiederherstellung und Wiederherstellungstests).

Offenlegung #

• To do: Ihr Team weiß, wie es eine Schwachstelle in Exponential vertraulich meldet, wie SECURITY.md es beschreibt (Sicherheitsupdates und Offenlegung).
• To do: Ihr eigenes Verfahren für Vorfälle ist aktuell (Kompromittierte Website).

Demomodus.

• To do: grep -r EXP_DEMO_MODE über die PHP-FPM-Pools, virtuellen Hosts, .htaccess-Dateien, systemd-Units und Drop-ins, Crontabs, /etc/environment und Container-Definitionen findet nur die Konfiguration öffentlicher Demos; keine Produktions-Website hat eine Zeile demo/mode in security.log oder ein Audit-Ereignis system.demo.mode (Demomodus für Hoster).

Verwandte Seiten #

• Zusammenfassung der Sicherheitsprüfung für Führungskräfte
• Checkliste für den monatlichen Betrieb
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.