Журнал входа пользователей в windows server

При расследовании различных инцидентов администратору необходимо получить информацию кто и когда заходил на определенный компьютер Windows. Историю входов пользователя в доменной сети можно получить из журналов контроллеров домена. Но иногда проще получить информацию непосредсвенно из логов компьютера. В этой статье мы покажем, как получить и проанализировать историю входа пользователей на компьютер/сервер Windows. Такая статистика поможет вам ответить на вопрос “Как в Windows проверить кто и когда использовал этот компьютере”.

Настройка политики аудита входа пользователей в Windows

Сначала нужно включить политик аудита входа пользователей. На отдельностоящем компьютере для настройки параметров локальной групповой политики используется оснастка gpedit.msc. Если вы хотите включить политику для компьютеров в домене Active Directorty, нужно использовать редактор доменных GPO (
gpmc.msc
).

1. Запустите консоль GPMC, создайте новую GPO и назначьте ее на Organizational Units (OU) с компьютерами и / или серверами, для которых вы хотите включить политику аудита событий входа;
2. Откройте объект GPO и перейдите в раздел Computer Configuration -> Policies -> Windows Settings -> Security Settings –> Advanced Audit Policy Configuration -> Audit Policies -> Logon/Logoff;
3. Включите две политики аудита Audit Logon и Audit Logoff. Это позволит отслеживать как события входа, так и события выхода пользователей. Если вы хотите отслеживать только успешные события входа, включите в настройках политик только опцию Success;
4. Закройте редактор GPO и обновите настройки политик на клиентах.

Поиск событий входа пользователей в журнале событий Windows

После того как вы включили политики аудита входа, при каждом входе пользователя в Windows в журнале Event Viewer будет появляться запись о входе. Посмотрим, как она выглядит.

1. Откройте оснастку Event Viewer (
   eventvwr.msc
   );
2. Разверните секцию Windows Logs и выберите журнал Security;
3. Щелкните по нему правой клавишей и выберите пункт Filter Current Log;
4. В поле укажите ID события 4624 и нажмите OK;
5. В окне события останутся только события входа пользователей, системных служб с описанием
   An account was successfully logged on
   ;
6. В описании события указано имя и домен пользователя, вошедшего в систему:

   New Logon:
   Security ID: WINITPROa.khramov
   Account Name: a.khramov
   Account Domain: WINITPRO

Если полистать журнал событий, можно заметить, что в нем присутствуют не только события входа пользователей на компьютер. Здесь также будут события сетевого доступа к этому компьютеру (при открытии по сети общих файлов или печати на сетевых принтерах), запуске различных служб и заданий планировщика и т.д. Т.е. очень много лишний событий, которые не относятся ко входу локального пользователя. Чтобы выбрать только события интерактивного входа пользователя на консоль компьютера, нужно дополнительно сделать выборку по значению параметра Logon Type. В таблице ниже перечислены коды Logon Type.

При удаленном подключении к рабочему столу компьютера по RDP, в журнале событий появится записи с Logon Type 10 или 3. Подробнее об анализе RDP логов в Windows.

В соответствии с этой таблицей событие локального входа пользователя на компьютер должно содержать Logon Type: 2.

Для фильтрации события входа по содержать Logon Type лучше использовать PowerShell.

Анализ событий входа пользователей в Windows с помощью PowerShell

Допустим, наша задача получить информацию о том, какие пользователи входили на этот компьютер за последнее время. Нам интересует именно события интерактивного входа (через консоль) с
LogonType =2
. Для выбора события из журналов Event Viewer мы воспользуемся командлетом Get-WinEvent.

Следующий PowerShell скрипт выведет история входа пользователей на текущий компьютер и представит ее в виде графической таблицы Out-GridView.

$query = @'
<QueryList>
<Query Id='0' Path='Security'>
<Select Path='Security'>
*[System[EventID='4624']
and(
EventData[Data[@Name='VirtualAccount']='%%1843']
and
EventData[Data[@Name='LogonType']='2']
)
]
</Select>
</Query>
</QueryList>
'@
$properties = @(
@{n='User';e={$_.Properties[5].Value}},
@{n='Domain';e={$_.Properties[6].Value}},
@{n='TimeStamp';e={$_.TimeCreated}}
@{n='LogonType';e={$_.Properties[8].Value}}
)
Get-WinEvent -FilterXml $query | Select-Object $properties|Out-GridView

Если нужно выбрать события входа за последние несколько дней, можно добавить pipe с таким условием:

|Where-Object {$_.TimeStamp -gt '5/10/22'}

Командлет Get-WinEvent позволяет получить информацию с удаленных компьютеров. Например, чтобы получить историю входов с двух компьютеров, выполните следующий скрипт:

'msk-comp1', 'msk-comp2' |
ForEach-Object {
Get-WinEvent -ComputerName $_ -FilterXml $query | Select-Object $properties
}

Вы когда-нибудь хотели следить за тем, кто и когда входил в систему, установленную на вашем компьютере. На профессиональных изданиях Windows специально для этого существует политика аудита входа, о которой мы сейчас и поговорим.

«Аудит событий входа в систему» отслеживает как локальные, так и сетевые входы. При каждом входе определяется учетная запись пользователя и время, в которое состоялся вход. Также вы сможете узнать, когда пользователь вышел из системы.

Включаем «Аудит входа в систему»

Во-первых, откройте «Редактор локальной групповой политики» – откройте меню «Пуск», в поисковую строку введите gpedit.msc и нажмите Enter.

В левой части окна проследуйте по следующему пути: Конфигурация компьютера -> Конфигурация Windows -> Параметры безопасности -> Локальные политики -> Политика аудита.

Дважды кликните по политике «Аудит событий входа в систему» в правой части окна. В диалоговом окне «Свойства» отметьте галочкой параметр «Успех» для того, чтобы позволить отслеживание успешных входов в систему. Также вы можете включить параметр «Отказ» – так вы позволите отслеживание неудачных попыток входа.

Просматриваем события входа в систему

После включения этого параметра, Windows начнет регистрировать (в журнал безопасности) все события входа в систему, в том числе имя пользователя и время. Чтобы увидеть эти события, запустите инструмент «Просмотр событий» – откройте меню «Пуск», в строку поиска введите текст «Просмотр событий» и нажмите клавишу Enter.

Далее перейдите в «Журналы Windows» и выберите категорию «Безопасность». Нас интересуют события с кодом 4624 – это события успешного входа в систему.

Чтобы увидеть больше информации, включая имя учетной записи пользователя, входившего в систему, дважды щелкните по событию. Прокручивая вниз текстовое поле, вы увидите всю необходимую информацию.

Если вы хотите, чтобы в журнале безопасности отображались исключительно события входа, нажмите на кнопку «Фильтровать текущий журнал», которая расположена в боковой панели справа и в появившемся окне отфильтруйте события как на скриншоте ниже:

Отличного Вам дня!

Это значит, что за прошедшие сутки таких событий не найдено.

Скрипт который вы запустили:

1. Ищет события за последние сутки от момента запуска — (Date).AddDays(-1). Можете поменять -1 на больший интервал.
2. Ищет события, у которых LogonType = 2, т.е. интерактивный вход/выход в систему. Подробности здесь.

Этот код использует тот же Get-WinEvent из PowerShell, вот только выбирает он события о терминальном входе в систему (RemoteInteractive), о чём вы забыли уточнить в изначальном запросе + диапазон в вашем примере почти два года.

А вот учитывая, что вам необходимо выбирать события за очень длительный срок, выбор xml-фильтра, действительно более оправдан, т.к. Get-WinEvent с хеш-фильтром обрабатывает Security-журнал намного дольше (где-то даже есть об этом статья).

Однако, ваш код не выбирает события выхода и не показывает неудачные попытки. Если это добавить, получится примерно так:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62

