Глава 9. Упрочнение и безопасность

Термин Microsoft Defender применяется уже много лет, но его терминология и возможности неоднократно менялись при появлении новых выпусков ОС. Defender присутствовал ещё в 2005 году, в то время обеспечивая очень простую защиту от вредоносных программ. Эпоха Windows 8 принесло весьма ошеломительные изменения для пользователей Windows, в том числе Windows Defender в самой ОС, бесплатный и готовый к использованию. Хотя на бумаге это и звучит великолепно, ИТ содружество не воспринимало слишком серьёзно возможности Defender. Однако, давайте быстро перенесёмся в наши дни и в то, что сейчас именуется как Microsoft Defender Antivirus, представляет собой значительно улучшенную защиту от вредоносных программ/ антивирусов, которая работает в миллионах компьютеров клиентов с Windows 10 и 11, а также, как вы уже догадались, в текущих версиях Windows Server. Антивирус Defender присутствует в ОС и включён по умолчанию, в результате чего его уровень интеграции и быстродействия трудно сопоставим со сторонними поставщиками. Я не могу сказать вам в точности сколько раз я наблюдал утечку памяти и случайные перезапуски серверов по причине плохо работающего стороннего программного обеспечения, что недопустимо в современном мире серверов. Некоторые до сих пор полагают слабыми предоставляемые Defender антивирусные возможности, скорее всего, только потому, что он бесплатный, но он, несомненно, обладает рядом преимуществ перед сторонним антивирусом. Я пока не видел, чтобы продукт Windows Defender побеждал за явным преимуществом в клиенте или сервере.

Вероятно, вы также видели или слышали упоминание об ATP (Advanced Threat Protection, расширенной защите от угроз) Windows Defender, который теперь переименован в Microsoft Defender ATP. Это семейство продуктов и систем, которые совместно защищают ваши компьютеры с Windows. Антивирус/ противодействие вредоносному Программному обеспечению (ПО) это лишь одна из таких возможностей, а встроенный антивирус это относительно новая идея, когда мы говорим об ОС семейства Windows Server.

Первой серверной ОС, которую мы обнаружили со встроенным Defender была Server 2016. Многие работающие в промышленном применении компаний серверы по всему миру всё ещё являются Server 2012 R2 (я знаю это, потому как работаю с ними ежедневно), а раз так, улучшенный набор средств Defender в Server 2022 это ещё одна из причин начала планирования миграции сегодня.

У нас просто не хватает места на странице чтобы окунуться во все стороны ATP в Windows Defender, а он постоянно совершенствуется. На самом деле, пока я набираю эти строки, начинается ещё одна революция, когда стали появляться справочные материалы и статьи о Microsoft Defender для облачного решения. Что мы выполним, так это изучим некоторые интерфейсы, убедимся что вам известно как применять наиболее распространённые компоненты, которые не требуют манипуляций на уровне политик или централизованного администрирования и расширив ваши знания о некоторых более современных функциональных возможностях, доступных для дальнейшего изучения и копания в них.

Вы её уже выполнили! Windows Defender устанавливается по умолчанию в Windows Server 2022. На самом деле, пока вы не предпримите чего- нибудь чтобы изменить это, AV Defender не только установлен, но он также автоматически защищает вашу систему сразу после установки своей ОС. Но если вы не принимайте мои слова на веру, когда вы откроете Server Manager и выберите Add roles and features, кликните затем по странице Select features и вы должны обнаружить помеченным флажок, идущий вслед за Microsoft Defender Antivirus:

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

Сам интерфейс для инструментария Microsoft Defender в точности тот же, что и внутри самых последних версий Windows 10, но если вы его пока не изучали, мы его здесь быстренько рассмотрим. Пройдите вперёд и запустите Settings изнутри меню Start, затем кликните по Update & Security.

Попав вовнутрь этого раздела, вы обнаружите слева перечисленными Windows Security. Здесь вы получаете служебный просмотр различных работающих сообща над защитой вашей системы компонентов Defender.

Помните, что вы не включали никакие из этих возможностей; все они доступны сразу после установки.

Кликнув далее по одной из этих Protection areas вы перенесётесь к более подробному описанию подробностей каждой из возможностей, а также ко множеству параметров которые включают и запрещают различные существующие определённые защиты. К примеру, если вы кликнули по Virus & threat protection, вы увидите итоговую информацию относительно AV Defender, когда обновлялись его файлы определений, что отсканировано и и так далее. Затем кликните далее по ссылке с названием Manage settings вы получите свои параметры для отключения AV Defender если это вам потребуется, а также целый ряд прочих параметров которые вы можете выбирать или отключать. Рисунок 9.3отображает всего лишь для небольшое число доступных внутри AV Defender настроек. Я выбрал для отображения именно эти три, так как они важны для прочих тем, которые мы вскорости рассмотрим, когда будем обсуждать свою порцию ATP Defender:

Вы уже знаете, что AV Defender включён по умолчанию как и многие прочие компоненты, которые составляют обсуждаемое семейство продуктов Microsoft Defender. Перекинув в другое положение показанную на Рисунке 9.3 кнопку Real-time protection, у вас имеется возможность временного отключения AV. Продвинемся ещё на один шаг вперёд если вы абсолютно уверены что вы не желаете применять AV Defender, поскольку у вас имеется собственное программное обеспечение AV, за которое вы уже заплатили, у вас есть две проторённые дороги которыми вы можете пойти.

Во- первых, AV Defender разработан с автоматическим шагом вниз в том случае когда установлен иной AV. Скорее всего, всё что вам требуется, это установить ваши антивирусный инструмент стороннего разработчика, а после того как ваш сервер завершит перезагрузку, AV Defender вернётся на место и позволит работу продукта стороннего разработчика с тем чтобы они не конфликтовали друг с другом. Это важно, так как это факт, что подавляющее большинство компьютерных специалистов не допускают исполнение множества программ AV в отдельной системе, так как в целом это ужасная идея. Зачастую это приводит к их конфликтам друг с другом, имеет ошибки выделения памяти, а также вызывает прочее странное и замедляющее поведение в вашей системе.

По умолчанию, Microsoft Defender работает в том, что носит название Active mode, что имеет гигантское значение. Когда вы пользуетесь дополнительной возможностью в своём семействе с названием Microsoft Defender for Endpoint, при установленном стороннем AV продукте Defender меняет механизмы и входит в Passive mode. В подобной ситуации AV Defender не является первичным антивирусом. Он всё ещё сканирует некоторые файлы и выявляет угрозы когда он наблюдает их, однако Defender не предпринимает действий для исправления потенциальных угроз.

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

Uninstall-WindowsFeature -Name Windows-Defender
		

Достаточно сложно в точности определить что означает ATP (Advanced Threat Protection), так как он является вершиной всех тех частей, фрагментов и механизмов безопасности Microsoft Defender, которые работают совместно чтобы защищать клиентов и серверы от плохого наполнения: AV, возможности межсетевого экрана, аппаратная защита, а также даже особая устойчивость к требующему выкупа кода.

Такое сочетание совместных возможностей внутри раздела Безопасности Windows (Windows Security) в Windows 10 и Server 2022 работает воедино и превращается в ATP.

Нечто, что должно быть особенно интригующим для всех нас, так это тот интеллектуальный способ, которым Microsoft теперь применяет связь с облаком и вычисления чтобы улучшать AV Defender на повседневной основе. Осознаём ли мы это или нет, большинство подключаемых в мире в Интернет машин Windows сейчас помогают друг другу сообщать о вновь возникающих уязвимостях и вредоносных активностях обратно в Microsoft. Эта информация впоследствии подвергается разбору и машинному обучению, а получаемая в результате информация получает возможность немедленно применяться всеми остальными машинами Windows по всему миру.

Хотя это слегка и созвучно с Большим Братом и наполнено подлежащим рассмотрению частной жизни, я верю, что мы в целом, как сообщество, вскоре избавимся от этой боязни и осознаем те преимущества, которые перевешивают наши опасения. В наши дни миллионы пользователей пропускают свою электронную почту через Office 365; вы можете даже не осознавать это, но Office 365 также выполняет и такой вид обработки чтобы выявлять и блокировать подобную эксплуатацию. К примеру, если некий адрес электронной почты внутри какой- то компании непрерывно отправляет электронную почту большим группам людей, а это электронное сообщение содержит некий документ Word с включёнными макросами, что является чем- то тем, что обычно этот пользователь не выполняет, Office 365 скорее всего перенесёт данный документ в некую зону безопасности, откроет его (или запустит его если так случится что его присоединение является исполняемым) и выявит или нет что данный файл выступает некой разновидностью вредоносного обеспечения. Если это так, Office 365 немедленно начнёт блокировать такой файл, тем самым останавливая распространение подобного потенциально пагубного поведения. Всё это произойдёт без вмешательства конкретного пользователя или соответствующей команды ИТ компании. Это даже не сопровождается особыми действиями внутри компании. Если одно из моих пользовательских электронных писем является первым полученным новым вирусом, а это будет выявлено Microsoft, такое поведение поможет блокировать такой новый вирус для всех прочих потребителей, которые также имеют свою электронную почту в облаке Microsoft. Это достаточно неправдоподобное лекарство!

