Windows server 2016 защита от шифровальщиков — Ваш верный помощник с OS Windows

В этой статье мы разберем методику использования функционала File Server Resource Manager (FSRM) на файловом сервере Windows Server 2012 R2 для детектировании и блокировки работы вирусов-шифровальщиков (троянов-энкодеров, Ransomware или CryptoLocker). В частности, разберемся, как установить службу FSRM, настроить детектирование определенных типов файлов и, в случае детектирования таких файлов, заблокировать доступ пользователя к каталогу на файловом сервере.

Содержание:

Детектирование шифровальщиков с помощью FSRM
Настройка SMTP параметров FSRM для отправки email уведомлений
Создание группы расширений файлов, создаваемых шифровальщиками
Настройка File Screen Templates
Применение шаблона File Screen к диску или папке
Автоматическая блокировка доступа пользователя, зараженного шифровальщиком
Тестирование защиты FSRM

Детектирование шифровальщиков с помощью FSRM

Если компонент File Server Resource Manager еще не установлен на сервере, его можно установить с помощью графической консоли Server Manager или из командной строки PowerShell:

Install-WindowsFeature FS-Resource-Manager -IncludeManagementTools

Проверим, что роль установилась:

Get-WindowsFeature -Name FS-Resource-Manager

После установки компонента сервер нужно перезагрузить.

Настройка SMTP параметров FSRM для отправки email уведомлений

Следующий этап — конфигурация SMTP параметров службы FSRM, благодаря которым администратор может настроить отправку email уведомлений на свой ящик. Для этого запустите консоль fsrm.msc, щелкните ПКМ по корню консоли File Server Resource Manager и выберите пункт Configure Options.

Укажите адрес SMTP сервера, почтовый ящик администратора и имя отправителя.

Совет. Если у вас отсутствует внутренний почтовый сервер, можно настроить пересылку через SMTP релей на внешние ящики.

Проверить корректность настройки SMTP сервера можно, отправив тестовое письмо с помощью кнопки Send Test E-mail.

Настроить параметры SMTP службы FSRM также можно выполнить с помощью Powershell:

Set-FsrmSetting -AdminEmailAddress "[email protected]" –smtpserver smtp.adatum.com –FromEmailAddress "[email protected]"

Создание группы расширений файлов, создаваемых шифровальщиками

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

Этот список можно задать из консоли FSRM. Для этого разверните раздел File Screening Management -> File Groups и в меню выберите Create File Group.

Нужно указать имя группы (к примеру, Crypto-files) и внести все известные расширения в список с помощью поля Files to include.

Список известных расширений файлов, создаваемых шифровальщиками довольно большой, поэтому намного проще создать его с помощью PowerShell.

В Windows Server 2012 создать группу файлов с помощью PowerShell можно так:

New-FsrmFileGroup -Name "Crypto-files" –IncludePattern @("_Locky_recover_instructions.txt","DECRYPT_INSTRUCTIONS.TXT", "DECRYPT_INSTRUCTION.TXT", "HELP_DECRYPT.TXT", "HELP_DECRYPT.HTML", "DecryptAllFiles.txt", "enc_files.txt", "HowDecrypt.txt", "How_Decrypt.txt", "How_Decrypt.html", "HELP_RESTORE_FILES.txt", , "restore_files*.txt", "restore_files.txt", "RECOVERY_KEY.TXT", "how to decrypt aes files.lnk", "HELP_DECRYPT.PNG", "HELP_DECRYPT.lnk", "DecryptAllFiles*.txt", "Decrypt.exe", "AllFilesAreLocked*.bmp", "MESSAGE.txt","*.locky","*.ezz", "*.ecc", "*.exx", "*.7z.encrypted", "*.ctbl", "*.encrypted", "*.aaa", "*.xtbl", "*.abc", "*.JUST", "*.EnCiPhErEd", "*.cryptolocker","*.micro","*.vvv")

В Windows Server 2008 R2 придется воспользоваться утилитой filescrn.exe:

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

_https://www.bleib-virenfrei.de/ransomware/

_https://fsrm.experiant.ca/api/v1/combined

