Глава 3. Безопасность и сетевая среда

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

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

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

Следующие шаги помогут вам включить требование сложных паролей в вашей сетевой среде:

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

Я часто наталкиваюсь на большое число сетевых сред с применяемыми в них политиками, которые запрещают встроенный WFAS (Windows Firewall with Advanced Security, Межсетевой экран Windows с Расширенной безопасностью) по умолчанию на всех их машинах. Обычно если я спрашиваю об этом причина либо неизвестна, либо "Так было всегда". Я полагаю, что это проистекает со времён Windows XP/ Server 2003 или может быть ещё более ранних, когда Межсетевой экран Windows был менее чем желанен. Поверьте мне, когда я говорю вам, что WFAS в сегодняшних операционных системах очень развит, надёжен и привносит множество преимуществ. Если желаете прекратить ненужный и злонамеренный обмен попадающий в ваш сервер. Более не смотрите за пределы этого встроенного инструмента.

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

Если вы хотите остановить нежелательный обмен в сторону своего сервера выполните следующие шаги:

Мы воспользовались Межсетевым экраном Windows с Расширенной безопасностью (WFAS) для создания пары правил блокирования нежелательного обмена, поступающего на наш сервер. Эти правила помещаются на место немедленно и их очень просто создать. ЧТо ещё лучше, так это что наши правила WFAS несомненно могут быть созданы с применением Групповой политики с тем, чтобы вам даже не нужно было прикасаться к конкретным серверам для применения правил соединения к ним. WFAS очень сильно отличается от имевшегося 10 лет назад Межсетевого экрана Windows, и если вы не применяете его сегодня, я настоятельно рекомендую чтобы вы пересмотрели своё отношение к нему.

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

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

Измените порт, по которому работает RDP! Что? Мы можем сделать это? Да, RDP по умолчанию прослушивает соединения и осуществляет их по порту TCP 3389, Клиент Удалённого рабочего стола, который устанавливается практически на всех машинах клиентов и почти везде, автоматически полагает, что ваш сервер, с которым он должен соединиться прослушивает порт 3389 и поэтому даже не определяет никакой порт при попытке осуществить соединение. В клиенте даже нет никакого поля для его определения. Поэтому достаточно редко я общаюсь с людьми (даже с персоналом ИТ), которые знают, что порт 3389 является значением по умолчанию. Допустим, мы имели бы возможность изменить такой 3389 на нечто другое, что- то по нашему собственному выбору, я полагаю, что это было бы грандиозным делом по удержанию людей вдали от наших систем. Допустим, у нас имеется чувствительный сервер, доступ к которому мы хотим свести к минимуму. Давайте сменим его порт RDP на какой- то известный только нам, может быть на порт 4822. Это сдержит как- то от доступа к нему. {Прим. пер.: неплохо также вместе с этим задать правила защиты от сканирования портов - например, их последовательного перебора - в вашей сетевой среде.}

Эту работу выполнит любая машина Windows Server 2016. Мы собираемся настроить индивидуальный порт RDP на WEB1, а затем мы собираемся проверить доступ к нему с некоторой машины клиента Windows 10.

Для изменения имеющегося значения порта RDP на выбранное вами значение пройдите следующие этапы:

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

Исторически имелось не так много сценариев, которые требовали от серверов Windows наличия более одной сетевой платы. Это происходило по той причине, что основную часть ролей, которую они выполняли, осуществлялась в некоторой единственной сетевой среде, к которой они были подключены. Для сервера не существовало потребности прямого соединения со множеством сетевых сред, поскольку это была работа межсетевого маршрутизатора и коммутатора, так? В сегодняшнем мире Windows Server имеется множество ролей, которые могут получить преимущество от наличия группового сервера (multi-homing), что просто напросто означает, что можно применять множество NIC; роли Удалённого доступа, такие как DirectAccess и VPN рекомендуют применять установку с двумя NIC, причём вы даже можете применять некий Windows Server как обычный маршрутизатор, если пожелаете.

