Как предотвращать атаки с подменой IP-адреса
Где применять фильтрацию источников, когда строгая проверка обратного пути ломает допустимый трафик и почему аутентификация и IPv6 требуют отдельного внимания.
Проверка маршрута доставки и решение о том, кому разрешён вход, — разные задачи. Проверке источника и аутентификации нужны отдельные средства.
На стойке регистрации можно проверить, пришла ли доставка ожидаемым маршрутом. Получатель всё равно должен решить, кого впускать в здание. В сетях действует похожее разделение: сначала проверяется заявленное происхождение трафика, затем аутентифицируется доступ к сервису.
Размещайте первую проверку рядом с источником
Оператор сети знает, какие диапазоны адресов должны приходить через соединение клиента. Пакеты с несвязанным адресом источника можно отклонить там, прежде чем они пойдут дальше. Это подход проверки источника, описанный в BCP 38.
В корпоративной сети проверяйте как трафик, уходящий в Интернет, так и трафик, приходящий извне. Одна и та же граница является выходом из одной сети и входом в другую. Определяйте ожидаемые источники для каждого соединения, включая правомерно делегированные диапазоны, вместо применения одного общего правила везде.
Проверка диапазона не устанавливает личность человека, стоящего за пакетом. Она также оставляет возможность подделки внутри разрешённого диапазона. Рассматривайте её как полезный пограничный контроль, а не как удостоверение личности.
Согласуйте проверки обратного пути с реальными маршрутами
Одноадресная пересылка по обратному пути, или uRPF, сопоставляет источник пакета с маршрутной информацией. В строгом режиме входной интерфейс должен совпадать с выбранным обратным маршрутом. Это хорошо работает там, где пути предсказуемы.
Однако допустимый трафик может прийти по одному соединению, тогда как лучший обратный маршрут проходит через другое. Так бывает при асимметричной маршрутизации и в сетях с несколькими провайдерами. Строгая проверка в этом случае может отбросить допустимый трафик. RFC 3704 объясняет эти компромиссы. Подходы с учётом допустимых путей рассматривают разрешённые альтернативы; ослабленные проверки обычно спрашивают лишь, существует ли маршрут, поэтому дают более слабый тест. Выбирайте и проверяйте режим с учётом реальной топологии и отказоустойчивости.
Аутентифицируйте сервис и пользователя
Сохраняйте ограничения по адресам там, где они полезны, но не делайте их единственным доказательством личности при чувствительном доступе. Используйте корректно проверяемый TLS для веб-сервисов и подходящие аутентифицированные протоколы для администрирования и сетевых узлов. Аутентификация учётных записей и права доступа выполняют собственные задачи.
TLS 1.3 аутентифицирует сервер, может также аутентифицировать клиента и защищает трафик приложения. Он не удостоверяет каждый IP-адрес источника и не предотвращает флуд, истощающий канал. Шифрование и проверка источника защищают разные вещи.
Снижайте возможности для отражения
Если вы управляете рекурсивным DNS, ограничьте рекурсию клиентами, которых собираетесь обслуживать. Это отличается от авторитетного DNS, которому может потребоваться отвечать всему Интернету за ваши домены. RFC 5358 объясняет, почему открытая рекурсия может превратить сервер в отражатель.
Проверьте другие открытые сервисы на предмет ненужной доступности и чрезмерно больших ответов. Заранее спланируйте помощь вышестоящего провайдера при DDoS: фильтрация на собственном сервере не восстановит соединение, уже насыщенное до того, как трафик до него дошёл.
IPv6 также требует таких решений
Переход на IPv6 автоматически не включает шифрование и не предотвращает подмену источника. IPsec требует осознанной настройки и управления ключами и может использоваться с обеими версиями IP. В руководстве по эксплуатационной безопасности IPv6 описаны необходимые меры. В сети с двумя стеками оценивайте и тестируйте оба пути.
Проверяйте защиту, не ломая сервис
Запишите ожидаемые диапазоны и маршруты, протестируйте разрешённый трафик и отказоустойчивость, затем изучите отбрасывания и состояние сервиса. Система обнаружения вторжений может предупреждать о шаблонах; блокировка требует функции предотвращения или реакции оператора. Журналы должны помогать объяснить произошедшее, а не превращать заявленный источник в предполагаемую личность.
Обычному пользователю Интернета следует сосредоточиться на обновлениях, аутентифицированных соединениях и безопасности учётных записей. При необходимости спросите провайдера о фильтрации источников: исправить проверку пакетов у вышестоящей сети из браузера нельзя. Для общего контекста прочитайте, как работает поддельный источник, или какому шаблону атаки соответствует каждая мера.