Та же самая идея остаётся верной и для AV Defender когда вы выбираете разрешение позволить ему взаимодействовать с Microsoft и передавать информацию в облачные ресурсы Microsoft. Ранее я выставлял некий снимок экрана кое с какими возможностями AV Defender под названием cloud-delivered protection and automatic sample submission (движимая облаком защита и автоматическое представление образцов) - это та часть AV Defender, которая делает возможной магию облачного решения и преимущества всей популяции компьютеров.

И снова мы рассматриваем нечто выглядящее длинным заголовком для технологии, которая имеет очень специфические цели, так? Совсем нет. Такой новый Защитник применения (Exploit Guard) не является какой- то новой возможностью, а вместо этого целым набором новых возможностей, испечённых в семействе Microsoft Defender. В частности, эти новые защитные возможности разработаны в помощь выявлению и противодействию некоторых из распространённых манер поведения, которые применяются современными вредоносными атаками.

Вот четыре первичных компонента ATP Защитника применения Defender (Defender ATP Exploit Guard):

Этим средствам управления, в особенности средствам защиты от использования (эксплойтов), можно управлять различными способами. Их можно развёртывать централизованно через Inline, Групповую политику или Microsoft Endpoint Configuration Manager. Кроме того, их можно настраивать по отдельности для каждой машины при помощи PowerShell или встроенного в каждую текущую версию Windows прикладного приложения безопасности Windows (Windows Security app).

Давайте бросим взгляд на настройки отдельного экземпляра Windows Server 2022. Откройте Windows Settings | Update & Security. Внутри, в панели слева, вы обнаружите иконку щита, которая сообщает Windows Security. Пройдите далее и кликните по ней, Теперь в App & browser control. В этом экране у вас имеется вариант настройки Reputation-based protection (защиты на основе репутации), что является тем разделом, в котором осуществляется настройка защиты SmartScreen на основе URL, а также раздел для Exploit protection (защиты от эксплойтов). Кликнув по Exploit protection settings, теперь мы получаем практически важные подробности этих механизмов защиты. Существует множество различных элементов защиты от эксплойтов, которые можно включать или отключать глобально (многие из них включены по умолчанию), а щелчок по Program settings позволяет вам получать детализацию, определяя до какой степени защита от эксплойтов обрабатывает отдельные программы, как вы это можете наблюдать на Рисунке 9.5:

Давайте поиграем в игру ассоциируемых слов. Я скажу что- нибудь, а вы ответите первым пришедшим вам в голову словом.

Сетевая безопасность.

Вы сказали межсетевой экран (firewall)? Когда мы рассуждаем о безопасности своих устройств на сетевом уровне, мы говорим о периметрах. Такие периметры определяются и защищаются межсетевыми экранами, причём в основном на аппаратном уровне, на чём специализируются сетевые устройства, сделанные для обработки таких определённых задач в наших сетевых средах. Сегодня мы здесь чтобы обсудить другой уровень межсетевых экранов, который вы можете и должны обслуживать в своих средах. Да, мы говорим о Межсетевом экране Windows. Прекратите хохотать, это грубо!

Легко подшучивать над Межсетевым экраном Windows на основе его истории. В дни Windows XP и Server 2003 им просто невозможно было пользоваться и он больше вызывал головную боль, чем решал проблемы. На самом деле это его восприятие стало настолько распространённым, что я и по сей день нахожу многие компании, которые полностью вовсе отключают Windows Firewall в своих подключаемых к домену системах в виде определяемой по умолчанию политики. Когда я спрашиваю их о причине, обычно она не определена - мы всегда делали так или это предписанная политика таковы стандартные ответы. И именно это основная проблема, поскольку WFAS (Windows Defender Firewall with Advanced Security, Межсетевой экран Windows Defender с расширенной безопасностью), который сегодня присутствует в ОС Windows намного более надёжен и современен, чем был когда- то ранее и совершенно точно может применяться для расширения вашей архитектуры безопасности. Я бы даже зашёл настолько далеко, что это абсолютно глупо отключать WFAS в современных ОС пока у вас нет совершенно конкретной и обоснованной причины для этого.

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

Межсетевой экран Windows Defender (WDF, Панель управления)

Когда вы пробуете запустить любое приложение или установки в Windows Server 2022, обычно наиболее действенно просто кликнуть по кнопке Start и затем набрать некое слово, имеющее отношение к той задаче, которую вы намерены выполнить. В моём случае я выполняю клик по Start и набираю firewall. Наилучший вариант соответствия, который предоставился первым в результатах моего поиск, оказался Windows Defender Firewall (WDF), поэтому я двигаюсь далее и щёлкаю по нему.

Интересно, что данная ссылка открывет консоль настроек Межсетевого экрана Windows изнутри Control Panel, что является способом старой школы для выполнения настроек системы. Эта консоль всё ещё работает и полностью способна манипулировать базовыми функциями работы межсетевого экрана,такими как включение и отключение самого Межсетевого экрана Windows, но так этот инструмент расположен внутри Control Panel, у нас есть предположение, что на самом деле это не тот инструмент, который подразумевался Microsoft для применения нами. Запомните, все новые возможности настроек переместились в экраны Windows Settings, вместо того чтобы быть представленными в Control Panel:

Межсетевой экран и сетевая защита (Настройки безопасности Windows)

В то время как инструменты на основе Control Panel всегда занимали должное место для выполнения необходимых изменений в предыдущих версиях ОС, мы уже знаем, что многие параметры Microsoft Defender хранятся внутри Windows Settings. Может ли быть так, что и в этом случае установки настроек Межсетевого экрана Windows Defender хранятся внутри раздела Windows Security из Settings?

Да это несомненно так. Откройте Windows Settings и кликните по Update & Security, а затем по Windows Security. Вы уже бывали здесь ранее - это тот экран, который предоставляет быстрое резюме всех компонентов Microsoft Defender. Конечно же, здесь имеется такое с названием Firewall & network protection. Кликните по этой кнопке и вы войдёте в новую платформу настроек для функций Межсетевого экрана Windows, который не существовал в предыдущих версиях Windows Server:

Кликнув по любой из тех ссылок, которые представлены здесь, вы откроете дополнительные параметры настроек. Например, если вы желаете быстро включать и отключать определённые профили межсетевого экрана (вскоре мы изучим их), вы можете кликнуть по тем профилям которые вы желаете настраивать, например, профилю Domain network, и отсюда вы сможете запросто отключать свой межсетевой экран для этого сетевого профиля. Многие компании отключают для своих машин профиль Domain network чтобы этот межсетевой экран не защищал обмен, который происходит внутри корпоративной локальной сети.

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

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

Межсетевой экран Windows Defender с расширенной безопасностью (WFAS)

Если вы похожи на меня, вас не удовлетворит эта предоставляемая внутри Windows Settings информация и вы пожелаете увидеть что происходит под капотом , а потому вы пожелаете слегка больше информации чем та, что способны вам предоставить базовые инструменты Межсетевого экрана Windows. Вы можете либо кликнуть по ссылкам Advanced settings, показанным в предыдущих снимках экранов, или просто открыть Приглашение командной строки или запустить приглашение Start | Run и набрать wf.msc. Любое из этих действий запустит полную консоль администрирования WFAS:

Здесь вы можете видеть гораздо больше глубинных сведений относительно имеющейся активности и правил, которые вступают в игру при посредстве Межсетевого экрана Windows, а также выполнять намного больше неотложных регулировок в ваших разрешениях и блокировках. Также имеется раздел Monitoring, в котором у вас есть возможность просмотра активных вовлечённых правил, включая Connection Security Rules. Это важный раздел, поскольку он подчёркивает тот факт, что WFAS выполняет гораздо больше чем простая блокировка сетевого обмена. Это не просто межсетевой экран, но также и платформа для подключений. Если вы планируете применять IPsec для шифрования сетевого обмена, будь то естественный IPsec внутри вашей сетевой среды, или же это происходит в технологии удалённого доступа DirectAccess, вы обнаружите наполняющие это раздел правила, которые являются определениями таких туннелей IPsec.

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

Когда какая- то NIC в компьютере или сервере подключена к сетевой среде, Межсетевой экран Windows назначает это подключение одному из трёх различных профилей. Скорее всего вы уже ранее взаимодействовали с этим процессом принятия решения, даже и не осознавая того. Когда вы подключаете свой ноутбук к Wi-Fi в своей местной кофейне, спрашивал ли вас Microsoft подключаетесь ли в к домашней, рабочей или общедоступной сетевой среде? Это именно Межсетевой экран Windows задаёт вам вопрос относительно того выполняете ли вы подключение дома, на работе или в общественной сетевой среде? Или же, в более поздних версиях Windows, он задаёт вам вопрос, похожий на "Would you like to allow your computer to be discoverable on this network—yes or no?" ("Хотите ли вы разрешить обнаружение своего компьютера в данной сети - да или нет?"). Это ваш межсетевой экран спрашивает какой именно профиль вы бы хотели назначить своему новому сетевому соединению.

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

Всякое сетевое подключение получает назначенным её собственное определение профиля, причём несомненно вы можете иметь активным более одного профиля межсетевого экрана в одно и то же время в одной и той же системе. Например, мой сервер RA1 подключён как к корпоративной, так и к общедоступной сетям. А внутри WFAS вы можете увидеть активными и Профиль домена и Общедоступный профиль:

