Welche Sicherheitsbedrohungen stellen das SA-Konto und andere bekannte Kontonamen für die Sicherheit dar?

Stellt ein bekannter Kontoname wie sa eine Sicherheitsbedrohung für die Datenbank dar? Wenn Sie die Windows-Authentifizierung unter SQL Server verwenden, wird dieselbe Kennwortrichtlinie festgelegt (wenn nach fünfmal die Kontosperrung angegeben wurde)?

Stellt ein bekannter Kontoname wie sa eine Sicherheitsbedrohung für die Datenbank dar?

Ein "Gott" -Nutzerkonto mit einem bekannten Namen wird im Allgemeinen als schlechtere Idee angesehen als ein Gott-Benutzer mit einem weniger bekannten Namen. Dies erleichtert Brute-Force-Angriffe ein wenig, da der Angreifer nur das Kennwort erraten muss und nicht den Benutzernamen und das Kennwort.

Es kann auch gefährlich sein, einen Gott-Benutzer zu haben. Im Allgemeinen ist es besser, bestimmte Benutzer mit bestimmten Rechten für das zu haben, was sie tun müssen. Diese Art von privilegierter Sicherheit ist einfacher von Grund auf neu zu implementieren als später in Ihre Umgebung nachzurüsten.

Das Deaktivieren von sa und das Erteilen bestimmter Administratorrechte für bestimmte Benutzer in SQL Server ist im Wesentlichen dieselbe Empfehlung wie das Deaktivieren rootund Verteilen von Administratorrechten nach Bedarf über sudoLinux und ähnliches. Sie können jederzeit wieder aktivieren, sasobald eine direkte Verbindung zum Computer mit angemessenen Berechtigungen besteht, falls etwas schief geht und Sie am Ende alle Rechte verlieren, die Ihre Benutzer zum Betrieb (und Beheben des Problems) benötigen, genauso wie Sie den Root-Zugriff auf ein Linux ausführen können Box, wenn Sie physischen Zugriff auf die Box haben - das Deaktivieren des Kontos ist also kein Wundermittel (aber sobald ein Angreifer physischen Zugriff auf Ihren Computer oder vollen Administratorzugriff über RDC oder SSH hat, sind alle Wetten sowieso deaktiviert).

Wenn Sie die Windows-Authentifizierung unter SQL Server verwenden, wird dieselbe Kennwortrichtlinie festgelegt (wenn nach fünfmal die Kontosperrung angegeben wurde)?

Bei Verwendung der integrierten Windows-Authentifizierung hat SQL Server keine Kontrolle über Kontosperrungen und dergleichen. Er ordnet lediglich einen Windows-Benutzer einem SQL-Benutzer zu und fordert das Betriebssystem auf, dafür zu bürgen, dass der Benutzer die entsprechenden Anmeldeinformationen angegeben hat. Für interaktive Benutzer bedeutet dies, dass eine Sperrung auftritt, wenn der Benutzer versucht, sich bei Windows zu authentifizieren, und nicht, wenn er sich bei SQL Server anmeldet.

Es ist keine schlechte Idee, dies so zu gestalten, dass der Standard-Administratorbenutzer (admin / root / postgres / sa / etc) in Ihrem System nicht vorhanden ist. Sie können jederzeit ein privilegiertes Konto unter einem anderen Namen erstellen.

Nicht zuletzt haben Leute, die versuchen, Ihr System auszunutzen, nicht so viel Zeit wie blind zu arbeiten (z. B. SQL-Injection ohne interaktive Shell oder direkte Ausgabe ihrer Befehle).

Was die Kontosperrung betrifft - wenn es jemandem gelungen ist, weit genug zu kommen, um überhaupt versuchen zu können, sich bei Ihrem Computer anzumelden, haben Sie den Kampf bereits verloren, es sei denn, Sie erlauben ausdrücklich die direkte Anmeldung von Benutzern. Persönlich bin ich größtenteils nicht für Aussperrungen, da dadurch jemand die Möglichkeit erhält, einen Denial-of-Service zu erstellen, wenn er den Namen eines Ihrer Benutzer erhält. (und sie den Superuser aussperren lassen? kein Spaß).

Ich würde empfehlen, sich die CIS-Benchmarks anzusehen ... sie haben sie nicht für jede Datenbank, aber sie haben Empfehlungen für Oracle, MS SQL, DB2 und MySQL. Wenn Sie etwas anderes betreiben, lohnt es sich immer noch, sich die allgemeinen Dinge anzusehen, die sie empfehlen.

