IP-трассировка

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

Использование ложных исходных IP-адресов позволяет проводить атаки типа «отказ в обслуживании» (DoS) или односторонние атаки (когда ответ от хоста-жертвы настолько хорошо известен, что для продолжения атаки не требуется получать ответные пакеты ^{[ необходимо разъяснение ]} ). Трассировка IP-адресов имеет решающее значение для определения источников атак и принятия мер защиты для Интернета. Большинство существующих подходов к этой проблеме были адаптированы для обнаружения DoS-атак. Такие решения требуют большого количества пакетов для сходимости на пути(ах) атаки.

Savage et al. ^[1] предложили вероятностную маркировку пакетов, когда они проходят через маршрутизаторы в Интернете. Они предлагают, чтобы маршрутизатор маркировал пакет либо IP-адресом маршрутизатора, либо ребрами пути, который пакет прошел, чтобы достичь маршрутизатора.

Для первой альтернативы, маркировки пакетов IP-адресом маршрутизатора, анализ показывает, что для получения правильного пути атаки с точностью 95% требуется до 294 000 пакетов. Второй подход, маркировка ребер, требует, чтобы два узла, составляющие ребро, маркировали путь своими IP-адресами вместе с расстоянием между ними. Этот подход потребует больше информации о состоянии в каждом пакете, чем простая маркировка узлов, но будет сходиться гораздо быстрее. Они предлагают три способа сокращения информации о состоянии этих подходов до чего-то более управляемого. ^[1]

Первый подход заключается в выполнении операции XOR для каждого узла, образующего ребро на пути друг с другом. Узел a вставляет свой IP-адрес в пакет и отправляет его в b . После обнаружения в b (путем обнаружения 0 на расстоянии) b выполняет операцию XOR своего адреса с адресом a . Этот новый объект данных называется идентификатором ребра и вдвое уменьшает требуемое состояние для выборки ребра. Следующий подход заключается в дальнейшем взятии этого идентификатора ребра и фрагментации его на k меньших фрагментов. Затем случайным образом выбирается фрагмент и кодируется вместе со смещением фрагмента, так что правильный соответствующий фрагмент выбирается из маршрутизатора ниже по потоку для обработки. Когда получено достаточно пакетов, жертва может восстановить все ребра, пройденные серией пакетов (даже при наличии нескольких злоумышленников). ^[1]

Из-за большого количества комбинаций, необходимых для восстановления фрагментированного идентификатора ребра, реконструкция такого графа атак является вычислительно интенсивной, согласно исследованию Сонга и Перрига. Кроме того, этот подход приводит к большому количеству ложных срабатываний. Например, при наличии всего 25 атакующих хостов в DDoS-атаке процесс реконструкции занимает несколько дней и приводит к тысячам ложных срабатываний. ^[2]

Соответственно, Сонг и Перриг предлагают следующую схему трассировки: вместо кодирования IP-адреса, перемежаемого хешем , они предлагают кодировать IP-адрес в 11-битный хеш и поддерживать 5-битный счетчик переходов, оба из которых хранятся в 16-битном поле идентификатора фрагмента. Это основано на наблюдении, что 5-битного счетчика переходов (максимум 32 перехода) достаточно для почти всех интернет-маршрутов. Кроме того, они предлагают использовать две разные функции хеширования, чтобы можно было определить порядок маршрутизаторов в маркировке. Затем, если какой-либо заданный переход решает пометить его, сначала проверяет поле расстояния на наличие 0, что означает, что предыдущий маршрутизатор уже пометил его. Если это так, он генерирует 11-битный хеш своего собственного IP-адреса, а затем выполняет операцию XOR с предыдущим переходом. Если он находит ненулевое количество переходов, он вставляет свой хеш IP, устанавливает количество переходов на ноль и пересылает пакет дальше. Если маршрутизатор решает не маркировать пакет, он просто увеличивает количество переходов в поле идентификатора перегруженного фрагмента. ^[2]

Song и Perrig определяют, что это недостаточно надежно против коллизий, и поэтому предлагают использовать набор независимых хэш-функций, случайным образом выбирая одну, а затем хэшируя IP вместе с FID или идентификатором функции, а затем кодируя это. Они утверждают, что этот подход по сути снижает вероятность коллизии до (1/(211)m). Для получения более подробной информации см. Song и Perrig. ^[2]