<#
Logon Type Description
 
2   Interactive (logon at keyboard and screen of system)
3   Network (i.e. connection to shared folder on this computer from elsewhere on network)
4   Batch (i.e. scheduled task)
5   Service (Service startup)
7   Unlock (i.e. unnattended workstation with password protected screen saver)
8   NetworkCleartext (Logon with credentials sent in the clear text. Most often indicates a logon to IIS with "basic authentication") See this article for more information.
9   NewCredentials such as with RunAs or mapping a network drive with alternate credentials.  This logon type does not seem to show up in any events.  If you want to track users attempting to logon with alternate credentials see 4648.  MS says "A caller cloned its current token and specified new credentials for outbound connections. The new logon session has the same local identity, but uses different credentials for other network connections."
10  RemoteInteractive (Terminal Services, Remote Desktop or Remote Assistance)
11  CachedInteractive (logon with cached domain credentials such as when logging on to a laptop when away from the network)
 
#>
 
$EndDate = date
$StartDate = $EndDate.AddDays(-365)
 
$LogonType = 10
$csvFile = 'c:tempreport.csv'
$ComputerName = 'localhost'
 
 
$time = [int64](New-TimeSpan $StartDate $EndDate).TotalMilliseconds
$xmlFilter = "*[System[TimeCreated[timediff(@SystemTime) < $time] and (EventID=4624 or EventID=4634)] and EventData[Data[@Name='LogonType']=$LogonType]]"
 
Get-WinEvent -ComputerName $ComputerName -FilterXPath $xmlFilter -LogName Security | %{
    
    $event = $_
    
    $xmlEvent = [xml]$event.ToXml()
    $EventData = New-Object PSObject
    $xmlEvent.event.EventData.Data | % {$EventData | Add-Member NoteProperty $_.Name $_."#text"}
    
    [pscustomobject][ordered]@{
        EventId =     $event.Id
        DateCreated = $event.TimeCreated.ToShortDateString()
        TimeCreated = $event.TimeCreated.ToLongTimeString()
        Task        = "$($event.TaskDisplayName)"
        Keywords    = "$($event.KeywordsDisplayNames)"
        User        = $EventData.TargetUserName
        IP          = $EventData.IpAddress
        LogonType   = switch ($EventData.LogonType)
                      {
                        2  {'Interactive'}
                        3  {'Network'}
                        4  {'Batch'}
                        5  {'Service'}
                        7  {'Unlock'}
                        8  {'NetworkCleartext'}
                        9  {'NewCredentials'}
                        10 {'RemoteInteractive'}
                        11 {'CachedInteractive'}
                        Default {$EventData.LogonType}
                      }
 
    }
 
} | Export-Csv -Encoding UTF8 -Path $csvFile -NoTypeInformation -Delimiter ";"
 
cls
Import-Csv $csvFile -Delimiter ';' | ft -a

При расследовании различных инцидентов администратору необходимо получить информацию кто и когда заходил на определенный компьютер Windows. Историю входов пользователя в доменной сети можно получить из журналов контроллеров домена. Но иногда проще получить информацию непосредсвенно из логов компьютера. В этой статье мы покажем, как получить и проанализировать историю входа пользователей на компьютер/сервер Windows. Такая статистика поможет вам ответить на вопрос “Как в Windows проверить кто и когда использовал этот компьютере”.

Сначала нужно включить политик аудита входа пользователей. На отдельностоящем компьютере для настройки параметров локальной групповой политики используется оснастка gpedit.msc. Если вы хотите включить политику для компьютеров в домене Active Directorty, нужно использовать редактор доменных GPO (
gpmc.msc
).

1. Запустите консоль GPMC, создайте новую GPO и назначьте ее на Organizational Units (OU) с компьютерами и / или серверами, для которых вы хотите включить политику аудита событий входа;
2. Откройте объект GPO и перейдите в раздел Computer Configuration -> Policies -> Windows Settings -> Security Settings –> Advanced Audit Policy Configuration -> Audit Policies -> Logon/Logoff;
3. Включите две политики аудита Audit Logon и Audit Logoff. Это позволит отслеживать как события входа, так и события выхода пользователей. Если вы хотите отслеживать только успешные события входа, включите в настройках политик только опцию Success;
4. Закройте редактор GPO и обновите настройки политик на клиентах.

Поиск событий входа пользователей в журнале событий Windows

После того как вы включили политики аудита входа, при каждом входе пользователя в Windows в журнале Event Viewer будет появляться запись о входе. Посмотрим, как она выглядит.

1. Откройте оснастку Event Viewer (
   eventvwr.msc
   );
2. Разверните секцию Windows Logs и выберите журнал Security;
3. Щелкните по нему правой клавишей и выберите пункт Filter Current Log;
4. В поле укажите ID события 4624 и нажмите OK;
5. В окне события останутся только события входа пользователей, системных служб с описанием
   An account was successfully logged on
   ;
6. В описании события указано имя и домен пользователя, вошедшего в систему:

   New Logon:
   Security ID: WINITPROa.khramov
   Account Name: a.khramov
   Account Domain: WINITPRO

Если полистать журнал событий, можно заметить, что в нем присутствуют не только события входа пользователей на компьютер. Здесь также будут события сетевого доступа к этому компьютеру (при открытии по сети общих файлов или печати на сетевых принтерах), запуске различных служб и заданий планировщика и т.д. Т.е. очень много лишний событий, которые не относятся ко входу локального пользователя. Чтобы выбрать только события интерактивного входа пользователя на консоль компьютера, нужно дополнительно сделать выборку по значению параметра Logon Type. В таблице ниже перечислены коды Logon Type.

При удаленном подключении к рабочему столу компьютера по RDP, в журнале событий появится записи с Logon Type 10 или 3. Подробнее об анализе RDP логов в Windows.

В соответствии с этой таблицей событие локального входа пользователя на компьютер должно содержать Logon Type: 2.

Для фильтрации события входа по содержать Logon Type лучше использовать PowerShell.

Анализ событий входа пользователей в Windows с помощью PowerShell

Допустим, наша задача получить информацию о том, какие пользователи входили на этот компьютер за последнее время. Нам интересует именно события интерактивного входа (через консоль) с
LogonType =2
. Для выбора события из журналов Event Viewer мы воспользуемся командлетом Get-WinEvent.

Следующий PowerShell скрипт выведет история входа пользователей на текущий компьютер и представит ее в виде графической таблицы Out-GridView.

$query = @'
<QueryList>
<Query Id='0' Path='Security'>
<Select Path='Security'>
*[System[EventID='4624']
and(
EventData[Data[@Name='VirtualAccount']='%%1843']
and
EventData[Data[@Name='LogonType']='2']
)
]
</Select>
</Query>
</QueryList>
'@
$properties = @(
@{n='User';e={$_.Properties[5].Value}},
@{n='Domain';e={$_.Properties[6].Value}},
@{n='TimeStamp';e={$_.TimeCreated}}
@{n='LogonType';e={$_.Properties[8].Value}}
)
Get-WinEvent -FilterXml $query | Select-Object $properties|Out-GridView

Если нужно выбрать события входа за последние несколько дней, можно добавить pipe с таким условием:

|Where-Object {$_.TimeStamp -gt '5/10/22'}

Командлет Get-WinEvent позволяет получить информацию с удаленных компьютеров. Например, чтобы получить историю входов с двух компьютеров, выполните следующий скрипт:

'msk-comp1', 'msk-comp2' |
ForEach-Object {
Get-WinEvent -ComputerName $_ -FilterXml $query | Select-Object $properties
}

Здравствуйте, уважаемое сообщество!

ИТ-инфраструктура всегда находится в динамике. Тысячи изменений происходят ежеминутно. Многие из них требуется регистрировать. Аудит систем является неотъемлемой частью информационной безопасности организаций. Контроль изменений позволяет предотвратить серьезные происшествия в дальнейшем.

