Доменные политики безопасности windows

Картинка с сайта: abuzov.com

Доменом в  Windows Server называют отдельную область безопасности компьютерной сети.

В домене может быть один или несколько серверов выполняющих различные роли. Разрешения, применяемые администратором, распространяются на все компьютеры в домене.

Пользователь, имеющий учетную запись в домене, может войти в систему на любом компьютере, иметь учетную запись на локальном компьютере не требуется.

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

Несколько доменов имеющих одну и ту же конфигурацию и глобальный каталог называют деревом доменов. Несколько деревьев могут быть объединены в лес.

В домене есть такое понятие как групповая политика. Под групповой политикой понимают настройки системы, которые применяются к группе пользователей. Изменения групповой политики затрагивают всех пользователей входящих в эту политику.

Параметры групповой политики хранятся в виде объектов групповой политики (Group Policy Object, GPO). Эти объекты хранятся в каталоге подобно другим объектам. Различают два вида объектов групповой политики  –  объекты групповой политики, создаваемые в контексте службы каталога, и локальные объекты групповой политики.

Не будем подробно вдаваться в теорию и перейдем к практике.

Запускаем Диспетчер серверов -> «Добавить роли и компоненты».

Картинка с сайта: abuzov.com

На первой странице мастер напоминает, что необходимо сделать перед началом добавления роли на сервер. Нажмите «Далее».

На втором шаге нужно выбрать «Установка ролей и компонентов» и нажать «Далее».

Картинка с сайта: abuzov.com

Выбираем сервер, на который нужно установить Active Directory (он у нас один), «Далее».

Картинка с сайта: abuzov.com

Теперь нужно выбрать роль, которую нужно добавить. Выбираем «Доменные службы Active Directory». После чего откроется окно, в котором будет предложено установить службы ролей или компоненты, необходимые для установки роли Active Directory, нажмите кнопку «Добавить компоненты», после чего кликните «Далее».

Картинка с сайта: abuzov.com

PЗатем нажимайте «Далее», «Далее» и «Установить».

Картинка с сайта: abuzov.com

Перезапустите компьютер.

После того, как роль была добавлена на сервер, необходимо настроить доменную службу, то есть установить и настроить контроллер домена.

Настройка контроллера домена Windows Server

Запустите «Мастер настройки доменных служб Active Directory», для чего нажмите на иконку «Уведомления» в диспетчере сервера, затем нажмите «Повысить роль этого сервера до уровня контроллера домена».

Картинка с сайта: abuzov.com

Выберите пункт «Добавить новый лес», затем введите имя домена в поле «Имя корневого домена». Домены в сети Windows имеют аналогичные названия с доменами в интернете. Я ввел имя домена buzov.com. Нажимаем «Далее».

Картинка с сайта: abuzov.com

На этом шаге можно изменить совместимость режима работы леса и корневого домена. Оставьте настройки по умолчанию. Задайте пароль для DSRM (Directory Service Restore Mode – режим восстановления службы каталога) и нажмите «Далее».

Затем нажимайте «Далее» несколько раз до процесса установки.

Когда контроллер домена установиться компьютер будет перезагружен.

Добавление и настройка групп и пользователей в домене Windows Server

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

Отроем «Пользователи и компьютеры Active Directory». Для этого перейдите в Пуск –> Панель управления –> Система и безопасность –> Администрирование –> Пользователи и компьютеры Active Directory.

Картинка с сайта: abuzov.com

Создадим отдел «Бухгалтерия», для этого выделите название домена и вызовите контекстное меню, в котором выберите (Создать – Подразделение). Введите имя отдела (бухгалтерия) и нажмите «OK»

Картинка с сайта: abuzov.com

Подразделения служат для управления группами компьютеров пользователей. Как правило их именуют в соответствии с подразделениями организации.

Создайте учетную запись пользователя в новом подразделении. Для этого в контекстном меню нового подразделения выберите пункт Создать –> Пользователь. Пусть первым пользователем будет Бухгалтер.

Картинка с сайта: abuzov.com

