Настройка брандмауэра windows server 2016

Обновлено: 07.07.2024

date

06.12.2019

directory

Active Directory, Windows 10, Windows Server 2012 R2, Групповые политики

comments

комментариев 7

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

В крупных организация правила фильтрации портов обычно выносятся на уровень маршрутизатором, L3 коммутаторов или выделенных межсетевых экранах. Однако ничего не мешает вам распространить ваши правила ограничения сетевого доступа Windows Firewall к рабочим станциям или серверам Windows.

Групповые политики, использующиеся для управления настройками Брандмауэра Защитника Windows

С помощью редактора доменной групповой политики (group Policy Management Console – gpmc.msc) создайте новую политику с именем Firewall-Policy и перейдите в режим редактирования (Edit).

групповая политика управления брандмауэром windows

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

Administrative Templates -> Network -> Network Connections -> Windows Firewall

  • Computer Configuration -> Administrative Templates -> Network -> Network Connections -> Windows Firewall – эта секция GPO использовалась для настройки правил брандмауэра для ОС Vista / Windows Server 2008 и ниже. Если у вас в домене нет компьютеров со старыми ОС, для настройки файервола используется следующая секция.
  • Computer Configuration -> Windows Settings -> Security Settings -> Windows Firewall with Advanced Security – это актуальный раздел для настройки Брандмауэра Windows в современных версиях ОС и по интерфейсу он напоминает интерфейс локальной консоли управления Брандмауэра.

Включаем Windows Firewall с помощью GPO

Чтобы пользователи (даже с правами локального админа) не могли выключить службу брандмауэра, желательно настроить автоматический запуск службы Windows Firewall через GPO. Для этого перейдите в раздел Computer Configuration- > Windows Settings -> Security Settings -> System Services. Найдите в списке служб Windows Firewall и измените тип запуск службы на автоматический (Define this policy setting -> Service startup mode Automatic). Убедитесь, что у пользователей нет прав на остановку службы.

автозапуск службы Windows Firewall

Перейдите в раздел консоли GPO Computer Configuration -> Windows Settings -> Security Settings. Щелкните ПКМ по Windows Firewall with Advanced Security и откройте свойства.

На всех трех вкладках Domain Profile, Private Profile и Public Profile (что такое профиль сети) измените состояние Firewall state на On (recommended). В зависимости от политик безопасности в вашей организации вы можете указать, что все входящие подключения по умолчанию запрещены(Inbound connections -> Block), а исходящие разрешены (Outbound connections -> Allow) и сохраните изменения.

GPO включить файервол для всех профилей

Создаем правило файервола с помощью групповой политики

Теперь попробуем создать разрешающее входящее правило файервола для всех. Например, мы хотим разрешить подключение к компьютерам по RDP (порт TCP 3389). Щелкните ПКМ по разделу Inbound Rules и выберите пункт меню New Rule.

создать новое правило бранжмауэра windows

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

Выберите тип правила. Можно разрешить доступ для:

тип правила файервола

В нашем случае мы выберем правило Port. В качестве протокола укажем TCP, в качестве порта – порт 3389 (RDP порт по-умолчанию, можно изменить).

выбрать порт

Далее нужно выбрать что нужно сделать с таким сетевым соединением: разрешить (Allow the connection), разрешить если оно безопасное или заблокировать (Block the connection).

разрешить подключение в брандмауэре windows

Осталось выбрать профили файервола, которым нужно применить правило. Можно оставить все профили (Domain, Private и Public).

тип сетевого профиля для применения правила

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

правила windows firewall, настроенные через GPO

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

Теперь осталось назначить политику Firewall-Policy на OU с компьютерами пользователей

Важно. Прежде, чем применять политику файервола к OU с продуктивными компьютерами, настоятельно рекомендуется проверить ее на тестовых компьютерах. В противном случае из-за неправленых настроек брандмауэра вы можете парализовать работу предприятия. Для диагностики применения групповых политик используйте утилиту gpresult.exe.

Проверка политик брандмаэера Windows на клиентах

Обновите политики на клиентах (gpupdate /force). Проверьте, что указанные вами порты доступны на компьютерах пользователей (можно использовать командлет Test-NetConnection или утилиту Portqry).

