Was sind Best Practices zum Sichern des Admin-Bereichs einer Website? [geschlossen]

Ich möchte wissen, welche Methoden als Best Practice für die Sicherung der Admin-Bereiche von Websites angesehen werden, insbesondere unter dem Gesichtspunkt der Authentifizierung / des Zugriffs.

Natürlich gibt es offensichtliche Dinge, wie die Verwendung von SSL und die Protokollierung des gesamten Zugriffs, aber ich frage mich, wo genau über diesen grundlegenden Schritten die Leute die Messlatte setzen.

Beispielsweise:

• Verlassen Sie sich nur auf denselben Authentifizierungsmechanismus, den Sie für normale Benutzer verwenden? Wenn nicht, was?
• Führen Sie den Admin-Bereich in derselben 'Anwendungsdomäne' aus?
• Welche Schritte unternehmen Sie, um den Admin-Bereich unentdeckt zu lassen? (Oder lehnen Sie die ganze "Dunkelheit" ab?)

Bisher enthalten die Vorschläge der Antwortenden:

• Führen Sie bei jeder Kennwortprüfung für Administratoren eine künstliche serverseitige Pause ein, um Brute-Force-Angriffe zu verhindern. [Developer Art]
• Verwenden Sie separate Anmeldeseiten für Benutzer und Administrator, die dieselbe DB-Tabelle verwenden (um zu verhindern, dass XSRF und Sitzungsdiebstahl Zugriff auf Administratorbereiche gewähren) [Thief Master]
• Erwägen Sie auch, dem Administratorbereich eine native Webserver-Authentifizierung hinzuzufügen (z. B. über .htaccess). [Thief Master]
• Ziehen Sie in Betracht, die IP-Adresse des Benutzers nach mehreren fehlgeschlagenen Anmeldeversuchen des Administrators zu blockieren [Thief Master]
• Fügen Sie Captcha nach fehlgeschlagenen Administrator-Anmeldeversuchen hinzu [Dieb-Meister]
• Stellen Sie sowohl Benutzern als auch Administratoren gleich starke Mechanismen (unter Verwendung der oben genannten Techniken) zur Verfügung (z. B. behandeln Sie Administratoren nicht speziell). Administratoren Administratoren [Lo'oris]
• Berücksichtigen Sie die Authentifizierung der zweiten Ebene (z. B. Client-Zertifikate, Smartcards, Kartenbereich usw.). [JoeGeeky]
• Erlauben Sie nur den Zugriff von vertrauenswürdigen IPs / Domänen und fügen Sie der grundlegenden HTTP-Pipeline (z. B. über HttpModules) nach Möglichkeit eine Prüfung hinzu. [JoeGeeky]
• [ASP.NET] Sperren Sie IPrincipal & Principal (machen Sie sie unveränderlich und nicht aufzählbar). [JoeGeeky]
• Erhöhung der Verbundrechte - z. B. E-Mail an andere Administratoren, wenn die Rechte eines Administrators aktualisiert werden. [JoeGeeky]
• Berücksichtigen Sie differenzierte Rechte für Administratoren. Definieren Sie beispielsweise anstelle von rollenbasierten Rechten Rechte für bestimmte Aktionen pro Administrator [JoeGeeky].
• Beschränken Sie die Erstellung von Administratoren - z. B. können Administratoren keine anderen Administratorkonten ändern oder erstellen. Verwenden Sie dazu einen gesperrten 'Superadmin'-Client.[JoeGeeky]
• Betrachten Sie clientseitige SSL-Zertifikate oder RSA-Schlüsselanhänger (elektronische Token). [Daniel Papasian]
• Wenn Sie Cookies zur Authentifizierung verwenden, verwenden Sie separate Cookies für Administrator- und normale Seiten, indem Sie beispielsweise den Administratorbereich auf eine andere Domain setzen. [Daniel Papasian]
• Wenn dies sinnvoll ist, sollten Sie die Admin-Site in einem privaten Subnetz außerhalb des öffentlichen Internets aufbewahren. [John Hartsock]
• Neuausstellung von Authentifizierungs- / Sitzungstickets beim Wechsel zwischen Administrator- und normalen Nutzungskontexten der Website [Richard JP Le Guen]

Dies sind alles gute Antworten ... Ich möchte im Allgemeinen ein paar zusätzliche Ebenen für meine Verwaltungsabschnitte hinzufügen. Obwohl ich einige Variationen eines Themas verwendet habe, enthalten sie im Allgemeinen eine der folgenden:

• Authentifizierung der zweiten Ebene : Dies kann Client-Zertifikate (z. B. x509-Zertifikate), Smartcards, Kartenraum usw. umfassen.
• Domänen- / IP-Einschränkungen : In diesem Fall nur Clients, die von vertrauenswürdigen / überprüfbaren Domänen stammen. wie interne Subnetze; sind in den Admin-Bereich erlaubt. Remote-Administratoren durchlaufen häufig vertrauenswürdige VPN-Einstiegspunkte, sodass ihre Sitzung überprüfbar ist und häufig auch mit RSA-Schlüsseln geschützt wird. Wenn Sie ASP.NET verwenden, können Sie diese Überprüfungen in der HTTP-Pipeline problemlos über HTTP-Module durchführen. Dadurch wird verhindert, dass Ihre Anwendung jemals Anforderungen erhält, wenn die Sicherheitsüberprüfungen nicht erfüllt sind.
• Gesperrte IPrincipal- und Principal-basierte Autorisierung : Das Erstellen benutzerdefinierter Principles ist eine gängige Praxis, obwohl ein häufiger Fehler darin besteht, sie modifizierbar und / oder aufzählbar zu machen. Obwohl es sich nicht nur um ein Administratorproblem handelt, ist es wichtiger, da hier Benutzer wahrscheinlich über erhöhte Rechte verfügen. Stellen Sie sicher, dass sie unveränderlich und nicht aufzählbar sind. Stellen Sie außerdem sicher, dass alle Bewertungen für die Autorisierung auf der Grundlage des Auftraggebers vorgenommen werden.
• Erhöhung der Verbundrechte : Wenn ein Konto eine ausgewählte Anzahl von Rechten erhält, werden alle Administratoren und der Sicherheitsbeauftragte sofort per E-Mail benachrichtigt. Dies stellt sicher, dass wir sofort wissen, ob ein Angreifer die Rechte erhöht. Diese Rechte beziehen sich im Allgemeinen auf privilegierte Rechte, Rechte zum Anzeigen datenschutzgeschützter Informationen und / oder Finanzinformationen (z. B. Kreditkarten).
• Stellen Sie Rechte sparsam aus, auch für Administratoren : Schließlich kann dies für einige Geschäfte etwas weiter fortgeschritten sein. Autorisierungsrechte sollten so diskret wie möglich sein und sich auf echte Funktionsverhalten beziehen. Typische rollenbasierte Sicherheitsansätze (RBS) haben tendenziell eine Gruppenmentalität . Aus Sicherheitsgründen ist dies nicht das beste Muster. Versuchen Sie, anstelle von " Gruppen " wie " Benutzermanager " eine weitere Aufschlüsselung vorzunehmen (z . B. Benutzer erstellen, Benutzer autorisieren, Zugriffsrechte erhöhen / widerrufen usw.).). Dies kann etwas mehr Verwaltungsaufwand verursachen, bietet Ihnen jedoch die Flexibilität, nur Rechte zuzuweisen, die tatsächlich von der größeren Administratorgruppe benötigt werden. Wenn der Zugriff zumindest gefährdet ist, erhalten sie möglicherweise nicht alle Rechte. Ich möchte dies in CAS-Berechtigungen (Code Access Security) einschließen, die von .NET und Java unterstützt werden, aber das geht über den Rahmen dieser Antwort hinaus. Eine weitere Sache ... In einer App können Administratoren keine Änderungen an anderen Administratorkonten verwalten oder einen Benutzer zum Administrator machen. Dies kann nur über einen gesperrten Client erfolgen, auf den nur wenige Personen zugreifen können.