После ввода имени пользователя и учетной записи нажмите «Далее». Теперь нужно ввести пароль. По умолчанию пароль должен соответствовать требованиям сложности, то есть содержать три из четырех групп символов: заглавные буквы, строчные буквы, цифры, специальные знаки ( . , + – = ? № $ и так далее). Установите параметр «Требовать смену пароля при следующем входе в систему».

Создайте учетную запись группы безопасности. Для этого в контекстном меню нового подразделения (бухгалтерия) выберите пункт (Создать – Группа). При создании новой группы безопасности необходимо ввести имя, область действия и тип группы. Область действия определяет видимость данной группы в службе каталога. Глобальная группа видна в любом домене службы каталога и ей могут назначаться привилегии доступа к ресурсам других доменов. Локальная группа видна только в своем домене, то есть ей будут доступны ресурсы только ее домена. Группы безопасности позволяют
объединять пользователей и другие группы для назначения им одинаковых привилегий на различные объекты. Группы распространения используются для рассылки сообщений, они не участвуют в разграничении прав доступа.

Картинка с сайта: abuzov.com

Теперь нужно ввести компьютер в домен и зайти под новым пользователем. Для этого на клиентском компьютере нужно указать DNS-адрес. Для этого откройте «Свойства сетевого подключения» (Пуск –> Панель управления –> Сеть и Интернет – >Центр управления сетями и общим доступом – Изменение параметров адаптера), вызовите контекстное меню подключения и выберите «Свойства».

Выделите «Протокол Интернета версии 4 (TCP/IPv4)», нажмите кнопку «Свойства», выберите «Использовать следующие адреса DNS-серверов» и в поле «Предпочитаемый DNS-сервер» укажите адрес вашего DNS-сервера. Проверьте, что задан IP-адрес и маска той же подсети, в которой находится сервер.

Присоединение компьютера к домену

Откройте свойства системы (Пуск –> Панель управления –> Система и безопасность –> Система –> Дополнительные параметры системы). Выберите вкладку «Имя компьютера» и нажмите «Изменить». Выберите «Компьютер является членом домена» и введите имя домена.

Картинка с сайта: abuzov.com

После этого необходимо ввести логин и пароль пользователя с правами присоединения к домену (обычно администратора домена). Если вы всё указали правильно, то появиться приветственное сообщение «Добро пожаловать в домен …».

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

После перезагрузки войдите в систему под доменной учётной записью пользователя, которая была создана ранее

Картинка с сайта: abuzov.com

После ввода пароля операционная система попросит вас сменить пароль.

Вернемся на сервер. Нажмите «Пуск» -> Администрирование и перейдите в окно Управления групповой политикой. Выбираем наш лес, домен, Объекты групповой политики, щелкаем правой кнопкой мыши -> создать. Называем его buh (это объект групповой политики для группы Бухгалтерия).

Теперь необходимо привязать данный объект групповой политики к созданной группе. Для этого нажмите правой кнопкой на созданное подразделение (Бухгалтерия) и выберите «Связать существующий объект групповой политики…», затем выберите созданный ранее объект в списке и нажмите «ОК».

Картинка с сайта: abuzov.com

Далее выбираем созданный объект.

Картинка с сайта: abuzov.com

Выбранный объект должен появиться в списке связанных объектов групповой политики. Для редактирования параметров, определяемых данным объектом, нажмите на него правой кнопкой и выберите «Изменить».

Установка параметров безопасности

Установка параметров безопасности — завершающий этап настройка домена и групповых политик в Windows Server.

Ограничения парольной защиты

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

Картинка с сайта: abuzov.com

В данном разделе объекта групповой политики определяются следующие параметры:

1. «Минимальный срок действия пароля» задает периодичность смены пароля.
2. «Минимальная длина пароля» определяет минимальное количество знаков пароля.
3. «Максимальный срок действия пароля» определяет интервал времени, через который разрешается менять пароль.
4. «Пароль должен отвечать требованиям сложности» определяет требования к составу групп знаков, которые должен включать пароль.
5. «Хранить пароли, используя обратимое шифрование» задает способ хранения пароля в базе данных учетных записей.
6. «Вести журнал паролей» определяет количество хранимых устаревших паролей пользователя.