На ПК пользователя откройте Панель управления\Система и безопасность\Брандмауэр Защитника Windows и убедитесь, что появилась надпись: Для обеспечения безопасности, некоторые параметры управляются групповой политикой (For your security, some settings are controlled by Group Policy), и используются заданные вами настройки брандмаэера.

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

Пользователь теперь не может изменить настройки брандмауэра, а в списке Inbound Rules должны быть указаны все созданные вами правила.

список правил локлаьного брандмауэра после применения политики

Также вы можете вывести настройки файервола с помощью команды:

netsh firewall show state

Импорт / экспорт правил Брандмауэра Windows в GPO

Конечно, процесс создания правил для брандмауэра Windows – очень кропотливое и долгое занятие (но результате того стоит). Для упрощения свое задачи можно воспользоваться возможностью импорт и экспорта настроек брандмауэра Windows. Для этого вам достаточно нужным образом настроить локальные правила брандмауэра на обычном рабочей станции. Затем встаньте на корень оснастки брандмауэра (Монитор Брандмауэра Защитника Windows в режиме повышенной безопасности) и выберите пункт Действие -> Экспорт политики.

Экспорт политики Брандмауэра Защитника Windows

Политика выгружается в WFW файл, который можно импортировать в редакторе Group Policy Management Editor, выбрав пункт Import Policy и указав путь к файлу wfw (текущие настройки будут перезаписаны).

Импорт политики в GPO

Доменные и локальные правила брандмауэра

В зависимости от того, хотите ли вы, чтобы локальные администраторы могли создавать на своих компьютерах собственные правила брандмауэра и эти должны быть объединены с правилами, полученными с помощью групповой политики. в групповой политике вы можете выбрать режим объединения правил. Откройте свойства политики и обратите внимание на настройки в разделе Rule merging. По умолчанию режим объединения правил включен. Вы можете принудительно указать, что локальный администратор может создавать собственные правила брандмауэра: в параметре Apply local firewall rules выберите Yes (default).

правила объединения локальных и доменных правил Брандмауэра Защитника Windows

Совет. Блокирующие правила файервола имеют приоритет перед разрешающими. Т.е. пользователь не сможет создать собственное разрешающее правило доступа, противоречащее запрещающему правилу, настроенному администратором через GPO. Однако пользователь может создать локальное запрещающее правило, даже если этот доступ разрешен администратором в политике.

Несколько советов об управлении брандмауэром Windows через GPO

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

Какие порты нужно открыть для той или иной службы нужно искать в документации на сайте разработчика. Процесс довольно кропотливый и на первый взгляд сложный. Но постепенно вполне реальной придти к работоспособной конфигурации Windows файервола, который разрешает только одобренные подключения и блокирует все остальное. По опыту хочу отметить, что на ПО Microsoft можно довольно быстро найти список используемых TCP/UDP портов.

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

Смена стандартного порта Remote Desktop Protocol

Начнем со стандартной меры — смены стандартного порта Windows 2016 RDP, что позволит предотвратить атаку всем известных портов (well-known ports).
Настройку порта можно осуществить с помощью реестра — HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TerminalServer\WinStations\RDP-Tcp\PortNumber.


Рис. 1. Смена порта RDP в Windows Server 2016 с помощью редактора реестра

После этого запустите Брандмауэр Windows и на боковой панели слева выберите Дополнительные параметры. Далее — Правила для входящих соединений и нажмите кнопку Создать правило (на панели справа)


Рис. 2. Правила для входящих подключений

В появившемся окне выберите Для порта и нажмите кнопку Далее. Затем выберите Определенные локальные порты и введите порт, указанный при редактировании реестра (рис. 3). В следующем окне мастера нужно выбрать Разрешить подключение(рис. 4).


Рис. 3. Задаем новый порт


Рис. 4. Разрешаем подключение

Собственно, на этом настройка завершена. Отключитесь от сервера и установите новое соединение. Не забудьте в настройках RDP-клиента Windows Server 2016 указать новый порт: IP-адрес_сервера: порт.

Блокируем учетные записи с пустым паролем

