Кратко

  • RFC 2267 разместил проверку исходного префикса на интерфейсе провайдера, принимающем трафик клиента; допустимые для этой сети префиксы можно было задать локально.
  • В 2000 году BCP 38 закрепил эту практику как Best Current Practice. Прошедший проверку пакет указывает на сетевую границу, но не раскрывает устройство или человека за ним.

Адрес в заголовке не называл отправителя

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

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

На клиентском входе провайдер знал допустимые префиксы

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

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

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

Проверка префикса — не проверка обратного маршрута

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

Обе проверки выполняются на входе, но отвечают на разные вопросы. Тест обратного пути зависит от направления, выбранного таблицей маршрутизации; фильтр клиента сопоставляет адрес с префиксами, разрешёнными для подключённой сети. Позднее RFC 3704 рассмотрел механизмы фильтрации для многосвязных сетей и обновил RFC 2827. Строгий, допустимый и свободный режимы RPF и их компромиссы относятся к отдельному сюжету; здесь они не разбираются.

Мобильность обнаружила границу правила

Адрес может быть правильным для мобильного узла, но неожиданным для сети, к которой он подключён сейчас. RFC 2267 приводит пример Mobile IP: исходящий из посещаемой сети пакет может нести домашний адрес узла. Простой фильтр, принимающий только локальный клиентский префикс, способен его отбросить. В документе упомянут обратный туннель, описанный позднее в RFC 2344: исходящий пакет сначала доставляется домашнему агенту, а затем направляется в Интернет.

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

Информационный документ стал BCP 38

RFC 2267 вышел в январе 1998 года как информационный документ и не задавал интернет-стандарт. В мае 2000 года RFC 2827 заменил его, сохранил заголовок «Network Ingress Filtering» и получил статус Best Current Practice под номером BCP 38. Основная рекомендация не изменилась: провайдерам следовало фильтровать трафик клиента на входе и отбрасывать исходные префиксы, которые эта сеть не использует на законном основании.

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

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

Историческое изменение было узким и практическим. Жертва переставала быть единственным местом, где приходилось разбираться с поддельным адресом. RFC 2267 предложил проверяемое правило на стыке провайдера и клиента, где связь между каналом и префиксами можно было хранить и применять локально. BCP 38 дал этой практике общее имя. На каждом конкретном подключении результат всё равно зависел от того, была ли локальная политика точной, установленной и действующей.

Источники

  1. RFC 2267 — Network Ingress Filtering
  2. RFC 2827 — Network Ingress Filtering (BCP 38)
  3. RFC 1812 — Requirements for IP Version 4 Routers
  4. RFC 2002 — IP Mobility Support
  5. RFC 2344 — Reverse Tunneling for Mobile IP
  6. RFC 3704 — Ingress Filtering for Multihomed Networks (BCP 84)