В качестве альтернативы, когда вы откроете в этом сервере Network and Sharing Center, здесь мы также сможем обнаружить перечисленными эти профили, а вы сможете быстро выяснить какая NIC применяет какой профиль:

Теперь, когда мы знаем что составляет плоть и кровь нашего Межсетевого экрана Windows внутри имеющейся консоли WFAS, давайте воспользуемся WFAS чтобы создать собственное новое правило. В своём сервере RA1 я разрешу доступ RDP с тем, чтобы я легко мог управлять этим сервером со своего рабочего места. Тем не менее, включая RDP, я теперь разрешаю доступ RDP к этому серверу из всех сетевых сред. Это означает, что я могу получить доступ к серверу RA1 изнутри своей сетевой среды, но также я способен выполнять RDP и из Интернет, поскольку это сервер удалённого доступа и может так получаться что к нему будет выполняться подключение напрямую через Интернет. Это большая проблема, так как теперь любой yahoo из Всемирной паутины потенциально сможет обнаружить мой сервер, найти его приглашение на регистрацию RDP и попытаться силой войти таким образом в RA1.

Для частичного снятия данной проблемы я хочу плющить RDP только со своей внешней NIC. Я желаю оставить его активным внутри с тем, чтобы я мог продолжать доступ к этому серверу со своего рабочего места, но существует ли некий простой способ внутри WFAS для создания некого правила, которое блокирует RDP доступ только извне? Да, несомненно оно имеется.

Откройте wf.msc чтобы запустить Межсетевой экран с расширенной безопасности Windows Defender и перейдите к разделу Inbound Rules и вы увидите все имеющиеся входящие правила межсетевого экрана, которые присутствуют в этом сервере (если вы никогда не бывали ранее в этом разделе, здесь имеется перечисленными множество правил, все эти правила установлены при помощи ОС). Кликните правой кнопкой по Inbound Rules и выберите New Rule.... Это запустит мастер, из которого мы будем создавать своё новое правило межсетевого экрана. Самым первым экраном является тот, в котором мы будем указывать какой вид правила мы хотим создать. Вы можете создать некое правило, которое изменяет обмен для какой- то определённой программы, либо вы можете просмотреть некий перечень Predefined протоколов.

Я хочу в точности знать что делает моё правило по причине того способа, который определяю я, а не по причине предварительно имевшегося определения протокола, а также мне известно, что RDP работает по порту 3389. Поэтому я собираюсь в этом экране выбрать порт и после того как я кликну по Next, я определю 3389 как конкретно тот порт, который я намерен изменить:

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

Для своего примера мы уже имеем работающим RDP, но мы желаем заблокировать его для единственной определённой NIC, поэтому я намерен выбрать Block the connection:

Мы не желаем блокировать RDP для всех имеющихся NIC, следовательно данный экран очень важен. Здесь нам следует сослаться обратно на те знания, которые мы обсуждали относительно таких профилей. Вы помните, что все подключаемые к нашей сетевой среде домена внутренние NIC будут иметь назначенным им Профиль домена. В то время как все те NIC, которые не подключены к внутренней сети, в которой расположен контроллер домена, будут иметь активным либо Частный, либо Общедоступный профиль. Именно это знание нам требуется представить в данном экране. Если мы желаем запретить RDP только для всех внешних NIC, нам требуется активировать это правило только для Частных и Общедоступных профилей. На самом деле, оглядываясь назад на тот снимок экрана, который мы уже рассматривали, мы можем обнаружить, что внешней NIC определённо назначается значение Общедоступного профиля, а поэтому мы здесь можем пометить только флажок Public и RDP после этого будет блокироваться во всех внешних NIC. Однако в случае если мы добавим в будущем ещё NIC для этого сервера, с помощью которых мы желаем убедиться что доступ по RDP не возможен, мы оставим помеченными и флажок Public, и флажок Private , чтобы гарантировать в будущем лучшую безопасность.

Убедитесь, что вы uncheck свой профиль Domain! В противном случае вы окончательно целиком заблокируете доступ RDP, а если вы в настоящий момент вы применяете RDP для подключение к данному серверу, вы вышибете себе самостоятельно и у вас не будет возможности подключиться повторно:

А теперь мы просто создаём некое название для своего нового правила и мы закончили! Наша возможность в RDP к данному серверу через интернет немедленно была отключена и мы сегодня ночью можем отдыхать намного проще.

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

Это является проблемой для сред, в которых ping является стандартным методом того, доступен ли некий употребляемый IP адрес. Вы можете смеяться, но, поверьте мне, что всё ещё имеется достаточно много администраторов ИТ, которые не отслеживают какие именно адреса IP они используют внутри своих сетевых сред, а когда они сталкиваются с ситуацией, связанной с установкой нового сервера и им требуется принять решение какой IP адрес ему присвоить, они просто запускают ping IP адресов в своей сетевой среде пока не обнаружат один из тех, который отвечает тайм- аутом! Я наблюдал это много раз. Хотя это и не самый лучший способ управления IP адресами, так бывает. К несчастью, этот метод сталкивается с громадной проблемой, потому как большинство новых установок Windows спроектированы на блокирование откликов ICMP сразу после установки, что означает, что вы не можете выполнять ping для некого IP адрес и получать некий тайм- аут, но тем не менее по этому адресу может присутствовать запущенный сервер.

Итак, давайте вернёмся к этому моменту. Вам может потребоваться включить ICMP в своём сервере с тем, чтобы он отвечал когда некто пытается выполнять ping к нему. Когда вам требуется создать новое правило, которое позволит происходить ping, мы настраиваем это правило в точности так же как мы делали это для RDP, но имеется одна большая западня. В самом первом экране Rule Type при создании вашего нового правила когда вы должны определить какой вид правила вы создаёте, нет никаких вариантов или предварительных определений для ICMP. Я нахожу это странным, так как это очень распространённый тип правила, чтобы быть помещённым здесь, но увы, выбор ICMP из имеющегося ниспадающего меню был бы слишком простым. Вместо этого вам придётся делать это через создание нового входящего правила, в точности как и для RDP, однако в самом первом экране для Rule Type убедитесь что вы выбрали вариант с названием Custom.

Далее оставьте значение выбранного варианта для определения этого правила для All programs. Снова кликните далее и теперь вы имеете ниспадающий блок с названием Protocol type. Именно в этом меню вы можете выбрать новое правило для манипуляций с ICMP обменом. Как вы можете видеть на Рисунке 9.15,у вас имеется вариант выбора из ICMPv4 или ICMPv6, в зависимости от того, какой сетевой обмен вы предпочитаете. Моя лаборатория для проверок является приспособленной только под IPv4, поэтому я намерен выбрать ICMPv4:

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

Если вам требуется изменить некое правило, либо погрузиться в дополнительные подробности правила межсетевого экрана, вернитесь обратно в свой экран Inbound Rules, по которому вы кликнули правой кнопкой в любом персональном правиле межсетевого экрана и проследуйте в Properties. Внутри этих закладок у вас имеется возможность изменять любые критерии относительно данного правила. Например, вы можете выделить дополнительные порты, вы можете изменять к какому именно профилю его применять, или даже можете ограничить для каких конкретных адресов IP применять это правило, воспользовавшись закладкой Scope.

Это позволяет вам применять своё правило межсетевого экрана для входящего или исходящего обмена, происходящего в определённой части вашей сетевой среды, или конкретном подмножестве ваших машин. Например, здесь я изменил свою закладку Scopeчтобы отразить тот факт, что я желаю применять данное правило который происходит в моей подсети 192.168.0.0/16:

Управление правилами межсетевого экрана в ваших серверах и клиентах может стать гигантским шагом вперёд к более безопасное среде в вашей компании. Что тут самое лучшее? Эта технология является технологией корпоративного уровня и свободно доступна для применения так как она уже встроена в те ОС, которые вы применяете. Единственная цена, которую вы связываете с межсетевым экраном на данном уровне это то время, которое займёт у вас размещение этих правил на свои места, что может стать ночным кошмаром администратора если вам требуется реализовать целый список разрешений и блокировок в каждой машине индивидуально.

Отдадим должное благости GPO (Group Policy Object). Как это имеет место и для большинства настроек и функций внутри платформы Microsoft, установка некой политики, которая применяется ко всем является лёгким ветерком для ваших подключаемых к домену машин. Вы даже имеете возможность разбить их на множество наборов политик, создавая GPO, который применят правила межсетевого экрана для ваших клиентов, а также отдельный GPO, который применяет правила межсетевого экрана для ваших серверов, как вы сочтёте нужным. Основной момент состоит в том, что вы можете группировать множество машин вместе по категориям, создавать наборы правил GPO для каждой из категорий, и автоматически применять их ко всем машинам применяя мощность возможностей распространения GPO.

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

После того как вы создали новый GPO, кликните правой кнопкой по нему изнутри Group Policy Management Console и кликните по Edit...:

Теперь, когда вы рассматриваете этот новый GPO изнутри, нам сего лишь требуется определить правильное местоположение чтобы создать некие новые правила межсетевого экрана. Когда мы просматриваем правила внутри самой локальной машины, все они перечислены под заголовком Windows Defender Firewall with Advanced Security и он расположен в Computer Configuration | Policies | Windows Settings | Security Settings | Windows Defender Firewall with Advanced Security | Windows Defender Firewall with Advanced Security:

Как вы можете видеть, это также то место, это также и то место, в которое надо следовать, когда вы желаете убедиться, что определённо включаются или отключаются конкретные профили межсетевого экрана, или весь Межсетевой экран Windows целиком.

Кликая по свойствам Межсетевого экрана Windows Defender (Windows Defender Firewall Properties), на указанную на Рисунке 9.19 ссылку, вы можете определять значение состояние для каждого профиля межсетевого экрана персонально:

После того как вы завершите настройки своих профилей в соответствии со своими потребностями, кликните по OK и вы обнаружите что вернулись обратно в свой WFAS в часть GPO. Прямо внутри даной локальной консоли WFAS у вас имеются категории Inbound Rules и Outbound Rules. Просто кликните правой кнопкой по Inbound Rules и кликните по New Rule... чтобы начать построение правила прямо в этом GPO. Пройдите тот же самый мастер с которым вы уже ознакомились при создании некого правила в своей локальной консоли WFAS, а когда завершите, ваше новое правило межсетевого экрана будет отображено внутри этого GPO:

Быстрее чем вы произнесёте Джек Робинсон, данное новое правило межсетевого экрана уже проделало свой путь в Active Directory и установило себя на те компьютеры и серверы, которые вы определили в ссылках и критериях фильтрации данной политики:

Идея, которая сделала большой шаг от того с чем пытаются поиграть большие организации к тому что требуется всем это применение шифрования. Многие из нас многие годы шифруют обмен наших вебсайтов с применением вебсайтов HTTPS, но даже в этой области имеются удивительные исключения: многие экономичные компании хостинга по- прежнему предоставляют страницы входа, которые передают обмен в виде открытого текста. Это ужасно, так как всё то что вы передаёте через открытый интернет в наши дни применяя обычный HTTP или не шифрованную почту, всё это вы должны считать что это также доступно для прочтения и кому- то ещё. Скорее всего, вы страдаете паранойей, и никто не перехватывает и не читает ваш обмен, но вы должны знать, что если обращаетесь к веб-сайту с сообщением HTTP в адресной строке или, если вы отправляете электронное письмо из любой бесплатной почтовой службы, любые данные, вводимые на этой веб-странице или в этом электронном письме, могут быть легко украдены кем-то на полпути в их Мир. Для корпоративной информации шифрование данных является абсолютно необходимым требованием относительно путешествующей через интернет корпоративной информации; хотя в то же самое время я говорю, что в глубине души мне возражают, что подавляющее большинство компаний по-прежнему не используют какие-либо технологии шифрования в своей системе электронной почты, и поэтому для большинства из них все ещё остаётся ожидающей их потенциальная катастрофа.

В то время как мы всё лучше и лучше защищаем свой обмен в интернете через браузер, мы по- прежнему не уделяем большого внимания тем данным, которые пребывают в "безопасности" за стенами нашей организации. Теме не менее, плохие парни не глупы, и у них имеется очень большой набор трюков для социальной интеграции с нашими сетевыми средами. Оказавшись внутри, что они обнаруживают? В большинстве случаев это большая свобода для всех. Получите одну учётную запись пользователя или один компьютер, и у вас есть ключи от подавляющей части всего королевства. К счастью, в Windows Server 2022 имеется ряд технологий, разработанных для борьбы с подобными вторжениями и защиты ваших данных даже если они окружены четырьмя стенами вашего центра обработки данных. Давайте рассмотрим некоторые сведения о них чтобы у вас была возможность изучить варианты применения таких технологий шифрования для дальнейшей защиты ваших данных.

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

По мере эскалации приспособления к ресурсам облачных вычислений несомненно более существенным становится желание BitLocker в наших серверах. Более конкретно, когда мы обсуждаем облачные решения, то в чём мы действительно нуждаемся, это BitLocker в наших виртуальных машинах, будь то ОС клиента или сервера. Будете ли вы хранить свои VM (Virtual Machines, Виртуальные машины) в реальной облачной среде, предоставляемой общедоступным поставщиком облачных служб, или размещаетесь в своём собственном частном облачном решении, в котором арендаторы имеют богатые возможности создания и управления своими собственными ВМ без возможности шифрования таких виртуальных жёстких дисков - файлов VHD или VHDX - ваши данные абсолютно не безопасны.

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

Почему исторически не соблюдалось шифрование ВМ? По той причине, что BitLocker поступал с неким интересным требованием. Тот факт что жёсткий диск зашифрован, означает что он не способен загружаться без снятия защиты шифрованием. Как мы можем разблокировать свой жёсткий диск с тем, чтобы наша машина имела возможность для загрузки? Одним из двух способов.

Самым лучшим методом является хранение значения ключа снятия блокировки внутри некого TPM (Trusted Platform Module, Доверенного модуля платформы). Это некая физическая микросхема, которая встроена непосредственно в большинство компьютеров, которые вы приобретаете в наши дни {Прим. пер.: к сожалению, не в РФ.} Хранение ключа разблокирования BitLocker в этом чипе означает, что вам не приходится никак физически связываться с вашим компьютером для его загрузки, вы просто вводите некий пин- код для получения доступа к имеющемуся TPM, а затем этот TPM снимает блокировку BitLocker. С другой стороны, когда вы выбираете развёртывание BitLocker без наличия некого TPM, для снятия блокировки с тома BitLocker и превращения его в загружаемый, вам требуется подключить некое физическое USB устройство, которое содержит соответствующие ключи BitLocker для снятия блокировки. Видите ли вы какие- нибудь проблемы с одним из этих сценариев установки виртуальных машин? ВМ не могут иметь физического чипа TPM, а у вас также нет простого способа подключения какого- либо USB устройства! Итак, как мы можем шифровать такие ВМ, чтобы любопытные взгляды из компании хостинга облачных решений не могли видеть в её наше наполнение?

Введём виртуальный TPM. Эта возможность пришла к нам совершенно новой в Windows Server 2016; теперь у нас есть возможность придания своим серверам некого виртуального TPM, который может применяться для хранения подобных ключей! Это невероятная новость, и она означает, что мы наконец можем шифровать свои серверы, размещаются ли они на физических серверах Hyper-V в вашем центре обработки данных, или располагаются в облаке Azure.

Применяя BitLocker и виртуальный TPM для шифрования и защиты файлов виртуальных дисков производится нечто, именуемое Защищённой ВМ (Shielded VM). Защищённые ВМ в качестве такой возможности впервые были предложены в Windows Server 2016 и были далее усовершенствованы в Windows Server 2019. При том что Microsoft перенесла свою сосредоточенность на размещение облачных решений и серверы с поддержкой Azure, скорее всего Microsoft не будет добавлять дополнительные разработки или возможности в будущем для Защищённых ВМ на площадке, однако они всё ещё имеются в Server 2022 и всё ещё полностью сопровождаются.

Более подробно мы рассмотрим Защищённые ВМ в Главе 14, Hyper-V.

Разве не было бы замечательно если бы мы имели возможность настраивать, контролировать и управлять своими сетевыми средами из графического интерфейса администрирования, вместо того чтобы смотреть целыми днями на CLI маршрутизатора? Разве мы не получили бы выгоду от гибкости сетевой среды для перемещения серверов и рабочих нагрузок из одной подсети в другую без необходимости изменения IP адресации и маршрутизации на этих серверах? Неужели мы не можем найти некий способ автоматического шифрования всего обмена, который проходит между нашими серверами без необходимости настраивания такого шифрования в самих серверах?

Да, да, да! Мы можем делать все эти вещи посредством применения SDN (Software Defined Networking, Программно определяемых сетевых сред) и новой возможности, именуемой encrypted virtual networks (зашифрованными виртуальными сетями). Это раздел текста просто ориентировка, место, которое поможет вам вернуться к Главе 7, Построение сетей Windows Server 2022, если вы вдруг пропустили её, оказавшись в этом месте. Мы уже обсуждали SDN и их новые возможности по созданию автоматически шифруемых виртуальных сетей, которые протекают между ВМ Hyper-V и серверами хостинга Hyper-V, поэтому если вас заинтересовала эта идея, вернитесь назад чтобы ещё раз познакомиться с этой главой.

Encrypting File System (EFS, Зашифрованная файловая система) является компонентом Microsoft Windows, который имеется как в ОС клиентов, так и в ОС серверов на протяжении многих лет. В то время как BitLocker служит для шифрования тома или диска целиком, EFS слегка более конкретная. Когда вы желаете зашифровать только определённые документы или папки, это именно то что вам требуется включить. Когда вы выбираете шифрование файлов с помощью EFS, важно понимать, что Windows требуется применять некий сертификат пользователя в качестве общего процесса шифрования/ дешифрации, а следовательно ключом для успешного развёртывания является доступность некого внутреннего PKI. Также важно отметить, что ключи аутентификации связываются таким паролем пользователя, поэтому полностью взломанная учётная запись пользователя может свести на нет те преимущества, которые предоставляет EFS.

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