Усилить RDP безопасность можно, запретив windows server подключаться учетным записям с пустым паролем. Для этого нужно включить политику безопасности «Учетные записи: разрешить использование пустых паролей только при консольном входе»:

  1. Откройте локальную политику безопасности (нажмите Win + R и введите команду secpol.msc)
  2. Перейдите в раздел Локальные политики, Параметры безопасности
  3. Дважды щелкните на нужной нам политике и убедитесь, что для нее задано значение Включен (рис. 5).


Рис. 5. Включение политики безопасности в Windows 2016 RDP «Учетные записи: разрешить использование пустых паролей только при консольном входе»

Настраиваем политику блокировки

Основная проблема в том, что по умолчанию Windows-server (даже 2016!) не защищен от брутфорса, поэтому безопасность RDP в Windows 2016 пребывает не на очень высоком уровне. При наличии какого-либо сервиса, в частности, FTP, вас могут брутфорсить, пока не получат доступ к системе, перебирая огромное множество логинов и паролей. Именно поэтому необходима настройка временной блокировки пользователя после нескольких неудачных попыток.

Необходимый набор правил и настроек называется Политика блокировки учетной записи (Account Lockout Policy). Пока вы еще не закрыли окно Локальная политика безопасности, перейдите в раздел Политики учетных записей, Политика блокировки учетной записи. Установите Пороговое значение блокировки — 5 (максимум 5 неудачных попыток входа), Продолжительность блокировки учетной записи — 30 (на 30 минут учетная запись будет заблокирована после 5 неудачных попыток входа).


Рис. 6. Настройка политики блокировки учетной записи

Настройка службы шлюза служб терминалов

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

Порядок действий для установки службы «Шлюз ТS»:


Рис. 7. Установка службы ролей

Рис. 8. Все готово для установки

Далее нужно создать сертификат для шлюза служб удаленных рабочих столов. Запустите Диспетчер служб IIS, выберите пункт Сертификаты сервера. На панели справа выберите Создать сертификат домена. Введите необходимые сведения (рис. 11).


Рис. 9. Диспетчер служб IIS


Рис. 10. Выберите Создать сертификат домена


Рис. 11. Информация о сертификате

Далее нужно выбрать центр сертификации, который подпишет сертификат, и нажать кнопку Готово. Сертификат появится в списке сертификатов.

Следующий шаг — настройка шлюза TS на использование сертификата. Вернитесь к Диспетчеру серверов и, используя меню Средства, запустите Диспетчер шлюза удаленных рабочих столов. Обратите внимание, что есть одна ошибка — Сертификат сервера еще не установлен или не выбран. Собственно, все, что остается сделать — нажать ссылку рядом Просмотр и изменение свойств сертификата и выбрать ранее созданный сертификат, нажав кнопку Импорт сертификата (рис. 13). В этом окне также можно создать самозаверяющийся сертификат.


Рис. 12. Диспетчер шлюза удаленных рабочих столов


Рис. 13. Выбор сертификата SSL

Используем протокол SSL/TLS для защиты RDP

Если соединение с RDP-сервером реализовывается не через VPN, для обеспечения защиты подключений рекомендуется активировать SSL/TLS-туннелирование соединения.

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

Смена стандартного порта Remote Desktop Protocol

Начнем со стандартной меры — смены стандартного порта Windows 2016 RDP, что позволит предотвратить атаку всем известных портов ( ports).
Настройку порта можно осуществить с помощью реестра —

Смена порта RDP в Windows Server

Рис. 1. Смена порта RDP в Windows Server 2016 с помощью редактора реестра

После этого запустите Брандмауэр Windows и на боковой панели слева выберите Дополнительные параметры. Далее — Правила для входящих соединений и нажмите кнопку Создать правило (на панели справа)

Смена порта RDP в Windows Server

Рис. 2. Правила для входящих подключений

В появившемся окне выберите Для порта и нажмите кнопку Далее. Затем выберите Определенные локальные порты и введите порт, указанный при редактировании реестра (рис. 3). В следующем окне мастера нужно выбрать Разрешить подключение (рис. 4).

Смена порта RDP в Windows Server

Рис. 3. Задаем новый порт

Разрешаем подключение