Тут нужно указать необходимые параметры (определите самостоятельно).

Политика ограниченного использования программ

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

Выберите раздел Конфигурация пользователя –> Политики –> Конфигурация Windows –> Параметры безопасности –> Политики ограниченного использования программ. Нажмите правой кнопкой на «Политики ограниченного использования программ», далее заходим в «Дополнительные правила» и жмем правой кнопкой мыши, затем выбираем «Создать правило для пути».

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

Давайте запретим использовать командную строку на клиентском компьютере.

Картинка с сайта: abuzov.com

Запрет запуска командной строки (cmd.exe).

Картинка с сайта: abuzov.com

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

При попытке запустить командную строку на клиентской машине вы получите сообщение.

Картинка с сайта: abuzov.com

В системном администрировании есть такой термин — GPO, или Group Policy Object. Он расшифровывается как «объект групповой политики». Этот инструмент существует в операционных системах Windows и помогает массово настраивать правила использования компьютеров.

Рассказываем, что представляют собой групповые политики в Windows Server и почему они — незаменимый инструмент администратора.

Для чего нужны групповые политики

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

Всем перечисленным нужно управлять:

• У каждого пользователя в сети должны быть свои права доступа, ограничения и возможности. Например, офисным сотрудникам нужен доступ к факсу, а вот серверам — вряд ли.
• Есть и требования безопасности: какие пароли должны ставить сотрудники, как часто их обновлять, сколько длится сессия в учетной записи и так далее.
• Иногда изменения нужно применить к одному устройству или службе, иногда — к нескольким или даже ко всем сразу.

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

Как устроены доменные политики

У серверной операционной системы Windows Server есть набор инструментов, который называется Active Directory (AD). Эти инструменты помогают управлять устройствами, учетными записями и правилами безопасности в сети. Компании используют AD, чтобы задать каждому пользователю свои настройки доступа и наладить связи между разными видами техники.

Групповые политики — один из компонентов Active Directory. Они помогают создать определенные правила и настройки, а затем массово применить их к разным объектам: компьютерам и принтерам, службам вроде электронной почты, аккаунтам пользователей. 

Картинка с сайта: blog.skillfactory.ru

Например, с помощью групповых политик Active Directory можно:

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

Картинка с сайта: blog.skillfactory.ru

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

Второе понятие — сайт. Это тоже участок компьютерной сети, но созданный не по логическому, а по физическому принципу. В него входят объекты с определенными областями IP-адресов.

Каждый набор правил называется объектом групповой политики и состоит из двух компонентов — контейнера и шаблона.

• Контейнер — одно из основных понятий Active Directory. Это объект, который выполняет функции своеобразного хранилища: группирует внутри разные объекты и другие контейнеры. Конкретно контейнер групповой политики хранит свойства самого GPO, например статус и версию объекта.
• Шаблон — непосредственно набор правил, которые хранятся в объекте групповой политики. Сюда входят разные разрешения, требования и прочие параметры для устройств.

Правила не применяются, пока шаблон групповой политики не связан с определенным контейнером Active Directory. После этого они будут действовать для той группы объектов, с которой связаны.

Какими бывают групповые политики

Важное преимущество групповых политик — они довольно гибкие. Можно создать множество объектов AD GPO с разными правилами и применить их к любой группе устройств, протоколов или аккаунтов. Например, когда администратор создает домен в Windows Server, автоматически появляются две основных политики:

• групповая политика домена по умолчанию — базовые правила, которые применяются ко всем компьютерам. Они касаются трех направлений: паролей, блокировки учетных записей и настроек Kerberos. Последнее — протокол, с помощью которого проверяют корректность пароля;
• политика контроллеров домена по умолчанию — правила безопасности для контроллеров, то есть серверов, которые управляют разными участками сети Windows Server. 

