Die Administration einschränken #

Diese Seite ist für Systemadministratoren bei einem Hoster und für Support-Mitarbeitende, die die Website eines Kunden einrichten. In der Administration werden Inhalte veröffentlicht, Rollen vergeben und Einstellungen geändert; die Anmeldung (/user/login, /admin/user/login) ist die am meisten angegriffene Adresse jeder Website (Sicherheitshärtung). Die Referenz ist 13.5 Der Siteaccess der Administration.

Inhalt #

1. Was standardmäßig vorhanden ist
2. Ein eigener Hostname
3. Einschränkungen im Netzwerk
4. Eine Browserprüfung davor
5. Geringste Rechte
6. Konfiguration aus der Versionsverwaltung
7. Der Setup-Assistent bleibt geschlossen
8. Checkliste

Was standardmäßig vorhanden ist #

• Die Administration ist ein eigener Siteaccess (meist admin). Der Installer schreibt [SiteAccessSettings] RequireUserLogin=true in dessen site.ini.append.php, sodass jede Seite eine Anmeldung verlangt.
• Der Zugriff auf jede Funktion wird durch Rollen und Richtlinien entschieden (setup/*, content/*, audit/* ...).
• Die Anmeldung kostet für einen unbekannten Anmeldenamen genauso viel wie für ein falsches Passwort und verrät also nicht, welche Konten existieren.
• Die Alarmregeln des Audits brute_force (20 Fehlschläge aus einem Netzwerk in 5 Minuten) und brute_force_user (10 für ein Konto in 15 Minuten) melden Angriffe (Prüfprotokoll).

Ein eigener Hostname #

Geben Sie der Administration einen eigenen Hostnamen, zum Beispiel admin.example.com, zugeordnet über [SiteAccessSettings] HostMatchType, statt eines Pfads unterhalb der öffentlichen Website. Sie lässt sich dann als Einheit einschränken: eigener virtueller Host, eigenes Zertifikat, eigene Firewall-Regel. Für Hoster macht das auch den Support einfacher: Die Redakteure des Kunden kennen eine Adresse, und Cache und CDN der öffentlichen Website sehen nie Verkehr der Administration.

Einschränkungen im Netzwerk #

Von der stärksten zur einfachsten, pro Webserver:

<Location />
    Require ip 203.0.113.0/24 2001:db8::/48
</Location>

Hinter einem Proxy ist die Adresse, die Exponential sieht, die des Proxys, es sei denn, TrustedProxies[] ist gesetzt; eine Einschränkung im Proxy selbst vermeidet diese Frage (TLS und HTTPS).

Hinweis Kunden mit Redakteuren, die reisen oder von zu Hause arbeiten, haben vielleicht kein festes Netzwerk. Dann passt ein VPN oder die Browserprüfung unten besser als eine Liste von Adressen. Vereinbaren Sie es mit dem Kunden und schreiben Sie es in die Dokumentation der Website.

Eine Browserprüfung davor #

Die Exponential-Beispiele von request-shield stellen eine Browserprüfung vor das Anmeldeformular und die Administration, durchsuchen jeden Parameter nach Angriffen und können die Administration auf ein Netzwerk beschränken (EXP-ADMIN-NET). Die Hintergrundanfragen der Administration (das Mega-Menü von Admin 4) bekommen eine maschinenlesbare Antwort statt einer Prüfseite. Wählen Sie die Hauptregeldatei nach Aufbau: exponential-admin-uri.rules für /admin auf demselben Host, exponential-admin-host.rules für einen eigenen Host der Administration. Siehe request-shield und Request-Regeln.

Geringste Rechte #

Geben Sie Redakteuren die Rollen, die sie brauchen, nicht Administrator. Richtlinien, die für die Sicherheit zählen (13.5):

Ein persönliches Konto pro Person, und admin als Anmeldung stillgelegt (Kontenpflege). Auch die eigenen Support-Mitarbeitenden des Hosters sollten persönliche Konten haben, mit ihrem Arbeitsverhältnis angelegt und entfernt, nie eine geteilte Support-Anmeldung.

Konfiguration aus der Versionsverwaltung #

Mit [ConfigurationSettings] ManagedByDeployment=enabled auf einem Siteaccess der Administration in der Produktion kann die Administration den Setup-Assistenten nicht ausführen, keine Einstellungen oder Templates bearbeiten, keine Erweiterungen aktivieren und keine Pakete installieren (Konfiguration, die vom Ausrollen verwaltet wird). Nutzen Sie es, wo Einstellungen und Templates aus Git kommen: Eine gestohlene Sitzung eines Administrators kann dann weder Code noch Konfiguration ändern.

Der Setup-Assistent bleibt geschlossen #

Auf einer installierten Website zeigt setup/init nur „Diese Website ist bereits installiert“ und schreibt nichts. Behalten Sie:

# settings/override/site.ini.append.php
[SiteAccessSettings]
CheckValidity=false

[SetupSettings]
AllowWizardOnInstalledSite=disabled

Solange CheckValidity true ist (der mitgelieferte Standard vor einer Installation), wird jede Anfrage an den Setup-Assistenten geschickt. Setzen Sie es auf einer Live-Website nie zurück; die Seite Setup-Assistent auf Shared Hosting behandelt die Seite der Bereitstellung.

Checkliste #

• To do: Die Administration auf einem eigenen Hostnamen.
• To do: Eingeschränkt durch Netzwerk, VPN, Basic-Authentifizierung oder die Browserprüfung des Schutzes.
• To do: Keine geteilten Anmeldungen; persönliche Konten für Redakteure und für die Support-Mitarbeitenden des Hosters; admin stillgelegt.
• To do: Rollen geprüft: setup/setup, audit/*, mailpreferences/export nur wo nötig.
• To do: Zweistufige Anmeldung für Administratoren verlangt (Zweistufige Anmeldung).
• To do: ManagedByDeployment=enabled, wo die Konfiguration aus der Versionsverwaltung kommt.
• To do: CheckValidity=false, AllowWizardOnInstalledSite=disabled.

Verwandte Seiten #

• Sicherheit für Hoster: Überblick
• Kapitel 13: Der Siteaccess der Administration
• Das Administratorpasswort ändern
• Request-Regeln
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.