Рис. 4. Разрешаем подключение

Собственно, на этом настройка безопасности RDP завершена. Отключитесь от сервера и установите новое соединение. Не забудьте в настройках Windows Server 2016 указать новый порт: : порт.

Блокируем учетные записи с пустым паролем

Усилить RDP безопасность можно, запретив windows server подключаться учетным записям с пустым паролем. Для этого нужно включить политику безопасности «Учетные записи: разрешить использование пустых паролей только при консольном входе»:

  1. Откройте локальную политику безопасности (нажмите Win + R и введите команду secpol.msc)
  2. Перейдите в раздел Локальные политики, Параметры безопасности
  3. Дважды щелкните на нужной нам политике и убедитесь, что для нее задано значение Включен (рис. 5).

Разрешаем подключение

Рис. 5. Включение политики безопасности в Windows 2016 RDP «Учетные записи: разрешить использование пустых паролей только при консольном входе»

Настраиваем политику блокировки

Основная проблема в том, что по умолчанию (даже 2016!) не защищен от брутфорса, поэтому безопасность RDP в Windows 2016 пребывает не на очень высоком уровне. При наличии сервиса, в частности, FTP, вас могут брутфорсить, пока не получат доступ к системе, перебирая огромное множество логинов и паролей. Именно поэтому необходима настройка временной блокировки пользователя после нескольких неудачных попыток.

Необходимый набор правил и настроек называется Политика блокировки учетной записи (Account Lockout Policy). Пока вы еще не закрыли окно Локальная политика безопасности, перейдите в раздел Политики учетных записей, Политика блокировки учетной записи. Установите Пороговое значение блокировки — 5 (максимум 5 неудачных попыток входа), Продолжительность блокировки учетной записи — 30 (на 30 минут учетная запись будет заблокирована после 5 неудачных попыток входа).

Разрешаем подключение

Рис. 6. Настройка политики блокировки учетной записи

Широкий спектр услуг
по выделенным северам
и мультиклауд-решениям Конфигурация VPS и бесплатный тест уже через 2 минуты Организация вашей IT-инфраструктуры на основе мультиклауд-решения

Настройка службы шлюза служб терминалов

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

Порядок действий для установки службы «Шлюз ТS»:

 Установка службы ролей

Рис. 7. Установка службы ролей

Все готово для установки

Рис. 8. Все готово для установки

Далее нужно создать сертификат для шлюза служб удаленных рабочих столов. Запустите Диспетчер служб IIS, выберите пункт Сертификаты сервера. На панели справа выберите Создать сертификат домена. Введите необходимые сведения (рис. 11).

Диспетчер служб IIS

Рис. 9. Диспетчер служб IIS

Выберите Создать сертификат домена

Рис. 10. Выберите Создать сертификат домена

Информация о сертификате

Рис. 11. Информация о сертификате

Далее нужно выбрать центр сертификации, который подпишет сертификат, и нажать кнопку Готово. Сертификат появится в списке сертификатов.

Следующий шаг — настройка шлюза TS на использование сертификата. Вернитесь к Диспетчеру серверов и, используя меню Средства, запустите Диспетчер шлюза удаленных рабочих столов. Обратите внимание, что есть одна ошибка — Сертификат сервера еще не установлен или не выбран. Собственно, все, что остается сделать — нажать ссылку рядом Просмотр и изменение свойств сертификата и выбрать ранее созданный сертификат, нажав кнопку Импорт сертификата (рис. 13). В этом окне также можно создать самозаверяющийся сертификат.

Диспетчер шлюза удаленных рабочих столов

Рис. 12. Диспетчер шлюза удаленных рабочих столов

Выбор сертификата SSL

Рис. 13. Выбор сертификата SSL

Используем протокол SSL/TLS для защиты RDP

Если соединение с реализовывается не через VPN, для обеспечения защиты подключений рекомендуется активировать SSL/ соединения.


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

Итак, предположим, что у нас есть небольшая компания, которая арендует терминальный сервер в удаленном дата-центре.

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

Во времена Windows 2003 встроенный фаервол представлял собой жалкое зрелище, и в случае невозможности применения сторонних средств приходилось использовать IPSec. Пример такой настройки разобран, например, в материале Secure Windows Servers using IPSec Firewall.