Эти две политики — базовые. Но администратор может добавить намного больше объектов GPO и задать для каждого свои наборы правил. 

Картинка с сайта: blog.skillfactory.ru

Применять политики можно на нескольких уровнях в зависимости от того, с каким контейнером AD связан объект:

• на уровне локального компьютера;
• на уровне сайта;
• на уровне домена;
• на уровне OU — организационной единицы.

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

Настройки GPO, примененные к объектам внутри подразделения, наследуются. То есть если внутри OU или домена есть какие-то другие контейнеры, политики применяются ко всем объектам внутри них.

В чем состоит управление политиками Active Directory

Создавать, настраивать, копировать, удалять и выполнять другие действия с GPO администратор может с помощью специальной консоли — GPMC. Это редактор групповой политики домена, в котором есть все нужные функции, включая составление отчетов. Для GPMC существуют разные интерфейсы для работы с теми или иными настройками. Кроме того, есть утилита GPResult — она позволяет отследить, какие политики применяются к какому-либо объекту. А для командной строки PowerShell можно установить модуль GPO и управлять политиками из нее.

Работать с редактором могут группы пользователей, которым выданы права на управление GPO. По умолчанию к ним относятся:

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

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

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

Картинка с сайта: blog.skillfactory.ru

Картинка с сайта: blog.skillfactory.ru

Порядок можно изменить — именно этим занимаются администраторы, если разные политики начинают конфликтовать или перекрывать друг друга. Вот какие возможности Windows GPO дают это сделать.

Изменение последовательности. Администратор может использовать стандартное свойство объектов Active Directory: более поздние GPO применяются позже всех и имеют самый высокий приоритет. Он может намеренно создать какую-то политику последней, чтобы она оказалась приоритетнее других.

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

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

Отключение связей. Можно вручную отключить применение GPO для определенного контейнера или объекта. Например, если политика распространяется на все компьютеры сети, администратор может «вывести» из-под нее конкретные устройства.

Фильтрация политик. В Active Directory можно использовать списки контроля доступа — ACL, или Access Control List. Они описывают, кто имеет доступ к тому или иному устройству и какие действия может с ним совершать. Для групповых политик тоже можно создать ACL. Тогда они будут действовать только в отношении объектов, к которым получат доступ и право на применение.

Групповые политики и безопасность сети

При всем удобстве GPO их нельзя назвать полностью защищенными. Основная опасность для сети — в необдуманном делегировании. Администраторы могут передавать другим пользователям права на работу с групповыми политиками. А те в свою очередь могут случайно или намеренно применить правила, которые нарушат защиту сети. Например:

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

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

Поэтому при работе с групповыми политиками нужно внимательно относиться к делегированию доступа. А еще — настраивать службы безопасности так, чтобы не допускать инцидентов:

• мониторить изменения в политиках и уведомлять о них администраторов;
• защитить самые важные настройки GPO — не предоставлять к ним доступ никому, кроме доверенных администраторов;
• иметь возможность быстро откатить изменение, если оно нарушает требования безопасности.

Главное о GPO

• GPO — это групповые политики домена, наборы правил, которые применяются к компьютерам внутри локальной сети под управлением Windows Server.
• С помощью политик можно настраивать доступы, разрешения и правила использования для компьютеров, других устройств, учетных записей и служб.
• Политики можно устанавливать на отдельные компьютеры или учетные записи, а также массово: например, на целый отдел или всю сеть.
• Базово создается две политики: групповая политика домена по умолчанию и политика контроллеров домена по умолчанию. Первая управляет всеми устройствами в сети, вторая — только управляющими устройствами, или серверами.
• Администратор может настраивать групповые политики: вмешиваться в порядок наследования, блокировать или принудительно применять какую-то политику к конкретному объекту.
• Групповые политики в частности созданы для обеспечения безопасности, но чтобы сеть действительно была защищенной, нужно внимательно относиться к тому, кто имеет доступ к изменению GPO. А также мониторить изменения и в случае необходимости быстро их откатывать.

