Чек-лист защиты Windows Server, смотрящего в интернет

Как пользоваться этим списком

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

Этот — упорядочен. Первые разделы убирают те способы, которыми серверы действительно захватывают. Последний стоит сделать, но сам по себе он вас не спасёт. Если у вас есть только вечер — сделайте разделы 2 и 3 и остановитесь.

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

1. Учётные записи и аутентификация

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

• Отключите или переименуйте встроенную запись Administrator. Это первое имя из любого атакующего списка, а её общеизвестный SID означает, что переименование само по себе не защита — лучше отключить, заведя отдельного именованного администратора.
• Требуйте многофакторную аутентификацию для каждой учётной записи с удалённым входом. Это самая ценная мера в списке: угаданный пароль без второго фактора ничего не стоит.
• Требуйте длинные пароли — минимум в 15 символов сопротивляется офлайн-перебору куда лучше, чем правила сложности на коротком, — и запрещайте пароли из известных утечек, если инструменты позволяют.
• Проведите ревизию тех, у кого реально есть удалённый доступ. Уберите записи ушедших сотрудников, подрядчиков с завершёнными работами и служб, которых больше нет. Каждая забытая учётка — поверхность атаки, за которой никто не следит.
• Дайте служебным записям собственные идентичности, без прав интерактивного входа и с паролями, которые нигде больше не используются.
• К политике блокировки относитесь осторожно. На хосте, смотрящем в интернет, она позволяет кому угодно отключать ваши учётные записи по желанию; если используете — держите порог умеренным и никогда не полагайтесь на неё как на защиту от подбора.

2. Сетевая доступность

Второй вопрос после «кто может войти» — это «откуда». Каждый порт, доступный из интернета, — это служба, которую прямо сейчас кто-то проверяет.

• Составьте опись того, что реально слушает, — снаружи. Get-NetTCPConnection -State Listen на хосте, затем проверка с другой сети, что из этого отвечает.
• Закройте SMB (445) на периметре. Он практически никогда не должен смотреть в интернет, и это частая вторая находка на серверах, где собирались открыть только RDP.
• То же самое для WinRM (5985/5986), MS SQL (1433) и любых интерфейсов управления. Если службе не нужно быть доступной извне, это и есть всё исправление.
• Для самого RDP ограничьте адреса источников, если можете. Если не можете — читайте дальше, раздел 3 и есть компенсирующая мера.
• Включите Network Level Authentication, чтобы неаутентифицированный клиент никогда не получал созданную для него сессию.
• Проверьте не только фаервол Windows, но и облачную security group. Два слоя — это два места, где можно ошибиться, а разрешающая всё группа перед аккуратным хостовым фаерволом — частое несоответствие.

3. Автоматическая блокировка неудачных входов

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

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

Нужен эквивалент fail2ban: следить за потоком отказов и, когда источник перешёл порог, отбрасывать его на фаерволе. Рабочую реализацию от протекающей отличают три свойства — банить подсеть, а не отдельный адрес; делать баны постоянными и переживающими перезагрузку; внести собственный доступ в белый список раньше, чем включено что-либо ещё.

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

4. Обновления и поверхность атаки

Учётные данные — обычный способ войти; непропатченные службы — запоминающийся.

• Включите автоматические обновления или ведите цикл патчинга, которого вы действительно придерживаетесь. У RDP уже были уязвимости с удалённым выполнением кода до аутентификации, и будут ещё.
• Удалите роли и компоненты, которыми не пользуетесь. Установка IIS, о включении которой никто не помнит, — это служба, которую найдёт кто-то другой.
• Деинсталлируйте софт, приехавший с образом и не нужный. Каждый агент, тулбар и вендорский апдейтер — это код, работающий с привилегиями на вашем хосте.
• Держите актуальным тот агентский софт, который вы всё-таки используете, включая мониторинг и резервное копирование.
• Отключите легаси-протоколы — SMBv1, TLS 1.0 и 1.1, NTLMv1, — если что-то действительно их не требует; а если требует, запишите что именно и вернитесь к этому позже.

5. Журналирование и обнаружение

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

• Убедитесь, что аудит входов фиксирует отказы, а не только успехи: auditpol /get /subcategory:"Logon" должен показывать оба.
• Увеличьте максимальный размер журнала безопасности. Значение по умолчанию заполняется за часы на открытом хосте, и нужные события устаревают раньше, чем вы посмотрите.
• Пересылайте события за пределы хоста. Локальный журнал скомпрометированной машины — это улики, которые атакующий может отредактировать; копия в другом месте — те, которые не может.
• Настраивайте оповещения на значимое, а не на объём: успешный вход из новой страны, новый локальный администратор, установленная служба, очистка журнала аудита (событие 1102).
• Периодически и осознанно просматривайте, кто входил успешно. Неудачные входы — шум; успешный вход, который вы не можете объяснить, — это уже вся игра.

6. Резервные копии, которые вы восстанавливали

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

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

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