Я знаю, что люди могут изменять заголовки IP и изменять IP-адрес источника, но сетевые устройства должны легко обнаруживать эти сообщения. Если нет, то почему это так сложно? Это добавляет слишком много накладных расходов?
Ответы:
Я знаю, что люди могут изменять заголовки IP и изменять IP-адрес источника, но сетевые устройства должны легко обнаруживать эти сообщения.
Поддельные IP-адреса источника в заголовках могут быть обнаружены и заблокированы в коммерческом сетевом оборудовании; другие поддельные заголовки IPv4 может быть немного сложнее идентифицировать. Большинство людей называют функцию обнаружения поддельных IP-адресов источника «Unicast Reverse Path Forwarding», которая сокращенно называется uRPF ; uRPF определен в RFC 3704 и считается лучшей современной практикой в Интернете . uRPF должен применяться на первом маршрутизаторе от оборудования заказчика или на пограничном маршрутизаторе в корпоративной сети.
Если нет, то почему это так сложно? Это добавляет слишком много накладных расходов?
Пока маршрутизатор не является маршрутизатором на базе процессора, производительность не снижается. Многие из маршрутизаторов / коммутаторов, используемых интернет-провайдерами, имеют встроенную аппаратную функцию в ASIC; как правило, это не приводит к огромным потерям производительности. Иногда возникают конфликты функций, но, опять же, в большинстве случаев это не так уж важно.
Политики и компетенция инженерного / эксплуатационного персонала интернет-провайдера различаются, и многие интернет-провайдеры (особенно в небольших странах) настолько заняты тем, чтобы заставить вещи «работать», что у них нет циклов, чтобы заставить вещи «работать хорошо».
Для предотвращения изменения IP-адреса источника необходимо использовать списки доступа (ACL) или одноадресную фильтрацию обратного пути (uRPF).
Ни приходи бесплатно. uRPF обычно требует дополнительного поиска или более сложного одиночного поиска, так что это может даже вдвое снизить производительность поиска на некоторых платформах. ACL будет замедлять поиск и использовать память.
uRPF не требует обслуживания, вы просто настраиваете его один раз и забываете. ACL нужна система, которая знает, какие адреса находятся за интерфейсом, и следит за тем, чтобы ACL оставался в актуальном состоянии.
ACL более широко поддерживается, чем uRPF, uRPF - сравнительно редкая функция в устройствах уровня коммутации L3. В «реальных» маршрутизаторах обычно доступны обе функции.
Даже если обе функции доступны, настройка uRPF в неправильном месте сети может нарушить работу сети, а отсутствие понимания ограничений ACL для конкретной платформы может привести к сбоям.
Обычно вы сами не извлекаете выгоду из предотвращения подмены исходного адреса, в основном это Интернет. Вы несете ненулевой риск, пытаясь это сделать, так как вы можете в конечном итоге сломать вещи. И ваши клиенты не получат никакой выгоды, никто не заплатит вам больше за их реализацию. Так что вознаграждение за это невысоко
Ответственный поставщик услуг делает это, потому что это правильно, но нереально ожидать, что мы получим антиспуфинг в относительно большой части развернутых устройств доступа. Гораздо более реалистичной является цель, если мы используем ACL в транзитных IP-соединениях, поскольку там всего около 6000 или около того коротких номеров AS.
Почему это даже проблема, из-за атак отражения UDP, которые могут быть исправлены с помощью таких протоколов, как QUIC и MinimaLT, которые гарантируют, что отражение не имеет преимуществ, так как входящий запрос гарантированно больше, чем исходящий ответ, поэтому подмена теряет свою выгоду.
В последнее время снова стало довольно популярным использование отражения UDP в качестве DDoS-атаки. В потребительских устройствах CPE существует множество широко открытых DNS-серверов, которые потребители не знают, поэтому эти потребители страдают, поскольку их домашнее соединение перегружено, поскольку оно используется для отражения атаки. И это также простой способ получить значительное усиление, маленький запрос в несколько десятков байтов может дать большой ответ более тысячи байтов. Отражение DDoS-атак было несколько сотен гигабит в секунду, и меньше ежедневно, только в воскресенье ночью мы передали атаку со скоростью 43 Гбит / с одному из наших клиентов.
Фильтрация адресов источника нетривиальна в реальном мире, потому что интернет-маршрутизация асимметрична, поэтому в принципе нам нужно уметь догадываться, может ли пакет из этого источника появиться на этом входящем интерфейсе.
Легкой формулы для этого не существует, потому что для каждого правила, которое работает почти во всех случаях, есть также вариант использования, который имеет смысл в бизнесе, который затем нарушится.
Фильтрация обратного пути отлично работает на граничных маршрутизаторах, где есть четкое определение «внутри» и «снаружи» - вы не разрешаете посторонним использовать «внутренние» адреса и наоборот. Все становится сложнее, как только я начинаю использовать несколько граничных маршрутизаторов для резервирования.
Для магистральных маршрутизаторов единственный способ фильтрации обратного пути - реализовать входящие пакеты, когда одноранговый узел объявляет рабочий маршрут (независимо от того, будет ли это нашим предпочтением). Это был бы чрезмерно длинный поиск, который легко обойти и нарушил бы тот случай, когда я намеренно покупаю транзит, но не объявляю свой префикс по этой ссылке.