Во втором случае актуальный список расширений файлов для FSRM можно грузить прямо с веб сервера с помощью Invoke-WebRequest

new-FsrmFileGroup -name "Anti-Ransomware File Groups" -IncludePattern @((Invoke-WebRequest -Uri "_https://fsrm.experiant.ca/api/v1/combined").content | convertfrom-json | % {$_.filters})

Либо воспользоваться готовым файлом: crypto_extensions.txt. Данный файл можно сохранить на диск и обновить с его помощью созданную группу файлов FSRM:

$ext_list = Get-Content .\crypto_extensions.txt Set-FsrmFileGroup -Name "Crypto-files" -IncludePattern ($ext_list)

Настройка File Screen Templates

Создадим новый шаблон File Screen Template, в котором определяются действия, которые FSRM должен выполнить при обнаружении указанных файлов. Для этого в консоли FSRM перейдите в раздел File Screen Management -> File Screen Templates. Создадим новый шаблон Create File Screen Template.

На вкладке настроек укажем имя шаблона “Block_crypto_files”, тип скрининга – Active screening (запрещается создавать указанные типы файлов) и в списке групп файлов выбрать Crypto-Files.

fsrm шаблон блокировки файлов шифровальщиков

На вкладке E-mail Message включим отправку почтовых уведомлений, настроив текст оповещения по-своему вкусу.

На вкладке Event Log включим запись события в системный журнал. С указанием записывать только имя пользователя: [Source Io Owner]

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

Сохраните изменения. В списке шаблонов должен появится еще один.

Применение шаблона File Screen к диску или папке

Осталось назначить созданный шаблон к диску или сетевой папке на сервере. В консоли FSRM создадим новое правило Create File Screen.

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

Назначение политики FSRM к сетевому каталогу

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

