Чи є спосіб дізнатися, хто змінив пароль для входу?


11

Я намагаюся з’ясувати, хто змінив пароль для входу в SQL Server 2008 R2.

Я вже перевірив трасування за замовчуванням - і він не реєструє цю подію. Трасування за замовчуванням буде включати ці події, пов’язані з безпекою:

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

Крім того, заглянули в резервну копію журналу транзакцій, щоб дізнатися це, але не пощастило.

Чи є якийсь інший спосіб це дізнатися?

Також я знаю, що слід стороні сервера допоможе, але, на жаль, в сторону нашого сервера ми не включили Audit Login Change Password Event.

Найкраща стаття, яку я знайшов, - це від Aaron Bertrand: Відстеження змін пароля для входу в SQL Server


2
Я б створив одну з пропозицій Аарона, а потім створити резервну копію поточного хеша для паролів і десь змінити пароль. Подивіться, хто кричить .. або якщо це просто випадково зміниться назад, тоді у вас є слід, щоб їх зловити.
Кеннет Фішер

Не зовсім зрозуміло, чи змінено пароль для отримання доступу чи для запобігання чужому доступу. Просто констатуючи це тому, що хтось може не кричати. Кін також може не знати, що таке початковий пароль.
Аарон Бертран

Оригінальний пароль можна скинути за допомогою хеша (запитайте мене, як я знаю, ха-ха), який повинен бути десь у журналі транзакцій.
Джон Сейгель

Відповіді:


11

Моя стаття допоможе, якщо ви її встановили заздалегідь, але не тоді, коли подія траплялася в минулому, і у вас не було створено жодного механізму аудиту.

Надія все ж є. Скажімо, я зробив це:

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

Ця інформація знаходиться у сліді за замовчуванням у EventClass 104 (Аудит події Addlogin). Однак якщо я змінив пароль, використовуючи будь-який із цих способів:

ALTER LOGIN flooberella WITH PASSWORD = N'y';

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

Ці події не зафіксовані за замовчуванням, з очевидних причин безпеки - особам, які мають доступ до тракту за замовчуванням, не повинно бути зрозумілим, що таке чужий пароль, і не хочуть спростити це навіть зрозуміти, що це був змінений пароль (наприклад, опитування частоти цих подій може виявити певні властивості вашої стратегії безпеки).

То що ще можна зробити? Хоча це спирається на інформацію, яка все ще перебуває в журналі, а також покладається на використання незадокументованої команди DBCC проти системної бази даних (ви можете створити резервну копію головного майстра та відновити його в іншому місці), ви можете отримати деяку інформацію з журналу транзакцій, наприклад:

DBCC LOG(master, 1);

Це дасть для цих двох команд рядки з наступною (частковою) інформацією:

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

Здається, не так вже й багато, але тепер візьміть цю частину 0x опису, а потім виконайте:

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

Курильний пістолет! Це людина, відповідальна за цю подію.

Звичайно, якщо вони використовують ALTER LOGINсинтаксис для всіх операцій (які вони повинні використовувати замість них sp_password), ви не зможете розрізнити, хто змінить базу даних за замовчуванням і хтось змінить пароль. Ви ж не можете сказати (по крайней мере , що я можу бачити) , що увійти в цей постраждалих, тільки ця людина змінила на вхід в систему . Джон, здається, вважає, що ця інформація є і в журналі, але я не зміг її знайти (на відміну від інформації про час, яку я якось прокручував прямо в минуле).


Користувачі, що містяться в SQL Server 2012, можуть мати різні відповіді, хоча я підозрюю, що зміни пароля все ще приховуються аналогічно. Залишимо це для окремого питання.


Я думаю, ви могли б скористатися fn_dblog/ fn_dump_dblogпроти master(або його копією), щоб визначити, яка основна зміна була змінена, навіть якщо вам доведеться проаналізувати використання DBCC PAGE.
Джон Сейгель

Шукайте LOP_XACT_BEGINдля Transaction IDвас знайшли. Він буде містити точний час та SID логіна, який його запустив.
Рем Русану

@ Ви можете так подумати, але ідентифікатор сторінки та ідентифікатор місця - НУЛІ.
Аарон Бертран

Повинен бути спосіб для SQL знати, як відмовити транзакцію ... можливо, це просто не виставляє цих значень у TVF, хоча вони насправді є.
Джон Сейгель

@Jon продовжуйте і подивіться DBCC LOG(master,3);(або його fn_dblog()еквівалент) і побачите, чи зможете ви помітити щось, що допоможе визначити ціль. Коли я це роблю, BEGIN TRANSACTION; ALTER LOGIN...я отримую ще менш корисну інформацію, яка зникає, якщо я відкочуюсь назад, і стає вищезазначеною, якщо я виконую.
Аарон Бертран

4

це довше, ніж коментар, розміщення як відповідь

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 Це буде корисно лише в тому випадку, якщо ви безпосередньо запитуєте, що в T-журналі, але якщо ви спробуєте прочитати з резервної копії T-журналу, SID будуть відсічені. Також кожен раз, коли викликається fn_dump_dblog, він створює новий прихований планувальник SQLOS і до трьох потоків, який ніколи не згасне і ніколи не буде використаний повторно.
Кін Шах

1

Ви можете використовувати тригер DDL на рівні сервера (зауважте, що для цього прикладу ви повинні увімкнути та встановити функцію поштової бази даних 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
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.