Existe uma maneira de descobrir quem alterou a senha para um login?

11

Estou tentando descobrir quem alterou a senha para um logon no SQL Server 2008 R2.

Eu já verifiquei o rastreamento padrão - e ele não registra esse evento. O rastreamento padrão incluirá estes eventos relacionados à segurança:

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

Além disso, analisou o backup do log de transações para descobrir isso, mas sem sorte.

Existe alguma outra maneira de descobrir isso?

Além disso, estou ciente de que um rastreamento do lado do servidor ajudará, mas, infelizmente, no rastreamento do lado do servidor, não incluímos o Audit Login Change Password Event.

O melhor artigo que encontrei é de Aaron Bertrand: Rastreando alterações de senha de logon no SQL Server

Kin Shah
fonte
2
Eu configuraria uma das sugestões de Aaron e depois faria o backup do hash da senha atual em algum lugar e depois mudaria a senha novamente. Veja quem grita ... ou, se for mudado aleatoriamente de volta, você tem o rastro para pegá-los.
Kenneth Fisher
Não está totalmente claro se a senha foi alterada para obter acesso ou impedir o acesso de outra pessoa. Apenas afirmando isso porque alguém pode não gritar. Os Kin também podem não saber qual era a senha original.
Aaron Bertrand
A senha original pode ser redefinida usando o hash (pergunte-me como eu sei haha), que deve estar em algum lugar no log de transações.
precisa saber é o seguinte

Respostas:

11

Meu artigo ajudará se você o configurar com antecedência, mas não quando o evento aconteceu no passado e você não tiver nenhum tipo de mecanismo de auditoria configurado.

Ainda há esperança, no entanto. Digamos que eu fiz isso:

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

Essas informações estão no rastreamento padrão em EventClass 104 (Audit Addlogin Event). No entanto, se eu alterar a senha usando um destes métodos:

ALTER LOGIN flooberella WITH PASSWORD = N'y';

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

Esses eventos não são capturados pelo rastreamento padrão, por razões óbvias de segurança - não deve ser possível para qualquer pessoa com acesso ao rastreamento padrão descobrir qual é a senha de outra pessoa, nem deseja facilitar a descoberta de que uma senha foi alterada (pesquisar a frequência desses eventos, por exemplo, pode revelar certas propriedades da sua estratégia de segurança).

Então o que mais você faz? Enquanto isso depende das informações ainda estarem no log e também do uso de um comando DBCC não documentado em um banco de dados do sistema (você pode fazer backup do mestre e restaurá-lo em outro lugar), é possível obter algumas informações do log de transações, por exemplo:

DBCC LOG(master, 1);

Isso produzirá, para os dois comandos acima, linhas com as seguintes informações (parciais):

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

Não parece muito, mas agora pegue essa parte 0x da descrição e faça:

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

Arma de fumar! Essa é a pessoa responsável por esse evento.

Obviamente, se eles usarem ALTER LOGINsintaxe para todas as operações (que deveriam usar em vez de sp_password), não será possível distinguir entre alguém alterando o banco de dados padrão e alguém alterando a senha. Você também não pode dizer (pelo menos que eu posso ver) qual login afetou, apenas que essa pessoa alterou um login. Jon parece achar que essa informação também está no log, mas não consegui encontrá-la (ao contrário da informação de tempo, que de alguma forma eu passei direto).


Pode haver respostas diferentes para usuários contidos no SQL Server 2012 - embora eu suspeite que as alterações de senha ainda sejam ofuscadas de maneiras semelhantes. Deixará isso para uma pergunta separada.

Aaron Bertrand
fonte
Eu acho que você poderia usar fn_dblog/ fn_dump_dblogcontra master(ou uma cópia) para descobrir qual principal foi alterada, mesmo se você precisar digitar usando DBCC PAGE.
precisa
Procure LOP_XACT_BEGINo Transaction IDque encontrou. Ele conterá a hora exata e o SID do logon que o iniciou.
Remus Rusanu 16/01
@ Jon, você acha que sim, mas o ID da página e o slot são nulos.
Aaron Bertrand
É necessário que o SQL saiba como reverter a transação ... talvez não exponha esses valores no TVF, mesmo que eles estejam realmente lá.
Jon Seigel
@Jon vá em frente e dê uma olhada DBCC LOG(master,3);(ou fn_dblog()equivalente) e veja se você consegue identificar algo que possa ajudar a identificar o alvo. Quando eu BEGIN TRANSACTION; ALTER LOGIN...recebo informações ainda menos úteis, que desaparecem se eu reverter e se tornarão as acima se eu confirmar.
Aaron Bertrand
4

isso é mais longo que um comentário, postando como resposta

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
fonte
1
@RemusRusanu Isso só será útil se você estiver consultando diretamente o que está no log T, mas se você tentar ler a partir de um backup T-log, os SIDs serão cortados. Além disso, toda vez que o fn_dump_dblog é chamado, ele cria um novo planejador oculto do SQLOS e até três threads, que nunca desaparecem e nunca são reutilizados.
Kin Shah
1

Você pode utilizar o gatilho DDL no nível do servidor (observe que, neste exemplo, você deve ter o recurso Correio do Banco de Dados do SQL Server ativado e definido):

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
fonte