Уровень сложностиСредний

Время на прочтение17 мин

Количество просмотров9.2K

Картинка с сайта: habr.com

В корпоративных средах развертывание 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. 

Картинка с сайта: habr.com

Отключение 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 символов и включить историю хранения паролей, чтобы пользователь не смог изменять пароль на использовавшийся ранее. 

Картинка с сайта: habr.com

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

Внедрение 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.

В Microsoft Security Baseline содержатся рекомендованные настройки, которые Microsoft предлагает использовать на рабочих станциях и серверах Windows для обеспечения безопасной конфигурации для защиты контролеров домена, рядовых серверов, компьютеров и пользователей. На основе Microsoft Security Baseline разработаны эталонные групповые политики (GPO), которые администраторы могут использовать в своих доменах AD. Настройки безопасности в групповых политиках Microsoft Security Baseline позволяют администраторам обеспечить уровень защиты корпоративной инфраструктуры Windows, соответствующий актуальным мировым стандартам. В этой статье мы покажем, как внедрить групповые политики на основе Microsoft Security Baseline в вашем домене.

Эталонные политики Microsoft Security Baseline входят в состав продукта Microsoft Security Compliance Manager (SCM). SCM это бесплатный продукт, в который входит несколько инструментов для анализа, тестирование и применения лучших и актуальных рекомендаций безопасности для Windows и других продуктов Microsoft.

Microsoft Security Compliance Toolkit доступен по ссылке https://www.microsoft.com/en-us/download/details.aspx?id=55319. На данный момент в Security Compliance Toolkit доступны Baseline для следующих продуктов:

Картинка с сайта: winitpro.ru

• Windows 10 Version 2004 and Windows Server Version 2004;
• Windows 10 Version 1909 and Windows Server Version 1909;
• Windows 10 Version 1903 and Windows Server Version 1903;
• Windows 10 Version 1809 and Windows Server 2019;
• Microsoft Edge v85;
• Office365 ProPlus;
• Windows Server 2012 R2.

Также можно скачать утилиты:

• LGPO – используется для управления настройками локальной политики;
• PolicyAnalyzer – инструмент для анализа имеющихся групповых политик и сравнения их с эталонными политиками в Security Baseline;
• SetObjectSecurity.

Архив с Security Baseline для каждой версии Windows содержит несколько папок:

• Documentation – xlsx и docx файлы с подробным описанием настроек, которые применяются в данном Security Baseline;
• GP Reports – html отчеты с настройками GPO, которые будут применены;
• GPOs – каталог с готовыми объектами GPO для различных сценариев. Данные политики можно импортировать в Group Policy Management console;
• Scripts – PowerShell скрипты для упрощения импорта настроек GPO в доменные или локальные политики): Baseline-ADImport.ps1, Baseline-LocalInstall.ps1, Remove-EPBaselineSettings.ps1, MapGuidsToGpoNames.ps1;
• Templates – дополнительные admx/adml шаблоны GPO (например, AdmPwd.admx – настройки управления локальными паролями для LAPS, MSS-legacy.admx, SecGuide.admx).

Картинка с сайта: winitpro.ru

В доменной среде Active Directory проще всего внедрить Security Baseline через групповые политики (в рабочей группе можно применять рекомендованные настройки безопасности через локальную политику с помощью утилиты LGPO.exe) .

Есть шаблоны GPO Security Baseline для различных элементов инфраструктуры Windows: политики для компьютеров, пользователей, доменных серверов, контроллеров домена (есть отдельная политика для виртуальных DC), настройки Internet Explorer, BitLocker, Credential Guard, Windows Defender Antivirus. В папке GPOs хранятся готовые GPO политики для различных сценариев использования Windows (далее перечислен список GPO для Windows Server 2019 и Windows 10 1909):