Сейчас, с появлением WFP (Windows Filtering Platform) дела стали получше. В принципе, с этим фаерволом так или иначе сталкивался, наверное, каждый системный администратор Windows, поэтому настройка удаленного доступа к серверу только с определенных IP не должна вызывать затруднений. Я обращу внимание на некоторые «фишки», которые используются редко.

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


Теперь, если мы захотим запретить пользователям терминального сервера выходить с этого сервера в интернет — у нас это получится.

Стоит отметить, что при настройке правил доступа к серверу (входящие подключения) явно создавать правила для исходящего трафика не нужно. В терминах iptables — established и related всегда разрешены.

Для ценителей командной строки настройку фаервола можно производить в контексте netsh advfirewall. Почитать про команды можно в материале «Брандмауэр Windows 7 в режиме повышенной безопасности», я же добавлю, что блокировка входящих и исходящих подключений включается командой:

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

Выхода, по сути, два с половиной (напомню, мы пока говорим только про встроенные средства): регулярно проверять, не изменились ли правила, и использовать старый добрый IPSec или — как по мне, самый разумный вариант — настраивать фаервол групповой политикой. Настройка производится в Конфигурация компьютера — Конфигурация Windows — Параметры Безопасности — Монитор брандмауэра Защитника Windows в режиме повышенной безопасности.


Настройка фаервола групповой политикой.

Также при помощи фаервола windows можно реализовать простой fail2ban. Достаточно включить аудит неудачных попыток входа и при нескольких неудачах подряд блокировать IP источника. Можно использовать самописные скрипты, а можно уже готовые средства, о которых я писал в статье «Как дать шифровальщикам потопить компанию».

Если же встроенного фаервола не хватает и хочется использовать что-то более серьезное, то можно установить стороннее ПО. Жаль, что большинство известных решений для Windows Server — платные. Другим вариантом будет поставить перед сервером роутер. Понятно, что такая установка подойдет, если мы используем colocation, а не аренду сервера где-то далеко-далеко за рубежом. Если же зарубежный дата-центр — это наш выбор, то можно использовать виртуализацию — например, встроенный Hyper-V — и установить в виртуалку привычный GNU\Linux или FreeBSD.

Возникает вопрос: как сделать так, чтоб виртуалка имела прямой выход в интернет, а сервер — нет? Да еще чтобы MAC-адрес сервера не светился хостеру и не требовал тем самым покупки еще одного IP-адреса.

Осторожно! Дальнейшие действия лучше проводить через IP-KVM!

Для этого виртуальную машину нужно снабдить двумя сетевыми адаптерами. Один — для непосредственного подключения к интернету, для него мы сделаем виртуальный коммутатор типа «внешний» и снимем галочку, разрешающую операционной системе взаимодействие с этим коммутатором. Этой самой галочкой мы лишим сервер прямого доступа в интернет (настройку виртуальной машины-фаервола лучше произвести заранее), и его MAC не будет светиться хостеру.


Настройка внешнего виртуального коммутатора.

Другой виртуальный коммутатор следует сделать типа «внутренний» для взаимодействия виртуальной машины и сервера. На нем уже нужно настроить локальную адресацию. Так получится создать виртуальный роутер, стоящий перед сервером и защищающий его.

Заодно на этой виртуальной машине можно настроить любимый VPN до офиса или удаленных сотрудников, не заморачиваясь с ролью «Маршрутизация и удаленный доступ» или со встроенным IPSec, как я рассказывал в статье «Как я базы 1С в Германии прятал». Главное, не забыть проверить автозапуск этой виртуальной машины при старте системы.

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

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

Конечно, для защиты сервера изнутри очень хочется поставить какой-нибудь антивирус — мало ли что пользователи сервера накопируют или накачают из интернета. Но на практике антивирус на сервере может принести больше вреда, чем пользы. Поэтому я обычно использую механизмы блокировки запуска ПО не из белого списка — в частности, механизм SRP (software restriction policies), о котором я тоже упоминал в статье «Как дать шифровальщикам потопить компанию».

