Организация программной защиты сервера с использованием возможностей ос microsoft windows

Вопрос безопасности сервера был и будет актуальным. Рассмотрим базовые правила обеспечения безопасности серверов под управлением ОС семейства Window Server.

В быту существует мнение, что Windows не нуждается в обновлениях и их вообще лучше отключить, якобы “чтобы система не тормозила”. Это одна из самых главных ошибок. Обновления важно устанавливать своевременно, особенно критические. Упрощает эту задачу специальная утилита, с которой можно ознакомиться на официальном сайте Центра обновления Windows.

Также важно поддерживать в актуальном состоянии установленное сопутствующее программное обеспечение, в том числе СУБД, различные фреймворки и прочее.

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

Важно понимать, что сервер доступен из сети Интернет. По этой причине, ОС должна быть защищена любым устройством выполняющим функции файрволла. Если подобных устройств нет, то Брандмауэр Windows будет последней надеждой на защиту от несанкционированных подключений к серверу.

Чем меньше TCP/UDP портов доступно извне, тем меньше шансов провести атаку на сервер. В этом вопросе важно разобраться что блокировать. Если речь идет о web-сервере, то доступными необходимо оставить 80 и 443 TCP-порты (эти порты служба слушает по умолчанию).

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

• 3389 — RDP (Remote Desktop Protocol);
• 135-139 — NetBIOS;
• 445 — Samba (общий доступ к файлам и папкам);
• 5000 — 5050 — FTP в пассивном режиме;
• 1433 — 1434 — порты SQL;
• 3306 — стандартный порт MySQL;
• 53 — DNS

Создать правило не сложно. Открываем Пуск → Панель управления → Система и безопасность → Администрирование → Брандмауэр Windows в режиме повышенной безопасности.

В окне программы кликаем правой кнопкой мыши по “Правила для входящих подключений”. В открывшемся контекстном меню выбираем “Создать правило...”.

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

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

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

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

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

При использовании физического сервера (не удаленного и не виртуального), рекомендуется включить запрос пароля пользователя при выходе из режима ожидания. Данный параметр настраивается в панели управления: Панель управления → Все элементы панели управления → Электропитание.

Также важно установить лимиты бездействия пользователя, а “по возвращении” запросить пароль. Это исключит возможность входа другого лица от имени пользователя, в случае если тот отлучился или забыл закрыть RDP-сессию. Чтобы настроить этот пункт, следует воспользоваться настройкой локальных политик secpol.msc.

Мастер настройки безопасности (SCW – Security Configuration Wizard) позволяет создавать XML-файлы политик безопасности, которые впоследствии, можно перенести на другие серверы. Эти политики включают в себя не только правила использования сервисов, но и общие параметры системы и правила Firewall.

Кроме первоначальной настройки групповых политик Active Directory, периодически следует проводить их ревизию и повторную настройку. Это один из основных способов обеспечения безопасности Windows-инфраструктуры.

Для удобства управления групповыми политиками, можно воспользоваться не только встроенной в Windows Server утилитой «gpmc.msc», но и предлагаемую Microsoft утилиту «Упрощенные параметры настройки безопасности» (SCM-Security Compliance Manager).

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

Для управления локальными политиками вы можете использовать соответствующую оснастку «Локальная политика безопасности», вызываемую командой secpol.msc из Пуск -> Выполнить (клавиша Windows + R).

1. Блокировать RDP-подключения для пользователей с пустым паролем.

Наличие пользователей без паролей недопустимо, но если этого миновать не удается, то можно хотя бы запретить подключение к RDP. Для этого открываем Пуск → Средства администрирования.

В открывшемся каталоге, запускаем Локальная политика безопасности.

В окне локальный политик безопасности, слева, выбираем Локальные политики → Параметры безопасности. В основной части окна, находим “Учетные записи: Разрешить использование пустых паролей только при консольном входе”.

Выбираем этот пункт двойным кликом и переводим переключатель в положение “Отключен”. Нажимаем кнопку “OK”.

2. Поменять стандартный TCP-порт RDP.

Замена номеров TCP-портов стандартных сервисов на другие значения, вполне может повысить безопасность сервера, главное не забыть новый номер порта.

Для замены порта:

1. открываем редактор Реестра Windows — Windows + R

2. На всякий случай, создаем резервную копию реестра (Файл → Экспорт)

3. Разворачиваем ветку HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlTerminal ServerWinStationsRDP-Tcp и, в правой доле окна, находим параметр PortNumber.

4. Открываем параметр двойным кликом мыши. В открывшемся окне выбираем Систему исчисления: Десятичная, указываем новое значение порта, нажимаем кнопку “OK” и закрываем окно редактора реестра.

5. Чтобы была возможность подключиться к серверу, создаем соответствующее правило для Брандмауэра Windows. Кликаем правой кнопкой мыши по “Правила для входящих подключений”, в контекстном меню выбираем “Создать правило”.

В окне “Мастера”, выбираем “Для порта”

Затем выбираем “Протокол TCP”, “Определенные локальные порты” и указываем новый номер порта.

Следующим шагом выбираем “Разрешить подключение”

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

На итоговом шаге, указываем название правила и описание к нему.

6. Перезагружаем сервер чтобы применить изменения.

7. Для подключения к удаленному рабочему столу теперь используем IP-адрес или доменное имя, а через двоеточие указываем порт.

Служба “Шлюз TS (служб удаленных рабочих столов)” позволяет обезопасить подключение к удаленному рабочему столу путем использования протокола HTTPS(SSL), тем самым избавляя системного администратора от необходимости настройки VPN. Инструмент способен комплексно контролировать доступ к машинам, а также устанавливать правила авторизации и требования к удаленным пользователям, например:

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

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

1. Открываем Диспетчер серверов.

2. Выбираем “Добавить роли и компоненты”

3. На этапе “Тип установки”, выбираем “Установка ролей и компонентов«.

4. Следующим шагом выбираем текущий сервер.

5. Роль сервера — Служба удаленных рабочих столов.

6. Переходим к службе ролей. Выбираем “Шлюз удаленных рабочих столов”.

7. Переходим к этапу подтверждения, нажимаем кнопку “Установить”.

После установки роли, в окне Диспетчера серверов, выбираем Средства → Remote Desktop Services → Диспетчер шлюза удаленных столов.

В открывшемся окне, в левой его части, нажимаем по значку сервера. В основной части окна, выбираем “Просмотр и изменение свойств сертификата”.

В открывшемся окне “Свойства” переходим на вкладку “Сертификат SSL”. Выбираем пункт “Создать самозаверяющий сертификат”, нажимаем кнопку “Создать и импортировать сертификат”.

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

В новом окне следует проверить параметры. Если все верно — нажимаем “OK”.

Новым окном система оповестит об успешном создании сертификата и выдаст путь до файла.

Переходим к окну свойств сервера. Нажимаем “Применить”.

В окне “Диспетчер шлюза удаленных рабочих столов”, в левой колонке, раскрываем ветку сервера, выбираем “Политики”, затем “Политики авторизации подключений”. В правой колонке того же окна, выбираем “Создать новую политику”  → “Мастер”.

В новом окне выбираем ”Создать только политику авторизации подключений к удаленным рабочим столам”, нажимаем “Далее”.

Указываем желаемое имя для политики. Мы рекомендуем указывать имя латиницей.

Следующим шагом будет выбор удобного метода аутентификации — пароль или смарт-карта. Оставляем отмеченным только “Пароль”. Нажимаем кнопку “Добавить группу…”

В окне выбора групп кликаем по кнопке “Дополнительно”.

Размер окна изменится. Кликаем по кнопке “Поиск”. В найденных результатах выбираем “Администраторы домена” и нажимаем кнопку “OK”.

В окне выбора группы проверяем выбранные имена объектов и нажимаем “OK”.

Группа добавлена. Для перехода к следующему шагу нажимаем кнопку “Далее”.

На следующем этапе выбираем пункт “Включить перенаправление устройств для всех клиентских устройств” и нажимаем “Далее”.

Настраиваем таймауты сессий. И действия по их истечении. Рекомендуем отключать сеанс, чтобы фоновые пользовательские процессы не отнимали процессорное время. Нажимаем “Далее”.

На крайнем этапе просматриваем сводку, нажимаем “Готово”.
На подтверждение создания политики нажимаем “Закрыть”.

Настроим политику авторизации ресурсов.

Процесс выполняется подобно предыдущему.

В окне диспетчера шлюза удаленных рабочих столов, раскрываем ветку Политики → Политики авторизации подключений. В правой части окна выбираем “Создать новую политику” → “Мастер”.

В открывшемся окне выбираем “Создать только политику авторизации ресурсов удаленных рабочих столов”, нажимаем кнопку “Далее”.

