Как создать сценарий «человек посередине» с помощью ebtables и iptables

Для тестирования и в образовательных целях я хочу настроить сценарий «человек посередине» следующим образом:

  • Хост T – это целевой хост, который нужно «клонировать»
  • Хост М – человек посередине с интерфейсами eth0 и eth1 ; M подключен к сети через eth0 и к T через eth1 .

Смысл установки в том, что T должен иметь возможность отвечать на некоторые запросы (в частности, аутентификация 802.1X через EAPoL, таким образом, M использует T в качестве oracleа аутентификации). В частности, по умолчанию T будет подключен к сети и аутентифицируется через 802.1X, а M будет отказано в доступе. Наоборот, пользователь имеет административный доступ к M, но не к T. objective состоит в том, чтобы позволить M выглядеть как T при выполнении диагностики сети, которая была бы невозможна из-за T из-за отсутствия привилегий.

Есть два возможных подхода:

  1. Напишите программу (например, python с scapy или C с libpcap), которая копирует соответствующие кадры туда и обратно.

  2. Используйте ebtables и iptables .

Здесь вопрос фокусируется на 2 и просто звучит так: как достичь желаемого результата?

Что я пробовал до сих пор

Первым шагом было соединить eth0 и eth1 (например, присоединить их к br0 ). Без каких-либо ebtables / iptables T видна сети, как если бы она была подключена непосредственно к ней. Затем, поскольку основное внимание уделяется олицетворению T в IPv4, я установил следующее правило:

 ebtables -A FORWARD -p IPv4 -j DROP 

Это правило не позволяет трафику IPv4 пересекать мост. Теперь, чтобы олицетворять T, M должен выполнить NAT на уровнях 2 и 3:

 # interception of incoming packets for T: ebtables -t nat -A PREROUTING -i eth0 -p IPv4 -d $TARGET_MAC_ADDR -j dnat --to-destination $MY_ETH0_MAC_ADDR iptables -t nat -A PREROUTING -i eth0 -d $TARGET_IP4_ADDR -j DNAT --to-destination $MY_ETH0_IP4_ADDR # spoofing of outgoing packets as coming from T: ebtables -t nat -A POSTROUTING -o eth0 -p IPv4 -s $MY_ETH0_MAC_ADDR -j snat --to-source $TARGET_MAC_ADDR iptables -t nat -A POSTROUTING -o eth0 -s $MY_ETH0_IP4_ADDR -j SNAT --to-source $TARGET_IP4_ADDR 

Моя наивная мысль заключалась в том, что это следует делать. Но это не так. Помимо «разъединения» T, M совсем не ведет себя как T. В частности, iptables -t nat -L -v -n показывает, что правила SNAT запускаются, как и ожидалось, но правило DNAT инертно (т. Е. 0 пакетов, неважно что просходит). Что мне здесь не хватает?

Заметки

Проблема похожа на эту, но установка не та.

В комментарии Руи указывает, что некоторые протоколы подвержены проблемам при использовании NAT. Это тот случай, если маршрутизатор маскирует хосты в восходящей сети (также известной как Cone NAT ). Однако, это не главное здесь. В этом сценарии NAT используется для маскировки M как T при затенении T. M просто отбрасывает пакеты T (см. Первое правило ebtables)

Фон

802.1X (точнее, 802.1X-2010) обеспечивает только аутентификацию, но не обеспечивает последующую безопасность “канала”. Это как если бы рукопожатие TLS приводило к шифрованию и аутентификации NULL – во время аутентификации «соискатель» доказывает свою подлинность, но «сеанс», следующий за аутентификацией, может быть перехвачен.

Средством защиты для проводных соединений является MACsec (он же 802.1ae, который является частью 802.1X-2014). Беспроводной кулон для MACsec – WPA / WPA2. Удивительно, что даже самый дешевый аппаратный продукт может справиться с WPA2, в то время как высокопроизводительные коммутаторы, поддерживающие MACsec, значительно дороже, чем те, которые не имеют.

Среди прочего описанный сценарий показывает, что 802.1X без MACsec ничего не стоит.

Если вы согласны с попыткой подхода 1), я только что закончил писать прокси-сервер EAPOL ( https://github.com/kangtastic/peapod ). Он даже изменит MAC-адрес eth0 так, чтобы он автоматически совпадал с адресом вашей цели, хотя я бы сделал это вручную. Кажется, вы можете настроить статический IPv4-адрес на eth0 и получить подключение, что хорошо, потому что мой прокси не обрабатывает какие-либо вещи уровня 3. Во всяком случае, основываясь на вашем описании, я уверен, что это будет работать для вашей ситуации. Есть некоторые другие прокси EAPOL, в основном на Python, которые, вероятно, будут работать так же хорошо, если вы посмотрите.

Если вашему соискателю EAPOL также необходимо «зарегистрироваться» в сети восходящего streamа после завершения сеанса через DHCP для получения подключения IPv4, все становится немного сложнее в зависимости от того, требуется ли для исходящей сети определенное имя хоста, идентификатор клиента и т. Д. Для быть отправлено в запросах DHCP. В худшем случае вам придется настроить dhclient на M так, чтобы он отправлял точно такие же опции, как и DHCP-клиент на T. Это раздражает, но вы можете сделать так, чтобы они были идентичными, если вы достаточно настойчивы. Клонирование MAC соискателя к eth0 также помогает там.

Если вы настроены на подход 2), используя eb / iptables – извините, я не могу вам сильно помочь. Я просто скажу, что EAPOL не будет пересекать программный мост Linux по умолчанию, поскольку адрес многоадресной группы EAPOL, 01-80-C2-00-00-03, не пересылается мостами, совместимыми с 802.1D. Решение этой проблемы:

 echo 8 > /sys/class/net/brX/bridge/group_fwd_mask 

(Почему 8, а не какое-то другое значение? Потому что https://interestingtraffic.nl/2017/11/21/an-oddly-specific-post-about-group_fwd_mask/ )

У вас есть T для аутентификации через ваш мост, так что вы уже это знаете, но другие могут этого не делать 🙂

Вы смотрели на человека в середине прокси – https://github.com/mitmproxy/mitmproxy ? Он сделает все, что вы просите.

 wget https://github.com/mitmproxy/mitmproxy/releases/download/v2.0.2/mitmproxy-2.0.2-linux.tar.gz 

Или с PIP

 pip3 install mitmproxy 

Затем запустите это:

 ./mitmproxy --host 

Настройте прокси в вашем браузере, и он будет MITM весь трафик, который вы хотите.