Вокруг данных в покое вращается большое число встроенных в ОС технологий шифрования. Но что относительно данных в их перемещении? Мы уже обсуждали применение SSL в вебсайтах HTTPS как некий способ шифрования данных веб браузера при их перемещении через Интернет, но что относительно данных, которые не перемещаются через некий веб браузер?

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

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

Наиболее распространённое место, в котором демонстрируется взаимодействие IPsec в Windows Server, это применение роли Удалённого доступа (RA, Remote Access). При настройке VPN в вашем сервере RA, у вас будет иметься некое число протоколов подключения VPN, которые могут применяться для подключения к этому серверу VPN. В этом перечне возможных платформ подключения содержатся туннели IPsec (IKEv2). Второй технологией удалённого доступа , которая применяет IPsec является DirectAccess.

Когда вы устанавливаете в своей сетевой среде DirectAccess, всякий раз когда некий компьютер клиента создаёт какой- то туннель DirectAccess через Интернет к его серверу DirectAccess, этот туннель защищается IPsec. К счастью, та Консоль управления Удалённого доступа, которую вы применяете для развёртывания как VPN, так и DirectAccess, достаточно интеллектуальны чтобы знать, что всё что им требуется, так это выполнить работу по аутентификации и шифрованию, и вам нет нужды знать какие- то обособленные моменты относительно IPsec чтобы заставить эти технологии удалённого доступа работать на вас!

Главным недостатком IPsec, обеспечиваемым ролью удалённого доступа, является обмен внутри вашей сетевой среды. Когда вы говорите о VPN или DirectAccess, вы обсуждаете обмен, происходящий через Интернет. Но что если вы просто желаете зашифровать обмен, который происходит между двумя серверами внутри одной сетевой среды? Или обмен, который протекает между компьютерами клиентов в офисе с их локальными серверами, также расположенными в самом офисе? Именно здесь вам пригодятся знания о параметрах политики IPsec, поскольку мы можем указать что мы желаем чтобы перемещающийся внутри нашей корпоративной сетевой среды обмен должен быть зашифрован при помощи IPsec. Для того чтобы это происходило, необходимо разместить верную политику.

Настройка IPsec

Существует два различных места, где могут настраиваться установки IPsec в среде Microsoft Windows. Как старые, так и новые системы могут снабжаться настройками IPsec через обычную оснастку Политики безопасности IPsec. Если вы запускаете все системы, которые являются более новыми, такие как Windows 7 и Server 2008 или выше, тогда вы можете иметь на службе в качестве альтернативы Межсетевой экран с Расширенной безопасностью Windows Defender для настройки ваших политик IPsec. WFAS является более гибким решением, но оно не всегда доступно в зависимости от состояния наследуемых систем в вашей среде.

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

Политика сервера

Вероятно, политику сервера стоит переименовать в политику Запрашивающего (Requestor), поскольку она означает именно это. Когда некий компьютер или сервер делает какой- то сетевой запрос вовне к другому компьютеру или серверу, это запрос на установление некого сетевого подключения. Об этих запрашивающих компьютерах - которые инициируют данный обмен - мы и говорим как как о подлежащей приёму Политике сервера IPsec. Будучи применённой, эта Политика сервера сообщает что данный компьютер или сервер запрашивает шифрование IPsec для данного сеанса взаимодействия между нашей инициирующей машиной и её удалённым компьютером. Если такой удалённый компьютер поддерживает IPsec, тогда создаётся необходимый туннель IPsec чтобы защищать весь обмен между данными двумя машинами. Однако, сама Политика сервера достаточно снисходительна хотя, и если ваш удалённый сервер не поддерживает IPsec, тогда данное соединений всё равно будет успешным, но останется не шифруемым.

Политика безопасного сервера

Основное отличие здесь состоит в том, что Политика безопасного сервера (Secure Server policy) для того чтобы соединение произошло, требует шифрования IPsec. Обычная Политика сервера, которую мы обсуждали ранее, будет выполнять шифрование IPsec когда оно возможно, а если оно не возможно, она будет продолжать свой поток обмена в не зашифрованном виде. С другой стороны, Политика безопасного сервера выдаст отказ в установлении соединения совсем если между этими двумя машинами не возможно договориться об IPsec.

Политика клиента

Политику клиента следовало бы переименовать в политику Отклика (Response), так как именно она выступает другой стороной данного соединения. Эта Политика клиента не заботится о запросе некого подключения, она всего лишь ведает его получением. Когда некий компьютер делает какой- то запрос к серверу, а этот компьютер имеет установленной Политику сервера или Политику безопасного сервера, а следовательно он запрашивает IPsec, тогда такому серверу потребуется назначенной ему Политику клиента чтобы принять и построить такой туннель IPsec. Данная Политика клиента отвечает за то чтобы разрешить чтобы в данном сеансе происходило шифрование.

Оснастка политики безопасности IPsec

Первоначальная консоль для манипуляции настройками IPsec доступна через MMC. Откройте его и добавьте соответствующую оснастку IP Security Policy Management. Примечательно, что когда вы добавляете эту оснастку, вы обратите внимание на то, что у вас имеется возможность просматривать либо саму локальную политику IPsec данной машины, в которой вы зарегистрированы в настоящий момент, или же вы можете открыть соответствующую политику IPsec для самого вашего домена.Если вы заинтересованы в настройке реализации IPsec по всему домену, это будет вашей зоной запуска для работы с такими настройками. Но для того чтобы просто немного заглянуть сюда вы можете выбрать свой Local computer чтобы рассмотреть её консоль:

Оказавшись внутри, вы можете наблюдать все имеющиеся политики IPsec, которые могут иметься установленными, либо вы можете начать создание своей собственной, воспользовавшись действием Create IP Security Policy..., доступным при правом клике по IP Security Policies. Сделав это мы запускаем некий мастер, который пройдёт по необходимым настройкам для вашей конкретной политики:

Применение вместо этого WFAS

Новой платформой, применяемой для установления правил подключения IPsec является Windows Defender Firewall with Advanced Security (WFAS). Пройдём далее и откроем её, благо мы уже заем как это делать. оказавшись внутри, перейдём к разделу Connection Security Rules, который перечислен непосредственно за Inbound Rules и Outbound Rules. Connection Security Rules это то место, где вы определяете правила подключения IPsec. Если вы кликните по Connection Security Rules и выберете New Rule..., вы затем пройдётесь по мастеру, который аналогичен тому, в котором мы создавали правило межсетевого экрана:

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

У нас нет здесь достаточного пространства чтобы описать все доступные в этом мастере возможности, но я определённо рекомендую вам зацепиться за этот момент и сделать ещё один шаг в сторону добавления неких сведений из следующей статьи Microsoft Docs.

Если вы клиент Azure Active Directory, вы уже имеете доступ к этой новой функции с названием Azure Active Directory Password Protection, ранее носившей название Запрещённые пароли (banned passwords). Основная идея такова: Microsoft поддерживает глобальный пополняющийся перечень обычно плохих паролей (таких как слово password) и автоматически блокирует все варианты паролей, такие как P@ssword, Password123 и тому подобное. Все такие потенциальные пароли будут блокированы совместно если некий пользователь попробует создать один из них своим собственным паролем. У вас также имеется возможность добавлять ваши собственные индивидуальные запрещённые пароли внутри имеющегося интерфейса Azure Active Directory. После того как вы подняли Запрещённые пароли и работаете с ними в Azure, эта возможность может быть затем портирована также и в среду Active Directory на вашей площадке через реализацию службы посредника (прокси) защиты паролей Azure Active Directory (Azure Active Directory Password Protection proxy server, боже, кто это сможет произнести).

Такой посредник это агент, который устанавливается в ваших локальных серверах Контроллера домена и активно доставляет из Azure Active Directory политики паролей, гарантируя что все пароли, которые пользователи пытаются разместить в ваших Контроллерах домена соответствуют правилам, определённым алгоритмами Запрещённых паролей Azure.

Чтобы применять данную технологию, естественно, вы обязаны применять Azure Active Directory, следовательно она доступна не всем. Однако, если вы получили и синхронизировали Azure Active Directory, тогда эта возможность даже имеет обратную переносимость на более ранние Контроллеры домена на площадке. Эти серверы не должны быть старше Windows Server 2012.

Вот ссылка на дальнейшую информацию относительно Azure AD Password Protection для AD DS.

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

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

Действительно ли необходимо, чтобы эти пользователи механической мастерской обладали тем же самым уровнем сложности пароля, что и коммивояжёры? Обязаны ли они также обновлять свой пароль каждые 30 дней только потому, что вы просите об этом парней из отдела продаж?

Начиная с Windows Server 2012, зарегистрируйтесь в любом сервере Контроллера домена и запустите Диспетчер серверов (Server Manager) и в самом верху вашего списка Инструментов (Tools) вы обнаружите нечто с названием ADAC (Active Directory Administrative Center). Это средство ADAC можно применять для манипулирования многими вещами внутри Active Directory, однако что наиболее важно для нашей цели на сегодня, этот новый инструмент выступает механизмом, который позволяет вам создавать FGPP (fine-grained password policy, тонкую настройку политики паролей). FGPP допускает такой сценарий, на который мы намекали абзац назад, а именно, возможность создавать множество политик паролей и назначать эти политики различным классам пользователей и учётных записей пользователей.