В статье я хочу рассказать о своем опыте отслеживания событий входа (и выхода) пользователей на серверах организации, подробно описать те детали, которые возникли в ходе выполнения задачи анализа логов аудита, а также привести решение этой задачи по шагам.

Цели, которые мы преследуем:

• Контроль ежедневных подключений пользователей к серверам организации, в том числе терминальным.
• Регистрация события, как от доменных пользователей, так и от локальных.
• Мониторинг рабочей активности пользователя (приход/уход).
• Контроль подключений ИТ-подразделений к серверам ИБ.

Для начала необходимо включить аудит и записывать события входа в журнал Windows. В качестве контроллера домена нам предоставлен Windows Server 2008 R2. Включив аудит, потребуется извлекать, фильтровать и анализировать события, определенные политикой аудита. Кроме того, предполагается отправка в третью систему на анализ, например, в DLP. В качестве альтернативы предусмотрим возможность формирования отчета в Excel.

Анализ логов является рутинной операцией системного администратора. В данном случае объёмы фиксируемых событий в домене таковы, что это само по себе сложно. Аудит включается в групповой политике.

События входа в систему формируются:

1. контроллерами домена, в процессе проверки учетных записей домена;
2. локальными компьютерами при работе с локальными учетными записями.

Если включены обе категории политик (учетных записей и аудита), то входы в систему, использующие учетную запись домена, будут формировать события входа или выхода на рабочей станции или сервере и событие входа в систему на контроллере домена. Таким образом, аудит на доменные машины потребуется настроить через оснастку GPO на контроллере, аудит локальный — через локальную политику безопасности с помощью оснастки MMC.

Настройка аудита и подготовка инфраструктуры:

Рассмотрим этот этап подробно. Для уменьшения объемов информации мы смотрим только успешные события входа и выхода. Имеет смысл увеличить размер журнала security Windows. По умолчанию — это 128 Мегабайт.

Для настройки локальной политики:

Открываем редактор политик – Пуск, в строке поиска пишем gpedit.msc и нажимаем Ввод.
Открываем следующий путь: Local Computer Policy → Computer Configuration → Windows Settings → Security Settings → Local Policies → Audit Policy.

Дважды кликаем параметр групповой политики Audit logon events (аудит входа в систему) и Audit account logon events (аудит событий входа в систему). В окне свойств устанавливаем Success-чекбокс для записи в журнал успешных входов в систему. Чекбокс Failure устанавливать не рекомендую во избежание переполнения. Для применения политики необходимо набрать в консоли gpupdate /force

Для настройки групповой политики:

Создаем новый объект GPO (групповую политику) с именем «Audit AD». Переходим в раздел редактирования и разворачиваем ветку Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Configuration. В данной ветке групповых политик находятся расширенные политики аудита, которые можно активировать в ОС семейства Windows для отслеживания различных событий. В Windows 7 и Windows Server 2008 R2 количество событий, для которых можно осуществлять аудит увеличено до 53. Эти 53 политики аудита (т.н. гранулярные политики аудита) находятся в ветке Security SettingsAdvanced Audit Policy

Configuration и сгруппированы в десяти категориях:

Включаем:

• Account Logon – аудит проверки учетных данных, службы проверки подлинности Kerberos, операций с билетами Kerberos и других события входа;
• Logon/Logoff – аудит интерактивных и сетевых попыток входа на компьютеры и сервера домена, а также блокировок учетных записей.

После изменений выполняем gpupdate /force.

Сразу оговорим типы событий, которые будет анализировать наш будущий скрипт:

1. Remote access — удаленный вход через RDP-сессию.
2. Interactive — локальный вход пользователя с консоли.
3. Computer unlocked — разблокировка заблокированной станции.
4. Logoff — выход из системы.

В Windows 2008 событие успешного входа имеет идентификатор Event ID 4624, а logoff — Event ID 4672. Необходимо выбрать инструмент, позволяющий проанализировать огромное количество записей. Казалось бы, все можно написать, используя штатные инструменты. Однако, запросы на Powershell вида

get-eventlog security | where  {$_.EventId -eq 4624 -and ($_.TimeGenerated.TimeOfDay
 -gt '08:00:00'  )}

хорошо себя показывают только на стенде с контроллером домена на два пользователя. В продакшене средах сбор логов с сервера занимал по 20 минут. Поиски решения привели к утилите LOG PARSER , ранее обзорно рассмотренной на Хабре.

Скорость обработки данных возросла в разы, полный прогон с формированием отчета с одного ПК сократился до 10 секунд. Утилита использует немало опций командной строки, поэтому мы будем вызывать cmd из powershell, чтобы избавиться от экранирования кучи специальных символов. Для написания запросов можно воспользоваться GUI — Log Parser Lizard. Он не бесплатен, но триального периода в 65 дней хватает. Ниже привожу сам запрос. Помимо интересующих нас, распишем и другие варианты входа в систему, на случай дальнейшего использования.

SELECT 
eventid, 
timegenerated, 
 extract_token(Strings, 5, '|' ) as LogonName, 
extract_token(Strings, 18, '|' ) as LogonIP, 
case extract_token(Strings, 8, '|' ) 
 WHEN '2' THEN 'interactive' 
 WHEN '3' THEN 'network' 
 WHEN '4' THEN 'batch' 
 WHEN '5' THEN 'service' 
 WHEN '7' THEN 'unlocked workstation' 
 WHEN '8' THEN 'network logon using a cleartext password' 
 WHEN '9' THEN 'impersonated logons' 
 WHEN '10' THEN 'remote access' 
 ELSE extract_token(Strings, 8, '|' ) 
end as LogonType, 
case extract_token(Strings, 1, '|' ) 
 WHEN 'SERVER$' THEN 'logon' 
  
 ELSE extract_token(Strings, 1, '|' ) 
end as Type 
INTO 127.0.0.1c$AUDITnewreport(127.0.0.1).csv
FROM 127.0.0.1Security
WHERE 

 (EventID IN (4624) AND extract_token(Strings, 8, '|' )  LIKE '10') OR (EventID IN (4624) AND extract_token(Strings, 8, '|' ) LIKE '2') OR (EventID IN (4624) AND extract_token(Strings, 8, '|' ) LIKE '7') OR EventID IN (4647) AND
 TO_DATE( TimeGenerated ) = TO_LOCALTIME( SYSTEM_DATE() ) 
 ORDER BY Timegenerated DESC

Далее привожу общее описание логики:

1. Вручную формируем список хостов с настроенным локально аудитом, либо указываем контроллер домена, с которого забираем логи.
2. Скрипт обходит список имен хостов в цикле, подключается к каждому из них, запускает службу Remote registry и, с помощью парсера, выполняет SQL-запрос audit.sql для сбора логов безопасности системы. Запрос модифицируется для каждого нового хоста с помощью примитивного регулярного выражения при каждой итерации. Полученные данные сохраняются в csv-файлах.
3. Из файлов CSV формируется отчет в файле Excel (для красоты и удобства поиска) и тело письма в формате HTML.
4. Создается почтовое сообщение отдельно по каждому файлу отчета и отправляется в третью систему.

Готовим площадку для теста скрипта:

Для корректной работы скрипта необходимо выполнение следующих условий:
Создаем каталог на сервере/рабочей станции, с которой выполняется скрипт. Размещаем файлы скрипта в каталог С:audit. Список хостов и скрипт лежат в одном каталоге.

Устанавливаем дополнительное ПО на сервер MS Log Parser 2.2 и Windows powershell 3.0 в составе management framework. Проверить версию Powershell можно, набрав $Host.version в консоли PS.

Заполняем список интересующих нас серверов list.txt для аудита в каталоге С:audit по именам рабочих станций. Настраиваем политику Аудита. Убеждаемся, что она работает.

