Gibt es eine Möglichkeit herauszufinden, wer das Passwort für eine Anmeldung geändert hat?

11

Ich versuche herauszufinden, wer das Kennwort für eine Anmeldung in SQL Server 2008 R2 geändert hat.

Ich habe bereits die Standardablaufverfolgung überprüft - und dieses Ereignis wird nicht protokolliert. Die Standardablaufverfolgung enthält die folgenden sicherheitsrelevanten Ereignisse:

/*
    Audit Add DB user event
    Audit Add login to server role event
    Audit Add Member to DB role event
    Audit Add Role event
    Audit Add login event
    Audit Backup/Restore event
    Audit Change Database owner
    Audit DBCC event
    Audit Database Scope GDR event (Grant, Deny, Revoke)
    Audit Login Change Property event
    Audit Login Failed
    Audit Login GDR event
    Audit Schema Object GDR event
    Audit Schema Object Take Ownership
    Audit Server Starts and Stops 
*/

Außerdem haben wir uns die Transaktionsprotokollsicherung angesehen, um das herauszufinden, aber kein Glück.

Gibt es eine andere Möglichkeit, es herauszufinden?

Ich bin mir auch bewusst, dass eine serverseitige Ablaufverfolgung hilfreich sein wird, aber leider haben wir in unserer serverseitigen Ablaufverfolgung die nicht aufgenommen Audit Login Change Password Event.

Der beste Artikel, den ich gefunden habe, stammt von Aaron Bertrand: Nachverfolgen von Änderungen des Anmeldekennworts in SQL Server

Kin Shah
quelle
2
Ich würde einen von Aarons Vorschlägen einrichten, dann irgendwo den aktuellen Passwort-Hash sichern und dann das Passwort wieder ändern. Sehen Sie, wer schreit ... oder wenn es nur zufällig geändert wird, haben Sie die Spur, um sie zu fangen.
Kenneth Fisher
Es ist nicht ganz klar, ob das Passwort geändert wurde, um Zugriff zu erhalten oder den Zugriff eines anderen zu verhindern. Ich sage das nur, weil jemand vielleicht nicht schreit. Kin weiß möglicherweise auch nicht, wie das ursprüngliche Passwort lautete.
Aaron Bertrand
Das ursprüngliche Passwort könnte mithilfe des Hashs zurückgesetzt werden (fragen Sie mich, woher ich weiß, haha), der sich irgendwo im Transaktionsprotokoll befinden sollte.
Jon Seigel

Antworten:

11

Mein Artikel hilft, wenn Sie ihn im Voraus einrichten, aber nicht, wenn das Ereignis in der Vergangenheit stattgefunden hat und Sie keinen Überwachungsmechanismus eingerichtet haben.

Es gibt jedoch noch Hoffnung. Nehmen wir an, ich habe das getan:

CREATE LOGIN flooberella WITH PASSWORD = N'x', CHECK_POLICY = OFF;

Diese Informationen befinden sich in der Standardablaufverfolgung unter EventClass 104 (Audit Addlogin Event). Wenn ich das Kennwort jedoch mit einer der folgenden Methoden ändere:

ALTER LOGIN flooberella WITH PASSWORD = N'y';

EXEC sp_password N'y', N'z', N'flooberella';

Diese Ereignisse werden aus offensichtlichen Sicherheitsgründen nicht von der Standardablaufverfolgung erfasst. Es sollte niemandem mit Zugriff auf die Standardablaufverfolgung möglich sein, das Kennwort einer anderen Person herauszufinden, und sie möchten es auch nicht einfach machen, dies herauszufinden Ein Kennwort wurde geändert (das Abrufen der Häufigkeit dieser Ereignisse kann beispielsweise bestimmte Eigenschaften Ihrer Sicherheitsstrategie aufdecken).

Was können Sie sonst noch tun? Dies hängt zwar von den Informationen ab, die sich noch im Protokoll befinden, und auch von der Verwendung eines undokumentierten DBCC-Befehls für eine Systemdatenbank (möglicherweise möchten Sie den Master sichern und an anderer Stelle wiederherstellen). Sie können jedoch einige Informationen aus dem Transaktionsprotokoll abrufen. z.B:

DBCC LOG(master, 1);

Dies ergibt für die obigen zwei Befehle Zeilen mit den folgenden (Teil-) Informationen:

Current LSN             Description
======================  ======================================================================
000000f2:000001b8:0002  ALTER LOGIN;0x01050000000000051500000093a3bcd7a9f8fb1417ab13bce8030000
000000f2:000001b8:0004  Alter login change password;0x01050000000000 ... same sid as above ...

Scheint nicht viel zu sein, aber nehmen Sie jetzt diesen 0x-Teil der Beschreibung und tun Sie dann:

SELECT name FROM sys.server_principals
  WHERE sid = 0x01050000000000051500000093a3bcd7a9f8fb1417ab13bce8030000;

Rauchpistole! Dies ist die Person, die für dieses Ereignis verantwortlich ist.

Wenn sie die ALTER LOGINSyntax für alle Vorgänge verwenden (die sie anstelle von verwenden sollten sp_password), können Sie natürlich nicht zwischen jemandem unterscheiden, der die Standarddatenbank ändert, und jemandem, der das Kennwort ändert. Sie können auch nicht sagen (zumindest, dass ich sehen kann), welche Anmeldung davon betroffen ist, nur dass diese Person eine Anmeldung geändert hat . Jon scheint zu glauben, dass diese Informationen auch im Protokoll enthalten sind, aber ich habe sie nicht gefunden (im Gegensatz zu den Zeitinformationen, an denen ich irgendwie vorbei gescrollt habe).