Wenn für die Website ein Login sowohl für reguläre Aktivitäten als auch für Administratoren erforderlich ist, z. B. für ein Forum, würde ich separate Logins verwenden, die dieselbe Benutzerdatenbank verwenden. Dadurch wird sichergestellt, dass XSRF und Sitzungsdiebstahl dem Angreifer keinen Zugriff auf Verwaltungsbereiche ermöglichen.

Wenn sich der Administratorbereich in einem separaten Unterverzeichnis befindet, ist es möglicherweise eine gute Idee, dieses mit der Authentifizierung des Webservers zu sichern (z. B. .htaccess in Apache). Dann benötigt jemand sowohl dieses Kennwort als auch das Benutzerkennwort.

Das Verschleiern des Admin-Pfads bringt fast keinen Sicherheitsgewinn - wenn jemand gültige Anmeldedaten kennt, kann er höchstwahrscheinlich auch den Pfad des Admin-Tools herausfinden, da er ihn entweder phishing oder keyloggt oder über Social Engineering erhalten hat (was wahrscheinlich das enthüllen würde Weg auch).

Ein Brute-Force-Schutz wie das Blockieren der IP-Adresse des Benutzers nach 3 fehlgeschlagenen Anmeldungen oder das Erfordernis eines CAPTCHA nach einem fehlgeschlagenen Login (nicht für das erste Login, da dies für legitime Benutzer nur äußerst ärgerlich ist) kann ebenfalls nützlich sein.