Остановлюсь чуть подробнее на одном подводном камне, о котором часто забываем при включении SRP со стандартными настройками, когда блокируется все, кроме папок Windows и Program Files. Действительно, это отфильтровывает почти всех зловредов. Но не очень работает со злонамеренностью сотрудников, ведь в системных папках есть подпапки с правом на создание объектов пользователями. Например, можно посмотреть на папку C:\Windows\Temp.


Разрешения на папку, которая попадет в белый список.

И такая папка не одна. Можно, конечно, проводить аудит системных папок самостоятельно, а можно довериться людям, которые это уже сделали. Например, специалист Stefan Kanthak в своем блоге (по ссылке есть тестовый вирус EICAR, антивирус может сработать) в довольно агрессивной манере проходится по антивирусам и методам защиты Windows и заодно предлагает уже собранный пакет настроек SRP, который будет блокировать и такие подозрительные папки. По запросу автор предоставляет и программу для конвертирования этих настроек реестра в файлы локальных политик.

Если вы предпочитаете использовать механизм AppLocker c более гибкими настройками, то вам может помочь решение AaronLocker.

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

Если AppLocker появился уже довольно давно, а возраст SRP перевалил за 15 лет, то относительно свежей альтернативой является WDAC (Windows Defender Application Control). Действительно, со времен Security Essentials встроенный «антивирус» обзавелся многими интересными возможностями. Например, WDAC — модуль, который отвечает за политики доступа к приложениям и библиотекам. Ранее он являлся частью Device Guard (защита компьютера, в том числе с применением технологий виртуализации), и немного про его настройку рассказывалось в материале «Принцип работы S Mode в Windows 10 и настройка Device Guard своими руками». Подробнее со всеми тонкостями можно ознакомиться в официальной документации, мне же остается добавить несколько минусов, отличающих его от классических решений вроде SRP и AppLocker:

  • Графической настройки нет, все через командлеты PowerShell.
  • Нет настроек в срезе пользователя, только для компьютера.
  • Настройка делается довольно непривычно — подготавливается файл в формате xml, который затем приводится к бинарному, и распространяется по компьютерам.

Зато возможна настройка в срезе приложения: например, если вы хотите дать доступ к cmd.exe вашему скрипту, а не стороннему вирусу — это можно реализовать. Да еще и политику можно применить до загрузки системы, при помощи UEFI.


Блокировка хрома через WDAC.

В целом из-за тягостной настройки сложилось впечатление, что WDAC больше позиционируется не сам по себе для управления компьютерами, а как средство, позволяющее интегрироваться с централизованными MDM-системами вроде Microsoft Intune. Но при этом разработка старых добрых SRP прекращена в Windows 10 1803.

Если говорить про Защитник Windows, нельзя не упомянуть про Credential Guard и Remote Credential Guard.

Первое средство использует опять же виртуализацию, запуская компонент LSA (Local Security Authority) в изолированном от операционной системы процессе, что сильно усложняет процесс кражи хешей паролей и билетов Kerberos. Подробнее про технологию можно почитать в официальной документации. Для работы процессор должен поддерживать виртуализацию, а также в системе должна быть включена безопасная загрузка (Secure Boot) и модуль TPM для привязки учетных данных к оборудованию. Включить Credential Guard можно через групповую политику Конфигурация компьютера — Административные шаблоны — Система — Device Guard — Включить средство обеспечения безопасности на основе виртуализации.


Включение Credential Guard.

Второе средство служит для защиты передаваемых учетных данных (особенно админских!) для удаленного подключения, например, по тому же RDP. Ранее для этих целей предлагался механизм Restricted Admin Mode, но он ограничивал подключение только одним сервером. Подключившись к серверу, нельзя было просто так использовать ресурсы сети, права администратора применялись только к одному серверу а-ля системный аккаунт Local System.

Remote Credential Guard позволяет передавать учетные данные с локальной машины удаленному серверу без явного ввода пароля, что, помимо расширенной безопасности, даст и удобство подключения к серверам (SSO). Почитать подробнее можно в документации, ну а я добавлю, что для работы механизма достаточно включить его поддержку на сервере — например, через реестр командой:

А потом подключаться к серверу командой:

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

Читайте также: