межсетевой экран windows server 2019
Как открыть порт брандмауэра Windows Server 2019
Одним из наиболее фундаментальных механизмов безопасности, которые предлагают нам текущие операционные системы, является внедрение и активация брандмауэра, хотя мы много раз слышали этот термин, но не всегда осознаем, какое влияние он оказывает на систему как на корпоративном, так и на личном уровне, Хотя некоторые компании действительно предлагают брандмауэрные решения на физическом уровне, являющемся мостом между внешней сетью и локальной сетью, сама операционная система, в данном случае речь идет о Windows Server 2019, имеет собственный встроенный брандмауэр, который при правильной конфигурации это даст нам возможность повысить уровни безопасности и, таким образом, гарантировать доступность и целостность всех элементов, размещенных на сервере, таких как роли, службы, общие папки и многое другое.
В брандмауэре Windows Server обычно бывает необходимо настроить определенные исключения, чтобы разрешить обмен приложениями с сервером, в этом случае эти исключения необходимо настроить в соответствии с требованиями приложения и разрешить доступ к ним. Контроль всех ваших возможностей.
Набор правил, которыми управляет межсетевой экран, дает возможность установки метода фильтрации на основе политик безопасности организации, обычно у нас есть два типа политик безопасности, благодаря которым можно будет выполнять действия как:
В администрировании брандмауэра порты играют жизненно важную роль, поскольку они обеспечивают связь между сервером и внешней сетью. Вот почему в этих портах проводится более 95% атак, поскольку они действуют как дверь, открывающаяся для злоумышленников. Вот почему брандмауэр блокирует или закрывает большинство портов, это очевидно из соображений безопасности, но возможно, что какое-то управляющее приложение запрашивает открытие определенного порта в брандмауэре, чтобы его доступ был авторизован. В этом случае как администраторы мы должны разрешить этому конкретному порту иметь надлежащую авторизацию в брандмауэре.
Вот почему Solvetic объяснит, как мы можем открыть и авторизовать порт в брандмауэре Windows Server 2019 и, таким образом, гарантировать, что приложения или службы, использующие этот порт, будут иметь необходимые разрешения.
Откройте порт брандмауэра с расширенными настройками брандмауэра в Windows Server 2019
Шаг 3
При выборе раздела «Входящие правила» будут отображаться все предварительно настроенные правила Windows Server 2019, связанные с входящими сетевыми подключениями и пакетами, некоторые из этих правил не включены по умолчанию, поэтому, если мы хотим активировать их, просто щелкните правой кнопкой мыши на правиле и выберите опцию «Включить правило»:
$config[ads_text5] not found
$config[ads_text6] not found
Шаг 6
При выборе этой опции будет отображаться следующий мастер, где мы определяем тип создаваемого правила, в этом случае мы выбираем поле «Порт»:
$config[ads_text5] not found
Шаг 7
В следующем окне мы определим тип порта для включения:
TCP (протокол управления передачей)
Это протокол, ориентированный на установление соединения, то есть с помощью TCP можно будет создавать соединения друг с другом для отправки потока данных. Этот протокол гарантирует, что данные доставляются получателю без ошибок и в том же порядке, в котором они были передается.
UDP (протокол дейтаграмм пользователя)
Это протокол, не ориентированный на установление соединения, его разработка основана на обмене дейтаграммами и облегчает отправку дейтаграмм через сеть, для которой необходимо предварительно установить соединение с пунктом назначения.
$config[ads_text6] not found
Шаг 8
Мы также можем установить флажок «Все локальные порты», чтобы включить все незащищенные порты TCP или UDP на сервере, или установить флажок «Определенные локальные порты», чтобы определить, какой порт должен быть авторизован на основе требованиям. Определив это, нажмите на кнопку Далее, и теперь мы определим действие, которое будет иметь это правило, варианты:
Эта опция обеспечивает полную связь через этот порт.
Разрешить соединение, если оно безопасно
Эта опция позволяет передавать данные только в том случае, если соединение аутентифицировано через Ipsec.
Эта опция предотвращает направление данных через этот порт.
$config[ads_text5] not found
Шаг 9
Выберите опцию «Разрешить подключение» и нажмите «Далее», теперь мы должны определить, какие профили брандмауэра применить, помните, что мы можем использовать их в публичных, доменных или приватных профилях:
Шаг 10
Мы можем активировать их всех, если захотим. Наконец, мы должны присвоить имя и, если пожелаем, описание нового правила, чтобы облегчить его использование:
Шаг 11
Нажмите кнопку «Готово», чтобы завершить процесс и создать новое правило в Windows Server 2019:
$config[ads_text6] not found
Шаг 12
Там мы можем дважды щелкнуть правило и во всплывающем окне перейти на вкладку «Дополнительные параметры» и проверить аспекты этого правила:
При желании мы можем внести изменения на уровне безопасности созданного нового правила. С помощью этого простого метода мы можем создавать и настраивать правила в брандмауэре Windows Server 2019 и повышать безопасность нашей сети.
Windows Server 2019
История Windows Server насчитывает уже более 25 лет: Windows NT 3.1 Advanced Server был выпущен 27 июля 1993 года. В октябре 2018 года, через три года после предыдущего большого релиза, был выпущен Windows Server 2019. Windows Server 2019 развивает и улучшает возможности, заложенные в предыдущих релизах. Подробности об этом — под катом!
Начиная с Windows Server 2016 был принят новый цикл выхода релизов. Сейчас есть два канала распространения: LTSC (Long-term servicing channel) – релиз, выходящий через 2-3 года, с 5-летней основной и 5-летней расширенной поддержкой, а также Semi-Annual Channel – релизы, которые выходят каждые полгода, имеют основной цикл поддержки в течение 6 месяцев и расширенную поддержку в течение 18 месяцев. Для чего необходимы эти два канала? Microsoft активно внедряет новшества в свою облачную платформу Azure. Это поддержка виртуальных машин Linux, контейнеры с Linux и Windows, и многие другие технологии.
Заказчики, использующие эти технологии в облаке, также хотят их использовать и в своих датацентрах. Semi-Annual Channel сокращает разрыв в возможностях между Azure и локальными датацентрами. Полугодовые релизы предназначены для динамичных в развитии компаний, которые перешли к гибкой сервисной модели предоставления ИТ-услуг бизнесу. Релизы LTSC предназначены для компаний, которые используют устоявшиеся приложения с длительным циклом поддержки, например, Exchange Server, SharePoint Server, SQL Server, а также инфраструктурные роли, программно-определяемые датацентры и гиперконвергентную инфраструктуру.
Windows Server 2019 – это именно релиз в канале LTSC. Он включает в себя все обновления функционала с Windows Server 2016 и последующих полугодовых релизов.
Основные усилия разработчиков Windows Server 2019 были направлены на четыре ключевые области:
Windows Admin Center
Windows Admin Center (WAC) – это новое средство администрирования серверов. Устанавливается локально в инфраструктуре и позволяет администрировать локальные и облачные экземпляры Windows Server, компьютеры Windows 10, кластеры и гиперконвергентную инфраструктуру.
WAC дополняет, а не заменяет существующие средства администрирования, такие как консоли mmc, Server Manager. Подключение к WAC осуществляется из браузера.
Для выполнения задач используются технологии удаленного управления WinRM, WMI и скрипты PowerShell.
Можно опубликовать WAC и администрировать серверы извне периметра организации. Службы многофакторной аутентификации и прокси приложений Azure AD помогут защитить такой доступ извне, а использование решения Microsoft Enterprise Mobility + Security (EMS) позволит предоставлять или отказывать в доступе в зависимости от соответствия устройства политикам, рискам, местоположению и другим факторам. Использование веб-приложения вместо доступа к удаленному рабочему для администрирования, по моему мнению, это правильная стратегия для обеспечения безопасности.
Системная аналитика
Windows Server 2019 стал интеллектуальнее. С помощью новой функции System Insights реализуется прогнозная аналитика, позволяющая перейти от реактивного к проактивному управлению парком серверов. Модель машинного обучения учитывает счетчики производительности и события для точного предсказания проблем со свободным местом на дисковой подсистеме, определение трендов для процессорных вычислений, сетевому взаимодействию и производительности хранилища.
Новинки в подсистеме хранения
Storage Migration Service
В Windows Server 2019 появилась новая технология для миграции данных со старых серверов на новые – Storage Migration Service.
Миграция происходит в несколько этапов:
Azure File Sync
Azure File Sync трансформирует традиционные файловые серверы и расширяет объём хранения до практически недостижимых в реальной жизни объёмов. Данные распределяются по нескольким уровням: горячий кэш – это данные, хранящиеся на дисках файлового сервера и доступные с максимальной скоростью для пользователей. По мере остывания данные незаметно перемещаются в Azure. Azure File Sync можно использовать совместно с любыми протоколами для доступа к файлам: SMB, NFS и FTPS.
Storage Replica
Эта технология защиты от катастроф впервые появилась в Windows Server 2016. В версии 2019 появилась ограниченная поддержка редакции Windows Server Standard. Сейчас и небольшие компании могут делать автоматическую копию (реплику) хранилища в виртуальные машины Azure, если в инфраструктуре компании нет второго удаленного датацентра.
Storage Spaces Direct
Локальные дисковые пространства – это необходимый компонент для построения гиперконвергентной инфраструктуры и масштабируемого файл-сервера. В Windows Server 2019 появилась встроенная поддержка энергонезависимой памяти, улучшенные алгоритмы дедупликации, в том числе на томах с файловой системой ReFS, масштабируемость до 4ПБ на кластер, улучшения в производительности.
Изменения в отказоустойчивой кластеризации
Появились наборы кластеров (Cluster sets), увеличивающие масштабируемость до сотен узлов.
Для обеспечения кворума в кластерах с четным количеством узлов используется специальный ресурс – диск-свидетель. Во времена Windows Server 2012 R2 для диска-свидетеля необходимо было выделять диск на хранилище, в Windows Server 2016 стало возможно использовать сетевую папку или облачный диск-свидетель. Улучшения в Windows Server 2019 связаны с сокращением требований к инфраструктуре для малых предприятий. В качестве диска-свидетеля может выступать USB-диск, подключенный, например, к роутеру.
Появилась миграция кластеров между доменами и другие улучшения в службе отказоустойчивой кластеризации.
Что нового в платформе приложений
Теперь можно запускать контейнеры на основе Windows и Linux на одном и том же узле контейнера с помощью одинаковой управляющей программы Docker. Это позволяет работать в разнородной среде узлов контейнеров и предоставить разработчикам гибкость в создании приложений.
Контейнеры получили улучшенную совместимость приложений, значительно был уменьшен размер образов Server Core и Nano Server, повысилась производительность.
Windows Server 2019 получил множество других улучшений. Подробнее ознакомиться с ними можно в разделе Windows Server на официальном сайте документации docs.microsoft.com.
Системные требования
Документация описывает минимальные требования к установке Windows Server 2019. Надо понимать, что в зависимости от ролей и компонентов, от запущенных приложений, требования к серверу могут быть повышены.
Windows Server 2019 не поддерживает ATA/PATA/IDE и EIDE для загрузки, файла подкачки или дисков с данными. Минимальный объём – 32 ГБ.
Сравнение выпусков Windows Server 2019 Standard и Datacenter
Windows Server 2019 поставляется в двух редакциях: Standard и Datacenter.
Редакция для датацентров обладает расширенными возможностями: поддержка гиперконвергентной инфраструктуры, локальных дисковых пространств, расширенными лицензионными правами при использовании виртуализации.
Приглашение на вебинар
Подробнее с возможностями Windows Server 2019, сценариях использования, вариантах лицензирования можно будет ознакомиться на вебинаре «Windows Server 2019 для современного датацентра».
Спикер — Дмитрий Узлов, сертифицированный эксперт по решениям Майкрософт с многолетним опытом.
Вебинар пройдет 6 декабря в 11.00, после вебинара вы сможете сделать практические работы по развертыванию виртуальной инфраструктуры Windows Server и настройке типовых сценариев гибридного датацентра. Успешно справившиеся с заданиями практической работы получат электронный сертификат о прохождении тренинга.
Запись вебинара можно посмотреть по ссылке.
Firewall: настройка межсетевого экрана сервера
Инструкция по настройке правил Firewall для виртуальных серверов в панели управления Serverspace.
Что это такое?
С помощью межсетевого экрана прямо из панели управления можно управлять доступом к серверу, сетевыми пакетами данных. Данная опция отдельно не тарифицируется и входит в стоимость сервера.
На данный момент существует ограничение в 50 правил, если вам будет недостаточно этого лимита, то увеличить его можно по запросу в техническую поддержку.
Сетевая архитектура
Для входящих пакетов первым будет применяться брандмауэр на уровне сети (при наличии). Если пакет прошел, дальше будет применяться фаерволл на уровне сервера, в последнюю очередь будет использоваться внутренний программный механизм. Для исходящих пакетов будет применена обратная последовательность действий.
Мы не рекомендуем одновременно использовать межсетевой экран на уровне сервера и внутренний программный:
Создание правила
Конфигурация брандмауэра доступна для всех VPS и находится в настройках сервера в разделе Firewall.
Для создания правила нажмите кнопку Добавить:
Перед вами откроется окно добавления правила. Необходимо заполнить следующие поля:
Для создания правила нажмите Сохранить.
В нашем примере правило блокирует все входящие на сервер пакеты:
Чтобы созданное правило вступило в силу необходимо сохранить изменения с помощью кнопки Сохранить. Вы можете создать несколько правил и затем сохранить все разом:
После этого страница будет выглядеть следующим образом:
Приоритет правил
Чем меньше порядковый номер правила (чем выше оно в списке), тем выше его приоритет. Например, после того как было создано запрещающее правило для всего входящего трафика, создадим правило разрешающее получать входящие пакеты по 80 порту протокола Tcp. После сохранения изменений при такой конфигурации данный порт все также будет недоступен, в связи с тем, что запрещающее правило имеет более высокий приоритет:
Для изменения приоритета правил перетащите с помощью левой кнопки мыши разрешающее правило на первое место и сохраните изменения:
После сохранение порядковые номера правил изменятся, а также изменится их приоритет:
Теперь конфигурация брандмауэра позволяет получать пакеты по протоколу Tcp по 80 порту, остальные пакеты проходить не будут.
Защищаем удаленный сервер на Windows как можем
Тема безопасности сервера Windows не раз поднималась, в том числе и в этом блоге. Тем не менее мне хотелось бы еще раз освежить в памяти старые методы защиты и рассказать о малоизвестных новых. Разумеется, будем использовать по максимуму встроенные средства.
Итак, предположим, что у нас есть небольшая компания, которая арендует терминальный сервер в удаленном дата-центре.
При проектировании любой защиты следует начинать с модели угроз — от кого или чего, собственно, будем защищаться. В нашей типовой конфигурации я буду строить оборону от внешних злобных хакеров, от некомпетентных (а может, и немного злонамеренных) пользователей. Начнем с внешнего периметра обороны — фаервола.
За тобой как за огненной стеной
Во времена Windows 2003 встроенный фаервол представлял собой жалкое зрелище, и в случае невозможности применения сторонних средств приходилось использовать IPSec. Пример такой настройки разобран, например, в материале Secure Windows Servers using IPSec Firewall.
Сейчас, с появлением WFP (Windows Filtering Platform) дела стали получше. В принципе, с этим фаерволом так или иначе сталкивался, наверное, каждый системный администратор Windows, поэтому настройка удаленного доступа к серверу только с определенных IP не должна вызывать затруднений. Я обращу внимание на некоторые «фишки», которые используются редко.
По умолчанию фаервол блокирует все входящие соединения, кроме явно разрешенных, но исходящие разрешает все, кроме явно запрещенных. Политику эту можно изменить, открыв управление фаерволом через wf.msc и выбрав «Свойства».
Теперь, если мы захотим запретить пользователям терминального сервера выходить с этого сервера в интернет — у нас это получится.
Стоит отметить, что при настройке правил доступа к серверу (входящие подключения) явно создавать правила для исходящего трафика не нужно. В терминах iptables — established и related всегда разрешены.
Для ценителей командной строки настройку фаервола можно производить в контексте netsh advfirewall. Почитать про команды можно в материале «Брандмауэр Windows 7 в режиме повышенной безопасности», я же добавлю, что блокировка входящих и исходящих подключений включается командой:
Еще одной особенностью фаервола windows является то, что любая программа или настройка меняет его правила без уведомлений. Например, отключили вы все правила на нашем дедике, рядом появился второй, вы сделали между ними локальную сеть, настроили общий доступ и… внезапно у вас включается smb для всех и вся со всеми вытекающими последствиями.
Выхода, по сути, два с половиной (напомню, мы пока говорим только про встроенные средства): регулярно проверять, не изменились ли правила, и использовать старый добрый IPSec или — как по мне, самый разумный вариант — настраивать фаервол групповой политикой. Настройка производится в Конфигурация компьютера — Конфигурация Windows — Параметры Безопасности — Монитор брандмауэра Защитника Windows в режиме повышенной безопасности.
Настройка фаервола групповой политикой.
Также при помощи фаервола windows можно реализовать простой fail2ban. Достаточно включить аудит неудачных попыток входа и при нескольких неудачах подряд блокировать IP источника. Можно использовать самописные скрипты, а можно уже готовые средства, о которых я писал в статье «Как дать шифровальщикам потопить компанию».
Если же встроенного фаервола не хватает и хочется использовать что-то более серьезное, то можно установить стороннее ПО. Жаль, что большинство известных решений для Windows Server — платные. Другим вариантом будет поставить перед сервером роутер. Понятно, что такая установка подойдет, если мы используем colocation, а не аренду сервера где-то далеко-далеко за рубежом. Если же зарубежный дата-центр — это наш выбор, то можно использовать виртуализацию — например, встроенный Hyper-V — и установить в виртуалку привычный GNU\Linux или FreeBSD.
Возникает вопрос: как сделать так, чтоб виртуалка имела прямой выход в интернет, а сервер — нет? Да еще чтобы MAC-адрес сервера не светился хостеру и не требовал тем самым покупки еще одного IP-адреса.
Осторожно! Дальнейшие действия лучше проводить через IP-KVM!
Для этого виртуальную машину нужно снабдить двумя сетевыми адаптерами. Один — для непосредственного подключения к интернету, для него мы сделаем виртуальный коммутатор типа «внешний» и снимем галочку, разрешающую операционной системе взаимодействие с этим коммутатором. Этой самой галочкой мы лишим сервер прямого доступа в интернет (настройку виртуальной машины-фаервола лучше произвести заранее), и его MAC не будет светиться хостеру.
Настройка внешнего виртуального коммутатора.
Другой виртуальный коммутатор следует сделать типа «внутренний» для взаимодействия виртуальной машины и сервера. На нем уже нужно настроить локальную адресацию. Так получится создать виртуальный роутер, стоящий перед сервером и защищающий его.
Заодно на этой виртуальной машине можно настроить любимый VPN до офиса или удаленных сотрудников, не заморачиваясь с ролью «Маршрутизация и удаленный доступ» или со встроенным IPSec, как я рассказывал в статье «Как я базы 1С в Германии прятал». Главное, не забыть проверить автозапуск этой виртуальной машины при старте системы.
Подключаться к такому серверу можно при помощи обычного RDP или использовать HTML5 клиенты с двухфакторной аутентификацией. Стоит на случай брутфорса озаботиться и решениями fail2ban, и блокировкой учетной записи на некоторое время при нескольких неудачных попытках авторизации подряд.
Снаружи сервер мы более-менее защитили, перейдем к защите внутренней.
Защита внутренняя: остановить и не пущать
Конечно, для защиты сервера изнутри очень хочется поставить какой-нибудь антивирус — мало ли что пользователи сервера накопируют или накачают из интернета. Но на практике антивирус на сервере может принести больше вреда, чем пользы. Поэтому я обычно использую механизмы блокировки запуска ПО не из белого списка — в частности, механизм SRP (software restriction policies), о котором я тоже упоминал в статье «Как дать шифровальщикам потопить компанию».
Остановлюсь чуть подробнее на одном подводном камне, о котором часто забываем при включении SRP со стандартными настройками, когда блокируется все, кроме папок Windows и Program Files. Действительно, это отфильтровывает почти всех зловредов. Но не очень работает со злонамеренностью сотрудников, ведь в системных папках есть подпапки с правом на создание объектов пользователями. Например, можно посмотреть на папку C:\Windows\Temp.
Разрешения на папку, которая попадет в белый список.
И такая папка не одна. Можно, конечно, проводить аудит системных папок самостоятельно, а можно довериться людям, которые это уже сделали. Например, специалист Stefan Kanthak в своем блоге (по ссылке есть тестовый вирус EICAR, антивирус может сработать) в довольно агрессивной манере проходится по антивирусам и методам защиты Windows и заодно предлагает уже собранный пакет настроек SRP, который будет блокировать и такие подозрительные папки. По запросу автор предоставляет и программу для конвертирования этих настроек реестра в файлы локальных политик.
Если вы предпочитаете использовать механизм AppLocker c более гибкими настройками, то вам может помочь решение AaronLocker.
Редакция не рекомендует использовать и устанавливать скрипты и прочие программы из интернета без предварительного их изучения.
Если AppLocker появился уже довольно давно, а возраст SRP перевалил за 15 лет, то относительно свежей альтернативой является WDAC (Windows Defender Application Control). Действительно, со времен Security Essentials встроенный «антивирус» обзавелся многими интересными возможностями. Например, WDAC — модуль, который отвечает за политики доступа к приложениям и библиотекам. Ранее он являлся частью Device Guard (защита компьютера, в том числе с применением технологий виртуализации), и немного про его настройку рассказывалось в материале «Принцип работы S Mode в Windows 10 и настройка Device Guard своими руками». Подробнее со всеми тонкостями можно ознакомиться в официальной документации, мне же остается добавить несколько минусов, отличающих его от классических решений вроде SRP и AppLocker:
Зато возможна настройка в срезе приложения: например, если вы хотите дать доступ к 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). Почитать подробнее можно в документации, ну а я добавлю, что для работы механизма достаточно включить его поддержку на сервере — например, через реестр командой:
А потом подключаться к серверу командой:
Теперь учетные данные в безопасности, а сервер достаточно защищен. Правда, в материале я осознанно не касался вопросов защиты от злонамеренного хостера, но тут все сводится в общем-то к одному — к шифрованию дисков.