Проверяем, запущена ли служба удаленного реестра (скрипт делает попытку запуска и перевода службы в автоматический режим при наличии соответствующих прав). На серверах 2008/2012 эта служба запущена по умолчанию.

Проверяем наличие прав администратора для подключения к системе и сбора логов.
Проверяем возможность запуска неподписанных скриптов powershell на удаленной машине (подписать скрипт или обойти/отключить restriction policy).

Внимание на параметры запуска неподписанных скриптов — execution policy на сервере:
Обойти запрет можно подписав скрипт, либо отключить саму политику при запуске. Например:

powershell.exe -executionpolicy bypass -file С:auditnewrun_v5.ps1

Привожу весь листинг скрипта:

Get-ChildItem -Filter report*|Remove-Item -Force
$date= get-date -uformat %Y-%m-%d
cd 'C:Program Files (x86)Log Parser 2.2'
$datadir="C:AUDITnew"
$datafile=$datadir+"audit.sql"
$list=gc $datadir"list.txt"
$data=gc $datafile
$command="LogParser.exe -i:EVT -o:CSV file:127.0.0.1c$auditnewaudit.sql"
$MLdir= [System.IO.Path]::GetDirectoryName($datadir)
function send_email {
$mailmessage = New-Object system.net.mail.mailmessage 
$mailmessage.from = ($emailfrom) 
$mailmessage.To.add($emailto)
$mailmessage.Subject = $emailsubject
$mailmessage.Body = $emailbody
$attachment = New-Object System.Net.Mail.Attachment($emailattachment, 'text/plain')
$mailmessage.Attachments.Add($attachment)
#$SMTPClient.EnableSsl = $true
$mailmessage.IsBodyHTML = $true
$SMTPClient = New-Object Net.Mail.SmtpClient($SmtpServer, 25)  
#$SMTPClient.Credentials = New-Object System.Net.NetworkCredential("$SMTPAuthUsername", "$SMTPAuthPassword") 
$SMTPClient.Send($mailmessage)
}
foreach ($SERVER in $list) { 
Get-Service -Name RemoteRegistry  -ComputerName $SERVER | set-service -startuptype auto
Get-Service -Name RemoteRegistry  -ComputerName $SERVER | Start-service
$pattern="FROM"+" "+"$SERVER"+"Security"
$pattern2="report"+"("+$SERVER+")"+"."+"csv"
$data -replace "FROMs+\.+", "$pattern" -replace "report.+", "$pattern2"|set-content $datafile
<# #IF WE USE IP LIST
$data -replace "FROMs+\([0-9]{1,3}[.]){3}[0-9]{1,3}", "$pattern" -replace "report.+", "$pattern2"|set-content $datafile 
#>
cmd /c $command 
}
cd $datadir
foreach ($file in Get-ChildItem $datadir -Filter report*) {
#creating excel doc#
$excel = new-object -comobject excel.application
$excel.visible = $false
$workbook = $excel.workbooks.add()
$workbook.workSheets.item(3).delete()
$workbook.WorkSheets.item(2).delete()
$workbook.WorkSheets.item(1).Name = "Audit"
$sheet = $workbook.WorkSheets.Item("Audit")
$x = 2
$colorIndex = "microsoft.office.interop.excel.xlColorIndex" -as [type]
$borderWeight = "microsoft.office.interop.excel.xlBorderWeight" -as [type]
$chartType = "microsoft.office.interop.excel.xlChartType" -as [type]
For($b = 1 ; $b -le 5 ; $b++)
{
 $sheet.cells.item(1,$b).font.bold = $true
  $sheet.cells.item(1,$b).borders.ColorIndex = $colorIndex::xlColorIndexAutomatic
 $sheet.cells.item(1,$b).borders.weight = $borderWeight::xlMedium
}
$sheet.cells.item(1,1) = "EventID"
$sheet.cells.item(1,2) = "TimeGenerated"
$sheet.cells.item(1,3) = "LogonName"
$sheet.cells.item(1,4) = "LogonIP"
$sheet.cells.item(1,5) = "LogonType"
$sheet.cells.item(1,6) = "Type"

Foreach ($row in $data=Import-Csv $file -Delimiter ',' -Header EventID, TimeGenerated, LogonName, LogonIP, LogonType, Tipe)
{ 
 $sheet.cells.item($x,1) = $row.EventID
 $sheet.cells.item($x,2) = $row.TimeGenerated
 $sheet.cells.item($x,3) = $row.LogonName
 $sheet.cells.item($x,4) = $row.LogonIP
 $sheet.cells.item($x,5) = $row.LogonType
 $sheet.cells.item($x,6) = $row.Tipe
 $x++
} 
$range = $sheet.usedRange
 $range.EntireColumn.AutoFit() | Out-Null
  $Excel.ActiveWorkbook.SaveAs($MLdir +''+'Audit'+ $file.basename.trim("report")+ $date +'.xlsx')
if($workbook -ne $null)
 {
     $sheet = $null
     $range = $null
  
     $workbook.Close($false)
 }
 if($excel -ne $null)
 {
     $excel.Quit()
     $excel = $null
     [GC]::Collect()
     [GC]::WaitForPendingFinalizers()
 }
$emailbody= import-csv $file|ConvertTo-Html
$EmailFrom = "audit@vda.vdg.aero"
$EmailTo = foreach ($a in (Import-Csv -Path $file).logonname){$a+"@"+"tst.com"}
$EmailSubject = "LOGON"  
$SMTPServer = "10.60.34.131"
#$SMTPAuthUsername = "username"
#$SMTPAuthPassword = "password"
$emailattachment =  "$datadir"+"$file" #$$filexls
send_email
       }

Для полноценных отчетов в Excel устанавливаем Excel на станцию/сервер, с которой работает скрипт.

Добавляем скрипт в планировщик Windows на ежедневное выполнение. Оптимальное время —конец дня — поиск событий проводится за последние сутки.

Поиск событий возможен, начиная с систем Windows 7, Windows server 2008.
Более ранние Windows имеют другие коды событий (значение кода меньше на 4096).

Примечания и заключение:

Еще раз подытожим выполненные действия:

1. Настроили локальные и доменные политики аудита на нужных серверах и собрали список серверов.
2. Выбрали машину для выполнения скрипта, установили нужный софт (PS 3.0, LOG PARSER, Excel).
3. Написали запрос для LOG PARSER.
4. Написали скрипт, запускающий этот запрос в цикле для списка,.
5. Написали оставшуюся часть скрипта, обрабатывающую полученные результаты.
6. Настроили планировщик для ежедневного запуска.

Сгенерированные ранее отчеты лежат в каталоге до следующего выполнения скрипта. Список пользователей, выполнивших подключение, автоматически добавляется в получатели письма. Cделано это для корректной обработки при отправке отчета в систему анализа. В целом, благодаря LOG PARSER, получилось достаточно мощное, и, возможно, единственное средство автоматизации этой задачи. Удивительно, что такая полезная утилита с обширными возможностями не широко распространена. В минусы утилиты можно отнести слабую документацию. Запросы выполняются методом проб и ошибок. Желаю удачных экспериментов!

Вы никогда не задумывались о том, что если вы можете отслеживать деятельность залогиневшегося пользователя ОС Windows, то Вы так же можете и записывать информацию том, кто вошел в систему и, когда они из неё вышел? Это вполне возможно, если в системе Windows использовать функцию аудита входа. Отслеживание входа и выход пользователя очень полезно в организациях, где данные являются конфиденциальными и в ситуациях, когда Вы просто хотите узнать «кто это сделал» в вашей системе Windows. По умолчанию, функция аудита входа отключена в Windows. В этой статье, давайте посмотрим, как включить аудит авторизации и как отслеживания эти события в системе Windows.
Примечание: Аудит входа доступен только в Pro или Enterprise версий Windows 8.