In SQL Server 2012 gibt es möglicherweise unterschiedliche Antworten für enthaltene Benutzer. Ich vermute jedoch, dass Kennwortänderungen auf ähnliche Weise immer noch verschleiert werden. Lassen Sie das für eine separate Frage.

Aaron Bertrand
quelle
Ich denke, Sie könnten fn_dblog/ fn_dump_dbloggegen master(oder eine Kopie davon) verwenden, um herauszufinden, welches Prinzip geändert wurde, selbst wenn Sie mit Höhlenforschung arbeiten müssen DBCC PAGE.
Jon Seigel
Suchen Sie LOP_XACT_BEGINnach dem, was Transaction IDSie gefunden haben. Es enthält die genaue Zeit und die SID des Logins, mit dem es gestartet wurde.
Remus Rusanu
@ Jon Sie würden so denken, aber Seiten-ID und Steckplatz-ID sind NULL.
Aaron Bertrand
Es muss eine Möglichkeit für SQL geben, zu wissen, wie die Transaktion zurückgesetzt werden kann ... Vielleicht werden diese Werte in der TVF einfach nicht verfügbar gemacht, obwohl sie tatsächlich vorhanden sind.
Jon Seigel
@Jon gehen Sie voran und werfen Sie einen Blick auf DBCC LOG(master,3);(oder das fn_dblog()Äquivalent) und sehen Sie, ob Sie etwas erkennen können, das bei der Identifizierung des Ziels helfen würde. Wenn ich das tue, BEGIN TRANSACTION; ALTER LOGIN...erhalte ich noch weniger nützliche Informationen, die verschwinden, wenn ich zurücksetze, und die oben genannten werden, wenn ich mich verpflichte.
Aaron Bertrand
4

Dies ist länger als ein Kommentar, der als Antwort veröffentlicht wird

select top(10) 
    [Transaction ID], 
    [Begin Time], 
    [Transaction Name], 
    [Transaction SID],
    SUSER_SNAME([Transaction SID])
from fn_dblog(null, null)
where Operation = 'LOP_BEGIN_XACT';

Transaction ID Begin Time               Transaction Name                  Transaction SID
-------------- ------------------------ --------------------------------- ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
0000:00002b12  2014/01/08 20:10:14:890  Event_Session_Startup             NULL
0000:00002b13  2014/01/08 20:10:15:027  DBMgr::StartupDB                  NULL
0000:00002b14  2014/01/08 20:10:15:513  AddGuestUserToTempdb              NULL
0000:00002b15  2014/01/08 20:10:15:537  DBMgr::StartupDB                  NULL
0000:00002b16  2014/01/08 20:10:15:537  DBMgr::StartupDB                  NULL
0000:00002b17  2014/01/08 20:10:15:537  DBMgr::StartupDB                  NULL
0000:00002b18  2014/01/08 20:10:15:540  DBMgr::StartupDB                  NULL
0000:00002b19  2014/01/08 20:10:15:550  DBMgr::StartupDB                  NULL
0000:00002b1a  2014/01/11 11:49:42:760  AutoCreateQPStats                 0x010500000000000515000000A065CF7E784B9B5FE77C877084B65600
0000:00002b1b  2014/01/11 11:53:26:620  test_ack                          0x010500000000000515000000A065CF7E784B9B5FE77C877084B65600

(10 row(s) affected)
Remus Rusanu
quelle
1
@RemusRusanu Dies ist nur nützlich, wenn Sie direkt nachfragen, was im T-Protokoll enthalten ist. Wenn Sie jedoch versuchen, aus einer T-Protokoll-Sicherung zu lesen, werden die SIDs abgeschnitten. Außerdem wird bei jedem Aufruf von fn_dump_dblog ein neuer versteckter SQLOS-Scheduler und bis zu drei Threads erstellt, die niemals verschwinden und niemals wiederverwendet werden.
Kin Shah
1

Sie können den DDL-Trigger auf Serverebene verwenden (beachten Sie, dass für dieses Beispiel die SQL Server-Datenbankmail-Funktion aktiviert und festgelegt sein muss):

CREATE Trigger [Trg_TrackLoginManagement]
on ALL Server
for DDL_LOGIN_EVENTS
as
set nocount on
declare @data xml,
          @EventType varchar(100),
          @EventTime datetime,
          @ServerName varchar(100),
          @AffectedLoginName varchar(100),
          @WhoDidIt varchar(100),
          @EmailSubject varchar(500),
          @EmailBody varchar(800),
          @EmailRecipients varchar(300)
set @EmailRecipients = '[email protected]'
set @data = eventdata()
set @EventType = @data.value('(/EVENT_INSTANCE/EventType)[1]', 'varchar(100)')
set @EventTime = @data.value('(/EVENT_INSTANCE/PostTime)[1]','datetime')
set @ServerName = @data.value('(/EVENT_INSTANCE/ServerName)[1]','varchar(100)')
set @AffectedLoginName = @data.value('(/EVENT_INSTANCE/ObjectName)[1]','varchar(100)')
set @WhoDidIt = @data.value('(/EVENT_INSTANCE/LoginName)[1]','varchar(100)')

set @EmailSubject = 'ALERT: DDL_LOGIN_Event: ' + @EventType + ' occured by ' + @WhoDidIt + ' on ' + @ServerName

set @EmailBody =  'DDL_Login_Event: ' + @EventType + char(10) + 
                 'Event Occured at: ' + convert(Varchar, @EventTime) + char(10) + 
                 'ServerName: ' + @ServerName + char(10) +
                 'Affected Login Name:      ' + @AffectedLoginName + char(10) + 
                 'Event Done by: ' + @WhoDidIt
EXEC msdb.dbo.sp_send_dbmail
    @recipients = @EmailRecipients,
    @body = @EmailBody,
    @subject = @EmailSubject ;
GO
Ivan Stankovic
quelle