Я много работаю с DirectAccess и я обнаруживаю множество групповых серверов с неправильными сетевыми настройками. Данный рецепт является коллекцией моментов, которым необходимо следовать при настройке Windows Server со множеством NIC чтобы обеспечить гарантированным поток обмена в том виде, как вы его ожидаете видеть.

Для данной работы вам всего лишь необходим работающий Windows Server 2016. У нас имеются два NIC, установленные в данном сервере и они подключены к различным сетевым средам. Я подготавливаю сервер Удалённого доступа (Remote Access), который будет находиться здесь, поэтому у меня есть один NIC, подключённый к моей внутренней корпоративной сетевой среде, в то время как другой NIC подключён к Всемирному Интернету.

Для настройки Windows Server со множеством NIC выполните следующий процесс:

Любой может сделать свой сервер способным к групповому доступу (multi-home), простым подключением двух NIC к двум различным сетевым средам. Самая замысловатая часть состоит в том, чтобы гарантировать надлежащую настройку таких NIC и самой операционной системы с тем, чтобы сетевой обмен постоянно протекал в верном направлении. Следуя данному перечню правил создаст вам основательный фундамент для того, чтобы строить такие типы сценариев и понимать что вы делаете с тем, чтобы всё происходило как нужно. Отклонение от этих правил будет иметь результатом непредсказуемое поведение, что порой не является достаточно очевидным. Это может привести в дальнейшем вашем пути к очень обескураживающим поискам неисправностей.

С рецептом Добавление статической маршрутизации в таблицу маршрутизации вашего Windows

Данный рецепт выводит нас на поля, вспаханные в нашей предыдущей теме. Если вы никогда не работали с сервером, который применяет более одного NIC, тогда, скорее всего, у вас никогда не было причины соприкасаться с таблицей маршрутизации Windows. Те минуты, которую вы потратите на выполнение задачи с настройкой некоторого нового сервера, которому необходимо быть подключённым ко множеству сетевых сред, либо продраться сквозь некую ситуацию, в которой вам необходимо отыскать проблему в подобной системе, они несомненно станут критически важной информацией, которую необходимо всегда иметь в своём заднем кармане. {Прим. пер.: Вспоминается наставление на сборах пожилого генерала юным лейтенантам, только что призванным в Военную академию. Он достал из своего заднего кармана галифе с широкими лампасами солидный свёрток туалетной бумаги.}

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

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

В нашем примере имеющийся Внутренний NIC подключается к имеющейся сетевой среде 10.0.0.x. Так как он имеет непосредственное подключение к данной сетевой среде, он автоматически способен надлежащим образом осуществлять взаимодействие с прочими серверами, которые располагаются в данной подсети. Поэтому если сервер VPN имел адрес 10.0.0.5, и у нас имелся Контроллер домена, работающий по адресу 10.0.0.2, у нас будет возможность взаимодействовать с таким Контроллером домена без какой- либо дополнительной настройки. Однако большая часть компаний имеет множество подсетей внутри своих сетевых сред. Поэтому что если нашим пользователям VPN необходимо связаться с веб сервером, который располагается в нашей сетевой среде 10.0.1.x? Когда обмен достигает вашего сервера VPN, который осуществляет поиск получателя 10.0.1.8, такой VPN сервер проверит свою локальную таблицу маршрутизации и обнаружит, что у него не имеется никакой записи для вашей сетевой среды 10.0.1.x. Так как он не знает что ему делать с таким запросом, он отправит его в свой Шлюз по умолчанию, который отправит все такие пакеты обратно во Внешний NIC. Эти пакеты не имеют правильного получателя, которого они могли бы достичь через данный Внешний NIC, который подключён ко Всемирному Интернету, и поэтому такой обмен получит отказ.

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

Мы устанавливаем некий новый сервер VPN Windows Server 2016. Уэтого сервера имеются два установленных NIC, причём один подключён ко Всемирному Интернету, а другой подключается ко внутренней сетевой среде. Внутри нашей корпоративной сетевой среды имеются две подсети. А именно, 10.0.0.x (/24), к которой подключён наш Внутренний NIC и 10.0.1.x (/24), в которой расположены наши веб- серверы. Безусловно, между этими двумя Внутренними подсетями имеется некий маршрутизатор, который делает возможным обмен потоками данных между этими двумя. IP адрес такого маршрутизатора имеет значение 10.0.0.254. Если бы у нас была возможность настроить некий Шлюз по умолчанию в данном Внутреннем NIC нашего сервера VPN, он был бы установлен в значение 10.0.0.254 и весь обмен осуществлялся бы без всякого дальнейшего участия. Однако, поскольку наш сервер VPN является групповым (multi-homed), а может иметься только один Шлюз по умолчанию, который мы настроили на Внешнем NIC, нам необходимо сообщить данному серверу как ему перемещать обмен 10.0.1.x через 10.0.0.254 применяя его Внутренний NIC.

Итак, по существу, нам необходимо сделать следующее, чтобы создать некий статический маршрут в нашем сервере VPN:

Теперь у нас имеется вся информация, необходимая для того чтобы собрать её вместе в наш оператор маршрута и связать его с нашим Внутренним NIC. Общий формат, который должен иметь наш оператор добавления маршрута таков route add -p <subnet> mask <mask> <gateway> if <interfaceID>. Часть -p данной команды очень важна, так как именно она делает данный маршрут постоянным (persistent). Без части -p наш новый маршрут исчез бы после перезагрузки.

Итак, чтобы сообщить серверу VPN как отправлять обмен в нашу новую подсеть 10.0.1.x, о которой мы только что говорили, наша конкретная команда такова:

route add -p 10.0.1.0 mask 255.255.255.0 10.0.0.254 if 4
 	   

Эта команда сообщает серверу о необходимости добавления постоянного маршрута для сетевой среды 10.0.1.0/24, направляя этот сетевой обмен через шлюз 10.0.0.254 и связывая этот маршрут с NIC идентификатором 4, который является нашим Внутренним сетевым интерфейсом.

В групповом сервере только один NIC будет иметь Шлюз по умолчанию. Таким образом, все подсети, к которым нам необходим доступ через прочие интерфейсы должны быть определены специальным образом. Пока мы не добавили такой новый маршрут, данный сервер никак не мог взаимодействовать с имеющейся у нас сетью 10.0.1.0. Это было обусловлено тем, что имеющаяся таблица маршрутизации не имела никакой информации о данной подсети, поэтому всякий возникающий к ней обмен отправлялся в Шлюз по умолчанию, который находится во Внешнем NIC, подключённом к Всемирному Интернету. Добавив некий статический маршрут в свой сервер, мы теперь определили путь маршрута для данного сервера, который необходимо выбрать отмену, который должен достичь 10.0.1.x.

Если в вашей сетевой среде имеется множество подсетей, вам может понадобиться охватить их все неким оператором накрывающего маршрута. Накрывающий маршрут (blanket route) также имеет названия агрегирующего или суперсетевого маршрутов. Это может сберечь ваше время, необходимое для установки нового оператора маршрута для каждого без исключения маршрута ваших сетевых сред. Например, если у вас имеется множество сетевых сред 10.нечто и вы желаете проходить к ним всем через наш Внутренний NIC, мы могли бы выполнить это единым оператором маршрута следующим образом:

Route add -p 10.0.0.0 mask 255.0.0.0 10.0.0.254 if 4
 	   

Такой маршрут будет отправлять весь обмен 10.x.x.x через наш Внутренний NIC. Будете ли вы накрывать свои маршруты как в данном случае, либо устанавливать каждый маршрут индивидуально, для самого сервера это не имеет никакого значения, поскольку его таблица маршрутизации содержит информацию о том, куда посылать те пакеты, которые необходимо обработать.