Что такое Аудит входа

Аудит входа в систему — это встроенный параметр Windows, который можно найти в «Редакторе групповой локальной политики», который позволяет администратором Windows вести журнал и аудит каждого пользовательского входи и выхода на локальном компьютере или в сети. Также эта функция способна отслеживать любые неудачные попытки входа в систему. Это особенно полезно при определении и анализе любых несанкционированных подключений к Вашей машине Windows.

Включение аудита входа

Чтобы включить аудит входа в систему, мы должны настроить параметры групповой политики Windows. Нажмите сочетание клавиш “’Win + R”, введите gpedit.msc в диалоговом окне «Выполнить» и нажмите кнопку «ОК», чтобы открыть окно «Редактор локальной групповой политики».

После того, как редактор будет запущен, Перейдите в области навигации по следующему пути:

«Конфигурация компьютера -> Конфигурация Windows -> Параметры безопасности -> Локальные политики -> Политика аудита»

В открывшемся списке найдите и дважды кликните мышкой на политику «Аудит входа в систему». Пожалуйста, не путайте «Аудит входа в систему» с «Аудит событий входа в систему», так как это совершенно разных параметры.

После того, как откроется окно, выберите оба флажки «Успех» и «Отказ»’. Теперь нажмите на кнопку «Применить» и кнопку «ОК», чтобы сохранить изменения.

Вот и все, что нужно сделать. С этого момента, каждый вход и выход, а также попытки входа будут записываться в журнале событий.

Просмотр событий аудита входа в систему

Вы можете просмотреть все записи журнала входа, выхода и неудачных попыток входа в систему, в окне просмотра событий Windows. Вы можете запустить программу просмотра событий с помощью функции поиска в меню «Пуск». Если вы используете Windows 8, то Вы можете запустить то же самое окно с помощью меню сочетания клавиш «Win + X» и выбрав из меню пункт «Просмотр событий».

После того как вы запустите окно «Просмотра событий», перейдите к разделу «Журналы Windows», и выберете журнал «Безопасность».

Здесь Вы найдете все, что связанно с событиями безопасности, которые произошли в Вашей системе Windows. Если Вы дважды щелкните по ключевому слову «Аудит успеха», то Вы узнаете детальную информацию по данному событию.

Так же Вы можете фильтровать журнал событий с помощью различных параметров, нажав на кнопку «Фильтр текущего журнала…», расположенную на правой боковой панели окна «Просмотр событий».

Вот и все, что нужно сделать для того, чтобы просто отслеживать регистрацию пользователей в системе Windows.
Надеюсь, что статья была Вам интересна. Оставляйте комментарии, подписывайтесь на наши новости и оставайтесь с нами.

Случалось у вас так, что вы видите что за вашим компьютером кто-то работал, а вы не знаете когда и кто? Для того, чтоб система записывала в журнал событий информцию о том, кто входит в систему, нужно настроить групповые политики, а именно включить параметры аудита системы, относящиеся к событиям входа в систему (Audit logon events). События входа в систему отслеживают события как локального, так и сетевого входа в систему. Каждое событие содержит информацию об учетной записи, с помощью которой произведен вход в систему, а также время, когда это событие произошло. Помимо событий входа в систему, можно настроить аудит событий выхода из системы.

Открываем редактор групповых политик — Пуск — в строке поиска пишем gpedit.msc и нажимаем Ввод. Если вывляетесь администратором контроллера домена, можно нстроить данную групповую политику на контроллере домена.

Открываем следующий путь: Local Computer Policy –> Computer Configuration –> Windows Settings –> Security Settings –> Local Policies –> Audit Policy.

Дабл кликаем параметр групповой политики Audit logon events. В окне свойств устанавливаем Success чекбокс для записи в журнал успешных входов в систему. Также можно установить чекбокс Failure для журналирования неудачных попыток входа в систему.

После включения данного параметра групповой политики, Windows будет записывать в журнал событий информацию об учетной записи с помощью которой произведен вход в систему, а также время, когда это событие произошло.

Для просмотра данных событий открываем Оснастку Просмотр событий — нажимаем меню Пуск — пишем Просмотр событий (Event Viewer) и нажимаем Ввод

Открываем путь Windows Logs –> Security.

Смотрим события:

• ID 4624 – это события успехов входа в систему.
• ID 4625 – это события отказов входа в систему.

Для того чтоб посмотреть полнюу информацию — даблкликайте интнресующее вас событие, и в открывшемся диалоговом окне смотрите детальную информацию.

Если у вас в журнале записано много событий, среди которых сложно отделить события с ID 4624 или 4625, можно воспользоваться фильтром. Для этого в правой части окна нажимаем кнопку Фильтр текущего журнала…

В открывшемся окне настроек фильтра, введите интересующий вас ID:

Как видно элементов в журнале существенно поубавилось:

На этом все. Если есть вопросы, уточнения, замечания — пишите.

В качестве дополения к данному материалу можно сказать, что помимо просмотра пост фактум журнала событий, в системе Windows 7 можно организовать отправку уведомлений по электронной почте, в случае ,если к вам в систему кто-то входит.

Аудит события входа

Определяет, следует ли проверять каждый экземпляр входа пользователя на устройство или его отключение.

События логотипа учетной записи создаются на контроллерах доменов для действий учетных записей домена и на локальных устройствах для локальной активности учетной записи. Если включены как категории политик аудита для логотипов учетных записей, так и для политик аудита, логотипы, которые используют учетную запись домена, создают событие logon или logoff на рабочей станции или сервере и создают событие логотипа учетной записи на контроллере домена. Кроме того, интерактивные логотипы на сервере членов или рабочей станции, которые используют учетную запись домена, создают событие logon на контроллере домена, так как скрипты и политики логотипа извлекаются при входе пользователя в систему. Дополнительные сведения о событиях с логотипом учетной записи см. в сайте Audit account logon events.

Определяя этот параметр политики, можно задать аудит успехов, аудит неудач либо отключить аудит всех типов событий. Аудиты успешности создают запись аудита при успешной попытке логотипа. Аудиты сбоя создают запись аудита при сбое попытки логона.

Чтобы установить это значение без аудита, в диалоговом окне **** Свойства для этого параметра политики выберите флажок Определить эти параметры политики и очистить флажки Success и Failure. ****

Сведения о расширенных параметрах политики безопасности для событий с логотипами см. в разделе Logon/logoff в разделе Расширенные параметры политики аудита безопасности.

Настройка параметра аудита

Вы можете настроить этот параметр безопасности, открыв соответствующую политику в области конфигурации компьютераWindows ПараметрыSecurity ПараметрыLocal PoliciesAudit Policy.

При входе в журнал события 528 в журнале событий также указан тип логотипа. В следующей таблице описывается каждый тип логотипа.

Источник

Как посмотреть логи Windows?

Ищете сервер с Windows? Выбирайте наши Windows VDS

Просмотр событий для проверки логов.

После нажатия комбинации “ Win+R и введите eventvwr.msc ” в любой системе Виндовс вы попадаете в просмотр событий. У вас откроется окно, где нужно развернуть Журналы Windows. В данном окне можно просмотреть все программы, которые открывались на ОС и, если была допущена ошибка, она также отобразится.

Аудит журнал поможет понять, что и кто и когда делал. Также отображается информация по запросам получения доступов.

В пункте Установка можно посмотреть логи ОС Виндовс, например, программы и обновления системы.

Фильтрация событий.

С помощью Фильтра текущего журнала (раздел Действия) можно отфильтровать информацию, которую вы хотите просмотреть.

Обязательно нужно указать уровень Событий:

Для сужения поиска можно отфильтровать источник событий и код.

Просмотр PowerShell логов.

