IPv4, IPv6 и межсетевые экраны: проверьте пути к вашему серверу
Сервис может быть доступен через более чем одно семейство адресов и более чем один сетевой уровень. Ограничение порта IPv4 не доказывает, что тот же сервис ограничен через IPv6. Стройте проверку вокруг фактически существующих путей, включая DNS, прослушиватели, правила хостов и любые вышестоящие средства контроля.
Практический вывод
Проведите инвентаризацию обоих семейств адресов, открывайте только предполагаемые сервисы, сохраняйте управляющий трафик, необходимый сети, и проверяйте доступ извне сервера после каждого соответствующего изменения.
Начните с сервисов и адресов, а не со списка правил
Перечислите каждый публично доступный сервис, используемый им транспорт, его прослушиваемый порт и аудиторию, которой он должен быть доступен. Веб-приложение, административный интерфейс и база данных обычно требуют разной степени открытости. Зафиксируйте адреса, фактически назначенные серверу, и интерфейсы, на которых прослушивает каждый процесс. Процесс, привязанный к адресу обратной петли, имеет иную предполагаемую границу, чем процесс, прослушивающий все доступные интерфейсы.
Включите IPv4 и IPv6 в одну инвентаризацию, сохраняя при этом их адреса и обработку политик раздельными. Публичный DNS может направлять посетителей к IPv4 через запись A и к IPv6 через запись AAAA. Наличие или отсутствие одной записи не заменяет проверку самого сервиса. Тот, кто уже знает адрес, может обратиться к нему, не используя ожидаемое вами имя хоста.
HM Bastion описывает выделение IPv6 как зависящее от доступности пула адресов. Подтвердите выделение и конфигурацию для фактического сервиса, прежде чем планировать на их основе. Дополнительные параметры IPv4 не связаны с количеством открытых портов приложения: ещё один адрес не является межсетевым экраном и не заменяет аутентификацию приложения. Указывайте сетевые требования в заказе или заявке в поддержку, а не предполагайте, что определённое расположение адресов следует из названия диапазона.
Соблюдайте политику на каждом уровне, обрабатывающем трафик
Соединение может проходить через средства сетевого контроля провайдера, межсетевой экран хоста, сеть контейнера, обратный прокси и собственные проверки доступа приложения. Задокументируйте, какие уровни существуют в вашем развёртывании и кто управляет каждым из них. Два полезных средства контроля могут дополнять друг друга, но при отсутствии записей об их правилах они также могут затруднить поиск причины сбоя. Конфигурация хоста не должна зависеть от вышестоящего ограничения, которое никогда не подтверждалось.
| Уровень | Вопрос, на который нужно ответить | Полезная проверка |
|---|---|---|
| DNS и публичные адреса | Какие назначения клиенты могут обнаружить или уже знают? | Проверьте предполагаемые ответы A и AAAA |
| Прослушивающий процесс | Какие адреса и транспорты принимают соединения? | Проверьте конфигурацию службы и активные прослушиватели |
| Сетевая политика и политика хоста | Какие источники могут достичь каждой службы? | Проверьте разрешённые и запрещённые пути извне |
| Приложение | Кто может выполнить действие после подключения? | Проверьте аутентификацию и авторизацию с помощью тестовых учётных записей |
При использовании менеджера межсетевого экрана убедитесь, как он обрабатывает оба семейства IP в установленной конфигурации. Читайте документацию инструмента и дистрибутива, а не предполагайте одинаковые значения по умолчанию везде. Контейнерные платформы могут добавлять собственные правила сетевого взаимодействия и фильтрации, поэтому опубликованный порт контейнера заслуживает отдельной проверки. Не используйте видимое состояние одной привычной команды как доказательство полного пути к рабочей нагрузке.
Предпочитайте небольшую политику, соответствующую инвентаризации. Публичный веб-трафик может предполагаться из множества источников, тогда как административный доступ может иметь более узкую политику источников, где это практически возможно. Базы данных и внутренние конечные точки управления часто вообще не нуждаются в прямом публичном доступе. Сохраняйте путь восстановления доступа при изменении правил и проверьте вторую разрешённую сессию, прежде чем закрывать единственное работающее административное подключение.
Не нарушайте работу сети, пытаясь снизить поверхность атаки
IPv6 полагается на ICMPv6 для функций помимо простой проверки эхо-запросом. Общее правило, отбрасывающее весь ICMPv6, может нарушить необходимое сетевое поведение, включая обнаружение и обработку ошибок, связанных с доставкой пакетов. Рекомендации IETF по фильтрации различают типы сообщений и роли разных границ. Используйте рекомендации, подходящие для среды, а не копируйте необъяснённый набор правил, который считает каждое управляющее сообщение враждебным.
Сеть, которая работает для небольшого запроса, всё ещё может давать сбой для других размеров трафика или путей. Тестируйте реальные обмены данными приложения, а не только открытие одного порта. Сравнивайте поведение из сетей, поддерживающих нужное семейство адресов, и сохраняйте точное время и назначение при диагностике проблемы. Неудачная проверка IPv6 с клиента без работоспособного пути IPv6 мало что говорит о конфигурации приложения на сервере.
Смягчение DDoS и экспозиция служб также решают разные задачи. Смягчение может снизить атакующий трафик, тогда как политика межсетевого экрана определяет разрешённую сетевую доступность на своей границе. Ни то, ни другое не заменяет безопасные учётные записи приложений, обновления или осторожное обращение с секретами. Открытая административная панель может быть риском, даже если её потребление пропускной способности ничтожно. Проверьте, что разрешено делать авторизованному соединению после достижения службы.
Проверьте предполагаемую границу и сохраните путь отката
- Запишите текущие правила, предполагаемую политику и способ восстановления доступа.
- Внесите узкое изменение в подходящее окно обслуживания.
- Проверьте разрешённые и запрещённые соединения для каждого соответствующего семейства адресов.
- Убедитесь в работе обычного веб-сайта и необходимых внутренних зависимостей.
- Запишите итоговую политику и удалите временные диагностические исключения.
Например, после переноса административного интерфейса за ограниченный доступ убедитесь, что одобренный оператор всё ещё может подключиться, а обычный внешний путь — нет. Повторите эту проверку для каждого назначенного публичного семейства, на котором прослушивает интерфейс. Выполняйте эти проверки только в отношении систем, которые вы эксплуатируете или на тестирование которых у вас есть разрешение. Цель — проверить определённую границу, а не создавать широкие сканирования несвязанных адресов.
Возвращайтесь к инвентаризации после публикации нового приложения, включения IPv6, добавления контейнерной платформы или изменения прокси. Эти изменения могут добавить новый прослушиватель, не изменяя старый список правил очевидным образом. Краткая запись, связывающая службу, адрес, порт, владельца и разрешённую аудиторию, ускоряет будущие проверки и снижает зависимость от того, кто последним редактировал межсетевой экран.