• Ich lehne Dunkelheit ab
• Die Verwendung von zwei Authentifizierungssystemen anstelle von einem ist übertrieben
• Die künstliche Pause zwischen den Versuchen sollte auch für Benutzer erfolgen
• Das Blockieren von IPs fehlgeschlagener Versuche sollte auch für Benutzer erfolgen
• Starke Passwörter sollten auch von Benutzern verwendet werden
• Wenn Sie Captchas für in Ordnung halten, raten Sie mal, Sie können sie auch für Benutzer verwenden

Ja, nachdem ich es geschrieben habe, stelle ich fest, dass diese Antwort als "nichts Besonderes für die Administratoranmeldung, sie sind alle Sicherheitsfunktionen, die für jede Anmeldung verwendet werden sollten" zusammengefasst werden kann.

Wenn Sie nur eine einzige Anmeldung für Benutzer verwenden, die sowohl über normale Benutzer- als auch über Administratorrechte verfügen, generieren Sie ihre Sitzungskennung neu (sei es in einem Cookie oder einem GET-Parameter oder was auch immer ...), wenn sich die Stufe von ändert Privileg ... zumindest.

Wenn ich mich anmelde, mache ich ein paar normale Benutzeraufgaben und besuche dann eine Administrationsseite, um meine Sitzungs-ID neu zu generieren. Wenn ich dann von einer oder mehreren Administrationsseiten zu einer normalen Benutzerseite navigiere, generieren Sie meine ID erneut.

Haben Sie ein gutes Administratorkennwort.

Nicht "123456"nur eine Folge von Buchstaben, Ziffern und Sonderzeichen, die lang genug ist, beispielsweise 15 bis 20 Zeichen. Wie "ksd83,'|4d#rrpp0%27&lq(go43$sd{3>".

Fügen Sie für jede Kennwortprüfung eine Pause hinzu, um Brute-Force-Angriffe zu verhindern.

Hier sind einige andere Dinge zu beachten:

1. Eine Option, die Sie in Betracht ziehen sollten, insbesondere wenn Sie die Computer des Administrators verwalten oder diese technisch kompetent sind, besteht darin, für die Clientauthentifizierung etwas zu verwenden, das auf SSL-Zertifikaten basiert. RSA-Schlüsselanhänger und so weiter können ebenfalls für zusätzliche Sicherheit verwendet werden.
2. Wenn Sie überhaupt Cookies verwenden - möglicherweise für ein Authentifizierungs- / Sitzungstoken - möchten Sie wahrscheinlich sicherstellen, dass die Cookies nur an die Administrationsseiten gesendet werden. Dies hilft dabei, die Risiken für Ihre Website zu verringern, indem Cookies gestohlen werden, entweder durch Kompromisse der Ebene 1/2 oder durch XSS. Dies kann einfach durchgeführt werden, indem sich der Administratorteil auf einem anderen Hostnamen oder einer anderen Domäne befindet und das sichere Flag mit dem Cookie gesetzt wird.
3. Das Einschränken durch IP kann ebenfalls klug sein. Wenn Sie Benutzer im gesamten Internet haben, können Sie dies trotzdem tun, wenn ein vertrauenswürdiges VPN vorhanden ist, dem diese beitreten können.