В результате вы получите логи Системы

Также обязательно ознакомьтесь с перечнем аббревиатур:

Для выведения событий в командной оболочке только со столбцами «Уровень», «Дата записи события», «Источник», «Код события», «Категория» и «Сообщение события» для журнала «Система» используйте:

Get-EventLog –LogName ‘System’ | Format-Table EntryType, TimeWritten, Source, EventID, Category, Message

Если нужна подробная информация, замените Format-Table на Format-List на

Get-EventLog –LogName ‘System’ | Format-List EntryType, TimeWritten, Source, EventID, Category, Message

Формат информации станет более легким

Для фильтрации журнала, например, для фильтрации последних 20 сообщений, используйте команду

Get-EventLog –Logname ‘System’ –Newest 20

Если нужен список, позднее даты 1 января 2018 года, команда

Get-EventLog –LogName ‘System’ –After ‘1 января 2018’

Надеемся, данная статья поможет вам быстро и просто читать логи ОС Windows.

Желаем приятной работы!

Как установить свой образ на ВДС сервер с Виндовс, читайте в предыдущей статье.

Источник

Получаем логи (историю) входа пользователя в домен AD

Есть несколько различных инструментов получения информации о времени логина пользователя в домен. Время последней успешной аутентификации пользователя в домене можно получить из атрибута lastLogon (обновляется только на контроллере домена, на котором выполнена проверка учетных данных пользователя) или lastLogonTimpestamp (реплицируется между DC в домене, но по умолчанию только через 14 дней). Вы можете получить значение этого атрибута пользователя в редакторе атрибутов AD или командлетом Get-ADUser. Однако иногда нужно получить историю активности (входов) пользователя в домене за большой период времени.

Вы можете получить информацию об успешных входах (аутентфикации) пользователя в домене из журналов контроллеров домена. В этой статье мы покажем, как отслеживать историю входов пользователя в домен с помощью PowerShell.. Т.е. можно получить полную историю активности пользователя в домене, время начала работы и компьютеры, с которых работает пользователь.

Политика аудита входа пользователя в домен

Чтобы в журналах контроллеров домена отображалась информация об успешном/неуспешном входе в систему, нужно включить политику аудита событий входа пользователей.

Теперь при входе пользователя на любой компьютер домена Active Directory в журнале контроллера домена, который выполняет аутентификацию пользователя, появляется событие с Event ID 4624 (An account was successfully logged on). В описании этого события указана учетная запись, которая успешно аутентифицировалась (Account name), имя (Workstation name) или IP адрес (Source Network Address) компьютера, с которого выполнен вход.

Также в поле Logon Type указан тип входа в систему. Нас интересуют следующие коды

В событии 4768 также указана учетная запись пользователя (Account Name или User ID), который получил билет Kerberos (аутентифицировался) и имя (IP адрес) компьютера.

PowerShell: истории сетевых входов пользователя в домен

С помощью командлета PowerShell Get-Eventlog можно получить все события из журнала контроллера домена, отфильтровать их по нужному коду (EventID) и вывести данные о времени, когда пользователь аутентифицировался в домене, и компьютере, с которого выполнен вход. Т.к. в домене может быть несколько контроллеров домена и нужно получить история входов пользователя с каждого из них, нужно воспользоваться командлетом Get-ADDomainController (из модуля AD для Windows PowerShell). Данный командлет позволяет получить список всех DC в домене.

Следующий PowerShell скрипт позволяет получить все события входа пользователя в домен AD со всех контроллеров домена. На выходе вы получаете таблицу с историей входа пользователя и компьютеров, с которых аутентифицировался пользователь.

Получаем информацию об активности пользователя в домене по событиям Kerberos

Также вы можете получить историю аутентификации пользователя в домене по по событию выдачи билета Kerberos (TGT Request — EventID 4768). В этом случае в итоговых данных будет содержаться меньшее количество событий (исключены сетевые входы, обращения к папкам на DC во время получения политик и выполнения логон-скриптов). Следующий PowerShell скрипт выведет информацию о всех входах пользователей за последние 24 часа:

Обратите, что в этом случае вы не увидите события входов пользователей, которые аутентифицировались с клиентов или приложений, которые используют NTLM вместо Kerberos.

Источник

Вертим логи как хотим ― анализ журналов в системах Windows

Пора поговорить про удобную работу с логами, тем более что в Windows есть масса неочевидных инструментов для этого. Например, Log Parser, который порой просто незаменим.

В статье не будет про серьезные вещи вроде Splunk и ELK (Elasticsearch + Logstash + Kibana). Сфокусируемся на простом и бесплатном.

Журналы и командная строка

До появления PowerShell можно было использовать такие утилиты cmd как find и findstr. Они вполне подходят для простой автоматизации. Например, когда мне понадобилось отлавливать ошибки в обмене 1С 7.7 я использовал в скриптах обмена простую команду:

Она позволяла получить в файле fail.txt все ошибки обмена. Но если было нужно что-то большее, вроде получения информации о предшествующей ошибке, то приходилось создавать монструозные скрипты с циклами for или использовать сторонние утилиты. По счастью, с появлением PowerShell эти проблемы ушли в прошлое.

Основным инструментом для работы с текстовыми журналами является командлет Get-Content, предназначенный для отображения содержимого текстового файла. Например, для вывода журнала сервиса WSUS в консоль можно использовать команду:

Для вывода последних строк журнала существует параметр Tail, который в паре с параметром Wait позволит смотреть за журналом в режиме онлайн. Посмотрим, как идет обновление системы командой:

Смотрим за ходом обновления Windows.

Если же нам нужно отловить в журналах определенные события, то поможет командлет Select-String, который позволяет отобразить только строки, подходящие под маску поиска. Посмотрим на последние блокировки Windows Firewall:

Смотрим, кто пытается пролезть на наш дедик.

При необходимости посмотреть в журнале строки перед и после нужной, можно использовать параметр Context. Например, для вывода трех строк после и трех строк перед ошибкой можно использовать команду:

Оба полезных командлета можно объединить. Например, для вывода строк с 45 по 75 из netlogon.log поможет команда:

Для получения списка доступных системных журналов можно выполнить следующую команду:

Вывод доступных журналов и информации о них.

Для просмотра какого-то конкретного журнала нужно лишь добавить его имя. Для примера получим последние 20 записей из журнала System командой:

Последние записи в журнале System.

Для получения определенных событий удобнее всего использовать хэш-таблицы. Подробнее о работе с хэш-таблицами в PowerShell можно прочитать в материале Technet about_Hash_Tables.

Для примера получим все события из журнала System с кодом события 1 и 6013.

В случае если надо получить события определенного типа ― предупреждения или ошибки, ― нужно использовать фильтр по важности (Level). Возможны следующие значения:

Собрать хэш-таблицу с несколькими значениями важности одной командой так просто не получится. Если мы хотим получить ошибки и предупреждения из системного журнала, можно воспользоваться дополнительной фильтрацией при помощи Where-Object:

Ошибки и предупреждения журнала System.

Аналогичным образом можно собирать таблицу, фильтруя непосредственно по тексту события и по времени.

Подробнее почитать про работу обоих командлетов для работы с системными журналами можно в документации PowerShell:

PowerShell ― механизм удобный и гибкий, но требует знания синтаксиса и для сложных условий и обработки большого количества файлов потребует написания полноценных скриптов. Но есть вариант обойтись всего-лишь SQL-запросами при помощи замечательного Log Parser.

Работаем с журналами посредством запросов SQL

Утилита Log Parser появилась на свет в начале «нулевых» и с тех пор успела обзавестись официальной графической оболочкой. Тем не менее актуальности своей она не потеряла и до сих пор остается для меня одним из самых любимых инструментов для анализа логов. Загрузить утилиту можно в Центре Загрузок Microsoft, графический интерфейс к ней ― в галерее Technet. О графическом интерфейсе чуть позже, начнем с самой утилиты.