Первым шагом указываем желаемое имя для политики авторизации. Настоятельно рекомендуем указывать имя латиницей. Нажимаем кнопку “Далее”.

В окне выбора групп кликаем по кнопке “Дополнительно”.

Окно изменит размеры. Нажимаем кнопку “Поиск”. В результатах поиска находим “Администраторы домена” и нажимаем кнопку “OK”.

В окне выбора группы проверяем выбранные имена объектов и нажимаем “OK”.

Группа добавлена. Для перехода к следующему шагу нажимаем кнопку “Далее”.

На следующем шаге разрешаем подключение пользователей к любому сетевому ресурсу. Для этого выбираем соответствующий параметр и нажимаем кнопку “Далее”.

Настраиваем разрешенные порты. сли порт RDP-сервера не был изменен, то оставляем 3389. Нажимаем “Далее”.

Финальным этапом проверяем настройки и нажимаем кнопку “Готово”.

В обновленном окне нажимаем “Закрыть”.

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

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

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

Обзор Windows Nano Server.

Дальнейшим развитием Windows Server Core стал Nano Server. Данная версия дистрибутива исключает использование графического интерфейса пользователя. Всё управление сосредоточено на WMI — инструментарий управления Windows, а также Windows PowerShell. Данный дистрибутив Windows-сервер имеет на 92% меньше критических рекомендаций безопасности. Nano Server доступен только для клиентов Microsoft Software Assurance и на платформах облачных вычислений, например, Microsoft Azure и Amazon Web Services. Начиная со сборки Windows Server 1709, Nano Server можно устанавливать только внутри хоста контейнера .

Тема безопасности сервера 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 в режиме повышенной безопасности», я же добавлю, что блокировка входящих и исходящих подключений включается командой:

netsh advfirewall set currentprofile firewallpolicy blockinbound,blockoutbound

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

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

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

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

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

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

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

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

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

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

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

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

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

Защита внутренняя: остановить и не пущать

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

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

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

И такая папка не одна. Можно, конечно, проводить аудит системных папок самостоятельно, а можно довериться людям, которые это уже сделали. Например, специалист 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). Почитать подробнее можно в документации, ну а я добавлю, что для работы механизма достаточно включить его поддержку на сервере — например, через реестр командой:

reg add HKLMSYSTEMCurrentControlSetControlLsa /v DisableRestrictedAdmin /d 0

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

mstsc.exe /remoteGuard

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

Расскажите, а как вы защищаете свои удаленные серверы?

Проголосовали 86 пользователей.

Воздержался 21 пользователь.

В серии прошлых публикаций посвященных безопасности серверных платформ мы неоднократно рассказали о 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. Конфигурируем брендмауэр: запрещаем всё кроме нужного

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

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

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

Заходим в локальную политику Control PanelSystem and SecurityAdministrative ToolsLocal Security Policy

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

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

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

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

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

Заходим в локальную политику Control PanelSystem and SecurityAdministrative ToolsLocal 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). 

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

Реализована интеграция 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 администраторы компании могут поддерживать состояние «здоровья» сети. Параметры системы клиента проверяются на соответствие политике безопасности, например: наличие свежих обновлений операционной системы, наличие антивирусной программы и состояние её обновлений, установлен и работает ли на клиенте сетевой экран. На основе этих параметров каждый компьютер получает свою оценку безопасности. Компьютер, удовлетворяющий требованиям системы контроля, получает доступ в сеть предприятия. Компьютеры, не удовлетворяющие требованиям безопасности, не смогут получить доступа в сеть или смогут получить доступ лишь в изолированную часть сети, предоставляющую сервисы для достижения клиентом требуемого уровня безопасности.

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

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

Account Lockout Policy

К сожалению, Windows-серверы, включая даже 2016, не оснащены защитой от брутфорса. В любой момент к ним можно подключиться и начать перебирать пароли хоть бесконечно — ну и в конце концов подобрать, конечно. Так что придется вручную ставить блокировку после неудачных попыток входа.

В Windows эта политика обозначена Account Lockout Policy, ее можно запустить через secpol.msc -> Политика учетных записей -> Пороговое значение блокировки. Установите, например, максимум 3 или 5 попыток входа в час (для этого нужно задать часовую продолжительность блокировки после соответствующего числа попыток входа).

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

Правильные настройки брандмауэра, использование портов, защита RDP

