security evtx что это
Введение
Операционная система Windows 7 постоянно следит за различными достойными внимания событиями, возникающими в вашей системе. В Microsoft Windows событие (event) – это любое происшествие в операционной системе, которое записывается в журнал или требует уведомления пользователей или администраторов. Это может быть служба, которая не хочет запускаться, установка устройства или ошибка в работе приложения. События регистрируются и сохраняются в журналах событий Windows и предоставляют важные хронологические сведения, помогающие вести мониторинг системы, поддерживать ее безопасность, устранять ошибки и выполнять диагностику. Необходимо регулярно анализировать информацию, содержащуюся в этих журналах. Вам следует регулярно следить за журналами событий и настраивать операционную систему на сохранение важных системных событий. В том случае, если вы администратор серверов Windows, то необходимо следить за безопасностью их систем, нормальной работой приложений и сервисов, а также проверять сервер на наличие ошибок, способных ухудшить производительность. Если вы пользователь персонального компьютера, то вам следует убедиться в том, что вам доступны соответствующие журналы, необходимые для поддержки своей системы и устранения ошибок.
Программа «Просмотр событий» представляет собой оснастку консоли управления Microsoft (MMC) и предназначена для просмотра и управления журналами событий. Это незаменимый инструмент для наблюдения за работоспособностью системы и устранения возникших неполадок. Служба Windows, которая управляет протоколированием событий, называется «Журнал событий». В том случае, если она запущена, Windows записывает важные данные в журналы. При помощи программы «Просмотр событий» вы можете выполнять следующие действия:
Запуск приложения «Просмотр событий»
Приложение «Просмотр событий» можно открыть следующими способами:
Журналы событий в Windows 7
В операционной системе Windows 7, так же как и в Windosw Vista, существуют две категории журналов событий: журналы Windows и журналы приложений и служб. Журналы Windows – используются операционной системой для регистрации общесистемных событий, связанных с работой приложений, системных компонентов, безопасностью и запуском. А журналы приложений и служб – используются приложениями и службами для регистрации событий, связанных с их работой. Для управления журналами событий можно использовать оснастку «Просмотр событий» или программу командной строки wevtutil, о которой будет рассказано во второй части статьи. Все типы журналов описаны ниже:
Приложение – хранит важные события, связанные с конкретным приложением. Например, Exchange Server сохраняет события, относящиеся к пересылке почты, в том числе события информационного хранилища, почтовых ящиков и запущенных служб. По умолчанию помещается в %SystemRoot%\System32\Winevt\Logs\Application.Evtx.
Безопасность – хранит события, связанные с безопасностью, такие как вход/выход из системы, использование привилегий и обращение к ресурсам. По умолчанию помещается в %SystemRoot%\System32\Winevt\Logs\Security.Evtx
Установка – в этот журнал записываются события, возникающие при установке и настройке операционной системы и ее компонентов. По умолчанию размещается в %SystemRoot%\System32\Winevt\Logs\Setup.Evtx.
Система – хранит события операционной системы или ее компонентов, например неудачи при запусках служб или инициализации драйверов, общесистемные сообщения и прочие сообщения, относящиеся к системе в целом. По умолчанию помещается в %SystemRoot%\System32\Winevt\Logs\System.Evtx
Пересылаемые события – если настроена пересылка событий, в этот журнал попадают события, пересылаемые с других серверов. По умолчанию помещается в %SystemRoot%\System32\Winevt\Logs\ForwardedEvents.Evtx
Internet Explorer – в этот журнал записываются события, возникающие при настройке и работе с браузером Internet Explorer. По умолчанию помещается в %SystemRoot%\System32\Winevt\Logs\InternetExplorer.Evtx
Windows PowerShell – в этом журнале регистрируются события, связанные с использованием оболочки PowerShell. По умолчанию размещается в %SystemRoot%\System32\Winevt\Logs\WindowsPowerShwll.Evtx
События оборудования – если настроена регистрация событий оборудования, в этот журнал записываются события, генерируемые устройствами. По умолчанию помещается в %SystemRoot%\System32\Winevt\Logs\HardwareEvent.Evtx
В Windows 7 инфраструктура, обеспечивающая регистрацию событий, основана также как и в Windows Vista на XML. Данные о каждом событии соответствуют XML-схеме, что позволяет получить доступ к XML-коду любого события. Кроме того, можно создавать основанные на XML запросы для получения данных из журналов. Для использования этих новых возможностей не требуются знания об XML. Оснастка «Просмотр событий» предоставляет простой графический интерфейс для доступа к этим возможностям.
Свойства событий
Существует несколько свойств событий оснастки «Просмотр событий», которые подробно описаны немного ниже:
Источник – это программа, зарегистрировавшая событие в журнале. Это может быть как имя программы (например, «Exchange Server»), так и название компонента системы или большого приложения (например, имя драйвера). Например, «Elnkii» означает драйвер EtherLink II.
Уровень – это уровень важности события. В журналах системы и приложений события могут иметь следующие уровни важности:
Пользователь – определяет учетную запись пользователя, от имени которого возникло данное событие. К пользователям относятся особые сущности, например Local Service, Network Service и Anonymous Logon, а также учетные записи реальных пользователей. Это имя представляет собой идентификатор клиента, если событие фактически было вызвано серверным процессом, или основной идентификатор, если олицетворение не производится. В некоторых случаях запись журнала безопасности содержит оба идентификатора. А также в этом поле может стоять N/A (Н/Д), если в данной ситуации учетная запись неприменима. Олицетворение происходит в случаях, когда сервер позволяет одному процессу присвоить атрибуты безопасности другого процесса.
Категория и задачи – определяет категорию события, иногда используемую для последующего описания допустимого действия. У каждого источника событий свои категории. Например следующие категории: вход/выход, использование привилегий, изменение политики и управление учетной записью.
Ключевые слова – это набор категорий или меток, которые могут использоваться для фильтрации или поиска событий. Например: «Сеть», «Безопасность» или «Ресурс не найден».
Компьютер – идентифицирует имя компьютера, на котором произошло событие. Обычно это имя локального компьютера, но также может быть имя компьютера, переславшего событие, или имя локального компьютера до того, как оно было изменено.
Дата и время – определяет дату и время возникновения данного события в журнале.
ИД процесса – представляет идентификационный номер процесса, создавшего данное событие. Компьютерная программа представляет из себя только пассивную совокупность инструкций, в то время как процесс — это непосредственное выполнение этих инструкций
ИД потока – представляет идентификационный номер потока, создавшего данное событие. Процесс, порождённый в операционной системе, может состоять из нескольких потоков, выполняющихся «параллельно», то есть без предписанного порядка во времени. При выполнении некоторых задач такое разделение может достичь более эффективного использования ресурсов вычислительной машины
ИД процессора – представляет идентификационный номер процессора, обработавшего событие.
Код сеанса – это идентификационный номер сеанса на сервере терминалов, в котором произошло событие.
Время работы в режиме ядра – определяет время, потраченное на выполнение инструкций режима ядра, в единицах времени ЦП. Режим ядра имеет неограниченный доступ к системной памяти и внешним устройствам. Ядро системы NT называют гибридным ядром или макроядром.
Время работы в пользовательском режиме – определяет время, потраченное на выполнение инструкций пользовательского режима, в единицах времени ЦП. Режим пользователя состоит из подсистем, которые передают запросы ввода\вывода соответствующему драйверу режима ядра посредством менеджера Ввода-вывода.
Загруженность процессора – это время, потраченное на выполнение инструкций пользовательского режима, в тиках ЦП.
Код корреляции – определяет действие в процессе, для которого используется событие. Этот код используется для указания простых отношений между событиями. Корреляция — статистическая взаимосвязь двух или нескольких случайных величин (либо величин, которые можно с некоторой допустимой степенью точности считать таковыми). При этом, изменения одной или нескольких из этих величин приводят к систематическому изменению другой или других величин.
ИД относительной корреляции – определяет относительное действие в процессе, для которого используется событие
Работа с журналами событий
Просмотр событий
На следующем скриншоте можно увидеть журнал «Приложения», в котором можно узнать сведения о событиях, недавних представлениях и доступных действиях. Для того чтобы просмотреть события журнала приложений, выполните следующие действия:
Желательно почаще просматривать журналы событий «Приложение» и «Система» и изучать существующие проблемы и предупреждения, которые могут предвещать о проблемах в будущем. При выборе журнала в среднем окне отображаются доступные события, включая дату события, время и источник, уровень события и другие данные.
Панель «Область просмотра» показывает основные данные о событиях на вкладке «Общие», а дополнительные специфические данные – на вкладке «Подробности». Включить и выключить эту панель можно, выбрав меню «Вид», а затем команду «Область просмотра».
Для критических систем рекомендуется хранить журналы за последние несколько месяцев. Все время назначать журналам такой размер, чтобы в них умещалась вся информация, как правило, неудобно, решить эту задачу можно по-другому. Можно экспортировать журналы в файлы, распложенные в заданной папке. Для того чтобы сохранить выбранный журнал выполните следующие действия:
Очистка журнала событий
Иногда приходится очищать заполненные журналы событий для обеспечения эффективного анализа предупреждений и критических ошибок операционной системы. Для того чтобы очистить выбранный журнал выполните следующие действия:
Установка максимального размера журнала
Как было сказано выше, журналы событий хранятся в виде файлов в папке %SystemRoot%\System32\Winevt\Logs\. По умолчанию максимальный размер этих файлов ограничен, но его можно изменить следующим способом:
События сохраняются в файле журнала, размер которого может увеличиваться только до заданного максимального значения. После достижения файлом максимального размера, обработка поступающих событий будет определяться политикой хранения журналов. Доступны следующие политики сохранения журнала:
Переписывать события при необходимости (сначала старые файлы) – в этом случае новые записи продолжают заноситься в журнал после его заполнения. Каждое новое событие заменяет в журнале наиболее старое;
Архивировать журнал при заполнении; не переписывать события – в этом случае файл журнала автоматически архивируется при необходимости. Перезапись устаревших событий не выполняется.
Не переписывать события (очистить журнал вручную) – в этом случае журнал очищается вручную, а не автоматически.
Для того чтобы выбрать нужную политику сохранения журналов выполните следующие действия:
Активация аналитического и отладочного журнала
Аналитический и отладочный журналы по умолчанию неактивны. После активации они быстро заполняются большим количеством событий. По этой причине желательно активировать указанные журналы на ограниченный период времени для того, чтобы собрать необходимые для поиска и устранения неполадок данные, а затем снова их отключить. Активацию журналов можно выполнить следующим образом:
Открытие и закрытие сохраненного журнала
При помощи оснастки «Просмотр событий» можно открывать и просматривать сохраненные ранее журналы. Одновременно можно открыть несколько сохраненных журналов и обращаться к ним в любое время в дереве консоли. Журнал, открытый в «Просмотре событий», может быть закрыт без удаления содержащихся в нем сведений. Для открытия сохраненного журнала выполните следующие действия:
Для того чтобы удалить открытый журнал из дерева событий, выполните следующие действия:
Заключение
В этой части статьи, посвященной оснастке «Просмотр событий», рассказывается о самой оснастке и подробно описаны простейшие операции, связанные с мониторингом и обслуживанием системы при помощи «Просмотра событий». Следующая часть статьи будет рассчитана для опытных пользователей Windows. В ней будут описаны задачи с настраиваемыми представлениями, фильтрация, группировка/сортировка событий и управление подписками.
RDP: слабые места протокола и эксперимент с развертыванием ханипота
RDP — один из самых популярных протоколов для удаленного подключения к машинам Windows. Но при неправильной конфигурации он может стать ахиллесовой пятой любой инфраструктуры.
Когда бизнес переходил на удаленку, выбор компаний пал на протокол RDP из-за простоты его настройки и использования. Но переход был экстренным и далеко не все уделили необходимое внимание безопасности. В результате организации оказались под прицелом злоумышленников.
В этой статье мы решили разобрать слабые места протокола RDP и рассказать, как обезопасить инфраструктуру компании. Также мы провели эксперимент, развернув ханипот RDP на нескольких серверах, и описали криминалистические артефакты, которые могут быть обнаружены в случае несанкционированного подключения злоумышленников.
▍Слабости RDP
Почти 4 миллиона RDP-серверов по всему миру сегодня доступны из внешней сети. Не меньшее их количество, скорее всего, доступно лишь из внутренних сетей.
Злоумышленники часто специально ищут слабые места RDP-серверов, чтобы использовать их в своих целях. Так, RDP нередко подвергается брутфорс-атакам. Кроме того, за последние два года специалисты обнаружили серьезные RCE-уязвимости, связанные с RDP.
Брутфорс-атаки
Самые распространенные атаки на RDP — атаки типа брутфорс. Их можно условно разделить на несколько групп.
Простейшим атакам и атакам с использованием словарей организации обычно уделяют должное внимание и защищаются от них. Например, часто предусматривают блокировку учетной записи после нескольких безуспешных попыток входа.
В то же время про атаки password spraying и credential stuffing зачастую забывают. Однако подобные атаки сейчас не редкость, а, напротив, скорее стали обыденностью. Бороться с ними помогает блокировка IP-адресов, с которых производятся множественные неудачные попытки входа по RDP. Также не станет лишним запрет на повторное использование паролей. Кроме того, не стоит использовать один и тот же пароль на нескольких ресурсах.
Уязвимости
С 2019 года было обнаружено несколько серьезных RCE-уязвимостей, связанных с RDP. Их эксплуатация приводит к удаленному исполнению кода на целевой системе.
Уязвимость CVE-2019-0708, получившую название BlueKeep, обнаружили не в самом протоколе RDP, а в реализации службы удаленных рабочих столов (Remote Desktop Service). Данная уязвимость позволяет неаутентифицированному пользователю удаленно исполнить произвольный код на целевой системе. Уязвимости подвержены старые версии Windows: начиная с Windows XP (Windows Server 2003) и заканчивая Windows 7 (Windows Server 2008 R2). Для ее успешной эксплуатации необходимы лишь сетевой доступ к компьютеру с уязвимой версией Windows и запущенная служба RDP. Для этого злоумышленник отправляет специально сформированный запрос к службе по RDP, что позволяет атакующему удаленно выполнить произвольный код на целевой системе. Информация о BlueKeep была опубликована в мае 2019 года, но уязвимыми до сих пор остаются более 289 тысяч RDP-серверов.
Уязвимости CVE-2019-1181/1182/1222/1226 практически аналогичны BlueKeep. Однако если предыдущей уязвимости были подвержены лишь старые версии Windows, то теперь под угрозой оказались и все новые версии ОС. Для эксплуатации уязвимостей злоумышленнику также достаточно отправить специально сформированный запрос к службе удаленных рабочих столов целевых систем, используя протокол RDP, что позволит выполнить произвольный код. Эти уязвимости были опубликованы в августе 2019 года.
Еще одна уязвимость — BlueGate (CVE-2020-0609/0610) — была найдена в компоненте Windows Remote Desktop Gateway в Windows Server (2012, 2012 R2, 2016 и 2019). Она также позволяет злоумышленникам посредством RDP и специально созданных запросов осуществлять удаленное выполнение кода на целевой системе. BlueGate была опубликована в начале 2020 года.
▍Вредоносные программы и RDP
Слабости RDP не остаются вне поля зрения операторов вредоносных программ. Злоумышленники нередко используют ставшие известными учетные данные RDP при проведении целевых атак.
После получения доступа по RDP к целевой системе атакующие вручную отключают средства антивирусной защиты и запускают вредоносные программы. В подобных атаках на зараженной системе зачастую запускаются программы-вымогатели, такие как Dharma (aka Crysis).
▍Приманка для злоумышленников, или как мы развернули ханипот
Мы решили провести эксперимент и проверить, что будет происходить с RDP-сервером, доступным из внешней сети. Для этого было развернуто два ханипота. Мы воспользовались реализацией протокола RDP на Python — RDPY, который можно найти в открытом доступе.
Один ханипот был развернут на публичном сервере DigitalOcean, другой — на сервере в сети нашей организации. Из интернета были доступны три порта:
Максимальное внимание в сети привлек стандартный порт 3389. За те полтора месяца, что работали ханипоты, в общей сложности зафиксировано 15 попыток брутфорса и 237 попыток записи невалидных данных в сокет на публичном сервере; и, соответственно, 16 и 135 попыток — на сервере в сети организации.
Также, как и следовало ожидать, стандартный порт 3389 подвергался многочисленным сканированиям из сети. При этом публичный сервер сканировался в среднем в 2,5 раза чаще, чем сервер в сети организации.
Частоту сканирований можно увидеть на графике ниже. Вертикальными линиями здесь обозначены субботы и воскресенья, которые пришлись на период работы ханипотов. В большинстве случаев на конец рабочей недели приходился спад сканирований из сети.
Попыток просканировать нестандартные порты практически не было. Следовательно, перенос RDP на нестандартный порт поможет частично защититься от большей части атак.
▍Безопасность
Обобщая все вышесказанное, можно вывести несколько правил, которые помогут обезопасить инфраструктуру при удаленном подключении по RDP.
▏Где искать следы подключения по RDP▕
Если у вас возникли подозрения о компрометации системы по RDP, можно попробовать самостоятельно выполнить несколько шагов.
События 21, 22 и 25 — для успешного входа или переподключения, 23 — для отключения. Следует искать события с необычных IP-адресов.
Даже если подключения разрешены исключительно со внутренних IP-адресов, все еще имеет смысл периодически проверять описанные выше логи на предмет внезапного подключения из внешней сети. Это позволит своевременно найти ошибки конфигурации, допущенные администраторами по невнимательности (например, при настройке форвардинга портов и пр.).
Если следы обнаружены
В случае обнаружения следов успешного проникновения через RDP необходимо в первую очередь:
Заметки системного администратора
Грань между «Сейчас чуть-чуть подправлю» и «Ой, б#я!» — очень тонка!
Аудит создания и удаления файлов в Windows 2008, 2012 и 2016
1. Включение механизма аудита
Оптимальный инструмент — групповые политики (применять к OU отслеживаемых серверов). Возможно использование аналогичных локальных политик для каждого сервера
«Computer Settings \ Windows Settings \ Security Settings \ Advanced audit policy configuration \ system audit policies \ object access \ audit file system» => «audit events: success» enabled.
Весьма маловероятен сценарий, когда вам будет необходимо мониторить неудачные попытки доступа к файлам. Не отрицаю, что возможен. Но чаще нужно узнать кто удалил (или выложил) файл.
2. Настройка аудита на конкретных папках
Далее непосредственно на серверах, которые хранят данные, используя проводник, зайдя в свойства папки, которую нужно мониторить, включить настройки аудита для группы, которую хотим мониторить. Например, Everyone, если мы хотим отслеживать любые изменения любыми возможными пользователями и сервисами:
«Delete subfolders and file — Successful»
“Create files / write data — Successful”
“Create folders / append data — Successful”
3. Мониторинг событий
После этого в логах сервера (на котором хранятся файлы) в Security Event Log будут появляться события при создании и удалении файлов и поддиректорий из указанных выше папок.
Отследить конкретных участников операции можно с помощью двух событий:
Event ID: 4660
Description: An object was deleted.
Event ID: 4663
Description:An attempt was made to access an object.
Виды масок доступа:
Тип доступа | Hex | Описание |
ReadData (or ListDirectory) | 0x1 | ReadData – чтение данных из файла или объекта директории.ListDirectory – просмотр содержимого директории. |
WriteData (or AddFile) | 0x2 | WriteData – запись данных в файл.AddFile – создание файла в директории. |
AppendData (or AddSubdirectory or CreatePipeInstance) | 0x4 | AppendData – дописывание данных в файл. Не перезаписывает существующие данные, если дополнительно не содержит флага WriteData.AddSubdirectory – создание поддиректорий. |
DELETE | 0x10000 | Удаление объекта. |
Ключевой источник информации – события 4663:
Раздел Subject содержит информацию об аккаунте, из-под которого производились операции над объектом.
Object – информация о файле (путь, имя, handle)
Process Information содержит информацию о том, какой процесс производил операции с файлом.
В разделе Access Request Information размещена информация о типе доступа и маске доступа.
При создании файла в указанной папке, в Security Event Log появляется пара событий с ID 4663, первое с маской 0х2, второе с маской 0х4.
При удалении файла появляется событие с ID 4663 и маской доступа 0х10000, а также событие 4660. Определить какой именно файл был удалён по событию 4660 можно найдя предваряющее его событие 4663, имеющее идентичный handle.
- симс мобайл сколько дней растет ребенок
- с днем рождения стразы