Осталось настроить действие, которое FSRM будет выполнять при обнаружении файлов, созданных шифровальщиками. Мы воспользуемся готовым скриптом: Protect your File Server against Ransomware by using FSRM and Powershell (https://gallery.technet.microsoft.com/scriptcenter/Protect-your-File-Server-f3722fce). Что делает этот скрипт? При попытке записать «запрещенный» тип файла в сетевой каталог, FSRM запускает данный скрипт, который анализирует журнал событий и на уровне шары запрещает запись пользователю, из-под осуществлялась попытка записать запрещенный тип файла. Таким образом, мы заблокируем доступ зараженного пользователя к сетевой папке.

Скачайте указанный скрипт и распакуйте его в корень каталога C:\ на файловом сервере. В эту же папку скопируйте утилиту SubInACL (нужна для изменения разрешений на сетевой каталог). В каталоге должны оказаться следующие файлы:

RansomwareBlockSmb.ps1
StartRansomwareBlockSmb.cmd
subinacl.exe

Примечание. В PS скрипте пришлось изменить строки:

$SubinaclCmd = "C:\subinacl /verbose=1 /share \\127.0.0.1\" + "$SharePart" + " /deny=" + "$BadUser"

if ($Rule -match "Crypto-Files")

Осталось в настройках шаблона “Block crypto files” на вкладке Command указать, что должна запуститься командная строка с аргументом StartRansomwareBlockSmb.cmd:

Run this command or script:
c:\windows\system32\cmd.exe

Command arguments:
/c “c:\StartRansomwareBlockSmb.cmd”

Команда должна выполняться с правами локальной системы (Local System).

Тестирование защиты FSRM

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

При попытке сохранить запрещенный файл FSRM запишет в журнал событие:

Event ID: 8215 Source: SRMSVC

Скрипт RansomwareBlockSmb.ps1на основании данных из события запретит текущему пользователю доступ к данному каталогу, выставив в разрешениях на шару персональный deny:

Запрет на доступ к сетевому каталогу зараженному пользователю

Защита работает! В корне диска в логе можно посмотреть каталог и пользователя, из-под которого пытался запустится шифровальщик.

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

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

Как восстановить файлы пользователя из снимков VSS после заражения шифровальщиком
Блокировка вирусов и шифровальщиков с помощью Software Restriction Policies

Источник

Ранее мы рассказывали, как настроить сервер терминалов, а сегодня поговорим о его защите. Далее будут рассмотрены пять мер, позволяющих существенно повысить безопасность 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 завершена. Отключитесь от сервера и установите новое соединение. Не забудьте в настройках RDP-клиента Windows Server 2016 указать новый порт: IP-адрес_сервера: порт.

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

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

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

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

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

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

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

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

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

Служба «Шлюз TS (служб удаленных рабочих столов)» Windows Server 2016 разрешает сторонним пользователям реализовывать удаленное подключение к терминальным серверам и другим машинам частной сети с активированным протоколом удаленного рабочего стола. Служба обеспечивает RDP безопасность подключений за счет использования протокола HTTPS/SSL, что позволяет не заниматься настройкой VPN для шифрования трафика.

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

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

Откройте Диспетчер серверов и на главной его странице нажмите ссылку Добавить роли и компоненты
Нажмите Далее, а затем выберите Установка ролей или компонентов.
Выберите ваш сервер из пула серверов
Выберите Службы удаленных рабочих столов и нажмите Далее несколько раз, пока не достигнете страницы Выбор служб ролей
Выберите службы ролей Шлюз удаленных рабочих столов (рис. 7)
Нажмите кнопку Добавить компоненты
Нажимайте Далее для завершения процедуры установки. Когда все будет готово для установки выбранных компонентов, нажмите кнопку Установить (рис. 8).

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

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

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

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

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

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

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

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

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

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

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

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

Опцию RDP через TLS можно активировать через набор правил и настроек защиты сервера удаленных рабочих столов. Введите команду gpedit.msc и перейдите в раздел Конфигурация компьютера, Административные шаблоны, Компоненты Windows, Службы удаленных рабочих столов, Узел сеансов удаленных рабочих столов, Безопасность. Откройте политику Требовать использования специального уровня безопасности для удаленных подключений по протоколу RDP. Выберите значение Включено и выберите уровень безопасности SSL (рис. 14).

Рис. 14. Включение RDP через TLS

На этом настройка безопасности RDP Windows server 2016 закончена. Рекомендуем также прочитать статью «Обеспечение безопасности виртуального Windows-сервера». Если у вас что-то не получается, специалисты службы поддержки xelent.ru помогут вам с настройкой.

Источник

Автор

Tarnum

Возможно, кто-нибудь сталкивался с подобной проблемой? Начал ставить триальную версию KSOS 21.3 на Microsoft Windows Server 2016, официальный установщик обнаружил на сервере несовместимое ПО (Defender — т.е. защитник Windows) и начал его удалять, после чего предложил перезагрузить сервер (сам KSOS при этом даже ещё не начал устанавливаться!). После перезагрузки сервер больше не загружается, выпадает в BSOD (Critical Porocess Died), пробовал безопасный режим — тот же BSOD. Пускает только в командную строку консоли восстановления, но образа системы нет, восстанавливать неоткуда и всё это случилось, что называется, «на ровном месте».

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

Источник

“Static Key Ciphers” are used on Windows Server 2016/2019 for backward compatibility with legacy applications. It existing on Windows operating system by default. Hackers can decrypt the traffic if the weak cipher suites are being used. Hence how to secure the traffic is important for Windows security.

In short, certain communication security protocols and cipher suites should be disabled on Windows Server 2016/2019.

What’s Cipher?

Cipher is the algorithm of translation between plaintext and ciphertext. There are two algorithm categories: The symmetric key algorithm and the asymmetric key algorithm. Symmetric key algorithms use one key for encryption and decryption. Asymmetric key algorithms use different keys for encryption and decryption.

The popular ciphers are DES, AES, RSA, SHA…etc. However, some of them are out-of-date. And some maybe not in compliance with certain information security standards.

What’s the Cipher Suite?

A cipher suite is a set of ciphers and security protocols. A server encrypts data with a cipher suite. And a client decrypts data with the same cipher suite.

Naming Convention of Ciphers

Different Windows Server versions support different cipher suites. Following is the default cipher suite list for TLS protocol on Windows Server 2016/2019. As you can see, Windows Server 2019 supports few advanced cipher suites in addition.

Cipher Suites have an order on Windows. It always picks up the best cipher suite. “The best” means it must match two criteria:

At least one cipher suite in the order must be supported by the application.
The chosen cipher suite is the top one in the supported list.

If Windows cannot find a suitable cipher suite, then the communication is failed. As a result, you will see error messages in Windows Event Log (Similar to the event log samples below).

Windows Server 2016	Windows Server 2019
N/A	TLS_AES_128_GCM_SHA256
N/A	TLS_AES_256_GCM_SHA384
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA	N/A
TLS_DHE_DSS_WITH_AES_128_CBC_SHA	N/A
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256	N/A
TLS_DHE_DSS_WITH_AES_256_CBC_SHA	N/A
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256	N/A
TLS_DHE_RSA_WITH_AES_128_CBC_SHA	N/A
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256*	TLS_DHE_RSA_WITH_AES_128_GCM_SHA256*
TLS_DHE_RSA_WITH_AES_256_CBC_SHA	N/A
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384*	TLS_DHE_RSA_WITH_AES_256_GCM_SHA384*
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA	TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256	TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256*	TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256*
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA	TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384	TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384*	TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384*
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA	TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256	TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256*	TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256*
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA	TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384	TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384*	TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384*
TLS_PSK_WITH_AES_128_CBC_SHA256	TLS_PSK_WITH_AES_128_CBC_SHA256
TLS_PSK_WITH_AES_128_GCM_SHA256	TLS_PSK_WITH_AES_128_GCM_SHA256
TLS_PSK_WITH_AES_256_CBC_SHA384	TLS_PSK_WITH_AES_256_CBC_SHA384
TLS_PSK_WITH_AES_256_GCM_SHA384	TLS_PSK_WITH_AES_256_GCM_SHA384
TLS_PSK_WITH_NULL_SHA256	TLS_PSK_WITH_NULL_SHA256
TLS_PSK_WITH_NULL_SHA384	TLS_PSK_WITH_NULL_SHA384
TLS_RSA_WITH_3DES_EDE_CBC_SHA	TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA	TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256	TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_GCM_SHA256	TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA	TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA256	TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384	TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_NULL_SHA	TLS_RSA_WITH_NULL_SHA
TLS_RSA_WITH_NULL_SHA256	TLS_RSA_WITH_NULL_SHA256
TLS_RSA_WITH_RC4_128_MD5	N/A
TLS_RSA_WITH_RC4_128_SHA	N/A

Which Should Be Disabled?

Firstly we need to look into the communication security protocols. SSL 1.0, SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1 and TLS 1.2 are popular protocols. They are enabled on Windows Server 2016/2019 by default. However, most of them are out-of-date due to certain vulnerabilities. For example, SSL 3.0 is killed by the POODLE attack. So the suggested protocol is TLS 1.2.

The protocols are controlled by registry keys. The registry location is HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols.

There are two keys for each protocol: Client and Server. The Microsoft KB only introduced how to disable PCT 1.0 for Server. You need to do the same for the Client. The KB was written for the earlier Windows version. But it also applicable for Windows Server 2016/2019

Secondly, dealing with cipher suites. There are a lot of articles on the internet to talk about cipher suites. But no straight answer on what should be disabled and how. I think the easiest way is to compare your current cipher configuration with the blacklist of RFC 7540.

I compared Windows Server cipher suites with it. All cipher suites in the table above are on the blacklist except the green text. In other words, the green text cipher suites are safe for TLS 1.2.

If you follow the blacklist. As a result, there will be only 6 cipher suites for Windows Server 2016 and 8 for Windows Server 2019. Most importantly. It may cause a lot of problems since the cipher suites may not be supported by the majority of 3rd party applications.

So, to balance security and compatibility. I think it may be reasonable to disable the out-of-date cipher suites only. After research. I think the cipher suites with red text in the table can be disabled on Windows Server 2016/2019.

You can get the current cipher suite configuration list with PowerShell:

(Get-TlsCipherSuite).Name

What’re the Impacts to Disable Cipher?

Because the cipher suite must be supported by application and Windows both. Therefore, there are two impacts to disable cipher suites on Windows Server 2016/2019. Firstly, it’s the internal impact. It means the native application may throw out errors if it doesn’t support TLS 1.2. For example, you may see the following error in Windows Event Logs after disabled SSL 1.0, SSL 2.0, SSL 3.0, TLS 1.0, and TLS 1.1 on a new provisioned Windows Server 2016/2019. The reason is TLS support for the .Net framework is not enabled.

Log Name: System
Source: Schannel
Date: 10/11/2020 1:1:1 PM
Event ID: 36871
Task Category: None
Level: Error
Keywords:
User: SYSTEM
Computer: test.zhengwu.org
Description:
A fatal error occurred while creating a TLS client credential. The internal error state is 10013.

Secondly, It may impact communication with external services. For example, the 3rd party software only supports the disabled cipher suites. You may see following log in Windows Event Log:

Log Name: System
Source: Schannel
Date: 10/11/2020 11:11:01 PM
Event ID: 36874
Task Category: None
Level: Error
Keywords:
User: SYSTEM
Computer: test.zhengwu.org
Description:
An TLS 1.2 connection request was received from a remote client application, but none of the cipher suites supported by the client application are supported by the server. The TLS connection request has failed.

How to Disable Cipher Suites?

There are several ways to control cipher suites. GPO is the recommended way. Or you can edit registry keys. But it’s inflexible. For example, It takes time to change the registry to disable a single cipher suite.

Microsoft introduced the PowerShell TLS module since Windows Server 2016. It supports to control a single cipher suite. I think it’s a better way compared with other ways. Because you can re-enable a cipher suite easily if the application doesn’t work.

Following is the command to disable cipher suite.

Disable-TlsCipherSuite -Name <xxx>

References

TLS/SSL Server Supports The Use of Static Key Ciphers
PowerShell TLS Module on Windows Server 2016
TLS 1.2 Cipher Suite Black List
How to deploy custom cipher suite ordering in Windows Server 2016

Источник

В этой статье автор хотел бы дать пару хороших советов по администрированию серверов на Windows, которые по какой-то причине не нашел в интернете.

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

1. Правильно вводим компьютер в AD

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

1.1. Создаем нового пользователя

Для этого нужно перейти в ADUC (Active directory users and Computers). Нажать на пустое место в папке Users and Computers и создать пользователя. Для простоты назовем его JoinAdmin.

1.2. Делегируем полномочия

После того, как пользователь был создан, ему нужно назначить полномочия. Для этого нужно нажать ПКМ по папке «Users» и выбрать «Delegate Control». Жмём «Далее» и выбираем нашего админа.

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

Далее выбираем «Computer objects» и все его подпункты.

Используйте этого юзера и не беспокойтесь о том, что кто-то мог украсть пароль от администратора.

2. Controlled folder access

В Windows Server 2019 появилась очень недооцененная возможность — controlled folder access. Она запрещает доступ к записи программам, которых нет в белом списке на выбранных папках или разделах.

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

Включить функцию можно в центре безопасности Windows или через Powershell:

Set-MpPreference -EnableNetworkProtection Enabled

Добавляем разрешенные программы:

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

Set-MpPreference -ControlledFolderAccessAllowedApplications "C:\Folder\File.exe"

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

$ApplicationToAdd = "C:\Fodler\file.exe"
 
$ExistingApplicationList = (Get-MpPreference).ControlledFolderAccessAllowedApplications
 
$FullList = $ApplicationToAdd + $ExistingApplicationList 
 
Set-MpPreference -ControlledFolderAccessAllowedApplications $FullList

Добавляем защищенные папки:

Папки добавляются ровно так же, как и программы. К примеру этой командой мы добавляем диск C: целиком:

Set-MpPreference -ControlledFolderAccessProtectedFolders "C:\"

3. SYSWOW64 и SMB

Все 32 битные программы работают на 64 битных через слой совместимости — SYSWOW64. Отключение этого компонента делает несовместимым все 32 битное ПО, в том числе и вирусы.

Сами по себе 32 битные приложения более уязвимые, 64-битные программы не поддаются атаке на переполнение буфера и через них гораздо труднее исполнить код который этими программами не предусмотрен. Если на сервере работают только встроенные компоненты или только 64 битные программы, обязательно удалите этот компонент.

А помните Wannacry, который гулял через SMB1? SMB первой версии до сих пор является стандартным компонентом Windows Server и установлен по умолчанию в каждой редакции.
Wannacry проникал через уязвимость EternalBlue, уязвимость пропатчили, но осадочек остался.
Эта команда удалить и SMB1 и SYSWOW64:

Remove-WindowsFeature WoW64-Support, FS-SMB1

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

4. Отключите ping

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

Для того, чтобы показать что вы выиграете, если отключите ICMP, было создано два сервера. На обоих из них был открыт RDP, однако один из серверов не отвечал на ICMP.

ICMP отключен:

ICMP включен:

Как можно видеть из скриншота, это остановило не всех, но многих. Собрать данные о том, насколько сильно хотят взломать вас, можно этим скриптом:

function Get-Bruteforce {
 
    $Last = 4
    $Attempts = 10
 
    #Getting date -one hour (default)
    $DateTime = [DateTime]::Now.AddHours(-$Last)
 
    $BruteEvents = Get-EventLog -LogName 'Security' -InstanceId 4625 -After $DateTime -ErrorAction SilentlyContinue | Select-Object @{n='IpAddress';e={$_.ReplacementStrings[-2]} }
    $TopPunks = $BruteEvents | Group-Object -property IpAddress | Sort-Object Count
 
    #Get bruteforsers that tried to login greated or equal than 4 times (default)
    $GetPunks = $TopPunks | where {$_.Count -ge $attempts} | Select -property Name
 
    Write-host Unique attackers IP: $GetPunks.Length -ForegroundColor Green
    Write-Host Total bruteforce attempts: $BruteEvents.Length -ForegroundColor Green
 
    #Output-punks
    foreach ($i in $TopPunks | where {$_.Count -ge $attempts}) {
 
    $PunkRdns = (Resolve-DnsName $i.Name -ErrorVariable ProcessError -ErrorAction SilentlyContinue).NameHost 
 
    if ($ShowRDNS) {
        if ($PunkRdns) {
            Write-Host "attempts": $i.count IP: $PunkRdns
        }
        else {
            Write-Host "attempts": $i.count IP: $i.name
        }
    }
    else {
 
        Write-Host "attempts": $i.count IP: $i.name
 
    }
 
    }
   
}
Get-Bruteforce

Вы все еще сможете мониторить ваш сервер, к примеру, проверяя доступность определенного порта:

Test-NetConnection 192.168.0.1 -Port 3389

5. Не все имена одинаково хороши

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

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

Для вашего удобства, список «плохих» имен был переписан в таблицу:

Получить такой же список на вашем сервере можно этим скриптом:

function Get-Badname {
 
    $Last = 24
    $Attempts = 40
 
   
    $DateTime = [DateTime]::Now.AddHours(-$Last)
 
    $BruteEvents = Get-EventLog -LogName 'Security' -InstanceId 4625 -After $DateTime -ErrorAction SilentlyContinue | Select-Object @{n='IpAddress';e={$_.ReplacementStrings[5]} }
    $TopPunks = $BruteEvents | Group-Object -property IpAddress | Sort-Object Count
 
   
    $GetPunks = $TopPunks | where {$_.Count -ge $attempts} | Select -property Name
 
    Write-host Unique attackers IP: $GetPunks.Length -ForegroundColor Green
    Write-Host Total bruteforce attempts: $BruteEvents.Length -ForegroundColor Green
 
    #Output
    foreach ($i in $TopPunks | where {$_.Count -ge $attempts}) {
 
        Write-Host "Attempts": $i.count Username: $i.name
 
    }
   
}
Get-Badname

6. Очевидные вещи

Ну а закончим мы статью очевидными вещами:

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

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

Предлагаем обновлённый тариф UltraLite Windows VDS за 99 рублей с установленной Windows Server 2019 Core.

Источник