О возможностях Log Parser уже рассказывалось в материале «LogParser — привычный взгляд на непривычные вещи», поэтому я начну с конкретных примеров.

Для начала разберемся с текстовыми файлами ― например, получим список подключений по RDP, заблокированных нашим фаерволом. Для получения такой информации вполне подойдет следующий SQL-запрос:

Посмотрим на результат:

Смотрим журнал Windows Firewall.

Разумеется, с полученной таблицей можно делать все что угодно ― сортировать, группировать. Насколько хватит фантазии и знания SQL.

Log Parser также прекрасно работает с множеством других источников. Например, посмотрим откуда пользователи подключались к нашему серверу по RDP.

Работать будем с журналом TerminalServices-LocalSessionManagerOperational.

Не со всеми журналами Log Parser работает просто так ― к некоторым он не может получить доступ. В нашем случае просто скопируем журнал из %SystemRoot%System32WinevtLogsMicrosoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx в %temp%test.evtx.

Данные будем получать таким запросом:

Смотрим, кто и когда подключался к нашему серверу терминалов.

Особенно удобно использовать Log Parser для работы с большим количеством файлов журналов ― например, в IIS или Exchange. Благодаря возможностям SQL можно получать самую разную аналитическую информацию, вплоть до статистики версий IOS и Android, которые подключаются к вашему серверу.

В качестве примера посмотрим статистику количества писем по дням таким запросом:

Если в системе установлены Office Web Components, загрузить которые можно в Центре загрузки Microsoft, то на выходе можно получить красивую диаграмму.

Выполняем запрос и открываем получившуюся картинку…

Любуемся результатом.

Следует отметить, что после установки Log Parser в системе регистрируется COM-компонент MSUtil.LogQuery. Он позволяет делать запросы к движку утилиты не только через вызов LogParser.exe, но и при помощи любого другого привычного языка. В качестве примера приведу простой скрипт PowerShell, который выведет 20 наиболее объемных файлов на диске С.

Ознакомиться с документацией о работе компонента можно в материале Log Parser COM API Overview на портале SystemManager.ru.

Благодаря этой возможности для облегчения работы существует несколько утилит, представляющих из себя графическую оболочку для Log Parser. Платные рассматривать не буду, а вот бесплатную Log Parser Studio покажу.

Интерфейс Log Parser Studio.

Основной особенностью здесь является библиотека, которая позволяет держать все запросы в одном месте, без россыпи по папкам. Также сходу представлено множество готовых примеров, которые помогут разобраться с запросами.

Вторая особенность ― возможность экспорта запроса в скрипт PowerShell.

В качестве примера посмотрим, как будет работать выборка ящиков, отправляющих больше всего писем:

Выборка наиболее активных ящиков.

При этом можно выбрать куда больше типов журналов. Например, в «чистом» Log Parser существуют ограничения по типам входных данных, и отдельного типа для Exchange нет ― нужно самостоятельно вводить описания полей и пропуск заголовков. В Log Parser Studio нужные форматы уже готовы к использованию.

Помимо Log Parser, с логами можно работать и при помощи возможностей MS Excel, которые упоминались в материале «Excel вместо PowerShell». Но максимального удобства можно достичь, подготавливая первичный материал при помощи Log Parser с последующей обработкой его через Power Query в Excel.

Приходилось ли вам использовать какие-либо инструменты для перелопачивания логов? Поделитесь в комментариях.

Источник

Сбор и фильтрация событий входа в систему с помощью Log Parser

Здравствуйте, уважаемое сообщество!

ИТ-инфраструктура всегда находится в динамике. Тысячи изменений происходят ежеминутно. Многие из них требуется регистрировать. Аудит систем является неотъемлемой частью информационной безопасности организаций. Контроль изменений позволяет предотвратить серьезные происшествия в дальнейшем.

В статье я хочу рассказать о своем опыте отслеживания событий входа (и выхода) пользователей на серверах организации, подробно описать те детали, которые возникли в ходе выполнения задачи анализа логов аудита, а также привести решение этой задачи по шагам.

Цели, которые мы преследуем:

Анализ логов является рутинной операцией системного администратора. В данном случае объёмы фиксируемых событий в домене таковы, что это само по себе сложно. Аудит включается в групповой политике.

События входа в систему формируются:

1. контроллерами домена, в процессе проверки учетных записей домена;
2. локальными компьютерами при работе с локальными учетными записями.

Если включены обе категории политик (учетных записей и аудита), то входы в систему, использующие учетную запись домена, будут формировать события входа или выхода на рабочей станции или сервере и событие входа в систему на контроллере домена. Таким образом, аудит на доменные машины потребуется настроить через оснастку GPO на контроллере, аудит локальный — через локальную политику безопасности с помощью оснастки MMC.

Настройка аудита и подготовка инфраструктуры:

Рассмотрим этот этап подробно. Для уменьшения объемов информации мы смотрим только успешные события входа и выхода. Имеет смысл увеличить размер журнала security Windows. По умолчанию — это 128 Мегабайт.

Для настройки локальной политики:

Открываем редактор политик – Пуск, в строке поиска пишем gpedit.msc и нажимаем Ввод.
Открываем следующий путь: Local Computer Policy → Computer Configuration → Windows Settings → Security Settings → Local Policies → Audit Policy.

Дважды кликаем параметр групповой политики Audit logon events (аудит входа в систему) и Audit account logon events (аудит событий входа в систему). В окне свойств устанавливаем Success-чекбокс для записи в журнал успешных входов в систему. Чекбокс Failure устанавливать не рекомендую во избежание переполнения. Для применения политики необходимо набрать в консоли gpupdate /force

Для настройки групповой политики:

Создаем новый объект GPO (групповую политику) с именем «Audit AD». Переходим в раздел редактирования и разворачиваем ветку Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Configuration. В данной ветке групповых политик находятся расширенные политики аудита, которые можно активировать в ОС семейства Windows для отслеживания различных событий. В Windows 7 и Windows Server 2008 R2 количество событий, для которых можно осуществлять аудит увеличено до 53. Эти 53 политики аудита (т.н. гранулярные политики аудита) находятся в ветке Security SettingsAdvanced Audit Policy

Configuration и сгруппированы в десяти категориях:

Сразу оговорим типы событий, которые будет анализировать наш будущий скрипт:

Скорость обработки данных возросла в разы, полный прогон с формированием отчета с одного ПК сократился до 10 секунд. Утилита использует немало опций командной строки, поэтому мы будем вызывать cmd из powershell, чтобы избавиться от экранирования кучи специальных символов. Для написания запросов можно воспользоваться GUI — Log Parser Lizard. Он не бесплатен, но триального периода в 65 дней хватает. Ниже привожу сам запрос. Помимо интересующих нас, распишем и другие варианты входа в систему, на случай дальнейшего использования.

Далее привожу общее описание логики:

Готовим площадку для теста скрипта:

Для корректной работы скрипта необходимо выполнение следующих условий:
Создаем каталог на сервере/рабочей станции, с которой выполняется скрипт. Размещаем файлы скрипта в каталог С:audit. Список хостов и скрипт лежат в одном каталоге.

Заполняем список интересующих нас серверов list.txt для аудита в каталоге С:audit по именам рабочих станций. Настраиваем политику Аудита. Убеждаемся, что она работает.

Проверяем, запущена ли служба удаленного реестра (скрипт делает попытку запуска и перевода службы в автоматический режим при наличии соответствующих прав). На серверах 2008/2012 эта служба запущена по умолчанию.

Проверяем наличие прав администратора для подключения к системе и сбора логов.
Проверяем возможность запуска неподписанных скриптов powershell на удаленной машине (подписать скрипт или обойти/отключить restriction policy).