Зарегистрируйтесь в Контроллере домена в качестве администратора домена и откройте ADAC. В панели навигации слева раскройте название своего внутреннего домена, затем System | Password Settings Container. В среде своей лаборатории я щёлкаю по contoso (local) | System | Password Settings Container. В настоящий момент контейнер настроек паролей (Password Settings Container) пуст, однако воспользовавшись задачей New | Password Settings мы приступаем к вращению вещами:

Экран Password Settings достаточно хорошо поясняет себя сам. Здесь вы определяете те же самые типы сложности паролей, длины и критерия их срока истечения, которые вы бы обычным образом настраивали бы внутри GPO политики домена по умолчанию. Из Рисунка 9.27 вы можете видеть, что я создал политику настроек паролей с названием Sales Users с рядом определённых критериев.

У меня имелась возможность конфигурации установок паролей, а также настроек блокирования учётных записей (прочие настройки безопасности обычно осуществляются глобально через GPO) и отфильтровать эти политики паролей с тем, чтобы они применялись только к пользователям, которые пребывают внутри моей группы AD с названием Sales Users:

Теперь я намерен повторить этот процесс ещё пару раз, после чего у меня имеются три отдельные политики настроек паролей внутри моего контейнера ADAC:

Нечто, на что важно обратить здесь внимание эт то, что каждая политика настройки паролей обладает объявлением Precedence (старшинства). Поскольку мы применяем эти настройки паролей к группам, несомненно имеется вероятность, что определённый пользователь может быть частью множества групп, что снабдило бы его множеством политик паролей. Число Precedence помогает FGPP отличать какие именно настройки надлежит применять.

Вот и всё! Как только вы определили тонкую регулировку политик паролей внутри ADAC, эти новые настройки паролей теперь будут обладать приоритетом над настройками внутри GPO политики домена по умолчанию. Вместо того, чтобы задавать параметры паролей через Групповую политику, применяя тонкую настройку политик паролей вы пользуетесь собственными объектами внутри Active Directory для осуществления своей работы. Такие объекты носят название PSO (Password Settings Objects, объектов настройки паролей). Если вы жеалете заглянуть слегка дальше под капот PSO, теперь, когда вы создали FGPP внутри ADAC, проследуйте вперёд к Active Directory Users and Computers и разрешите Advanced Features в меню View. После включения Advanced Features вы можете переместиться к Domain | System | Password Settings Container и обнаружить созданные минуту назад новые PSO.

Кликнув дважды по любому из этих объектов и затем посетив закладку Attribute Editor, будут отображены подробности критериев такого объекта. Нет никакой необходимости посещать эти объекты изнутри ADUC, поскольку вы всегда можете подправлять и изменять свои FGPP изнутри описанной консоли ADAC, однако возможность видеть эти PSO помогает нам понять как Active Directory хранит эти политики и обрабатывает их:

По моему убеждению, одна из самых крутых функциональностей безопасности, пришедшая из Microsoft за последние несколько лет, это Advanced Threat Analytics (ATA, Расширенная аналитика угроз) и всё же я едва ли слышал чтобы кто- то говорил о ней. В любом случае, это не функциональность или функция встроенная в саму ОС Windows Server, но это локальное программное обеспечение, которое работает на базе Windows для создания неких удивительнейших функциональных возможностей. По сути, ATA отслеживает весь ваш обмен Active Directory и предупреждает вас об опасном или необычном поведении в реальном масштабе времени сразу же при его возникновении.

К сожалению, ATA достигла окончания поддержки в январе 2021 в основном канале. Однако, расширенная поддержка продолжится до 2026 года, а потому я решил сохранить сведения в этом самом последнем издании, потому как это действующая технология, которая будет присутствовать в тех средах, в которых она установлена, ещё какое- то время. В конце данного раздела приводятся дополнительные сведения о дорожной карте ATA.

Основная идея ATA достаточно банальна для понимания и настолько логична, что все мы будем удивлены почему кому-то потребовалось так много времени чтобы догадаться до неё. Active Directory существует уже очень давно, а атаки на вашу среду с применением учётных записей пользователей происходят так же долго. Обнаружение и устранение атак внутри каталога сложно и лишено упорядоченности; внутри AD регистрируется так много сведений, что практически невозможно поймать и отследить негодяев, в то время когда они выполняют свои грязные дела. После какой- то атаки в некотором виде вы, несомненно, можете просмотреть сведения журналов в нескольких Контроллерах домена и собрать воедино некоторое подобие произошедшего, но возможность выявлять что происходит когда это случается - это просто несбыточная мечта. Или это...?

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

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

В любом случае, такие серверы обработки ATA получают все подобные данные и начинаю выискивать шаблоны. Если Бетти применяет компьютер с названием BETTY-PC и планшет с названием BETTY-TABLET, ATA обнаружит такой шаблон и свяжет её учётную запись пользователя с такими устройствами. Он также будет отслеживать её обычные шаблоны обмена. Бетти обычно регистрируется около 8 часов утра и её обмен обычно прекращается где- то около 5 вечера. Она обычно осуществляет доступ к нескольким файловым серверам и к серверу SharePoint. После недели или около того сбора и отслеживания данных, ATA обладает достаточно хорошим представлением о стандартном образе действий Бетти.

Сегодня ночью нечто произошло. ATA отследил массу отказов в приёме пароля для учётной записи Бетти. Само по себе это не может быть чем- то волнующим, однако, внезапно, Бетти регистрируется в системе терминального сервера, к которому она обычно не осуществляет доступа. Оттуда её учётные данные применяются для доступа к Контроллеру домена. О, для меня это очевидно выглядит как атака. Что мы знаем при помощи встроенных в Active Directory инструментов, которыми мы располагаем в настоящее время? На самом деле, ничего. Мы можем обнаружить отказы в приёме своего пароля, когда мы копаемся в журналах событий, а на основании этого мы можем просмотреть журналы событий в прочих серверах чтобы выяснить к чему именно обращалась данная учётная запись, но у нас на самом деле не было никаких оснований подозревать что- нибудь. Это может стать большим взломом, а мы можем никогда этого и не увидеть. К счастью ATA информирован лучше.

Интерфейс управления для ATA похож на канал социальных сетей, причём обновляемый практически в режиме реального времени. Во время событий, которые я только что изложил, если бы мы смотрели новостную ленту ATA, мы бы обнаружили происходящими все те моменты, на которые я указывал, как они происходили и сразу станет очевидны, что некто скомпрометировал учётную запись Бетти для получения доступа к Контроллеру домена. Никогда ещё не имелось технологии, которая столь интенсивно отслеживала бы обмен Active Directory и, конечно же, не было ничего такого, что могло бы изучать такие схемы поведения м отклонений в поведении. Это на самом деле поразительная технология и я говорю это, потому что знаю тех парней, которые её создавали. Ну, а раз так, я могу сказать вам что они великолепны, что уже очевидно, поскольку Microsoft подхватил их.

Несмотря на то, что данная технология в настоящее время трансформируется в нечто на облачном уровне, давайте уделим её несколько минут и просмотрим пару снимков экрана из взаимодействия с ATA с тем, чтобы у вас сложилось представление о том, как выглядит эта лента в стиле социальных сетей. Этот снимок экрана был взят из демонстрации Microsoft, когда они намеренно украли квитанцию (ticket) Kerberos некого пользователя, а затем применили её в другом компьютере, чтобы получить доступ к неким конфиденциальным файлам, к которым имеет возможность доступа только Деми Альбуз. Хотя ATA и не прекратила эти действия, он немедленно - я имею в виду в течении нескольких секунд - выдал предупреждение внутри данного канала чтобы отобразить данную Pass-the-Ticket Attack (Атаку передачи квитанции):

Вот другой пример, в котором пользователь Альмета Уитфилд внезапно получила доступ к 16 компьютерам, которыми никогда не пользовалась, с вывешиванием другого большого красного флага о том что в её учётной записи пользователя случилось нечто:

В то время как ATA является локальным решением на площадке, его замена обитает в облачном решении. Новым домом для технологии данного типа выступает Microsoft Defender for Identity, естественно, размещаясь внутри сред Microsoft Azure и M365. Defender for Identity не всегда носил такое название {Прим. пер.: Microsoft умеет удивлять!} и вы до сих пор сможете находить документацию об этой технологии, отмечаемой как Azure Advanced Threat Protection, именем для того, что должно было бы напрямую заменить ATA, прежде чем Microsoft спихнула эти возможности под зонтик Defender.

Всё ещё находящиеся в Интернете сведения для ATA и дальнейшие обучающие материалы можно найти здесь. {Прим. пер.: Их перевод на русский.}

За дополнительными сведениями по новому Microsoft Defender for Identity, хорошим стартом послужит эта ссылка. {Прим. пер.: Её перевод на русский.}

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

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

Все ли ваши специалисты ИТ имеют права администратора домена в день их приёма на работу? Есть ли у кого-нибудь из ваших ИТ- специалистов доступ к встроенному паролю учётной записи администратора домена? У вас есть постоянные пользователи, чьи учётные записи имеют права администратора на своих компьютерах? Вы знаете, к чему я веду - всё это ужасные идеи!

К сожалению, это всё было существующим положением дел на протяжении многих лет почти в каждой сети, и эта тенденция сохраняется в наши дни. Я до сих пор постоянно наблюдаю, как инженеры используют учётную запись администратора домена для многих задач при настройке новых серверов. Это означает, что они не только имеют доступ к потенциально самой важной учётной записи в вашей сети и применяют её для повседневных задач, но также означает что всё настраиваемое с этой учётной записью пользователя, не обладает подотчётностью. Что я под этим подразумеваю? Когда я настраиваю новый сервер или изменяю существующий сервер, применяя учётную запись общего администратора, в конечном итоге я вызываю некий вид какой-то большой проблемы, поскольку никто не сможет доказать, что именно я это и сделал. Применение обобщённых учётных записей пользователей - верный способ снять ответственность в случае, когда что-то идёт не так. Я не пытаюсь иметь в виду то, что вы всегда в поиске "кто это натворил?" Но если я что- то испорчу в сервере приложений, которым обычно не занимаюсь, было бы неплохо, если бы те ребята, которые пытаются это исправить легко могли понять что это был я, и пришли бы спросить что же я именно наделал, чтобы они могли вернуть это на место. Есть много причин, по которым применение встроенной учётной записи администратора должно быть запрещено нам всем.

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

Эта идея идёт прицепом к предыдущей, причём я даже начал применять её на всех домашних компьютерах, которые я устанавливал для друзей и членов семьи. На самом деле это сводится к следующему: применять две различные учётные записи пользователей. Одну с административным доступом, а другую без. Когда вы входите в систему для выполнения повседневных задач и дел, убедитесь что вы входите в систему с обыкновенной учётной записью пользователя, которая не имеет прав администратора, причём не на локальном компьютере, ни в домене. Тем самым, если вы попробуете что- то установить или нечто устанавливается самостоятельно, вам будет предложен блок UAC (User Account Control, Контроля учётных записей), прося вас ввести имя пользователя с правами администратора и его пароль прежде чем позволить такой программе установки выполнить что либо. Я могу сообщить вам, что это работает, так как я позволял некоторым вирусам на моём собственном компьютере устанавливать себя, когда просматривал Интернет, чтобы провести исследование для того или иного проекта. Если я получаю приглашение UAC на ввод пароля администратора, я не щёлкаю по некому файлу установщика, потому что я знаю что мне это не нужно делать. Всё что мне требуется сделать, так это нажать No и этот установщик не заполучит мой компьютер. С другой стороны, если это именно то что я намерен установить, то ввод пароля моей учётной записи с правами администратора будет наименьшим неудобством и это позволит продолжать работу.

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

Если вы желаете развить обсуждаемую идею раздельных учётных записей ещё дальше, вы можете сделать свою практику работы с компьютерами ещё более безопасной, применяя всеми вместе некий обособленный компьютер для выполнения задач административного уровня. Один компьютер для обычных задач опытного пользователя, а другой компьютер для административных задач. Это несомненно поможет вам сохранять вашу систему администрирования в безопасности, а также те удалённые системы, к которым она должна выполнять доступ. И хотя иметь на своём рабочем столе два компьютера кажется обременительным, помните, что для большинства SKU в Windows 10 мы способны запускать Hyper-V прямо в своих настольных компьютерах.

Я на самом деле поступаю так со своим собственным компьютером. У меня имеется компьютер под управлением Windows 10, а затем, уже внутри него я запускаю через Hyper-V я запускаю виртуальную машину для выполнения всех административных задач на чувствительных серверах. Тем самым компромисс с моей повседневной ОС не требует компромисса со всей моей средой.

Также вы можете воспользоваться этой идеей в обратном порядке. Когда вам требуется проверить какое- то новое программное обеспечение, функциональную возможность или ссылку, вы можете развернуть ВМ в Hyper-V на своей рабочей станции, удерживая её отключённой от каких бы то ни было сетевых сред с тем, чтобы она прибывала в изолированной программной среде (sandbox) и тестировать любые новые или схематичные моменты, которые вам надлежит проверить. Если оно бомбит вашу ВМ, ничего страшного. Просто удалите эту ВМ и создайте новую. {Прим. пер.: на самом деле, начиная с обновления 1903 Windows в мае 2019 Microsoft поддерживает эту функциональную возможность как самостоятельную, подробнее...}

Если вы решите разделить административный доступ на уровне учётной записи пользователя или на уровне компьютера, запомните такое простое правило: никогда не выполняйте задачи администрирования Active Directory с того же самого места, с которого вы просматриваете Facebook. Я полагаю, что это достаточно хорошо подводит общий итог.

Похоже, и ежу понятно что все люди делают это. За работой в серверах мы проводим целые дни, причём очень часто приходится обращаться к веб- браузеру чтобы что- то проверять. Поскольку в серверах Windows имеется Edge и Internet Explorer, порой проще и быстрее проверить всё что нам требуется с самой консоли сервера, нежели возвращаться к обратно к своему рабочему столу. Удерживайтесь от соблазна! Очень легко наткнуться на плохие вещи в Интернете, в особенности работая с сервера, поскольку если какие- то машины в нашей сетевой среде и работают без антивирусной защиты, то скорее всего это происходит именно на стороне серверов. То же самое и относительно интернет- фильтрации. мы всегда следим за тем, чтобы обмен клиента проходил через наш корпоративный сервер посредника (прокси, если он у нас имеется), но нас не всегда беспокоит перемещается ли обмен нашего сервера тем же образом.

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

Сама фраза Role-Based Access Control (RBAC, Управление доступом на основе ролей) не ограничивается исключительно средами Microsoft. Это также не некая конкретная технология, которая может применяться внутри Windows Server 2022, а вместо этого оно представляет некую идеологию, которая целиком посвящена разделению заданий для ролей и обязанностей.

Когда мы рассматриваем разделение ролей своих сотрудников с точки зрения ИТ, мы обычно мыслим в терминах групп Active Directory. Хотя добавление учётной записи пользователя в группы и разрешает множество проблем относительно расщепления уровней полномочий и доступа, при таком образе мышления может быть осложнён рост, и в конечном итоге группы AD предоставляют администраторам доступ к самим группам. Технологии RBAC делят роли на ином уровне, заботясь не только о полномочиях. RBAC больше сосредотачивается на описании заданий сотрудников, нежели на ограничениях доступа. Существует множество различных технологий, которые получают преимущества от интегрированного в них инструментария RBAC, что делает их чрезвычайно распространёнными по всей вашей организации и не ограничивает работу границами отдельного домена или леса.

Великолепным примером технологии RBAC, который содержится в Windows Server 2022, выступает Just Enough Administration (JEA), являющийся частью PowerShell. JEA предоставляет вам некий способ выделения особого привилегированного доступа для тех людей, причём без предоставления им прав администратора, которые требовались ранее для выполнения тех же самых обязанностей. Такая потребность в добавлении кого- то в имеющуюся группу администраторов в неком сервере с тем, чтобы он мог выполнять свои задания всё ещё достаточно распространена, однако JEA является самым первым шагом прочь от такой необходимости.

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

Фактически, если пользователь работает в рамках контекста JEA PowerShell, и он пытается вызвать некий командлет, который не входит в часть допустимых командлетов, PowerShell притворяется что он даже и не распознаёт такой командлет. Он не сообщает извините, я не могу этого сделать - он игнорирует такую команду! Это несомненно позволяет удерживать посторонние пальцы от банки с печеньем, которую вы не желаете делить.

Вот некий образец ситуации, который поможет с портретом возможностей JEA. Возможно,вы являетесь администратором DNS и порой вам может потребоваться перезапускать службы DNS. Поскольку мы внедряем менталитет JEA/ RBAC,у вас не будет прав администратора в ОС данного сервера, но у вас будут права на уровне JEA в PowerShell чтобы вы имели возможность запускать инструменты, которые требуются для вашей работы. Перезапуск службы DNS требует доступ для применения командлета Restart-Service, так? Но разве это не означает,что я смог бы перезапустить в этом сервере любую службу и потенциально мог бы делать все виды тех действий, которые мне не требуются? JEA даже обладает достаточной мощность чтобы справиться и с таким сценарием. При настройке уровня доступа, который должен получить такой пользователь, вы даже имеете возможность погружаться в отдельные командлеты и разделять полномочия. В нашем примере вы могли бы предоставить такому пользователю доступ к командлету Restart-Service, но при этом разрешить перезапуск лишь определённых служб, например тех, которые относятся к DNS. Если этот пользователь испробует Restart-Service для WINrm, он получит отказ.

Всякий инженер ИТ знаком с применением RDP для Windows Server и, скорее всего, именно это тот подход, при помощи которого вы наиболее часто контролируете серверы в своей среде. Любой достойный этого звания хакер также знает об этом и обязан понимать, что всякая машина Windows в отдельности, будь то рабочая станция клиента, или сервер, по умолчанию выполняют ожидание по порту 3389 для протекания через них соединений RDP. На что указывает данное утверждение? Если злоумышленник получил доступ к компьютеру в вашей сетевой среде, у него имеются очень быстрые и простые средства для обнаружения имён серверов в вашей сетевой среде. Они могут немедленно попытаться подключиться к вашим серверам через RDP, просто вводя имея такого сервера и применяя порт по умолчанию 3389. Если они уже получили учётные данные в вашей сетевой среде, потенциально, они способны получить доступ ко всем вашим критически важным серверам в течение нескольких секунд после входа в вашу среду.

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

Не превратится ли это в нечто обременительное и раздражающее вашу команду ИТ, когда им теперь придётся документировать или запоминать все эти разнообразные номера портов? Вы готовы держать пари, что это будет именно так. Но также это будет обременять и раздражать и ваших врагов, а в этом- то и смысл.

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

Давайте продемонстрируем. RDP включён в моём сервере WEB1. В настоящий момент я могу запросто подключаться к нему открывая MSTSC.EXE, набирая WEB1 и щёлкая по Connect. После ввода учётных данных, я немедленно подключаюсь к WEB1 и управляю его интерфейсом. Средство удалённого доступа к рабочему столу, RDP (Remote Desktop Connection, а именно, MSTSC) достаточно сообразительно чтобы знать, что когда я не определяю номер порта совместно с именем своего сервера, я полагаю по умолчанию пользоваться для подключения портом 3389. Для изменения того номера порта, который WEB1 применяет для ожидания подключений RDP, мне необходимо внести изменения в реестр и посетить следующий ключ:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ Terminal Server\WinStations\RDP-Tcp
 	   

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

Всё что вам потребуется сделать, это ввести новый номер порта (убедитесь что он не применяется пока вашим сервером, воспользовавшись просмотром вывода команды netstat) с последующим перезапуском своего сервера. {Прим. пер.: не совсем всё, так как требуется ещё разрешить этот порт RDP в межсетевом экране Windows.} Теперь, когда мой сервер WEB1 вернулся в строй и работает, вы можете наблюдать на приводимом ниже снимке экрана что я не способен больше создавать соединение RDP к WEB1 просто воспользовавшись именем этого сервера; теперь мне приходится для создания такого подключения вручную определять номер используемого мной порта (4095).

{Прим. пер.: Изменить номер порта в удалённом компьютере можно и через PowerShell:}

# открываем удалённый сеанс
PS C:\Windows\Sytem32\> Enter-PSSession –ComputerName <имя компьютера>
# проверяем наличие в реестре ключа для RDP
[<имя компьютера>]: PS C:\Users\<имя пользователя>\Documents> Get-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-TCP"
# создаём ключ с номером порта, если он не существует
[<имя компьютера>]: PS C:\Users\<имя пользователя>\Documents> New-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-TCP" -Name PortNumber -PropertyType DWORD -Value 3389 -Force
# или устанавливаем значение номера порта
[<имя компьютера>]: PS C:\Users\<имя пользователя>\Documents> Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-TCP" -Name PortNumber -PropertyType DWORD -Value 3389 -Force
# проверяем значение номера порта RDP
[<имя компьютера>]: PS C:\Users\<имя пользователя>\Documents> Get-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-TCP" -Name PortNumber
# перезапускаем компьютер для применения настроек
Restart-Computer –ComputerName <имя компьютера>
		

{Прим. пер.: Работа с правилами для порта RDP в межсетевом экране Windows через PowerShell:}

# открываем удалённый сеанс
PS C:\Windows\Sytem32\> Enter-PSSession –ComputerName <имя компьютера>
# выводим установленные по умолчанию правила для портов RDP
[<имя компьютера>]: PS C:\Users\<имя пользователя>\Documents> Get-NetFirewallRule -Name "RemoteDesktop-UserMode*" | Format-Table -Property Name, {Name='Protocol';Expression={($PSItem | Get-NetFirewallPortFilter).Protocol}}, {Name='LocalPort';Expression={($PSItem | Get-NetFirewallPortFilter).LocalPort}}, {Name='RemotePort';Expression={($PSItem | Get-NetFirewallPortFilter).RemotePort}}, {Name='RemoteAddress';Expression={($PSItem | Get-NetFirewallAddressFilter).RemoteAddress}}, Enabled,Profile,Direction,Action
# Проверяем наличие правил, содержащих в отображаемом названии символов RDP
[<имя компьютера>]: PS C:\Users\<имя пользователя>\Documents> Get-NetFirewallRule -DisplayName "*RDP*"
# если такие имеются, выводим сведения о них
[<имя компьютера>]: PS C:\Users\<имя пользователя>\Documents> Get-NetFirewallRule -DisplayName "*RDP*" | Format-Table -Property Name, {Name='Protocol';Expression={($PSItem | Get-NetFirewallPortFilter).Protocol}}, {Name='LocalPort';Expression={($PSItem | Get-NetFirewallPortFilter).LocalPort}}, {Name='RemotePort';Expression={($PSItem | Get-NetFirewallPortFilter).RemotePort}}, {Name='RemoteAddress';Expression={($PSItem | Get-NetFirewallAddressFilter).RemoteAddress}}, Enabled,Profile,Direction,Action
# определим диапазоны портов, для которых разрешён доступ RDP
[<имя компьютера>]: PS C:\Users\<имя пользователя>\Documents> $ips = @("192.168.1.10-192.168.1.20", "192.165.2.122-192.168.2.144", "10.10.0.0/16")
# Разрешаем входящий RDP для заданных ранее диапазонов портов 
[<имя компьютера>]: PS C:\Users\<имя пользователя>\Documents> New-NetFirewallRule -DisplayName "AllowRDP" –RemoteAddress $ips -Direction Inbound -Protocol TCP –LocalPort 4095 -Action Allow
# проверяем настройку межсетевого экрана для заданного нами правила
[<имя компьютера>]: PS C:\Users\<имя пользователя>\Documents> Get-NetFirewallRule -DisplayName "AllowRDP" | Format-Table -Property Name, {Name='Protocol';Expression={($PSItem | Get-NetFirewallPortFilter).Protocol}}, {Name='LocalPort';Expression={($PSItem | Get-NetFirewallPortFilter).LocalPort}}, {Name='RemotePort';Expression={($PSItem | Get-NetFirewallPortFilter).RemotePort}}, {Name='RemoteAddress';Expression={($PSItem | Get-NetFirewallAddressFilter).RemoteAddress}}, Enabled,Profile,Direction,Action
# закрываем удалённый сеанс
[<имя компьютера>]: PS C:\Users\<имя пользователя>\Documents> Remove-PSSession
		

Мы все знаем, как применять RDP в серверах, и я уверен, что 99% всех, кто читает это применяет RDP для подключения к серверам большую часть дней в неделю. Выполнение этого внутри корпоративной сети является быстрым и простым способом взаимодействия с серверами, и применение данной технологии имеет большой смысл. Вы когда-нибудь задумывались о возможности разрешить доступ RDP через Интернет? Было бы неплохо, если бы вы могли просто открыть MSTSC на своём домашнем компьютере и прыгнуть прямо на свои серверы без необходимости сначала устанавливать громоздкий VPN? Вы сделали это? У вас есть серверы, в которых прямо сейчас настроены правила NAT в вашем межсетевом экране, чтобы вы могли подключиться к определённому порту при помощи RDP из любой точки мира, и осуществить RDP напрямую в ваш сервер?

ОСТАНОВИТЕ ЭТО ПРЯМО СЕЙЧАС!

Выключите порт, удалите правило NAT, не проходите Go, не собирайте $200.

Это абсолютно наихудшая идея, и тем не менее я постоянно обнаруживаю такие правила NAT. Я часто работаю с новыми компаниями, поддерживая различные части их инфраструктуры, и при обнаружении таких сетей клиентов мы всегда проверяем правила межсетевого экрана. Поистине удивительно, как много мест в мире имеют доступ RDP к серверам, открытым для всего Интернета.

Теперь, возможно, вы говорите себе: "Конечно, я этого не делаю! Ну да, но я хитрый и применяю необычные номера портов для такого доступа. Вы, конечно, не найдёте RDP порт 3389 открытым на моем межсетевом экране, потому что я настроил свои правила NAT так, чтобы вам приходилось подключаться к таким сумасшедшим вещам, как порты 33343 и 5896; такие никто никогда не найдёт. Я удивлён, что вы вообще спрашиваете нас об этом, Джордан, ведь две страницы назад вы показали нам, как изменить наши RDP-порты!"

Вы ошибаетесь.

Здесь мы говорим об Интернете. Мы говорим о тысячах 12-летних поклонников Minecraft с абсолютно бесконечным количеством свободного времени. О нет, возможно, я только что обидел любого "профессионального хакера", читающего эти строки. Извини, но мне наплевать.

Не имеет значения, будет ли вашим внешним портом 3389 или 12345, или любой иной. У злоумышленников имеются сканеры портов, которые могут запросто найти любые открытые каналы RDP; применяющий эти каналы порт RDP для них не имеет значения.

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

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

Удалите такие правила межсетевого экрана и немедленно загасите его, а после этого изучите лучший способ удалённого доступа по протоколу RDP. Это может означать запуск VPN с вашего клиента или настройку шлюза удалённых рабочих столов в вашей среде. Шлюзы удалённых рабочих столов безопасны и я ни словом не обмолвлюсь о том, что ваши серверы шлюза удалённых рабочих столов представляют опасность, поскольку они допускают доступ RDP к внутренним компьютерам из Интернета. Именно в этом их цель и они обладают механизмами для того, чтобы превратить такое взаимодействие в безопасное.

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

Реестр Windows

IIS Crypto