Безопасность Windows Server: общие рекомендации

В серии прошлых публикаций посвященных безопасности серверных платформ мы неоднократно рассказали о GNU Linux, его механизмах и средствах защиты. Сегодня очередь дошла и до «золотого стандарта» - платформы Microsoft Windows Server. В сегодняшней статье будут обзорно собраны общие рекомендации и технологии применимые для повышения уровня безопасности Windows Server 

1. Изоляция серверных ролей

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

Однако для максимизации защиты рекомендуется зайти немного дальше. В общем случае рекомендуется конфигурировать каждый сервер на выполнение одной конкретной задачи. Например, вместо того, чтобы запускать службы DNS и DHCP на машине, уже выполняющей роль файлового сервера, с точки зрения безопасности лучше устанавливать каждую роль на выделенном сервере. Это не только позволяет сократить контактную зону, но также упрощает устранение неполадок, потому что конфигурация серверов значительно проще.

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

Дополнительную экономию средств на серверы можно получить за счет виртуализации серверов. Например, лицензия на редакцию Windows Server 2008 R2 Enterprise предусматривает возможность размещения до четырех виртуальных машин при условии, что на сервере установлена только роль Hyper-V.

2. Форсирование безопасности DNS  с помощью DNSSEC

Недостатки открытого DNS-севера

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

Проблема в том, достоверность ответа DNS-сервера никак не проверяется, это означает, что в случае взлома DNS сервера (и перенаправления его на ложные DNS сервера), подделки DNS записи, отравлении кэша DNS (DNS cache poisoning), можно отправить пользователя на произвольный IP адрес, причем пользователь будет находится в полной уверенности, что он работает с легитимным сайтом или сервисом. Этими методиками широко используют злоумышленники, перенаправляя пользователей на сайты, содержащие вредоносные коды или собирая их личные данные (пароли, номера кредиток и т.п.) с помощью т.н. pharming атак.

Зачем нужна технология DNSSEC

DNS Security Extensions (DNSSEC) – технология, предназначена для повышения безопасности службы DNS за счет использования криптографических подписей, позволяющих однозначно удостоверится в подлинности информации, полученной от DNS сервера. Т.е. все запросы и ответы DNS сервера с поддержкой DNSSEC должны обладать цифровой подписью, верность которой может проверить клиент с помощью открытого ключа. Эти цифровые подписи создаются при подписывании зоны (применения к ней DNSSEC).

Упрощенно механизм проверки DNSSEC работает так: клиент отправляет запрос на DNS сервер, сервер возвращает DNS ответ с цифровой подписью. Т.к. клиент обладает открытым ключом центра сертификации, подписавшего записи DNS, он может расшифровать подпись (хэш-значение) и проверить ответ DNS. Для этого и клиент и сервер DNS должны быть настроены на использование одного якоря доверия (trust anchor).Trust anchor – предварительно настроенный открытый ключ, связанный с конкретной зоной DNS. Если DNS сервер поддерживает несколько зон, то может использоваться несколько якорей доверия.

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

Основные компоненты DNSSEC определены в следующих стандартах RFC:

RFC 4033

RFC 4034

RFC 4035

DNSSEC в системах Windows

Поддержка технология DNSSEC появилась еще в Windows Server 2008 R2 и Windows 7. Однако из-за сложности и неочевидности настроек, широкого распространения она не получила. Свое дальнейшее развитие DNSSEC получила в Windows Server 2012, в котором функционал DNSSEC был существенно расширен, и предполагает возможность настройки через графический интерфейс.

3. Изменяем стандартный порт RDP-сессий

По умолчанию RDP слушает tcp порт 3389, брутфорсеры и прочие злодеи постоянно сканируют сеть на наличие открытого порта 3389 и 445, подбирая пароли, кормят протокол эксплоитами, сервер из за этого в лучшем случае может зависнуть или уйти в BSOD, а в худшем он может быть скомпрометирован. Поэтому стоит изменить стандартный порт 3389 на любой другой, свободный порт. Сделать это можно специальной утилитой от microsoft или изменив ключ реестра. 

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

4. Конфигурируем брендмауэр: запрещаем всё кроме нужного

Редактируем правила входящих подключений в брандмауре, отключаем всё что не нужно, например обычно на веб-сервере не нужно ничего кроме:

• DNS
• HTTP
• HTTPS
• FTP
• RDP

5. Защита от намеренного подбора паролей к учетных записям

Так как мы выше изменили порт то теперь следует защитится от намеренного подбора паролей, делается это следующим образом

