Có cách nào để tìm ra ai đã thay đổi mật khẩu để đăng nhập không?


11

Tôi đang cố gắng tìm ra ai đã thay đổi mật khẩu để đăng nhập trong SQL Server 2008 R2.

Tôi đã kiểm tra theo dõi mặc định - và nó không ghi lại sự kiện đó. Theo dõi mặc định sẽ bao gồm các sự kiện liên quan đến bảo mật:

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

Ngoài ra, xem xét sao lưu nhật ký giao dịch để tìm ra điều đó, nhưng không có may mắn.

Có cách nào khác để tìm ra nó?

Ngoài ra, tôi biết rằng theo dõi phía máy chủ sẽ giúp ích, nhưng thật không may trong theo dõi phía máy chủ của chúng tôi, chúng tôi không bao gồm Audit Login Change Password Event.

Bài viết hay nhất mà tôi tìm thấy là từ Aaron Bertrand: Theo dõi thay đổi mật khẩu đăng nhập trong SQL Server


2
Tôi sẽ thiết lập một trong những gợi ý của Aaron sau đó sao lưu mật khẩu băm hiện tại ở đâu đó và sau đó thay đổi mật khẩu trở lại. Xem ai hét lên .. hoặc nếu nó chỉ được thay đổi ngẫu nhiên trở lại thì bạn có dấu vết để bắt chúng.
Kenneth Fisher

Không hoàn toàn rõ ràng liệu mật khẩu đã được thay đổi để có quyền truy cập hay để ngăn chặn quyền truy cập của người khác. Chỉ cần nói rằng bởi vì ai đó có thể không hét lên. Kin cũng có thể không biết mật khẩu ban đầu là gì.
Aaron Bertrand

Mật khẩu ban đầu có thể được đặt lại bằng cách sử dụng hàm băm (hỏi tôi làm thế nào tôi biết haha), mật khẩu sẽ ở đâu đó trong nhật ký giao dịch.
Jon Seigel

Câu trả lời:


11

Bài viết của tôi sẽ giúp ích nếu bạn thiết lập trước, nhưng không phải khi sự kiện xảy ra trong quá khứ và bạn không có bất kỳ loại cơ chế kiểm toán nào được thiết lập.

Vẫn còn hy vọng. Hãy nói rằng tôi đã làm điều này:

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

Thông tin này nằm trong theo dõi mặc định trong EventClass 104 (Sự kiện Addlogin Audit). Tuy nhiên, nếu tôi thay đổi mật khẩu bằng một trong hai phương pháp sau:

ALTER LOGIN flooberella WITH PASSWORD = N'y';

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

Những sự kiện này không bị bắt bởi dấu vết mặc định, vì lý do bảo mật rõ ràng - không ai có thể truy cập vào dấu vết mặc định để tìm ra mật khẩu của người khác, và họ cũng không muốn dễ dàng phát hiện ra rằng một mật khẩu đã được thay đổi (ví dụ, việc thăm dò tần suất của các sự kiện này có thể tiết lộ một số thuộc tính nhất định của chiến lược bảo mật của bạn).

Vậy bạn có thể làm gì khác? Mặc dù điều này phụ thuộc vào thông tin vẫn còn trong nhật ký và nó cũng dựa vào việc sử dụng lệnh DBCC không có giấy tờ đối với cơ sở dữ liệu hệ thống (bạn có thể muốn sao lưu chính và khôi phục nó ở nơi khác), bạn có thể lấy một số thông tin từ nhật ký giao dịch, ví dụ:

DBCC LOG(master, 1);

Điều này sẽ mang lại, cho hai lệnh trên, các hàng có thông tin (một phần) sau:

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

Có vẻ như không nhiều, nhưng bây giờ hãy lấy phần 0x của mô tả và sau đó thực hiện:

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

Súng hút thuốc! Đây là người chịu trách nhiệm cho sự kiện đó.

Tất nhiên, nếu họ sử dụng ALTER LOGINcú pháp cho tất cả các hoạt động (mà họ nên sử dụng thay vì sp_password), bạn không thể phân biệt giữa ai đó thay đổi cơ sở dữ liệu mặc định và ai đó thay đổi mật khẩu. Bạn cũng không thể nói (ít nhất mà tôi có thể nhìn thấy) mà đăng nhập này bị ảnh hưởng, chỉ rằng người này đã thay đổi một đăng nhập. Jon dường như nghĩ rằng thông tin này cũng có trong nhật ký, nhưng tôi đã không tìm thấy nó (không giống như thông tin về thời gian, bằng cách nào đó tôi đã cuộn qua quá khứ).


Có thể có các câu trả lời khác nhau cho người dùng có trong SQL Server 2012 - mặc dù tôi nghi ngờ các thay đổi mật khẩu vẫn bị che giấu theo những cách tương tự. Sẽ để lại cho một câu hỏi riêng biệt.


Tôi nghĩ rằng bạn có thể sử dụng fn_dblog/ fn_dump_dblogchống lại master(hoặc một bản sao của nó) để tìm ra hiệu trưởng nào đã được thay đổi, ngay cả khi bạn phải sử dụng trò chơi DBCC PAGE.
Jon Seigel

Tìm kiếm cho LOP_XACT_BEGINcác Transaction IDbạn tìm thấy. Nó sẽ chứa thời gian chính xác và SID của thông tin đăng nhập đã bắt đầu nó.
Remus Rusanu

@ Bạn nghĩ như vậy, nhưng ID trang và ID Slot là NULL.
Aaron Bertrand

Phải có một cách để SQL biết cách khôi phục giao dịch ... có thể đó không phải là phơi bày những giá trị đó trong TVF mặc dù chúng thực sự ở đó.
Jon Seigel

@Jon đi trước và xem DBCC LOG(master,3);(hoặc fn_dblog()tương đương) và xem nếu bạn có thể phát hiện bất cứ điều gì sẽ giúp xác định mục tiêu. Khi tôi làm, BEGIN TRANSACTION; ALTER LOGIN...tôi nhận được thông tin ít hữu ích hơn , nó sẽ biến mất nếu tôi quay lại và trở thành bên trên nếu tôi cam kết.
Aaron Bertrand

4

Điều này dài hơn một bình luận, đăng dưới dạng câu trả lời

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 Điều này sẽ chỉ hữu ích nếu bạn đang truy vấn trực tiếp những gì trong nhật ký T, nhưng nếu bạn cố đọc từ bản sao lưu T-log, SID sẽ bị cắt nhỏ. Ngoài ra, mỗi khi fn_dump_dblog được gọi, nó sẽ tạo một bộ lập lịch SQLOS ẩn mới và tối đa ba luồng, sẽ không bao giờ biến mất và không bao giờ được sử dụng lại.
Kin Shah

1

Bạn có thể sử dụng trình kích hoạt DDL ở cấp máy chủ (lưu ý rằng trong ví dụ này, bạn phải bật và đặt tính năng Thư cơ sở dữ liệu 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
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.