Wir verwenden Windows Authenticationfür den Administratorzugriff. Dies ist die praktischste Methode, um Administratorbereiche zu schützen und gleichzeitig die Authentifizierung von den allgemeinen Endbenutzern zu trennen. Der Systemadministrator verwaltet die Anmeldeinformationen für den Administratorbenutzerzugriff und erzwingt Kennwortrichtlinien für das Domänenbenutzerkonto.

Der strikte Weg besteht darin, zwei vollständig unterschiedliche "Farmen" zu haben, einschließlich Datenbanken, Server und aller, und die Daten von einer Farm in die andere zu verschieben. Die meisten modernen Großsysteme verwenden diesen Ansatz (Vignette, SharePoint usw.). Es wird normalerweise als unterschiedliche Phasen "Bearbeitungsphase" -> "Vorschauphase" -> "Lieferphase" bezeichnet. Mit dieser Methode können Sie Inhalt / Konfiguration genauso behandeln wie Code (dev-> qa-> prod).

Wenn Sie weniger paranoid sind, können Sie eine einzige Datenbank haben, aber nur Ihren Admin-Bereich auf den "Bearbeitungs" -Servern verfügbar haben. Ich meine, nur die Bearbeitungsskripte / -dateien müssen auf dem Bearbeitungsserver abgelegt werden.

Natürlich sollte die Bearbeitungsphase nur in einem lokalen Intranet und / oder über ein VPN verfügbar sein.

Dies mag ein wenig übertrieben erscheinen und ist möglicherweise nicht die einfachste Lösung für alle Anwendungsfälle, aber es ist definitiv die robusteste Art, Dinge zu tun.

Beachten Sie, dass Dinge wie "Starke Administratorkennwörter haben" nett sind, aber Ihren Administrator dennoch für intelligente Angriffe aller Art offen lassen.

Es hängt sehr davon ab, welche Art von Daten Sie schützen möchten (gesetzliche Anforderungen und dergleichen).

• Bei vielen Vorschlägen geht es um die Authentifizierung. Ich denke, Sie sollten nur die Verwendung der OpenId / Facebook-Authentifizierung als Login in Betracht ziehen. (Sie werden höchstwahrscheinlich mehr Ressourcen für die Authentifizierungssicherheit ausgeben als Sie.)

• Speichern Sie die Änderungen und aktualisieren Sie die Werte in der Datenbank. Auf diese Weise können Sie Änderungen von Benutzer X oder zwischen Datum X und Y rückgängig machen.

Ich habe nicht bemerkt, dass jemand die Speicherung / Validierung des Administratorkennworts erwähnt hat. Bitte, bitte, bitte speichern Sie das PW nicht im Klartext und vorzugsweise nicht einmal in etwas, das rückgängig gemacht werden kann. Verwenden Sie so etwas wie einen gesalzenen MD5-Hash, damit zumindest jemand, der das gespeicherte "Passwort" abruft, dies nicht hat alles schrecklich Nützliche, es sei denn, sie haben auch Ihr Salzschema.

Fügen Sie ein Kennwortfeld und eine Sicherheitsfrage hinzu, die der Administrator kennt, z. B. den Namen Ihrer ersten Freundin, oder ordnen Sie die Fragen bei jedem Anzeigen des Admin-Bereichs nach dem Zufallsprinzip zu.

Vielleicht könnten Sie den Administrationsbereich immer in ein großes Verzeichnis stellen, z

http://domain.com/sub/sub/sub/sub/index.php

Aber das ist nicht wirklich gut, hah.

Vielleicht könnten Sie eine Abfragezeichenfolge in die Startseite aufnehmen, wie:

http://domain.com/index.php?display=true

In diesem Fall werden das Feld Benutzername und Kennwort angezeigt.