Внимание на параметры запуска неподписанных скриптов — execution policy на сервере:
Обойти запрет можно подписав скрипт, либо отключить саму политику при запуске. Например:

Привожу весь листинг скрипта:

Для полноценных отчетов в Excel устанавливаем Excel на станцию/сервер, с которой работает скрипт.

Добавляем скрипт в планировщик Windows на ежедневное выполнение. Оптимальное время —конец дня — поиск событий проводится за последние сутки.

Поиск событий возможен, начиная с систем Windows 7, Windows server 2008.
Более ранние Windows имеют другие коды событий (значение кода меньше на 4096).

Примечания и заключение:

Еще раз подытожим выполненные действия:

Источник

Мониторинг внешнего входа и выхода пользователей Windows

Данные будем брать из Журнал событий (англ. Event Log)
Панель управленияВсе элементы панели управленияАдминистрированиеПросмотр событий
или (Win+R) команду eventvwr.msc
eventlog-Microsoft-Windows-TerminalServices-LocalSessionManager-Operational
LSM — Local Session Manager
RCM — Remote Connection Manager
Запрос для Ключа eventlog[«Microsoft-Windows-TerminalServices-LocalSessionManager/Operational»,,,,^(21|23|24|25)$,,skip]

Пример Просмотр и анализ логов RDP подключений в Windows

Ключ в zabbix будет использоваться eventlog

eventlog[имя,<регулярное выражение>,<важность>,<источник>,<eventid>,<макс. кол-во строк>,<режим>]
eventlog[имя»Microsoft-Windows-TerminalServices-LocalSessionManager/Operational»,<регулярное выражение>пропускаем пусто,<важность>пропускаем пусто,<источник>пропускаем пусто,<eventid>^(21|23|24|25)$,<макс. кол-во строк>пропускаем пусто,<режим>skip]
skip — пропустить обработку старых данных

СПЕЦИФИЧНЫЕ КЛЮЧИ ЭЛЕМЕНТОВ ДАННЫХ

Триггер
logeventid
Проверка, совпадает ли ID события последней записи из журнала указанному регулярному выражению.
шаблон — регулярное выражение описывающее требуемый шаблон, в формате расширенных регулярных выражений POSIX.
Поддерживаемые типы значений: log
Возвращает:
0 — не совпадает
1 — совпадает

Изначально шаблон был взят с Windows Server Login monitor далее путь на гитхаб Server-Login-monitor-Zabbix

Для начала оригинальный шаблон автора который был скачен с гитхаба

Далее первые изменения в шаблоне
Переведён полностью на Русский язык
Добавлены описания
Добавлен триггер на повторный вход 25

Дальнейшие доработки
Мало инфы в триггере 1.Пользователь который подключился 2.IP-адресс откуда подключился 3.Код Сеанса 4.Имя ПК с которого выполнено подключение
Отключенные пользователи которые не завершили сеанс, а просто его закрыли! Корректно нужно завершать сеанс, так же нужно проверять.

Сперва текущий актуальный шаблон на 12.01.2021, ниже как это делалось какие проблемы возникали и тд.

Скачать

Скачать

Про Инфу в триггер 1.Пользователь который подключился 2.Код Сеанса 3.IP-адресс откуда подключился или локальный вход 4.Имя ПК с которого выполнено подключение
На примере диспетчера задач вкладка пользователи
Windows 10

Windows 7

Из журнала Microsoft-Windows-TerminalServices-LocalSessionManager/Operational можем получить
Пользователь: источника: Код сеанса:

Но Имя ПК с которого выполнено подключение в данном логе нет
оно есть в eventlog[«Security»,,,,^(1100|1102|4624|4634|4647)$,,skip]
Журналы Windows — Безопасность
Вход с Имя компьютера подключенного по RDP Лог 4624
Тип входа: Имя рабочей станции:
Описание Кодов:
1100 — Завершение работы
1102 — Очистка журнала
4624 — Вход в систему для обычной windows Новый вход: — Имя учетной записи: Сведения о сети: — Имя рабочей станции
4648 — Вход Windows (серверов) Были использованы учетные данные следующей учетной записи: Имя учетной записи: Целевой сервер: — Имя целевого сервера: (Попытка входа)
4634 — выход (23 в 2 журнале)
4647 — выход
4778 — Пользователь переподключился к RDP сессии (пользователю выдается новый LogonID)
4799 — Отключение от RDP сеанса
9009 — Пользователь инициировал завершение RDP сессии, и окно и графический shell пользователя был завершен

(Win+R) команду eventvwr.msc

Сделать 2 элемента в 1 триггер {ITEM.VALUE} получаем только значение с одного элемента которое первее отработает, второй элемент уже не попадает вариант отпадает. Сделать 2 триггера для того чтобы видеть имя подключившегося ПК как то не целесообразно.
В общем Элемент Вход в Windows Security — Отключен и Триггер так же отключен RDP auth {{ITEM.VALUE}.iregsub(«(Тип входа: .*)», «1»)} {{ITEM.VALUE}.iregsub(«(Имя рабочей станции: .*)», «1»)}

Вход в Windows RCM-Remote Connection Manager

1149 — установление сетевого подключение к серверу от RDP клиента пользователя (не аунтификация)
4624 — успешная аутентификация
4625 — ошибка аутентификации
При входе через терминальную службу RDP — LogonType = 10 или 3.
Если LogonType = 7, значит выполнено переподключение к уже имеющейся RDP сессии.
Account Name — имя пользователя
Workstation Name — имя компьютера
Source Network Address — имя пользователя
TargetLogonID – уникальный идентификатор сессии пользователя

(Win+R) команду eventvwr.msc

Следующая проблемка
Отключенные пользователи которые не завершили сеанс, а просто его закрыли! Корректно нужно завершать сеанс, так же нужно проверять.
Копятся не закрываются триггеры

Разница Завершения Сеанса пользователя и отключения

Так как

Завершение сеанса
23 — выход из сеанса (закрываем триггер все хорошо или не даем триггеру открыться)
24 — отключен

При закрытии сессии RDP на крестик
24 — отключен сработал триггер (выполним действие на завершение пользователя) и дальше его ничто уже не закроет так как 23 уже было в логе
23 — выход из сеанса, сработало действие на завершение сеанса пользователя по триггеру отключен

Открытие Срабатывание триггера отключённых пользователей происходить по 24 значению лога
а закрытие триггера по 23 значению лога

23 — выход из сеанса (закрывает триггер)
24 — отключен
Срабатывает если последняя запись 24 и предпоследняя не равна 23
не создавалось множество указано diff

По этому пришлось сделать еще один элемент который берет предыдущее значение из лога , уже не раз 15 секунд, а раз в 1 минуту.
Хотелось бы получать все с одного элемента но что делать.
system.run[«wevtutil qe Microsoft-Windows-TerminalServices-LocalSessionManager/Operational /c:2 /rd:true /f:text|FIND /I «Event ID»|find /n «2»|find /v «1»»]

По отключенным триггер срабатывает если 24 и предыдущая строка не 23

Триггер на отключение срабатывает
С журнала последний код 24 — отключен .logeventid(24)}=1
И
Предыдущее значение не равно 23 выход из сеанса .last()}<>23
И
не создавалось множество указано .diff(0)}=1
Закрытие триггера на отключение
С журнала последнее значение не 24 — отключен .logeventid(24)}=0
Или
С журнала последний код 24 — отключен .logeventid(24)}=1
И
Предпоследнее значение 23 — выход из сеанса .last()}=23

Так же была попытка сделать через теги , корреляцию.

В некоторых попытках в триггер можно получить предыдущее значение журнала (лога) но уже нельзя сравнить id

Кото для теста хочет подключатся к учетной записи по RDP без пароля не обходимо выполнить следующее