Беленки и Ансари описывают схему детерминированной маркировки пакетов. Они описывают более реалистичную топологию для Интернета, состоящую из локальных сетей и автономных систем с соединительной границей, и пытаются поместить одну метку на входящие пакеты в точке входа в сеть. Их идея заключается в том, чтобы поместить со случайной вероятностью .5 верхнюю или нижнюю половину IP-адреса входящего интерфейса в поле идентификатора фрагмента пакета, а затем установить резервный бит, указывающий, какая часть адреса содержится в поле фрагмента. Используя этот подход, они утверждают, что могут получить 0 ложных срабатываний с вероятностью .99 всего после 7 пакетов. ^[3]

Райанчу и Баруа предлагают другой вариант этого подхода (называемый DERM). Их подход похож тем, что они хотят использовать и закодированный IP-адрес входного интерфейса в поле идентификатора фрагмента пакета. Отличие от Беленки и Ансари в том, что они хотят закодировать IP-адрес как 16-битный хэш этого IP-адреса. Сначала они выбирают известную функцию хэширования. Они утверждают, что возникнут некоторые коллизии, если маркировку будут выполнять более 2^16 граничных маршрутизаторов. ^[4]

Они пытаются смягчить проблему коллизий, вводя случайный распределенный выбор хэш-функции из универсального набора, а затем применяя ее к IP-адресу. В любом сценарии хэширования исходный адрес и хэш сопоставляются вместе в таблице для последующего поиска вместе с битом, указывающим, какую часть адреса они получили. С помощью сложной процедуры и случайного выбора хэша они способны уменьшить коллизию адресов. Используя детерминированный подход, они сокращают время процедуры реконструкции для своей метки (16-битного хэша). Однако, кодируя эту метку с помощью хэширования, они вводят вероятность коллизий и, таким образом, ложных срабатываний. ^[4]

Шокри и Варшови представили концепции динамической маркировки и обнаружения на основе меток с помощью «динамической детерминированной маркировки пакетов» (DDPM). При динамической маркировке можно найти агентов атаки в крупномасштабной сети DDoS. В случае DRDoS это позволяет жертве проследить атаку на один шаг дальше к источнику, чтобы найти главную машину или настоящего злоумышленника с помощью всего лишь нескольких пакетов. Предлагаемая процедура маркировки увеличивает вероятность обнаружения атаки DRDoS у жертвы с помощью обнаружения на основе меток. В методе на основе меток механизм обнаружения учитывает метки пакетов для определения различных источников одного сайта, вовлеченного в атаку DDoS. Это значительно увеличивает вероятность обнаружения. Для того чтобы удовлетворить подход сквозных аргументов , разделение судьбы , а также с учетом необходимости масштабируемых и применимых схем, только пограничные маршрутизаторы реализуют простую процедуру маркировки. Достаточно незначительная задержка и издержки на полосу пропускания, добавляемые к граничным маршрутизаторам, делают DDPM реализуемым. ^[5]

S. Majumdar, D. Kulkarni и C. Ravishankar предлагают новый метод отслеживания происхождения пакетов DHCP в ICDCN 2011. Их метод добавляет новую опцию DHCP, которая содержит MAC-адрес и входной порт граничного коммутатора, который получил пакет DHCP. Эта новая опция будет добавлена ​​в пакет DHCP граничным коммутатором. Это решение следует DHCP RFC. Предыдущие механизмы отслеживания IP перегружали поля заголовка IP информацией об отслеживании и, таким образом, нарушали IP RFC. Как и другие механизмы, эта статья также предполагает, что сеть является доверенной. В статье представлены различные проблемы производительности маршрутизаторов/коммутаторов, которые были рассмотрены при разработке этого практического подхода. Однако этот подход неприменим к любому общему пакету IP. ^[6]

При подходах на основе маршрутизатора маршрутизатор отвечает за хранение информации о проходящих через него пакетах. Например, Sager предлагает регистрировать пакеты, а затем позже извлекать из них данные. Это имеет преимущество, поскольку находится вне полосы пропускания и, таким образом, не препятствует быстрому пути. ^{[ необходима цитата ]}