• MSFT Internet Explorer 11 — Computer
• MSFT Internet Explorer 11 — User
• MSFT Windows 10 1909 — BitLocker
• MSFT Windows 10 1909 — Computer
• MSFT Windows 10 1909 — User
• MSFT Windows 10 1909 and Server 1909 — Defender Antivirus
• MSFT Windows 10 1909 and Server 1909 — Domain Security
• MSFT Windows 10 1909 and Server 1909 Member Server — Credential Guard
• MSFT Windows Server 1909 — Domain Controller Virtualization Based Security
• MSFT Windows Server 1909 — Domain Controller
• MSFT Windows Server 1909 — Member Server

Обратите внимание, что для каждой версии Windows Server или билда Windows 10 есть собственный набор Security Baseline.

Распакуйте архив с версией Security Baseline для нужной версии Windows и запустите консоль управления доменными групповыми политиками Group Policy Management (gpmc.msc).

1. Скопируйте ADMX шаблоны в центральное хранилище GPO (Central Store) PolicyDefinitions на DC;
   

   Картинка с сайта: winitpro.ru

2. Создайте новую политику с названием Windows 10 2004 Security Baseline;
3. Щелкните по новой GPO правой кнопкой и выберите Import Settings;
   

   Картинка с сайта: winitpro.ru

4. В качестве Backup Location укажите путь к файлу с Security Baseline для нужной версии Windows (например, C:\distr\SCM\Windows 10 Version 2004 and Windows Server Version 2004 Security Baseline\Windows-10-Windows Server-v2004-Security-Baseline-FINAL\GPOs);
   

   Картинка с сайта: winitpro.ru

5. Перед вами появится список шаблонов политик. В нашем случае я импортирую политику с настройками компьютера. Выберите политику MSFT Windows 10 2004 – Computer (с помощью кнопки View Settings можно посмотреть настройки политики в виде отчета gpresult);
   

   Картинка с сайта: winitpro.ru

6. Далее предлагается указать как нужно переносить ссылки на объекты безопасности и UNC пути. Т.к. политика у нас чистая, выберите пункт Copying them identically from the source;
   

   Картинка с сайта: winitpro.ru

7. После этого настройки эталонной политики Security Baseline для компьютеров с Windows 10 2004 будут импортированы в новую GPO.
   

   Картинка с сайта: winitpro.ru

Чтобы применить данную политику только для компьютеров с нужной версией Windows, нужно использовать WMI фильтры GPO. Например, для Windows 10 2004 можно использовать такой WMI фильтр:

Select Version,ProductType from Win32_OperatingSystem WHERE Version LIKE "10.0.19041%" and ProductType = "1"

Примените данный фильтр к вашей политике.

Картинка с сайта: winitpro.ru

Аналогично можно импортировать Security Baseline для пользователей, контроллеров домена, рядовых серверов и т.д.

Перед применением Security Baseline на компьютеры пользователей, нужно внимательно проверить предлагаемые настройки и сначала применить на OU с тестовыми пользователями или компьютерами. При необходимости, вы можете в политике отключить некоторые настройки, которые предлагаются в Security Baseline.Только после успешного испытания настроек Security Baseline на тестовых компьютерах можно применять настройки для всех компьютеров/серверов в домене.

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

• Управление правилами запуска и установки программ: AppLocker (SRP), UAC и Windows Installer
• Политики паролей и блокировки учетных записей
• Ограничения административных аккаунтов
• Ограничение анонимного доступа
• Настройки политик аудита для получения информации о всех событиях и входов пользователей
• Защита памяти LSA (для
• Доступ к периферийным устройствам (в том числе политики установки принтеров и USB)
• Отключение NetBIOS и NTLM
• Настройки Remote Assistance, теневых подключений, таймаутов RDS, параметров CredSSP Oracle Remediation
• Политика запуска скриптов PowerShell
• Настройка Windows Error Reporting
• Управление правилами Windows Firewall
• Настройки WinRM
• Отключение встроенного администратора
• Политика Hardened UNC paths
• Отключение SMBv1

Политики Security Baseline позволяет существенно повысить защищенность инфраструктуры Windows и гарантировать, что одинаковые настройки применяются на всех (в том числе новых) компьютерах в сети.