Заходим в локальную политику Control Panel\System and Security\Administrative Tools\Local Security Policy

Переходим в Account Policies — Account Lockout Police

Account lockout threshold — Тут задается кол-во неудачных попыток входа до блокировки учетной записи (Устанавливаем 5 попыток, этого вполне достаточно)

Account lockout duration — Через сколько учетная запись будет автоматически разблокирована (Устанавливаем 20 минут)

Reset account lockout counter after — Сброс счетчика неудачных попыток входа (Устанавливаем 20 минут)

6. Изменяем имя локального администратора

Заходим в локальную политику Control Panel\System and Security\Administrative Tools\Local Security Policy

Переходим в Local Policies — Security Options — Account: Rename administrator account

Открываем правило и вводим новое имя учетной записи администратора.

Примечание: Выше есть правило отключения аккаунта администратора (Accounts: Administrator account status), но лучше просто переименовать, дело в том что учетные записи пользователей блокируются после определенного кол-ва неудачных попыток входа в систему, и только аккаунт администратора не подвержен блокировкам, сделано это специально, чтобы администратор не потерял контроль над сервером в период блокировки всех остальных учетных записей.

7. Отключаем показ пользователей сервера при интерактивном подключении.

Переходим в Local Policies — Security Options и меняем следующие привила:

Interactive logon: Display user information when the session is locket

Открываем правило и в выпадающем меню выбираем «Do not display user information»

Interactive logon: Do not display last user name

Открываем правило и выставляем «Enabled»

8. Patch-менеджмент (политика обновлений)

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

9. Динамическое управление доступом

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

Особо остро этот вопрос стоит сегодня, так как по статистике большинство утечек происходит по вине инсайдеров (намеренной или случайной), которые имеют легальный доступ к некоторой информации. В результате, чтобы перекрыть все потребности, создается большое количество групп, что серьезно усложняет администрирование, в частности понимание того, кто и куда действительно имеет доступ. Малейшая ошибка пользователя или админа — и документ оказывается не на своем месте и имеет ненадлежащие права доступа. Современным организациям остро необходим простой в использовании механизм предотвращения утечки информации (DLP, Data Leak Prevention).

Защитить содержимое можно при помощи службы управления правами (Rights Management Services), но она снимает только часть проблем. Более глобально задачу управления доступом и аудита призвана решить технология динамического управления доступом (Dynamic Access Controls, DAC). 

Технология базируется на трех основных понятиях:

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

Реализована интеграция DAC со службой RMS, что позволяет в реальном времени защищать документы, которым присвоен соответствующий тег. Настройки упрощает автоматическое тегирование документов, которое создается при помощи правил, настраиваемых в диспетчере ресурсов файлового сервера (File Server Resource Manager).

Для реализации DAC система безопасности Win2012 получила новый механизм утверждения claims, такие утверждения существуют для ресурсов, пользователей и учетных записей компьютеров. При входе в систему помимо идентификатора безопасности SID (Security Identifier) учетной записи в маркер добавляются claims (просмотреть их можно, введя «whoami /claims»). Вот эти утверждения, вместе с данными об участии в группах, и используются при доступе к объектам файловой системы. При этом старые механизмы никуда не исчезли. Вначале применяются права доступа к сетевому ресурсу, затем NTFS и, наконец, вступает в работу DAC.

10.  Используйте технологию доступа к сети NAP

Microsoft разработала технологию NAP (Network Access Protection), которая представлена в серверной операционной системе Windows Server 2008. Данная технология предназначена для блокирования/постановки в карантин компьютеров, не соответствующих политикам, принятым в локальной сети. Таким образом обеспечивается защита локальной сети. 

Технология NAP предлагает различные варианты реализации: выдача IP-адресов из различных диапазонов для «хороших» и «плохих» компьютеров; установление соединения IPSec с «хорошими» компьютерами, в то время как «плохим» компьютерам в соединении будет отказано. 

С помощью NetWork Access Protection администраторы компании могут поддерживать состояние «здоровья» сети. Параметры системы клиента проверяются на соответствие политике безопасности, например: наличие свежих обновлений операционной системы, наличие антивирусной программы и состояние её обновлений, установлен и работает ли на клиенте сетевой экран. На основе этих параметров каждый компьютер получает свою оценку безопасности. Компьютер, удовлетворяющий требованиям системы контроля, получает доступ в сеть предприятия. Компьютеры, не удовлетворяющие требованиям безопасности, не смогут получить доступа в сеть или смогут получить доступ лишь в изолированную часть сети, предоставляющую сервисы для достижения клиентом требуемого уровня безопасности.