Можете ли вы использовать ARP-Poisoning (спуфинг), чтобы применять смоделированные внешние эффекты?

Question

Мы ищем способы создания сервера сетевых эффектов. Под этим я подразумеваю центральный сервер, который будет проверять все пакеты в сети и применять логику (отбрасывание, задержка, изменение и т. Д.) На основе факторов, внешних по отношению к фактической сети, таких как погода и линия прямой видимости.

Это все, что связано с запуском моделирования множества реальных объектов: физический узел в сети будет представлять собой движущуюся 3D-сущность в 3D-виртуальном мире. Как я уже упоминал, эффекты будут рассчитываться на линии прямой видимости, расстоянии, помехах и т. Д. Между «положением виртуального мира» узлов.

Мне известны другие инструменты, которые позволяют вам выполнять подобные эффекты (такие как OPNET, которые мы могли бы использовать как часть решения), но они обычно требуют, чтобы вы направляли данные непосредственно к ним для обработки. Они также не обрабатывают ни UDP, ни TCP.

Мне нужен способ прозрачной работы нашего сервера и применения эффектов без изменения какого-либо существующего программного обеспечения (и, в любом случае, его нельзя изменить) для UDP и TCP.

В этом смысле мы думали об использовании ARP-отравления (или спуфинга, в зависимости от того, что вы предпочитаете называть), чтобы заставить весь трафик через один (или потенциально несколько для балансировки нагрузки) этих серверов выполнить пакет формообразование.

Это осуществимый подход? (не хочу тратить недели на развитие, прежде чем понять, что слишком много препятствий или что это невозможно)

Если это возможно, является ли RFC826 (плюс 5227 и 5494 ) самым последним документом по ARP? Есть ли лучший документ?

Будет ли это работать, когда некоторые из сети узлы являются виртуальными машинами (они могут быть наведенным мостом или NAT)?

Существуют ли библиотеки, которые позволяют вам делать это в C #?

(Мы открыты для используемого нами языка, но, вероятно, предпочитаем решения на основе C # или Qt)

Answer 1

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

Прежде всего, вы упомянули C #, который на самом деле не является языком для этого, низкоуровневая сеть слишком далека. Я думаю, что C # предоставляет класс необработанных сокетов, но если вы попытаетесь эмулировать TCP / IP и UDP, а адреса подделки не принадлежат вашему хосту, это фактически отбрасывает ваши пакеты. Возможно, есть способ остановить это, но вам придется исследовать .Net Raw Socket.

Вы также можете использовать WinPcap с оболочкой c #. Но это все еще не нативная реализация и может понести потери производительности. Существует оболочка C # для WinPcap, которую я использовал под названием SharpPcap , однако некоторые части не реализованы должным образом, и мне пришлось изменить ее так, как мне было нужно. Я провел несколько простых тестов захвата трафика на скорости 300 Мбит / с, но это не включало анализ протоколов или внедрение пакетов обратно в сеть. Это также может быть использовано для отправки пакетов обратно в сеть, но опять же в прошлом это была довольно низкая производительность. Среди моих коллег по сети распространено мнение, что этот тип проверки не может быть выполнен без помощи аппаратного обеспечения в скорости Гбит / с.

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

* Обратите внимание, что Боб Маккормик отмечает, что это повлияет только на хосты в разных подсетях, однако существует простой читерский подход: на каждом хосте (если назначены статические IP-адреса) маска маски подсети должна быть / 32 (т. Е. 255.255.255.255) ). Это по существу заставит хост отправлять все свои кадры для маршрутизации маршрутизатором, поскольку он больше не знает ни о каких других пользователях в той же сети, что и он сам.

Последнее замечание: я понятия не имею, будет ли это работать на виртуальной машине. Я думаю, что будет, если вы используете один тип сетевого интерфейса в vmware, но я не пробовал его и не имею представления о других провайдерах виртуальных машин.

Однако, если вы выполняете этот уровень работы, я бы посоветовал вам снова взглянуть на использование linux для хоста, на который вы отправляете трафик, и, возможно, инструмент, рекомендованный Бобом Маккормиком. Однако в Linux я уверен, что существует множество инструментов, которые можно настроить для имитации событий такого типа, которые вы ищете.

Answer 2

Спуфинг никогда не будет надежным. По сути, это гонка между вами и законным владельцем IP-адреса, который вы подделываете.

Обратите внимание, что любые конфигурации, связанные с использованием маршрутизатора, такие как предложение использовать маршрутизатор Linux и т. Д., Будут только , что позволит вам влиять на трафик между хостами, которые находятся в разных подсетях.

Если это работает для вас, могу ли я предложить вам начать с функциональности Netem (http://www.linuxfoundation.org/en/Net:Netem) в ядре Linux? Netem позволит вам контролировать пропускную способность, задержку, дрожание, переупорядочение пакетов и т. Д. для любых пакетов, пересылаемых ядром Linux. Я использовал его несколько раз для имитации характеристик WAN между маршрутизаторами Cisco для тестирования конфигураций QOS.

Answer 3

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

Это возможно?

Редактировать: Поскольку вы управляете сетью, я не думаю, что вам нужно ARP Poisoning вообще. Я не уверен, как выглядит ваша топография, но для небольшой / средней настройки я бы переключился с CISCO или эквивалентного устройства и исследовал бы запуск Linux-бокса в качестве маршрутизатора. Затем любые сценарии и тому подобное, необходимые для удаления / задержки / изменения пакетов по мере необходимости. Решение Linux вместо Cisco может быть немного обидчивым, я не эксперт, но для небольшой лаборатории это не должно быть проблемой.

Я лично использую shorewall (интерфейс iptables), чтобы сегментировать мою сеть и отбрасывать / отклонять / разрешать пакеты между сегментами. Подключение к использованию сценариев, управляемых внешними факторами, было бы много работы iptables для динамического добавления и удаления правил, но, безусловно, выполнимо.

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