Ich habe niemanden gesehen, der das erwähnt, also werde ich es hinzufügen. Wenn Ihr Server mit SQL Server 2005+ Teil einer Domäne ist und die Domäne über eine Kennwortrichtlinie verfügt, können Sie die Durchsetzung der Kennwortrichtlinie für SQL-Anmeldungen aktivieren. Dies umfasst Anforderungen an die Kennwortkomplexität und die Möglichkeit, Kennwortänderungen beim Anmelden zu erzwingen.

Beachten Sie, dass dies manchmal Probleme mit einigen Software-Installationsprogrammen verursachen kann, die nicht für SQL 2005+ aktualisiert wurden, und SQL-Anmeldungen mit unsicheren Kennwörtern erstellen.

In SQL Server werden zwei Authentifizierungsmodi verwendet: Windows-Authentifizierung und gemischter Modus (aktiviert sowohl die Windows-Authentifizierung als auch die SQL Server-Authentifizierung)

Der erste Modus ist weniger anfällig für Brute-Force-Angriffe, da der Angreifer nach einer begrenzten Anzahl von Angriffsversuchen wahrscheinlich auf eine Anmeldesperre (die Funktion zur Kontosperrung) stößt. Wenn der Windows-Authentifizierungsmodus verwendet wird, sollte jede Produktionsumgebung die Sperrrichtlinienfunktion verwenden, da dies Brute-Force-Angriffe unmöglich macht

Wenn es um die Sicherheitsanfälligkeit bei Brute-Force-Angriffen mit SQL Server-Authentifizierung geht, ist die Situation nicht so günstig. Die SQL Server-Authentifizierung verfügt über keine Funktionen, mit denen erkannt werden kann, wann das System einem Brute-Force-Angriff ausgesetzt ist. Darüber hinaus reagiert SQL Server sehr schnell auf die Überprüfung der SQL Server-Authentifizierungsdaten. Es kann problemlos wiederholte, aggressive Brute-Force-Anmeldeversuche ohne negative Gesamtleistung verarbeiten, die auf solche Angriffe hinweisen könnten. Dies bedeutet, dass die SQL Server-Authentifizierung ein perfektes Ziel für das Knacken von Passwörtern über Brute-Force-Angriffe ist

Außerdem entwickeln sich mit jeder neu eingeführten Verschlüsselungs- und Kennwortkomplexitätsmethode Brute-Force-Methoden. Beispielsweise können Angreifer, die Regenbogentabellen verwenden (die vorberechneten Tabellen zum Umkehren der kryptografischen Hashwerte für jede mögliche Zeichenkombination), jedes Hash-Passwort einfach und schnell knacken

Um Ihren SQL Server vor Brute-Force-Angriffen zu schützen, sollten Sie Folgendes berücksichtigen:

• Verwenden Sie nicht den SQL Server-Authentifizierungsmodus. Erzwingen Sie, dass der Angreifer die Anmeldesperre über die Windows-Authentifizierung aktiviert
• Wenn Sie den SQL Server-Authentifizierungsmodus verwenden müssen, deaktivieren oder entfernen Sie die SA-Anmeldung. Auf diese Weise muss der Angreifer sowohl den Benutzernamen als auch das Kennwort erraten und koppeln

Wenn das Konto sa aktiviert ist, kann es auf dem SQL Server alles tun. Wenn ein Angreifer in dieses Konto eindringt, kann er auf der SQL Server-Instanz (und möglicherweise auf dem Host-Betriebssystem) alles tun, was er möchte.

Die SA (und andere bekannte Kontonamen) sind bekannte Punkte, die Hacker angreifen können. Einige der Oracle-Passwörter waren schlecht dokumentiert und daher wurden die Standardkennwörter nicht immer geändert. Sobald Sie die Kontrolle über das SA-Konto in SQL Server haben, steuern Sie den Server, auf dem es ausgeführt wird, und können beliebigen Code ausführen oder alles installieren, was Sie möchten. In meinen Cowboy-Tagen war es mir nicht gestattet, ein ActiveX-Steuerelement auf einem Webserver zu installieren, auf dem sich auch der SQL Server befand. Daher habe ich xp_cmdshell zum Kopieren und Installieren des Steuerelements verwendet .