В корпоративных средах развертывание Active Directory (AD) — де-факто стандарт для администрирования ИТ-инфраструктуры на Windows. Да, в России есть тренд импортозамещения и сопутствующее ему «переползание» на отечественные решения типа Astra Linux-ALD Pro и так далее. Но пока еще Windows стоит много где, и оборона домена AD — это стратегическая задача для большинства организаций.
Кроме того, в процессе импортозамещения AD в вашей организации вполне может оказаться, что полный отказ от Windows+AD невозможен по ряду причин. Причем, как часто бывает, это может проявиться на этапе после того, как вы составили и согласовали техническое решение со всеми нужными инстанциями и регуляторами. Например, внезапно выясняется, что существует некий критический софт, который применяется только на винде и нормально работает только в условиях AD-домена. В итоге часть инфраструктуры продолжит функционировать по «неимпортозамещенной» схеме, при этом ежедневные задачи по администрированию и защите этого сегмента никуда не денутся.
Даже если ваша организация избежит таких «подводных камней» при миграции на отечественные решения, согласитесь, что подобный переезд — продолжительный процесс, который в крупных инфраструктурах с большим количеством legacy вполне может занять годы. Атаки на Active Directory, по моему опыту, происходят каждый день, и тот факт, что организация в это самое время мигрирует на другое решение, не поможет оправдаться, если вас взламывают прямо сейчас.
Короче говоря, если Active Directory используется в организации здесь и сейчас, не стоит пренебрегать мероприятиями по защите, несмотря ни на что.
Для кого эта статья и почему она важна
Защита корпоративной IT-инфраструктуры организации — это всегда комплексный процесс, который можно представить как эшелонированную многоуровневую оборону. В более-менее крупной организации почти всегда есть периметровые межсетевые экраны, WAF, шлюзы для защиты почтового трафика, IDS/IPS, защита конечных точек с помощью средств антивирусной защиты и EDR, сегментирование по VLAN и подсетям, различные политики безопасности, VPN для удалёнщиков, процедуры патч-менеджмента и так далее. Всё это части единой стратегии, и все защитные решения и их администраторы работают ради одной цели.
Проблема многих материалов и руководств по защите AD заключается в том, что их пишут администраторы домена для администраторов домена. Это закономерно, но не всегда эффективно. Да, на первый взгляд все логично — один специалист по Active Directory пишет руководство об Active Directory для других специалистов по Active Directory. Но на самом деле такие рекомендации по AD часто охватывают только архитектуру и настройку, тогда как защита AD, как ключевого элемента инфраструктуры организации, требует комплексного подхода:
Сетевые инженеры обеспечивают сегментацию сети, настройку межсетевых экранов и IDS/IPS.
Инженеры по управлению уязвимостями следят за своевременным обновлением и патчингом систем.
Команда SOC анализирует логи и события безопасности, а также реагирует на инциденты для предотвращения атак.
Системные инженеры и администраторы поддерживают серверы и рабочие станции, производят их замену/модернизацию, настраивают резервное копирование.
Инженеры по ИБ проводят аудиты, тесты на проникновение, следят за соответствием требованиям.
CISO отвечают за управление ИБ в организации, в том числе занимаются выработкой организационных мер по защите.
И, наконец, администраторы домена отвечают за управление доменной инфраструктурой, настройку политик безопасности, контролируют учетные записи и группы.
Если инфраструктура небольшая, то, как правило, вышеописанные функции распределяются на меньшее количество человек, однако общая картина от этого не меняется. Active Directory — ключевой элемент корпоративной инфраструктуры, и поэтому подход к ее защите обязан быть комплексным. Администратор домена (в большинстве случаев) совершенно не обязан знать, что такое EDR, какие политики надлежит настроить на файрволе периметра и каково состояние антивирусов и закрытия уязвимостей на конечных точках в определённый момент времени. Таким образом, рекомендации по этим мероприятиям не окажутся в его статье по харденингу AD. Тем не менее всё это важно для защиты домена.
В этой статье я, как автор, описал действия по повышению защищённости AD по принципу обозначенного выше комплексного подхода, охватив не только изменения в конфигурации домена. Надеюсь, она будет полезна для всех, кто обеспечивает этот пресловутый комплексный подход — от сетевых и системных инженеров до менеджеров ИБ — для понимания своей роли в защите и общего расширения кругозора :)
С чего начать?
Чтобы злоумышленникам начать какие-либо вредоносные действия, направленные на AD, им потребуется первоначальный доступ в сеть организации. Имея его, нарушители уже могут выполнить доставку вредоносного ПО на хосты для подготовки плацдарма внутри сети и дальнейшего продолжения атаки. Сложность получения первоначального доступа атакующими напрямую зависит от количества точек входа — систем, по той или иной причине имеющих существенные пробелы в безопасности. Совокупность точек входа называется поверхностью атаки (Attack Surface). Чем меньше поверхность атаки, тем сложнее злоумышленнику скомпрометировать систему. А если проникновение все же произойдет, это поможет замедлить его продвижение внутри сети. В роли точек входа могут выступать открытые в интернет порты, незащищенные протоколы, неполное покрытие конечных устройств средствами антивирусной защиты, устаревшие версии операционных систем, программного обеспечения и так далее.
Базовые мероприятия
Этот раздел содержит вещи, с которых следует начать. Это, если угодно, лучшие практики для сокращения поверхности атаки. Несмотря на их общеизвестность, далеко не во всех организациях им уделяют достаточно внимания. Ниже небольшой список, который можно использовать как чек-лист:
Установить на все системы организации (не только в домене, а вообще везде) антивирусы с централизованным управлением, а также регулярно обновлять антивирусные базы (не менее раза в сутки). Это поможет обнаружить и удалить известные вредоносные программы, попавшие в систему.
Провести аудит политик антивируса. Убедиться, что компоненты антивируса включены на всех системах, а централизованные политики запрещают отключение защиты, завершение работы и удаление антивирусного ПО без ввода пароля администратора защиты (пароль должен быть достаточно сложным).
Обновлять операционные системы. Это невероятно важно. Минимум, который нужно соблюдать: система должна быть поддерживаемой производителем, то есть для неё должны выходить обновления безопасности. Использование устаревших ОС, снятых с поддержки, приводит к тому, что новые уязвимости находятся, но не закрываются. Соответственно, поверхность атаки на таких системах будет только расти. Так, Windows Server 2012 R2 достиг EOL (End of Life) в октябре 2023 года, и Microsoft больше не выпускает для него обновления безопасности. Дальнейшая эксплуатация этой ОС повышает риск, так как новые уязвимости не будут закрыты. Поэтому важно вовремя обновлять ОС до актуальных версий и устанавливать свежие обновления безопасности.
Помимо закрытия уязвимостей, в новых системах могут появляться новые функции безопасности, которые разрабатываются в ответ на изменение ландшафта угроз. Яркие примеры здесь — Windows LAPS, Windows Sandbox и Credential Guard.
Обновлять программное обеспечение. Здесь история та же — в старых версиях ПО могут быть уязвимости, которые будут эксплуатироваться злоумышленниками в различных вредоносных целях: вызов отказа в обслуживании, раскрытие и перехват данных, повышение привилегий и так далее. Надо заметить, что в любой крупной корпоративной инфраструктуре есть legacy-системы, миграция которых на новое решение невозможна по тем или иным причинам. В этом случае требуется принять компенсирующие меры: установить все доступные патчи безопасности, вывести хост из домена, поместить в отдельную подсеть и ограничить использование минимально необходимыми задачами.
Усилить фильтрацию контента, передаваемого по электронной почте. Пожалуй, наиболее часто применяемый способ получить первоначальный доступ — это фишинговые электронные письма (T1566 Mitre). На корпоративную почту направляется письмо с вредоносной нагрузкой, в роли которой может быть исполняемый файл, ссылка на недоверенный сайт или текстовый документ с макросом, который активирует вредоносный код при открытии.
Для фильтрации электронной почты, прежде всего, требуется реализовывать проверку подписей DMARC, SPF и DKIM, чтобы быть уверенным, что адрес отправителя не был подменен. Также целесообразно использовать решения типа «песочница» для динамического анализа ссылок и исполняемых файлов или вовсе ограничить прием писем с файлами .exe, .ps1, .bat и т. д., которые могут быть потенциально вредоносными.
Заблокировать подключение недоверенных флеш-накопителей. Первоначальный доступ также может быть достигнут через заражённые флеш-накопители, и ущерб может быть катастрофическим. Яркий тому пример – Stuxnet, который вывел из строя 20% иранских центрифуг для обогащения урана. Для защиты можно применять политику «белых списков», разрешая запуск на конечных устройствах только для доверенных флеш-накопителей. Да, тетя Люда из отдела кадров будет недовольна, что теперь нельзя брать работу на дом… А может, оно и к лучшему?
Вынести контроллеры домена в отдельный сегмент. Изоляция DC в отдельный сегмент сети позволяет минимизировать риски бокового перемещения. Боковое перемещение — это процесс, при котором злоумышленник, получив доступ к одной системе в сети, пытается расширить свою активность, перемещаясь к другим системам. Вынесение DC в отдельный сегмент позволяет уменьшить вероятность такого рода перемещения. На DC должны быть доступны только необходимые сервисы (Kerberos, DNS, LDAPS). Это снизит вероятность успешной эксплуатации злоумышленником уязвимостей в других сервисах. Протоколы RDP и SMB, которые часто используются для бокового перемещения, должны быть отключены или ограничены. В этом случае злоумышленнику необходимо сначала скомпрометировать систему в сегменте, которая имеет доступ к DC, что усложняет задачу и дает время для реагирования. Важно: DNS отключать нельзя, так как Kerberos использует его для создания билетов.
Где продолжить: AD, сеть, эндпоинты и реагирование
Если вы уже Смешарик уделили вышеописанным мероприятиям должное внимание, то можно перейти к задачам поинтереснее. Ниже приведен ряд рекомендаций для AD, сетевых и конечных устройств, процесса резервного копирования, SOC и мер организационного характера.
Действия в AD
Ограничение привилегий администраторов. Лучше избегать неограниченных или избыточных привилегий. Например, в организации есть несколько администраторов, при этом их обязанности различаются. Кто-то отвечает за один отдел или департамент, кто-то —за другой, кто-то за серверы, кто-то — за управление контроллерами домена и политики GPO. Зачем назначать им права, не требующиеся для выполнения конкретных обязанностей? Целесообразно руководствоваться принципом наименьших привилегий (Principle of Least Privilege, PoLP).
Например, в организации есть департамент по продажам, за которым закреплен отдельный админ. Можно объединить учетные записи сотрудников департамента в отдельную организационную единицу (OU, Organizational Unit). Называться она будет, скажем, OU Sales. Затем создать группу безопасности SG_Sales_Admins, в которую будет входить администратор, закрепленный за этим департаментом, и через функцию «Делегирование управления» назначить этой группе права в этом конкретном OU. Руководствуясь этой схемой, создавать далее другие группы безопасности и OU, чтобы, к примеру, у пользователей SG_AD_Admins были права на администрирование контроллерами домена и настройку GPO, но не было прав на управление конечными устройствами. При таком подходе, даже если злоумышленник получит доступ к учетной записи администратора, это не приведет к эффекту разорвавшейся бомбы в инфраструктуре домена.
Отключение аутентификации NTLM. Где это возможно, следует полностью отключить NTLM в пользу Kerberos. Это исключает атаки типа NTLM Relay и кражу хэшей паролей. Если критичные приложения ломаются, то можно добавить через GPO исключения для конкретных серверов:
Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options → Network security: Restrict NTLM → Add server exceptions
В процессе перехода на Kerberos нужно убедиться, что для всех сервисов корректно настроены SPN , присутствует синхронизация времени по NTP (расхождение по времени более 5 минут может «сломать» работу протокола), и настроено делегирование для многоуровневых приложений (например, веб-сервер → SQL сервер).
SMB Signing. Написать предыдущий пункт, без сомнения, гораздо проще, чем реализовать его на практике. Полное отключение NTLM нежелательно в сложных или гибридных средах. Там могут возникать ситуации, когда поддержка Kerberos затруднена из-за отсутствия служб DNS и Netlogon. Если отказаться от NTLM не получается, можно включить подпись SMB, как способ митигации атаки NTLM Relay.
Отключение LLMNR. Это устаревший протокол, используемый для разрешения имен в случаях, когда DNS недоступен. Он уязвим к MitM-атакам – злоумышленник может принимать запросы на свой компьютер и перехватывать пароли (например, с помощью Responder или Inveigh). Если DNS есть — протокол можно отключить через GPO.
Ограничение попыток входа. Через политики Active Directory необходимо включить ограничения на попытки пользователей войти в систему, чтобы предотвращать атаки подбора паролей или распыления пароля (Brute Force/Password Spraying). Это делается через редактор групповых политик в разделе «Политика блокирования учетной записи». Здесь можно задать порог блокировки (через какое количество неудачных вводов учетная запись будет заблокирована) и сброс счетчика (через какое время счетчик неудачных попыток сбрасывается). Эти значения необходимо задавать с умом, чтобы не вызвать DoS-атаку с целью блокировки учетных записей и сократить число обращений в техподдержку.
Также в этом пункте нелишне упомянуть, что в рамках организации может быть целесообразно задать ограничение входов на компьютеры в пределах одного департамента. Проще говоря, сотрудники департамента продаж смогут осуществить вход только на компьютеры в своем департаменте. Для этого в AD в свойствах GPO для департамента продаж должно быть установлено, что только члены группы безопасности SG_Sales_Users имеют право «Разрешить вход на этот компьютер» и только для машин, относящихся к OU_Sales.
Сложность паролей. По соседству с политикой блокирования в AD находится политика паролей. Она определяет требования к сложности пароля и сроку его действия. Необходимо задать адекватный срок действия пароля (30-40 дней), длину от 12 символов и включить историю хранения паролей, чтобы пользователь не смог изменять пароль на использовавшийся ранее.
Имеет смысл применять отдельную парольную политику для учетных записей администраторов с более строгими правилами.
Внедрение LAPS. Учетной записи локального администратора на каждой системе следует присвоить уникальный случайно сгенерированный пароль. Если при настройке каждого компьютера в сети на нем создается одна и та же учетная запись локального администратора с одним и тем же паролем, это открывает серьезную дыру в безопасности. После компрометации одного устройства злоумышленник получит административный доступ на всех остальных устройствах в сети. LAPS (Windows Local Administrator Password Solution) решает эту проблему, автоматически генерируя уникальные пароли для локальной учетной записи администратора на каждом компьютере. Это означает, что даже если злоумышленник получит доступ к одному устройству, он не сможет использовать этот пароль для доступа к другим. Кроме того, LAPS предоставляет возможность смены пароля через заданный интервал времени, что также повышает безопасность. Проблема LAPS заключается в одном — для развертывания решения требуется функциональный уровень домена DFL 2016 и выше, а хосты должны быть под управлением Windows 10 21H2 для десктопов и Windows Server 2019 для серверов (или новее). Здесь в полный рост встает задача по обновлению операционных систем, упоминавшаяся выше.
Пароль krbtgt. Krbtgt — это сервисная учетная запись, пароль которой применяется для шифрования билетов Kerberos с помощью KDC (Kerberos Distribution Center, Центр распространения ключей Kerberos). Компрометация пароля может привести к серьезным последствиям, включая реализацию атаки Golden Ticket. Эта атака ведет к полной компрометации домена, поскольку созданный «золотой билет» позволяет злоумышленнику имитировать любую учетную запись, включая администратора домена. Это дает ему права на чтение, запись и удаление любых объектов в домене: пользователи, компьютеры, группы и политики. Менять пароль krbtgt рекомендуется не менее одного раза в год и немедленно — при подозрении на компрометацию. Это небыстрая процедура, занимающая не менее 10 часов, причем требуется сменить пароль дважды для обеспечения сброса билетов Kerberos.
Ограничение доступа к БД SAM. Следует ограничить доступ для анонимных пользователей, а также запретить удаленный доступ. База SAM хранит хэши паролей всех локальных учетных записей. Если анонимные пользователи или злоумышленники получат к ней доступ (например, через удаленные подключения), они могут украсть эти хэши и взломать пароли.
Количество предыдущих подключений к кэшу БД SAM. Если у злоумышленника будет возможность подключиться к кэшу SAM много раз подряд, он может подобрать пароли методом грубой силы (брутфорс).
Ограничения времени хранения кэша в lsass.exe. Процесс lsass.exe хранит в памяти токены (ключи доступа) пользователей. Если токены остаются там слишком долго, это повышает риск кражи. За настройку отвечает ключ TokenLeakDetectDelaySecs типа DWORD. Рекомендуемое значение — не более 10 секунд.
Аудит lsass.exe. Для контроля несанкционированных подключений к LSASS целесообразно включить аудит всех операций с lsass.exe. Это позволит оперативно узнавать о попытках дампа памяти.
Ограничения на доступ пользователей к резервной копии AD в NTDS.dit. Файл NTDS.dit содержит все данные домена, включая пароли. Если злоумышленник получит к нему доступ (например, через резервную копию), он сможет взломать пароли в офлайн-режиме. Требуется открыть доступ к файлу только для тех администраторов домена, которым такой доступ нужен для работы.
Мероприятия на сетевых устройствах
Перейдем к задачам, связанным с сетью. Возможно, этот раздел не откроет никаких тайн для сетевых инженеров. А для их коллег из других отделов? Кто знает…
Ограничение выхода в интернет для административных учетных записей. Доступ должен быть запрещен как из-под доменных административных учётных записей, так и из-под локальных администраторов. Если администраторам нужно выйти в интернет, пусть делают это из-под обычных, непривилегированных. Ограничения такого рода можно настроить, например, на NGFW с помощью интеграции с LDAP. Эта мера уменьшит риски несанкционированной сетевой активности привилегированных учетных записей.
Усиление сетевой сегментации. Рекомендуется выделить сети различных подразделений организации в отдельные сегменты. Передачу данных между сегментами сети ограничить лишь минимально необходимым перечнем портов и протоколов для осуществления рабочих процессов организации. Это замедлит продвижение злоумышленников по инфраструктуре в случае проникновения. Медленнее продвижение — больше времени на реагирование.
Hardening конфигураций сетевых устройств. Требуется административно отключать незанятые порты, запрещать трафик по незащищенным протоколам типа FTP и не использовать VLAN по умолчанию. Доступ к управлению сетевыми устройствами должен осуществляться с доверенных адресов администраторов. Также в корпоративных средах предпочтительнее применять аутентификацию через AAA-сервер типа RADIUS или TACACS+. Обязательно обновлять прошивку.
Мониторинг трафика через IPS/IDS. В контексте предотвращения атак на AD средства обнаружения/предотвращения вторжений должны отслеживать такие вещи, как подозрительный трафик SMB. Если хост соединяется с двадцатью другими за минуту по 445 порту, это странно и может указывать на вредоносную активность. Сетевой инженер может настроить правила для детекта такого поведения:
alert tcp any any -> $HOME_NET 445 (msg:"SMB anomaly"; flow:to_server, established; threshold: type both, track by_src, count 20, seconds 60; sid:1000001; rev:1;).
Изоляция ИБ-сервисов в отдельный сегмент. Хорошая практика — вывести сервисы, относящиеся к обеспечению информационной безопасности организации, в отдельный сетевой сегмент. Передачу данных между этим сегментом и остальной сетью ограничить лишь минимально необходимым перечнем портов и протоколов, необходимых для работы защитных решений и выполнения мониторинга.
Работа с конечными точками
Необходимо заметить, что многие важные для усиления защиты задачи для конечных точек были затронуты выше, в других разделах. Однако есть еще несколько моментов, требующих упоминания.
Пароль BIOS. На эндпоинте может быть всё хорошо с точки зрения политик, антивируса, EDR и осведомленности пользователя. Но это все мало поможет против внутреннего нарушителя, который загрузится с LiveCD Kali Linux и украдет хэши паролей локальных/доменных учёток из файла SAM или вовсе сделает побитовую копию диска. Установленный пароль BIOS заблокирует загрузку с внешних носителей и защитит от несанкционированного изменения настроек.
Контроль запуска программ и исполняемых файлов. На самом деле задача со звездочкой. Суть в том, что если в домене нет «зоопарка» программ и у защитников есть твердое понимание, какой набор софта используется для работы, можно реализовать политику «белых списков» для программного обеспечения, то есть «запрещено все, что явно не разрешено». Другой неплохой вариант — реализовать блокировку запуска неподписанных EXE и скриптов (PowerShell, VBS). Это существенно облегчит работу по реагированию на инциденты безопасности, потому что в условиях такого «зачищенного» ландшафта нелегитимная активность будет видна очень хорошо.
Резервное копирование. Настроить систему резервного копирования таким образом, чтобы резервные копии хранились на отдельном сервере, не входящем в домен, а права на удаление и изменение резервных копий имелись только у специально выделенной учетной записи, также не входящей в домен. Такая мера поможет сохранить резервные копии в случае компрометации домена и попытке удалить или зашифровать информацию на атакованных системах.
Частота резервных копий должна быть такова, чтобы отказ какого-либо хоста не приводил к потере критического объема информации. Исходя из этого же соображения, для критических систем лучше обеспечить создание и хранение как минимум 2 экземпляров каждой резервной копии.
Да, все еще про бэкапы! Делать копии — хорошо, но еще лучше — быть уверенным, что восстановление произойдет штатно. Для этого необходимо внедрить процедуру проверки целостности бэкапов и периодически проводить тестовые восстановления из резервной копии.
Настройка логирования. Вероятно, об этом можно было написать и в разделе про настройки AD, однако по смыслу это все же больше подходит в этот. Суть заключается в том, что если/когда система будет скомпрометирована и начнется расследование, для восстановления картины произошедшего качество и глубина логов будет иметь решающее значение.
Лучшая практика по хранению логов — их отправка на удаленный сервер. Если это невозможно по каким-то причинам, то надо хотя бы озаботиться тем, чтобы увеличить глубину локального журнала. Так, для журнала Security.evtx можно рекомендовать объем не менее 200 Мб.
Мониторинг и реагирование
Защитные решения — это хорошо и правильно. Но все же (пока что, по крайней мере) для эффективного противодействия угрозам требуется участие аналитиков. И тут появляется две проблемы.
Первая — система защиты домена состоит из множества ИБ-решений, которые генерируют тысячи событий в секунду. Хуже того, эти события надо сопоставлять между собой, потому что сообщение о подозрительном файле в письме от почтового шлюза, ивент исходящего соединения на неизвестный IP с МЭ, скачивание неизвестного скрипта и поступившая следом заявка пользователя с формулировкой «у меня тут ничего не работает» могут быть звеньями одной цепи.
Вторая — для работы аналитикам необходимо минимум две «оптики». Одна — слабого приближения, которая позволяет видеть картину в инфраструктуре в целом. Она собирает данные из разных защитных решений, приводит к виду, понятный человеку, обогащает контекстом и сопоставляет друг с другом. Это — SIEM, она показывает общую картину и занимается автоматизацией анализа событий.
EDR — это инструмент для тонкой работы. Он нужен, когда SIEM уже просигнализировал о подозрительной активности, но ее специфика и происхождение понятны не полностью. EDR позволяет эффективно противостоять сложным угрозам, которые не детектируются обычными антивирусными решениями. Решение такого класса позволяет действовать точечно: изолировать узел, убить процесс, собрать форензику.
Основных рекомендаций, которыми мы можем поделиться на этом этапе, всего две. Первая — мониторинг и реагирование связкой SIEM+EDR, вторая — отслеживать характерные события.
SIEM+EDR. С этой рекомендации можно начать. Без сочетания этих решений защита AD рискует превратиться в игру «жмурки»: вы либо видите угрозу, но не можете её изучить, либо изучаете, но не понимаете масштаб. Конкретный сценарий: атака через фишинг.
SIEM замечает:
Подозрительное письмо с вложением (от почтового шлюза).
Исходящие обращения на подозрительный URL (от межсетевого экрана).
Множественные события 4625 (от журнала Security хоста).
И дает быстро связать эти события в один инцидент.
EDR на зараженном ПК:
Обнаруживает запуск скрипта из вложения.
Видит попытку кражи учетных данных через LSASS.
И дает возможность быстро убить процесс, получить файл на анализ и прогнать через песочницу.
Без EDR аналитик может узнать об атаке из SIEM, но не может быстро остановить её на конечной точке. Без SIEM EDR найдет вредонос на одном ПК, но не даст быстро увидеть масштаб проблемы.
В бюджете ИБ не прописаны расходы на приобретение таких решений? Можно использовать бесплатные опенсорсные решения типа Wazuh. Лучше, чем ничего.
Отслеживание характерных событий. В контексте защиты домена у аналитика, работающего с SIEM-EDR, будет достаточно информации для анализа, скучать вряд ли придётся. Для примера приведём несколько важных индикаторов из WinLogEvent, которые надо отслеживать:
4624 (успешный вход) + 4625 (неудачный вход) — позволяют выявлять брутфорс-атаки и подбор учётных данных. Особенно важно, если фигурируют административные учётные записи и еще важнее если события происходят в нехарактерное время или месте.
4768-4769 (Запрос билета (TGT) от учетной записи/Запрос билета обслуживания (TGS) для доступа к сервису) — маркеры для обнаружения Golden Ticket и Silver Ticket.
4648 (Выполнена попытка входа с использованием явных учетных данных) — помогают выявить горизонтальное перемещение. Злоумышленники часто используют явные учетные данные для доступа к другим узлам сети. Пример: Атакующий, получивший хэш пароля, использует runas /user:admin cmd.exe для повышения привилегий.
1102 (очистка логов) — попытка скрыть следы атаки.
4688 (создание процесса) + 4104 (журнал PowerShell) — выявляют использование скриптов и вредоносных утилит.
4886-4887 (Событие получения Certificate Services запроса на сертификат и подтверждение запроса и выдача сертификата) — позволяют быстро определить недоверенные попытки получения сертификатов от Центра сертификации.
Заключение
Эта статья навеяна рядом бесед с коллегами об особенностях национальной защиты инфраструктуры. Спасибо им за это. В заключение можно сказать не так уж много.
Во-первых, AD — это не «раз настроил и забыл», и уж точно безопасность домена — не задача одного лишь админа.
Во-вторых, на внедрение высококлассной архитектуры защиты уйдут годы, но если будет внедрено даже 50% из вышеописанного, защита будет выстроена лучше, чем в 90% организаций. В-третьих, эта статья не является исчерпывающим руководством. Многое из того, что должно быть сделано, не описано в ней. Так, например, практически не затронута тема защиты центра сертификации. Но на эту тему, как и на многие другие, требуется отдельная статья с описанием реализации двухуровневой иерархии и изоляцией корневого CA и отказоустойчивостью подчиненных. По защите AD пишутся книги на сотни страниц, так что простора для работы здесь много.
Главное правило «бойцовского клуба»: не ждите, пока AD атакуют. Учитесь нейтрализовывать и обнаруживать угрозы до того, как их последствия станут необратимыми.
НЛО прилетело и оставило здесь промокод для читателей нашего блога:
-15% на заказ любого VDS (кроме тарифа Прогрев) — HABRFIRSTVDS.