Snoeren et al. предлагают маркировку внутри маршрутизатора. Идея, предложенная в их статье, заключается в создании отпечатка пакета на основе инвариантных частей пакета (источник, пункт назначения и т. д.) и первых 8 байтов полезной нагрузки (которая достаточно уникальна, чтобы иметь низкую вероятность коллизии). Более конкретно, m независимых простых хэш-функций генерируют выходные данные в диапазоне 2n-1. Затем бит устанавливается в сгенерированном индексе для создания отпечатка при объединении с выходными данными всех других хэш-функций. Все отпечатки хранятся в 2n-битной таблице для последующего извлечения. В статье показано простое семейство хэш-функций, подходящих для этой цели, и представлена ​​его аппаратная реализация. ^[7]

Пространство, необходимое на каждом маршрутизаторе, ограничено и контролируемо (2n бит). Малое n увеличивает вероятность столкновения хэшей пакетов (и ложной идентификации). Когда пакет необходимо отследить, он пересылается на исходные маршрутизаторы, где проверяются совпадения отпечатков пальцев. С течением времени информация об отпечатках пальцев «затирается» хэшами, сгенерированными другими пакетами. Таким образом, селективность этого подхода ухудшается со временем, прошедшим между прохождением пакета и запросом на трассировку. ^[7]

Другой известный подход к схемам на основе маршрутизаторов исходит от Хазеямы и др. В своем подходе они хотят интегрировать подход SPIE, описанный Снореном ^[7], с их подходом записи идентификатора канала уровня 2 вместе с идентификатором сети ( VLAN или истинным идентификатором), MAC-адресом коммутатора уровня 2, который получил пакет, и идентификатором канала, по которому он пришел. Затем эта информация помещается в две таблицы поиска — обе содержат идентификатор MAC коммутатора (маршрутизатора уровня 2) для поиска. Они полагаются на кортеж MAC:port как на метод отслеживания пакета (даже если MAC-адрес был подделан). ^[8]

Чтобы помочь смягчить проблему ограничений хранения, они используют подход и реализацию хеширования Снорена (SPIE) – модифицируя его для принятия их информации для хеширования. Они признают, что их алгоритм медленный (O(N2)) и при хранении всего 3,3 миллионов хэшей пакетов приблизительное время до того, как таблицы дайджестов станут недействительными, составляет 1 минуту. Это диктует, что любой ответ на атаку должен быть в режиме реального времени – возможность только в одноадминистративных доменах локальной сети. ^[8]

Схема трассировки ICMP Стивен М. Белловин предлагает вероятностно отправлять пакет трассировки ICMP на хост назначения IP-пакета с некоторой низкой вероятностью. Таким образом, необходимость поддерживать состояние либо в пакете, либо в маршрутизаторе устраняется. Кроме того, низкая вероятность сохраняет накладные расходы на обработку, а также требования к полосе пропускания низкими. Белловин предлагает, чтобы выбор также основывался на псевдослучайных числах, чтобы помочь блокировать попытки атаковать пакеты времени. Проблема с этим подходом заключается в том, что маршрутизаторы обычно блокируют сообщения ICMP из-за проблем безопасности, связанных с ними.

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

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

По своей природе DoS любая такая атака будет достаточно долгоживущей, чтобы отслеживание таким образом стало возможным. Изменения топологии третьего уровня, хотя их трудно скрыть от решительного злоумышленника, имеют возможность смягчить DoS до тех пор, пока изменение маршрутизации не будет обнаружено и впоследствии адаптировано. После того, как злоумышленник адаптировался, схема перемаршрутизации может снова адаптироваться и перенаправить; вызывая колебания в DoS-атаке; предоставляя некоторую возможность поглощать воздействие такой атаки.

Хэл Берч и Уильям Чесвик предлагают контролируемое затопление ссылок, чтобы определить, как это затопление влияет на поток атаки. Затопление ссылки приведет к тому, что все пакеты, включая пакеты от атакующего, будут сброшены с одинаковой вероятностью. Из этого можно сделать вывод, что если данная ссылка была затоплена, а пакеты от атакующего замедлились, то эта ссылка должна быть частью пути атаки. Затем рекурсивно маршрутизаторы восходящего потока «принуждаются» выполнять этот тест, пока не будет обнаружен путь атаки. ^[9]

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

Парк и Ли представляют расширение Ingress Filtering на уровне 3. Они представляют средство обнаружения ложных пакетов, по крайней мере, в подсети, по сути, используя существующее состояние маршрутизации OSPF , чтобы маршрутизаторы принимали разумные решения о том, следует ли маршрутизировать пакет. ^{[ необходима цитата ]}