Брандмауэра сервера на Windows вполне достаточно для обеспечения неплохого уровня защищенности, но и сам по себе он принесет пользу только в случае, если будет хорошо настроен. Как его хорошо настроить? Взять и все запретить!

Пусть открытыми для любого адреса будут порты 443 и 80, да и то только в случае, если сервер обеспечивает работу веб-ресурса. И только белому списку IP-адресов можно будет пользоваться портами 53 (DNS), 990 (FTPS), 1433-1434 (SQL), 3389 (RDP) и 5000-5050 (пассивный FTP).

Нечего и говорить, что посторонние пользователи не должны получать доступа к этим портам! Стандартные порты же лучше вообще не использовать, а перенести сервисы, которые вам нужны, на нестандартные. Откройте порт в правилах брандмауэра, перезапустите сервер — вуаля. Особенно это будет полезно для RDP, который будет полезно защитить пустым паролем. Делается это так: Локальные политики -> Параметры безопасности -> Учетные записи. Там настраиваем разрешение на использование пустого пароля исключительно для консольного входа.

Правильная политика администрирования

Чтобы защитит сервер на Windows, крайне важно правильно обращаться с администраторскими аккаунтами. Не используйте запись по умолчанию! Аккаунт Administrator нужно переименовать через secpol.msc -> Локальные политики -> Параметры безопасности -> Учетные записи -> Переименование учетной записи администратора.

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

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

О паролях и бэкапах, а также о критически важной информации

Грамотные, сложные, надежно защищенные пароли — основа безопасности сервера и всей инфраструктуры. Даже к общим папкам доступ должен получаться по паролю, вам нужно будет фиксировать доступ к ним и определять, кто и когда их использовал, любой анонимный доступ в системе должен быть исключен. Все пароли должны храниться в менеджере паролей: они должны быть гораздо более сложными, чем вы сможете запомнить, и их должно быть много и самых разнообразных.

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

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

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

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

Обновления безопасности

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

Используйте антивирус с актуальными базами сигнатур

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

Программное обеспечение скачиваемое с официальных сайтов

Если необходимое вам программное обеспечение, либо какие-то файлы скачиваются не из надежных источников, то возьмите за правило, сначала загрузить данные ПО на локальный компьютер, проверить его на содержание вредоносного ПО и корректную работу, а затем уже на сам сервер. Таким образом вы избежите возможных проблем. Следует так же взять за правило проверять целостность скачанных файлов, проверяя хэш-сумму скачанного файла с данными, указанными на официальном сайте. Сделать это довольно просто: достаточно воспользоваться консольной командой «certutil -hashfile файл алгоритм (MD5 MD4 MD2 SHA512 SHA384 SHA256 SHA1)» и сравнить вывод с данными на сайте производителя ПО.

Проверка настроек брандмауэра Windows Server

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

Отключение стандартных учетных записей пользователей

Переименуйте учетную запись администратора, используемую по умолчанию. В русскоязычных версиях Windows Server – это пользователь «Администратор», в англоязычных – «Administrator». Либо мы можете создать новую учетную запись с административными правами на сервере, а учетную запись по умолчанию заблокировать, это усложнит злоумышленникам подбор данных для входа на сервер. Гостевая учетная запись должна оставаться заблокированной все время, если же вам она потребовалась, не забудьте установить сложный пароль. Не рекомендуется использовать словарные имена пользователей, используемые при переборе паролей: учетные записи администратора на всех языках, запись гостя, test, учетные записи, привязанные к машинам или сетевым сервисам(printer, scanner, ftp). Естественно, используйте при этом сложные пароли, не менее 8-ми символов, в идеале сгенерируйте пароль случайным образом. Не используйте только лишь цифры или только буквы — такие пароли легко подобрать.

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

Ограничение прав для различных пользователей Windows Server

Обязательно заведите каждому учетную запись с необходимо минимальными правами доступа к серверу, и не используйте Административным учетные записи для регулярной работы на сервере. Для первичного аудита проблем сервера можете использовать журналы событий системы, чтобы выявить и устранить источник проблемы. Учетная запись с административными правами должна быть использована только для внесения изменений в конфигурацию сервера, таких как установка нового программного обеспечения, либо обновлений, ролей и других служебных функций.

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

Если вы используете для подключения к вашему серверу RDP(Remote Desktop Protocol) следует изменить стандартный порт подключения 3389 на нестандартный. Данное действие рекомендуется периодически повторять, так как злоумышленники время от времени сканируют все открытые порты потенциальной жертвы.

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