C'è un modo per scoprire chi ha cambiato la password per un login?


11

Sto cercando di scoprire chi ha modificato la password per un accesso in SQL Server 2008 R2.

Ho già controllato la traccia predefinita e non registra quell'evento. La traccia predefinita includerà questi eventi relativi alla sicurezza:

/*
    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 
*/

Inoltre, ho esaminato il backup del registro delle transazioni per scoprirlo, ma senza fortuna.

C'è un altro modo per scoprirlo?

Inoltre, sono consapevole che una traccia lato server sarà di aiuto, ma sfortunatamente nella nostra traccia lato server non abbiamo incluso Audit Login Change Password Event.

Il miglior articolo che ho trovato proviene da Aaron Bertrand: tenere traccia delle modifiche alla password di accesso in SQL Server


2
Vorrei impostare uno dei suggerimenti di Aaron, quindi eseguire il backup dell'hash della password corrente da qualche parte e quindi modificare nuovamente la password. Guarda chi urla .. o se viene semplicemente cambiato in modo casuale, allora hai la traccia in atto per catturarli.
Kenneth Fisher,

Non è del tutto chiaro se la password sia stata modificata per ottenere l'accesso o impedire l'accesso di qualcun altro. Lo sto solo dicendo perché qualcuno potrebbe non urlare. Kin potrebbe anche non sapere quale fosse la password originale.
Aaron Bertrand

La password originale potrebbe essere reimpostata utilizzando l'hash (chiedimi come faccio a sapere haha), che dovrebbe trovarsi da qualche parte nel registro delle transazioni.
Jon Seigel,

Risposte:


11

Il mio articolo sarà di aiuto se lo hai impostato in anticipo, ma non quando l'evento si è verificato in passato e non hai impostato alcun tipo di meccanismo di controllo.

C'è ancora speranza, però. Diciamo che ho fatto questo:

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

Questa informazione si trova nella traccia predefinita in EventClass 104 (Audit Addlogin Event). Tuttavia, se cambio la password utilizzando uno di questi metodi:

ALTER LOGIN flooberella WITH PASSWORD = N'y';

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

Questi eventi non vengono acquisiti dalla traccia predefinita, per ovvi motivi di sicurezza: non dovrebbe essere possibile per chiunque abbia accesso alla traccia predefinita per capire qual è la password di qualcun altro, né vogliono renderlo facile nemmeno scoprire che una password è stata modificata (il polling della frequenza di questi eventi, ad esempio, può rivelare alcune proprietà della tua strategia di sicurezza).

Quindi cos'altro puoi fare? Sebbene ciò si basi sulle informazioni ancora presenti nel registro e si basi anche sull'uso di un comando DBCC non documentato su un database di sistema (è possibile eseguire il backup del master e ripristinarlo altrove), è possibile ottenere alcune informazioni dal registro delle transazioni, per esempio:

DBCC LOG(master, 1);

Ciò produrrà, per i due comandi precedenti, righe con le seguenti informazioni (parziali):

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

Non sembra molto, ma ora prendi quella parte 0x della descrizione, e poi fai:

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

Pistola fumante! Questa è la persona responsabile di quell'evento.

Naturalmente, se usano la ALTER LOGINsintassi per tutte le operazioni (che dovrebbero usare invece di sp_password), non è possibile distinguere tra qualcuno che modifica il database predefinito e qualcuno che cambia la password. Inoltre non puoi dire (almeno che posso vedere) quale accesso ha interessato questo, solo che questa persona ha cambiato un accesso. Jon sembra pensare che anche queste informazioni siano nel registro, ma non sono riuscito a trovarle (a differenza delle informazioni temporali, che in qualche modo ho fatto scorrere oltre).


Potrebbero esserci risposte diverse per gli utenti contenuti in SQL Server 2012, anche se sospetto che le modifiche alla password siano ancora offuscate in modi simili. Lo lascerò per una domanda separata.


Penso che potresti usare fn_dblog/ fn_dump_dblogcontro master(o una sua copia) per capire quale entità è stata cambiata, anche se devi fare lo spelunk usando DBCC PAGE.
Jon Seigel,

Cerca il LOP_XACT_BEGINper quello che Transaction IDhai trovato. Conterrà l'ora esatta e il SID dell'account di accesso che lo ha avviato.
Remus Rusanu,

@Jon penseresti di sì, ma ID pagina e ID slot sono NULL.
Aaron Bertrand

Deve esserci un modo per SQL di sapere come ripristinare la transazione ... forse non sta semplicemente esponendo quei valori nel TVF anche se in realtà sono lì.
Jon Seigel,

@Jon vai avanti e dai un'occhiata DBCC LOG(master,3);(o fn_dblog()equivalente) e vedi se riesci a individuare qualcosa che possa aiutare a identificare il bersaglio. Quando lo faccio BEGIN TRANSACTION; ALTER LOGIN...ottengo informazioni ancora meno utili, che scompaiono se eseguo il rollback e diventano le precedenti se commetto.
Aaron Bertrand

4

questo è più lungo di un commento, postando come risposta

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)

1
@RemusRusanu Questo sarà utile solo se stai interrogando direttamente ciò che è nel T-log, ma se provi a leggere da un backup T-log, i SID verrebbero tagliati. Inoltre, ogni volta che viene chiamato fn_dump_dblog, crea un nuovo programmatore SQLOS nascosto e fino a tre thread, che non andranno mai via e non verranno mai riutilizzati.
Kin Shah,

1

È possibile utilizzare il trigger DDL a livello di server (si noti che per questo esempio è necessario abilitare e impostare la funzione Posta elettronica database SQL Server):

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 = 'name@domain.com'
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
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.