логи входа в систему windows 10
Аудит события входа
Определяет, следует ли проверять каждый экземпляр входа пользователя на устройство или его отключение.
События логотипа учетной записи создаются на контроллерах доменов для действий учетных записей домена и на локальных устройствах для локальной активности учетной записи. Если включены как категории политик аудита для логотипов учетных записей, так и для политик аудита, логотипы, которые используют учетную запись домена, создают событие logon или logoff на рабочей станции или сервере и создают событие логотипа учетной записи на контроллере домена. Кроме того, интерактивные логотипы на сервере членов или рабочей станции, которые используют учетную запись домена, создают событие logon на контроллере домена, так как скрипты и политики логотипа извлекаются при входе пользователя в систему. Дополнительные сведения о событиях с логотипом учетной записи см. в сайте Audit account logon events.
Определяя этот параметр политики, можно задать аудит успехов, аудит неудач либо отключить аудит всех типов событий. Аудиты успешности создают запись аудита при успешной попытке логотипа. Аудиты сбоя создают запись аудита при сбое попытки логона.
Чтобы установить это значение без аудита, в диалоговом окне **** Свойства для этого параметра политики выберите флажок Определить эти параметры политики и очистить флажки Success и Failure. ****
Сведения о расширенных параметрах политики безопасности для событий с логотипами см. в разделе Logon/logoff в разделе Расширенные параметры политики аудита безопасности.
Настройка параметра аудита
Вы можете настроить этот параметр безопасности, открыв соответствующую политику в области конфигурации компьютера\Windows Параметры\Security Параметры\Local Policies\Audit Policy.
| События Logon | Описание |
|---|---|
| 4624 | Пользователь успешно вошел на компьютер. Сведения о типе логотипа см. в таблице Типы logon ниже. |
| 4625 | Сбой Logon. Попытка логотипа была предпринята с неизвестным именем пользователя или известным именем пользователя с плохим паролем. |
| 4634 | Процесс входа был завершен для пользователя. |
| 4647 | Пользователь инициировал процесс входа. |
| 4648 | Пользователь успешно вошел на компьютер с использованием явных учетных данных, уже во время входа в систему в качестве другого пользователя. |
| 4779 | Пользователь отключил сеанс сервера терминала без входа. |
При входе в журнал события 528 в журнале событий также указан тип логотипа. В следующей таблице описывается каждый тип логотипа.
Сбор и фильтрация событий входа в систему с помощью 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 Settings\Advanced 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).
Примечания и заключение:
Еще раз подытожим выполненные действия:
Аудит входа в систему
Аудит Logon определяет, генерирует ли операционная система события аудита при попытке пользователя войти на компьютер.
Эти события связаны с созданием сеансов логотипа и происходят на компьютере, к нему был доступ. Для интерактивного логотипа события создаются на компьютере, на который был внесен вход. Для сетевого логотипа, например доступа к совместной информации, события создаются на компьютере, на котором размещен доступ к ресурсу.
Записывают следующие события:
Logon success and failure.
Попытки logon с помощью явных учетных данных. Это событие создается при попытке входа в учетную запись путем явного указания учетных данных этой учетной записи. Чаще всего это происходит в пакетных конфигурациях, таких как запланированные задачи или при использовании команды RunAs.
Идентификаторы безопасности (SID) фильтруются.
События Logon имеют важное значение для отслеживания активности пользователей и обнаружения потенциальных атак.
Том события:
Низкий уровень клиентского компьютера.
Medium на контроллерах домена или сетевых серверах.
| Тип компьютера | Общий успех | Общий сбой | Более сильный успех | Более сильный сбой | Комментарии |
|---|---|---|---|---|---|
| Контроллер домена | Да | Да | Да | Да | Аудит событий Logon, например, даст вам сведения о том, какая учетная запись, когда, с помощью которой тип Logon, из какой машины вошел в эту машину. События сбоя покажут неудачные попытки логотипа и причину сбоя этих попыток. |
| Сервер участника | Да | Да | Да | Да | Аудит событий Logon, например, даст вам сведения о том, какая учетная запись, когда, с помощью которой тип Logon, из какой машины вошел в эту машину. События сбоя покажут неудачные попытки логотипа и причину сбоя этих попыток. |
| Workstation | Да | Да | Да | Да | Аудит событий Logon, например, даст вам сведения о том, какая учетная запись, когда, с помощью которой тип Logon, из какой машины вошел в эту машину. События сбоя покажут неудачные попытки логотипа и причину сбоя этих попыток. |
Список событий:
4624(S): учетная запись успешно вошел в систему.
4625(F): учетная запись не смогла войти в систему.
4648(S): была предпринята попытка использования логона с использованием явных учетных данных.
Аудит событий входа в систему
Определяет, следует ли проверять каждый экземпляр входа пользователя на другое устройство, на котором это устройство используется для проверки учетной записи, или отключается от него.
Этот параметр безопасности определяет, следует ли проверять каждый экземпляр входа пользователя на другой компьютер, на котором этот компьютер используется для проверки учетной записи. События логотипа учетной записи создаются при проверке подлинности учетной записи пользователя домена на контроллере домена. Событие регистрируется в журнале безопасности контроллера домена. События Logon создаются при проверке подлинности локального пользователя на локальном компьютере. Событие регистрируется в локальном журнале безопасности. События входа в учетную запись не создаются.
Определяя этот параметр политики, можно задать аудит успехов, аудит неудач либо отключить аудит всех типов событий. Аудиты успеха создают запись аудита при успешной попытке логотипа учетной записи. Аудиты сбоя создают запись аудита при сбое попытки логоса учетной записи. Чтобы установить это значение без аудита, в диалоговом окне **** Свойства для этого параметра политики выберите флажок Определить эти параметры политики и очистить флажки Success и Failure. ****
По умолчанию: успех
Настройка параметра аудита
Вы можете настроить этот параметр безопасности, открыв соответствующую политику в области конфигурации компьютера\Windows Параметры\Security Параметры\Local Policies\Audit Policy.
Что полезного можно вытащить из логов рабочей станции на базе ОС Windows
Пользовательская рабочая станция — самое уязвимое место инфраструктуры по части информационной безопасности. Пользователям может прийти на рабочую почту письмо вроде бы из безопасного источника, но со ссылкой на заражённый сайт. Возможно, кто-то скачает полезную для работы утилиту из неизвестно какого места. Да можно придумать не один десяток кейсов, как через пользователей вредоносное ПО может внедриться на внутрикорпоративные ресурсы. Поэтому рабочие станции требуют повышенного внимания, и в статье мы расскажем, откуда и какие события брать для отслеживания атак.
Для выявления атаки на самой ранней стадии в ОС Windows есть три полезных событийных источника: журнал событий безопасности, журнал системного мониторинга и журналы Power Shell.
Журнал событий безопасности (Security Log)
Это главное место хранения системных логов безопасности. Сюда складываются события входа/выхода пользователей, доступа к объектам, изменения политик и других активностей, связанных с безопасностью. Разумеется, если настроена соответствующая политика.
Перебор пользователей и групп (события 4798 и 4799). Вредоносное ПО в самом начале атаки часто перебирает локальные учетные записи пользователей и локальные группы на рабочей станции, чтобы найти учетные данные для своих тёмных делишек. Эти события помогут обнаружить вредоносный код раньше, чем он двинется дальше и, используя собранные данные, распространится на другие системы.
Создание локальной учётной записи и изменения в локальных группах (события 4720, 4722–4726, 4738, 4740, 4767, 4780, 4781, 4794, 5376 и 5377). Атака может также начинаться, например, с добавления нового пользователя в группу локальных администраторов.
Попытки входа с локальной учётной записью (событие 4624). Добропорядочные пользователи заходят с доменной учётной записью и выявление входа под локальной учётной записью может означать начало атаки. Событие 4624 включает также входы под доменной учетной записью, поэтому при обработке событий нужно зафильтровать события, в которых домен отличается от имени рабочей станции.
Попытка входа с заданной учётной записью (событие 4648). Такое бывает, когда процесс выполняется в режиме “Запуск от имени” (run as). В нормальном режиме работы систем такого не должно быть, поэтому такие события должны находиться под контролем.
Блокировка/разблокировка рабочей станции (события 4800-4803). К категории подозрительных событий можно отнести любые действия, которые происходили на заблокированной рабочей станции.
Изменения конфигурации файрволла (события 4944-4958). Очевидно, что при установке нового ПО настройки конфигурации файрволла могут меняться, что вызовет ложные срабатывания. Контролировать такие изменения в большинстве случаев нет необходимости, но знать о них точно лишним не будет.
Подключение устройств Plug’n’play (событие 6416 и только для WIndows 10). За этим важно следить, если пользователи обычно не подключают новые устройства к рабочей станции, а тут вдруг раз — и подключили.
Windows включает в себя 9 категорий аудита и 50 субкатегорий для тонкой настройки. Минимальный набор субкатегорий, который стоит включить в настройках:
Системный монитор (Sysmon)
Sysmon — встроенная в Windows утилита, которая умеет записывать события в системный журнал. Обычно требуется его устанавливать отдельно.
Эти же события можно в принципе найти в журнале безопасности (включив нужную политику аудита), но Sysmon даёт больше подробностей. Какие события можно забирать из Sysmon?
Создание процесса (ID события 1). Системный журнал событий безопасности тоже может сказать, когда запустился какой-нибудь *.exe и даже покажет его имя и путь запуска. Но в отличие от Sysmon не сможет показать хэш приложения. Злонамеренное ПО может называться даже безобидным notepad.exe, но именно хэш выведет его на чистую воду.
Сетевые подключения (ID события 3). Очевидно, что сетевых подключений много, и за всеми не уследить. Но важно учитывать, что Sysmon в отличие от того же Security Log умеет привязать сетевое подключение к полям ProcessID и ProcessGUID, показывает порт и IP-адреса источника и приёмника.
Изменения в системном реестре (ID события 12-14). Самый простой способ добавить себя в автозапуск — прописаться в реестре. Security Log это умеет, но Sysmon показывает, кто внёс изменения, когда, откуда, process ID и предыдущее значение ключа.
Создание файла (ID события 11). Sysmon, в отличие от Security Log, покажет не только расположение файла, но и его имя. Понятно, что за всем не уследишь, но можно же проводить аудит определённых директорий.
А теперь то, чего в политиках Security Log нет, но есть в Sysmon:
Изменение времени создания файла (ID события 2). Некоторое вредоносное ПО может подменять дату создания файла для его скрытия из отчётов с недавно созданными файлами.
Загрузка драйверов и динамических библиотек (ID событий 6-7). Отслеживание загрузки в память DLL и драйверов устройств, проверка цифровой подписи и её валидности.
Создание потока в выполняющемся процессе (ID события 8). Один из видов атаки, за которым тоже нужно следить.
События RawAccessRead (ID события 9). Операции чтения с диска при помощи “\\.\”. В абсолютном большинстве случаев такая активность должна считаться ненормальной.
Создание именованного файлового потока (ID события 15). Событие регистрируется, когда создается именованный файловый поток, который генерирует события с хэшем содержимого файла.
Создание named pipe и подключения (ID события 17-18). Отслеживание вредоносного кода, который коммуницирует с другими компонентами через named pipe.
Активность по WMI (ID события 19). Регистрация событий, которые генерируются при обращении к системе по протоколу WMI.
Для защиты самого Sysmon нужно отслеживать события с ID 4 (остановка и запуск Sysmon) и ID 16 (изменение конфигурации Sysmon).
Журналы Power Shell
Power Shell — мощный инструмент управления Windows-инфраструктурой, поэтому велики шансы, что атакующий выберет именно его. Для получения данных о событиях Power Shell можно использовать два источника: Windows PowerShell log и Microsoft-WindowsPowerShell / Operational log.
Windows PowerShell log
Загружен поставщик данных (ID события 600). Поставщики PowerShell — это программы, которые служат источником данных для PowerShell для просмотра и управления ими. Например, встроенными поставщиками могут быть переменные среды Windows или системный реестр. За появлением новых поставщиков нужно следить, чтобы вовремя выявить злонамеренную активность. Например, если видите, что среди поставщиков появился WSMan, значит был начат удаленный сеанс PowerShell.
Microsoft-WindowsPowerShell / Operational log (или MicrosoftWindows-PowerShellCore / Operational в PowerShell 6)
Журналирование модулей (ID события 4103). В событиях хранится информация о каждой выполненной команде и параметрах, с которыми она вызывалась.
Журналирование блокировки скриптов (ID события 4104). Журналирование блокировки скриптов показывает каждый выполненный блок кода PowerShell. Даже если злоумышленник попытается скрыть команду, этот тип события покажет фактически выполненную команду PowerShell. Ещё в этом типе события могут фиксироваться некоторые выполняемые низкоуровневые вызовы API, эти события обычно записывается как Verbose, но если подозрительная команда или сценарий используются в блоке кода, он будет зарегистрирован как c критичностью Warning.
Обратите внимание, что после настройки инструмента сбора и анализа этих событий потребуется дополнительное время на отладку для снижения количества ложных срабатываний.
Расскажите в комментариях, какие собираете логи для аудита информационной безопасности и какие инструменты для этого используете. Одно из наших направлений — решения для аудита событий информационной безопасности. Для решения задачи сбора и анализа логов можем предложить присмотреться к Quest InTrust, который умеет сжимать хранящиеся данные с коэффициентом 20:1, а один его установленный экземпляр способен обрабатывать до 60000 событий в секунду из 10000 источников.