что такое сетевая инфраструктура на ноутбуке
Построение сетевой инфраструктуры на базе Nebula. Часть 1 — задачи и решения
В статье пойдет речь о проблемах организации сетевой инфраструктуры традиционным способом и о методах решения тех же самых вопросов при помощи облачных технологий.
Для справки. Nebula — облачная среда SaaS для удаленного поддержания сетевой инфраструктуры. Все устройства, поддерживающие Nebula, управляются из облака через безопасное соединение. Можно управлять крупной распределенной сетевой инфраструктурой из единого центра, не затратив усилия по его созданию.
Для чего нужен очередной облачный сервис?
Основная проблема при работе с сетевой инфраструктурой — это не проектирование сети и закупка оборудования, и даже не монтаж в стойку, а все то остальное, что с этой сетью в дальнейшем предстоит делать.
Сеть новая — заботы старые
При вводе в эксплуатацию нового узла сети после монтажа и подключения оборудования начинается первоначальная настройка. С точки зрения «большого начальства» — ничего сложного: «Берем рабочую документацию по проекту и начинаем настраивать. » Это так здорово говорится, когда все сетевые элементы стоят в одном ЦОД. Если же они разбросаны по филиалам, начинается головная боль с обеспечением удаленного доступа. Такой вот замкнутый круг: чтобы получить удаленный доступ по сети, нужно настроить сетевое оборудование, а для этого нужен доступ по сети.
Приходится придумывать различные схемы для выхода из вышеописанного тупика. Например, ноутбук с доступом в Интернет через USB 4G модем подключается через патчкорд к настраиваемой сети. На этом ноутбуке поднимается VPN клиент, и через него сетевой администратор из штаб-квартиры пытается получить доступ к сети филиала. Схема не самая прозрачная — даже если привезти ноутбук с заранее настроенным VPN на удаленную площадку и попросить его включить, далеко не факт что всё заработает с первого раза. Особенно если речь о другом регионе с другим провайдером.
Получается, самый надежный способ — держать «на другом конце провода» хорошего специалиста, который сможет настроить свою часть согласно проекту. Если такого в штате филиала не имеется, остаются варианты: либо аутсорсинг, либо командировка.
Ещё нужна система мониторинга. Её требуется установить, настроить, обслуживать (хотя бы следить за местом на диске, и регулярно делать резервные копии). И которая ничего не знает о наших устройствах, пока мы ей не сообщим. Для этого нужно прописать настройки для всех единиц оборудования и регулярно следить за актуальностью записей.
Замечательно, когда в штате есть свой «человек-оркестр», который, помимо специфических знаний сетевого администратора, умеет работать с Zabbix или с другой аналогичной системой. В противном случае берем ещё одного человека в штат или отдаем на аутсорсинг.
Примечание. Самые печальные проколы начинаются со слов: «Да что там этот Zabbix (Nagios,OpenView и т.д.) настраивать? Я сейчас вот его быстренько подниму и готово!»
От внедрения к эксплуатации
Рассмотрим конкретный пример.
Получено тревожное сообщение о том, что где-то не отвечает точка доступа WiFi.
Разумеется, у хорошего сетевого администратора есть свой личный справочник, в котором всё записано. Вопросы начинаются, когда этой информацией нужно делиться. Например, надо срочно послать гонца, чтобы разобраться на месте, а для этого нужно выдать что-то вроде: «Точка доступа в бизнес-центре на улице Строителей, дом 1, на 3-м этаже, кабинет N 301 рядом с входной дверью под потолком».
Допустим, нам повезло и точка доступа питается через PoE, а коммутатор позволяет её перезагрузить удаленно. Ехать не надо, но нужен удаленный доступ до коммутатора. Остается настроить проброс портов через PAT на маршрутизаторе, разобраться с VLAN для подключения извне и так далее. Хорошо, если все настроено заранее. Работа, может, и не сложная, но делать нужно.
Итак, точку по питанию перезагрузили. Не помогло?
Допустим, что-то не так в аппаратной части. Теперь ищем информацию о гарантии, начале эксплуатации и других интересующих деталях.
Кстати о WiFi. Использование домашнего варианта WPA2-PSK, в котором один ключ на все устройства — в корпоративной среде не рекомендуется. Во-первых, один ключ на всех — это попросту небезопасно, во-вторых, когда один сотрудник увольняется, то приходится менять этот общий ключ и заново выполнять настройки на всех устройствах у всех пользователей. Чтобы избежать подобных неприятностей, существует WPA2-Enterprise с индивидуальной аутентификацией для каждого пользователя. Но для этого нужен RADIUS сервер — ещё одна инфраструктурная единица, которую надо контролировать, делать резервные копии и так далее.
Обратите внимание, на каждом этапе, будь то внедрение или эксплуатация, мы пользовались вспомогательными системами. Это и ноутбук со «сторонним» выходом в Интернет, и система мониторинга, и справочная база по оборудованию, и RADIUS как система аутентификации. Помимо сетевых устройств, приходится обслуживать ещё и сторонние сервисы.
В таких случаях можно услышать совет: «Отдать в облако и не мучиться». Наверняка есть облачный Zabbix, возможно где-то есть облачный RADIUS, и даже облачная база данных, чтобы вести список устройств. Беда в том, что это нужно не порознь, а «в одном флаконе». И всё равно встают вопросы организации доступа, первоначальной настройки устройств, безопасности и многое другое.
Как это выглядит при использовании Nebula?
Разумеется, первоначально «облако» ничего не знает ни о наших планах, ни о приобретенном оборудовании.
Сперва создается профиль организации. То есть вся инфраструктура: штаб-квартира и филиалы вначале прописывается в облаке. Указываются реквизиты, создаются учетные записи для делегирования полномочий.
Зарегистрировать используемые устройства в облаке можно двумя способами: по старинке — просто вписав серийник при заполнении веб-формы или отсканировав QR-код при помощи мобильного телефона. Всё что нужно для второго способа — смартфон с камерой и доступом в Интернет, в том числе через мобильного провайдера.
Разумеется, необходимую инфраструктуру для хранения информации, как учетной, так и настроек предоставляет Zyxel Nebula.
Рисунок 1. Отчет безопасности Nebula Control Center.
А что с настройкой доступа? Открытием портов, пробросом трафика через входящий шлюз, всем тем, что администраторы безопасности ласково называют: «наковырять дырок»? К счастью, этого всего делать не нужно. Устройства под управлением Nebula устанавливают исходящее соединение. И администратор для настройки подключается не к отдельному устройству, а к облаку. Nebula выступает посредником между двумя соединениями: с устройством и с компьютером сетевого администратора. Это означает, что этап с вызовом приходящего админа можно свести к минимуму, либо пропустить вовсе. И никаких дополнительных «дырок» на файрволе.
А как же RADUIS сервер? Ведь нужна какая-то централизованная аутентификация!
И эти функцию тоже берет на себя Nеbula. Аутентификации учетных записей для доступа к оборудования идет через защищенную базу данных. Это сильно упрощает делегирование или изъятие прав по управлению системой. Нужно передать права — заводим пользователя, назначаем роль. Нужно отобрать права — выполняем обратные действия.
Отдельно стоит сказать о WPA2-Enterprise, для которого нужен отдельный сервис аутентификации. У Zyxel Nebula есть собственный аналог — DPPSK, который позволяет использовать WPA2-PSK с индивидуальным ключом для каждого пользователя.
«Неудобные» вопросы
Ниже попробуем дать ответы на наиболее каверзные вопросы, которые часто задают при вхождении в облачный сервис
А это точно безопасно?
При любом делегировании контроля и управления для обеспечения безопасности важную роль играют два фактора: анонимизация и шифрование.
Использование шифрования для защиты трафика от посторонних глаз — это читателям более или менее знакомо.
Анонимизация скрывает от персонала облачного провайдера информацию о владельце и источнике. Персональная информация удаляется, а записям присваивается «безликий» идентификатор. Ни разработчик облачного ПО, ни администратор, обслуживающий облачную систему — не могут знать владельца запросов. «Откуда это пришло? Кого это может заинтересовать?», — такие вопросы останутся без ответа. Отсутствие данных о владельце и источнике делает инсайдинг бессмысленной тратой времени.
Если сравнивать данный подход с традиционной практикой передачи на аутсорсинг или найма приходящего админа — очевидно, что облачные технологии безопаснее. Приходящий ИТ специалист знает о своей подопечной организации достаточно много, и может волей или неволей нанести существенный вред в плане безопасности. Ещё надо решить вопрос увольнения или завершения договора. Иногда, помимо блокировки или удаления учетной записи, это влечет глобальную смену паролей для доступа к сервисам, а также аудит всех ресурсов на предмет «забытых» точек входа и возможных «закладок».
Насколько Nebula дороже или дешевле приходящего админа?
Всё познается в сравнении. Базовые функции Nebula доступны бесплатно. Собственно, что может быть ещё дешевле?
Разумеется, совершенно обойтись без сетевого администратора или лица, его заменяющего не получится. Вопрос в количестве людей, их специализации и распределении по площадкам.
Что же касается платного расширенного сервиса, то ставить прямой вопрос: дороже или дешевле — такой подход всегда будет неточным и однобоким. Правильнее будет сравнить множество факторов, начиная от денег на оплату работы конкретных специалистов и заканчивая затратами по обеспечению их взаимодействия с подрядной организацией или физлицом: контроль качества выполнения, составление документации, поддержание уровня безопасности и так далее.
Если же говорить на тему выгодно или не выгодно приобретать платный пакет услуг (Pro-Pack), то примерный ответ может звучать так: если организация маленькая, можно обойтись базовой версией, если организация растет, то имеет смысл подумать о Pro-Pack. Различие между версиями Zyxel Nebula можно посмотреть в таблице 1.
Таблица 1. Различия наборов функций базовой версии и версии Pro-Pack для Nebula.
Это и расширенная отчетность, и аудит пользователей, и клонирование конфигурации, и многое другое.
А что с защитой трафика?
Nebula использует протокол NETCONF для обеспечения безопасности работы с сетевым оборудованием.
NETCONF может работать поверх нескольких транспортных протоколов:
Если сравнивать NETCONF с другими методами, например, управление через SNMP — следует отметить, что NETCONF поддерживает исходящее TCP-соединение для преодоления барьера NAT и считается более надежным.
Что с поддержкой оборудования?
Разумеется, не стоит превращать серверную в зоопарк с представителями редких и вымирающих видов оборудования. Крайне желательно, чтобы оборудование, объединенное технологией управления, закрывало все направления: от центрального коммутатора до точек доступа. Инженеры Zyxel позаботились о такой возможности. Под управлением Nebula работает множество устройств:
Используя широкий спектр поддерживаемых устройств можно строить сети под различные типы задач. Особенно это актуально для компаний, которые растут не вверх, а вширь, постоянно осваивая новые площадки для ведения бизнеса.
Постоянное развитие
Сетевые устройства с традиционным методом управления имеют только один путь совершенствования — изменение самого устройства, будь то новая прошивка или дополнительные модули. В случае с Zyxel Nebula есть дополнительный путь для улучшений — через совершенствование облачной инфраструктуры. Например, после обновления Nebula Control Center (NCC) до версии 10.1. (21 сентября 2020) пользователям доступны новые возможности, вот некоторые из них:
Как взять сетевую инфраструктуру под свой контроль. Глава вторая. Чистка и документирование
Эта статья является второй в цикле статей «Как взять сетевую инфраструктуру под свой контроль». Содержание всех статей цикла и ссылки можно найти здесь.
Наша цель на данном этапе — наведение порядка в документации и конфигурации.
На выходе этого процесса у вас должен быть необходимый комплект документов и сеть, сконфигурированная в соответствии с ними.
Сейчас мы не будем говорить об аудите безопасности – этому будет посвящена третья часть.
Сложность выполнения поставленной на этом этапе задачи, конечно, сильно варьируется от компании к компании.
Идеальная ситуация – это когда
В худшем варианте у вас будет
В этом случае, от вас потребуется в том числе и умение читать мысли, потому что вам придется научиться понимать, а что же хотели сделать “дизайнеры”, восстанавливать их логику, доделывать то, что не было закончено и удалять «мусор».
И, конечно, вам нужно будет купировать их ошибки, менять (на этом этапе по возможности минимально) дизайн и изменять или создавать заново схемы.
Данная статья ни в коей мере не претендует на полноту. Здесь я опишу лишь общие принципы и остановлюсь на некоторых распространенных проблемах, которые приходится решать.
Набор документов
Ниже приведены некоторые документы, которые принято создавать в компании Cisco Systems при проектировании.
CR – Сustomer Requirements, требования клиента (тех. задание).
Создается совместно с заказчиком и определяет требования к сети.
HLD – High Level Design, высокоуровневый дизайн на основе требований к сети (CR). Документ объясняет и обосновывает принятые архитектурные решения (топология, протоколы, выбор оборудования. ). HLD не содержит деталей дизайна, например, об используемых интерфейсах и IP-адресах. Так же здесь не обсуждается конкретная конфигурация оборудования. Этот документ скорее предназначен для объяснения техническому менеджменту заказчика ключевых концепции дизайна.
LLD – Low Level Design, низкоуровневый дизайн на основе высокоуровневого (HLD).
Он должен содержать все детали, необходимые для реализации проекта, такие как, информация о том, как подключить и настроить оборудование. Это полное руководство по реализации дизайна. Этот документ должен предоставлять достаточную информацию для его реализации даже не очень квалифицированным персоналом.
Что-то, например, IP-адреса, номера AS, схема физической коммутации (cabling), может быть «вынесено» в отдельные документы, такие как NIP (Network Implementation Plan).
Построение сети начинается после создания этих документов и происходит в строгом соответствии с ними и затем проверяется заказчиком (тесты) на соответствие с дизайном.
Конечно, у разных интеграторов, у разных клиентов, в разных странах требования к проектной документации могут быть разные. Но хотелось бы избежать формальностей и рассмотреть вопрос по существу. Этот этап — не о проектировании, а о наведении порядка и нам нужен достаточный для выполнения наших задач набор документов (схем, таблиц, описаний …).
И на мой взгляд, существует некий абсолютный минимум, без которого невозможно эффективно контролировать сеть.
Это следующие документы:
Схема физической коммутации
В некоторых небольших компаниях работы, связанные с установкой оборудования и физической коммутацией (cabling) находятся в зоне ответственности сетевых инженеров.
В этом случае задача отчасти решается следующим подходом.
Но понятно, что если вы потеряете доступ к оборудованию, то вы потеряете и доступ к этой информации. К тому же таким образом вы не сможете запротоколировать такую важную информацию как что за оборудование, с какой потребляемой мощностью, с каким количеством портов, в какой стойке находится, какие там патч-панели и куда (в какую стойку/патч-панель) они скоммутированы. Поэтому все же дополнительное документирование (не только дескрипции на оборудовании) очень полезно.
Идеальным вариантом является использование приложений, созданных для работы с подобного рода информацией. Но можно ограничиться и простыми таблицами (например, в Excel) или отобразить информацию, которую вы считаете необходимой в L1/L2 схемах.
Поэтому хорошей практикой является для решения задач связанных с установкой, подключением, поддержкой работоспособности оборудования, а так же физической коммутацией иметь или выделенные отделы или выделенных людей. Обычно для дата-центров это дата-центр инженеры, а для офиса — help-desk.
Если такие подразделения предусмотрены в вашей компании, то вопросы ведения журнала физической коммутации не являются вашей задачей, и вы можете ограничиться только дескрипцией на интерфейсе и административным выключением не используемых портов.
Схемы сети
Нет универсального подхода к рисованию схем.
Самое важное — схемы должны давать понимание того, как будет ходить трафик, через какие логические и физические элементы вашей сети.
Под физическими элементами мы подразумеваем
Т. к. в современных сетях может быть много логических уровней, то возможно, хорошим (но не обязательным) подходом является делать различные схемы для различных уровней, например, в случае оверлейного подхода это могут бы следующие схемы:
Схема маршрутизации
Как минимум на этой схеме должно быть отражено
L2 схема (OSI)
На этой схеме может быть отражена следующая информация:
Характерные ошибки при проектировании
Пример плохого подхода к построению сети.
Давайте возьмем простой пример построения простой офисной локальной сети.
Имея опыт преподавания телекома студентам, могу сказать, что фактически любой студент к середине второго семестра обладает необходимым знанием (в рамках курса, который вел я) для того чтобы настроить простую офисную LAN.
Что сложного в том, чтобы подключить друг к другу коммутаторы, настроить VLAN, SVI интерфейсы (в случае L3 коммутаторов) и прописать статический роутинг?
Все будет работать.
Но при этом остаются в стороне вопросы, связанные с
Характерные ошибки дизайна уровня L1 (OSI)
Характерные ошибки дизайна уровня L2 (OSI)
Часто, когда нет хорошего понимания, как работает STP, какие потенциальные проблемы он несет с собой, коммутаторы подключаются хаотично, с настройками по умолчанию, без дополнительного тюнинга STP.
В результате часто имеем следующее
Примеры ошибок в проектировании L3 (OSI)
Несколько характерных ошибок начинающих сетевиков:
Критерии оценки качества дизайна
Когда мы говорим про оптимальность/не оптимальность, мы должны понимать с точки зрения каких критериев мы можем оценить это. Вот с моей точки зрения наиболее существенные (но не все) критерии (и расшифровка применительно к протоколам маршрутизации):
Изменения
Основной принцип на данном этапе можно выразить формулой «не навреди».
Поэтому, даже если вы не вполне согласны с дизайном, и выбранной реализацией (конфигурацией), то не всегда целесообразно делать изменения. Разумным подходом является ранжирование всех выявленных проблем по двум параметрам:
Перфекционизм на данном этапе может быть вреден. Приведите дизайн к удовлетворительному состоянию и синхронизируйте конфигурацию сети в соответствии с ним.
Сбор сведений о текущей сетевой инфраструктуре
Относится к:
Пожалуй, наиболее важным аспектом планирования Защитник Windows брандмауэра с расширенным развертыванием безопасности является архитектура сети, так как IPsec находится на уровне самого протокола Интернета. Неполное или неточное понимание сети может предотвратить успешное Защитник Windows брандмауэра. Понимание макета подсетей, схем ip-адресов и схем трафика являются частью этой работы, но для завершения этапа планирования этого проекта важно точно документировать следующие компоненты:
Сегментация сети. Это включает карты IP-адресов, показывающие, как маршрутизаторы отделяют каждый сегмент сети. Он включает сведения о настройке маршрутизаторов и о том, какие фильтры безопасности они накладывают на сетевой трафик, течет через них.
Перевод сетевых адресов (NAT). NAT — это средство разделения сегментов сети с помощью устройства, которое совмещая все IP-адреса с одной стороны устройства с одним IP-адресом, доступным с другой стороны.
Устройства сетевой инфраструктуры. Это включает маршрутизаторы, коммутаторы, концентраторы и другое сетевое оборудование, которое делает возможным взаимодействие между устройствами в сети.
Текущая модель сетевого трафика. Это включает количество и характеристики сетевого трафика, течет по сети.
Устройства системы обнаружения вторжений (IDS). Необходимо определить, есть ли в сети устройства IDS, которые могут негативно повлиять на любое шифрование, введенное в зоне шифрования.
Цель состоит в том, чтобы иметь достаточно информации, чтобы иметь возможность идентифицировать актив по расположению сети, в дополнение к его физическому расположению.
Не используйте сложную и плохо документированную сеть в качестве отправной точки для разработки, так как она может оставить слишком много неопознанных областей, которые могут вызвать проблемы при реализации.
Это руководство помогает получать наиболее релевантные сведения для планирования реализации брандмауэра Защитник Windows брандмауэра, но не пытается решить другие проблемы, такие как TCP/IP-адрес или сегментация виртуальной локальной сети (VLAN).
Сегментация сети
Если в организации отсутствует документированная и доступная для справки текущая архитектура сети, такую документацию необходимо получить как можно скорее, прежде чем продолжить разработку и развертывание. Если документированные сведения не являются актуальными или не были проверены недавно, у вас есть два варианта:
Примите, что отсутствие точной информации может привести к риску для проекта.
Предпринять проект обнаружения либо с помощью ручных процессов, либо с помощью средств сетевого анализа, которые могут предоставить сведения, необходимые для документации текущей топологии сети.
Хотя требуемая информация может быть представлена различными способами, ряд схематических схем часто является наиболее эффективным методом иллюстрации и понимания текущей конфигурации сети. При создании сетевых схем не включай слишком много информации. При необходимости используйте несколько схем, которые показывают различные уровни детализации. Используйте диаграмму верхнего уровня, которая иллюстрирует основные сайты, которые составляют сеть организации, а затем разгона каждого сайта в более подробную схему, которая фиксирует более глубокий уровень детализации. Продолжайте, пока не достигнете уровня индивидуальной подсети IP, а также средства для определения расположения сети каждого устройства в вашей организации.
В ходе этого процесса можно обнаружить некоторые сетевые приложения и службы, несовместимые с IPsec. Например, IPsec нарушает сетевую приоритетизацию и управление трафиком на основе портов и протоколов. Если управление трафиком или приоритеты должны основываться на портах или протоколе, сам хост должен иметь возможность выполнять любое управление трафиком или приоритеты.
Другие примеры несовместимости:
Cisco NetFlow на маршрутизаторах не может анализировать пакеты между участниками IPsec на основе протокола или порта.
Качество службы на основе маршрутизатора (QoS) не может использовать порты или протоколы для приоритизации трафика. Однако на использование правил брандмауэра, которые указывают IP-адреса для приоритета трафика, это ограничение QoS не влияет. Например, не работает правило «От любого, кто использует приоритеты порта 80», но правило, которое говорит «От любого до 10.0.1.10 prioritize» работает.
Взвешение справедливой очереди и других методов приоритета трафика маршрутизатора на основе потока может привести к сбойу.
Устройства, которые не поддерживают и не позволяют IP-протоколу 50, порту, который используется encapsulating Security Payload (ESP).
Списки управления доступом маршрутизатора (ACLs) не могут проверять поля протоколов и портов в зашифрованных пакетах ESP, поэтому пакеты отброшены. AcLs, основанные только на IP-адресе, переадекируются в обычном режиме. Если устройство не может разработать ESP, в пакетах ESP не будут обрабатываться все acLs, указывав правила порта или протокола. Если устройство имеет parser ESP и использует шифрование, acLs, которые указывают правила порта или протокола, не будут обрабатываться в пакетах ESP.
Средства сетевого мониторинга могут не иметь возможности для анализа пакетов ESP, которые не шифруются (ESP-Null).
Примечание: Анализатор сообщений Майкрософт может помочь в устранении неполадок незашифрованных пакетов IPsec. Последняя версия анализатора сообщений доступна в Центре загрузки Майкрософт.
Перевод сетевых адресов (NAT)
Обход IPsec NAT (NAT-T) позволяет коллегам IPsec, которые находятся за naTs, обнаруживать присутствие NATs, согласовывать ассоциации безопасности IPsec и отправлять данные, защищенные ESP, даже если адреса в пакетах IPv4, защищенных IPv4, изменяются. IPsec NAT-T не поддерживает использование AH на устройствах NAT.
Устройства сетевой инфраструктуры
Устройства, которые составляют инфраструктуру сети (маршрутизаторы, коммутаторы, балансиры нагрузки и брандмауэры), должны иметь возможность общаться с помощью IPsec после реализации решения. По этой причине необходимо изучить следующие характеристики этих сетевых устройств, чтобы убедиться, что они могут обрабатывать технические и физические требования конструкции:
Make/model. Эти сведения можно использовать для определения функций, поддерживаемых устройством. Кроме того, проверьте версию BIOS или программное обеспечение, запущенное на устройстве, чтобы обеспечить поддержку IPsec.
Количество оперативной памяти. Эта информация полезна при анализе емкости или влияния IPsec на устройство.
Анализ трафика. Полезно иметь такие сведения, как пиковое использование и ежедневные тенденции или тенденции. Эти сведения помогают предоставить базовый снимок устройства и то, как оно используется со временем. Если проблемы возникают после внедрения IPsec, информация поможет определить, связана ли корневая причина с более большим использованием устройства.
AcLs маршрутизатора, которые влияют на IPsec непосредственно. AcLs напрямую влияют на способность отдельных протоколов функционировать. Например, блокировка протокола Kerberos V5 (UDP и TCP port 88) или IP-протокола 50 или 51 не позволяет IPsec работать. Устройства также должны быть настроены для допуска трафика IKE (UDP port 500) при использовании NAT-T (UDP port 4500).
Сети и подсети, подключенные к интерфейсам устройств. Эти сведения предоставляют наилучшее представление о том, как выглядит внутренняя сеть. Определение границы подсетей, основанных на диапазоне адресов, является простым и помогает определить, являются ли другие адреса неугодными или иностранными для внутренней сети (например, IP-адреса в Интернете).
Сегментация VLAN. Определение того, как реализуются VPN в сети, поможет вам понять шаблоны трафика и требования к безопасности, а затем определить, как IPsec может увеличить или помешать этим требованиям.
Максимальный размер блока передачи (MTU) на интерфейсе устройства (ы). MTU определяет самую большую телеграмму данных, которая может передаваться на определенном интерфейсе без разделения на более мелкие части для передачи (процесс, также известный как фрагментация). В сообщениях IPsec MTU необходимо предвидеть, когда произойдет фрагментация. Фрагментация пакетов должна отслеживаться маршрутизатором для Ассоциации безопасности Интернета и протокола управления ключами (ISAKMP). IPsec настраивает размер MTU на сеансе до минимального размера MTU по используемому пути связи, а затем установите бит Don’t Fragment (DF bit) до 1.
Примечание: Если обнаружение path MTU (PMTU) включено и функционирует правильно, не нужно собирать размер MTU на интерфейсах устройств. Хотя источники, например руководство по Windows Server 2003, рекомендуют отключить обнаружение PMTU, для правильной работы IPsec необходимо включить его.
Используемая система обнаружения вторжений (IDS). Для обнаружения пакетов ESP у вашего IDS должен быть совместимый с IPsec анализ. Если у IDS нет такого анализара, он не может определить, зашифрованы ли данные в этих пакетах.
После получения этих сведений можно быстро определить, необходимо ли обновить устройства для поддержки требований проекта, изменить ALS или принять другие меры для обеспечения того, чтобы устройства могли обрабатывать необходимые нагрузки.
Текущая модель сетевого трафика
После сбора сведений об адресной и сетевой инфраструктуре следующим шагом является изучение потока сообщений. Например, если отдел, например отдел кадров (HR), охватывает несколько зданий, и вы хотите использовать изолированность сервера с шифрованием для защиты информации в этом отделе, необходимо знать, как эти здания подключены, чтобы определить уровень доверия к подключению. Надежно защищенное здание, подключенное незащищенным кабелем к другому зданию, которое не защищено, может быть скомпрометировано в результате перехвата или атаки воспроизведения информации. Если такая атака считается угрозой, IPsec может помочь, предоставляя надежные хосты надежной взаимной проверки подлинности и шифрования трафика. IPsec позволяет более безопасно общаться по ненавязаным ссылкам, таким как Интернет.
При анализе потока трафика внимательно изучите, как взаимодействуют все управляемые и неуправляющие устройства. Это включает нестандартные Windows под управлением Linux, UNIX и Macintosh. Задайте себе такие вопросы, как:
Существуют ли определенные связи на уровне порта и протокола или между этими же хостами проходит много сеансов во многих протоколах?
Как серверы и клиенты взаимодействуют друг с другом?
Существуют ли в настоящее время устройства безопасности или проекты, которые могут повлиять на развертывание изоляции? Например, если вы Защитник Windows брандмауэра на устройствах для «блокировки» определенных портов, например UDP 500, переговоры по IKE не удается.
Некоторые из наиболее распространенных приложений и протоколов являются следующими:
NetBIOS по TCP/IP (NetBT) и блоку сообщений сервера (SMB). На локальной сети обычно включены порты 137, 138 и 139 для NetBT и порта 445 для SMB. Эти порты предоставляют службы разрешения имен NetBIOS и другие функции. К сожалению, они также позволяют создавать сеансы null. Сеанс null — это сеанс, созданный на хосте, который не использует контекст безопасности известного пользователя или объекта. Часто эти сеансы являются анонимными.
Удаленный вызов процедуры (RPC). RPC работает, прослушивая порт, известный как конечный mapper, TCP port 135. Ответ на запрос в этом порту — это инструкция по началу связи с другим портом в эфемерной области (порты с номером более 1024). В сети, сегментации брандмауэров, связь RPC представляет проблему конфигурации, так как это означает открытие порта прослушивания RPC и всех портов больше 1024. Открытие такого числа портов увеличивает поверхность атаки всей сети и снижает эффективность брандмауэров. Поскольку многие приложения зависят от RPC для базовых функций, любая политика безопасности брандмауэра и подключения должна учитывать требования RPC.
Другой трафик. Защитник Windows Брандмауэр может защитить передачи между устройствами, предоставляя проверку подлинности пакетов, а также шифруя содержащиеся в них данные. Важно определить, что необходимо защитить, и угрозы, которые необходимо устранить. Изучите и смоделите другие типы трафика или трафика, которые должны быть защищены.