Как работать с апокрифами

Апокрифы — это вторая половина курса. Основная программа отвечает на вопрос «как сеть устроена и как ею управлять»; апокрифы смотрят на ту же сеть с другой стороны: что происходит, когда в неё приходит чужой пакет, где заканчивается доверие между протоколами, как обойти контроль доступа и как каждый приём выглядит в глазах защитника. Одиннадцать тем идут от разведки до промышленных сетей, и каждая заканчивается не «атака удалась», а разбором следа, который она оставила.

Этот модуль ничего не атакует. Он объясняет, как устроены остальные: в каких границах ставятся эксперименты, чем отличаются утверждения разных уровней достоверности, как ведётся журнал и в каком порядке темы опираются друг на друга. Без него первые же расхождения между текстом и выводом команды выглядят как ошибка курса, хотя чаще это разница между требованием стандарта и поведением конкретного ядра.

Зачем отдельный нулевой модуль

Апокриф устроен иначе, чем тема основной программы. Там материал шёл от механизма к практике: как работает протокол, как его настроить, как проверить. Здесь на первом месте стоит вопрос «чему протокол верит», и ответ на него не всегда совпадает с тем, что написано в документации: стандарт описывает, как должно быть, ядро реализует подмножество, а учебная лаборатория упрощает ещё и это подмножество.

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

Чем апокриф отличается от темы основной программы

Каждая тема апокрифов отвечает на три вопроса, и третий — не приложение, а половина темы:

1. Как устроено. Механизм до структуры и функции: таблица соседей и struct neighbour, хук netfilter и кортеж conntrack, конечный автомат BGP, сообщение DNS.
2. Как воспроизвести. Рабочая команда, скрипт или конфигурация в среде, которую можно собрать на одной машине.
3. Как ловится. Что видно в захвате, в NetFlow, в журнале IDS; какое конкретное правило, настройка или счётчик останавливает приём.

Тема открывается разделом «Тень базового курса»: короткой отсылкой к легитимному механизму и сразу — к его извращению. Это не повторение. Читатель уже видел, как протокол должен работать, поэтому апокриф не пересказывает базу, а показывает, чего протоколу не хватает: аутентификации, привязки к контексту, проверки состояния.

Отсюда следствие для чтения: если в теме встретилось незнакомое понятие из основной программы, возвращаться нужно к ней, а не искать обходное объяснение здесь. Апокрифы предполагают, что стек TCP/IP, маршрутизация, DNS и TLS уже разобраны.

Приёмы курса не привязаны к конкретному инструменту и легко сопоставляются с внешними классификациями: разведка, первоначальный доступ, боковое перемещение и эксфильтрация в матрице ATT&CK ² покрывают те же шаги, что и темы 01–11, но с другой точки зрения — по действиям, а не по протоколам. Это сопоставление полезно при чтении отчётов и при построении детекторов.

Модель нарушителя

Любая оценка «атака работает» имеет смысл только вместе с возможностями атакующего. Один и тот же приём может быть тривиальным для того, кто стоит на пути, и вычислительно невозможным для того, кто видит только ответы сервера. Поэтому в каждой теме модель нарушителя названа явно, а вместе с ней — бюджет: сколько пакетов, попыток и времени требует приём.

Модель нарушителя — это рамка для расчётов, а не разрешение. Она нужна, чтобы отличить «приём невозможен» от «приём дорог»: подделка DNS-ответа вне пути при достаточной энтропии идентификатора и порта требует миллионов попыток, а на пути — одного пакета. Числа в таких оценках всегда указываются с источником: энтропия TXID и порта, размер окна TCP, таймеры BGP.

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

Своя лаборатория и документированные адреса

Курс исходит из простого правила: эксперимент ставится только в собственной изолированной среде. Это не формальность, а условие воспроизводимости. Чужая сеть меняется между запусками, её нельзя сбросить, а её реакция на подделку пакетов непредсказуема.

Технические следствия этого правила:

• Адреса — только документационные. IPv4 — 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24 ³, IPv6 — 2001:db8::/32 ⁴, номера AS — из диапазона для документации, 64496–64511 ⁷ (в курсе используются 64500–64502). Такие адреса не маршрутизируются в интернете, поэтому случайная утечка пакета не достигает чужой системы.
• Домены — только example.com и производные (nsu.example, lab.example). Это домены, зарезервированные для примеров.
• Изоляция — на уровне ядра. Сетевые пространства имён (unshare -rnm) дают собственный стек, свои таблицы маршрутизации и свои правила nftables, не затрагивая хост ⁵.
• Радио — только собственное оборудование. Передача в эфир регулируется: мощность, канал и разрешённые диапазоны зависят от страны. Эксперименты с 802.11 выполняются на собственном оборудовании или на виртуальном радиомодуле; чужие точки доступа и чужие клиенты не являются частью стенда.
• Никаких внешних целей. Ни сканирования, ни подделки пакетов, ни перебора за пределами стенда. Если в задании нужен «внешний» узел, он эмулируется.

Уборка — часть эксперимента, а не уборка после него. Каждая работа заканчивается возвратом стенда в исходное состояние: остановленные процессы, удалённые пространства имён, снятые правила, удалённые временные файлы. Процессы останавливаются по PID-файлу, а не по pkill -f: шаблон по имени убивает чужие процессы и скрывает ошибку в сценарии.

Уровни воспроизводимости

Не всякая часть темы воспроизводится одинаково. Один и тот же приём может быть показан на готовом захвате, в пространствах имён, в контейнерах или только на оборудовании. Уровень указывается в начале лабораторной, и от него зависит, что именно проверяется.

Уровень 0 — не «упрощённая версия» и не замена: это единственный способ гарантировать, что все увидят одни и те же байты. Уровни 1 и 2 — основные: они дают живую реакцию стека и при этом остаются воспроизводимыми. Уровень 3 используется там, где без него не обойтись: 802.11, АСУ ТП с реальным контроллером, поведение античит-защиты.

Если в среде нет инструмента, лабораторная не отменяется: у неё есть минимальный сценарий на уровне 0 и запасной вариант, названный в задании. В журнале при этом фиксируется, какой уровень использован, — иначе вывод «правило не сработало» может относиться к отсутствующей зависимости, а не к защите.

Как читать утверждения

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

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

Разница между уровнями видна на простом примере. Стандарт требует, чтобы узел не принимал ICMP redirect от не-шлюза ⁶; Linux принимает их только при определённых настройках маршрута; в лаборатории redirect приходит от узла, который шлюзом не является, и всё равно срабатывает — потому что маршрут уже указывает на этот адрес. Три утверждения верны одновременно, и каждое отвечает на свой вопрос.

Формат темы

Все темы апокрифов собраны по одной схеме. Это не бюрократия: одинаковая последовательность позволяет сравнивать темы между собой и быстро находить пропущенный раздел.

1. Легитимный механизм из основной программы — коротко, только то, что нужно для атаки.
2. Граница доверия — кому и чему протокол верит и почему.
3. Состояния и обмен сообщениями — что и в каком порядке отправляется.
4. Формат пакета или записи — поля, флаги, таймеры.
5. Предпосылки приёма — что должно совпасть, чтобы атака сработала.
6. Атакующий приём — команда, скрипт, конфигурация.
7. Что видит получатель, сеть и защитный инструмент — три разных картины одного события.
8. Обнаружение — конкретное правило, счётчик или настройка.
9. Защита и её ограничения — что именно она закрывает и чего не закрывает.
10. Лабораторное наблюдение и контрольный вывод — что должно получиться и как понять, что получилось не то.

Если раздел отсутствует, тема считается неполной — независимо от объёма. Если раздел есть, но в нём нет конкретики (породы правила, номера поля, названия счётчика), он тоже неполный.

Формат лабораторной

Лабораторная строится вокруг предсказания. Сначала формулируется гипотеза: что должно произойти и почему. Потом ставится эксперимент. Потом наблюдение сравнивается с гипотезой, и расхождение объясняется — а не замалчивается.

Журнал ведётся по пяти колонкам:

Такая форма отличается от «команда — результат» тем, что фиксирует расхождение как результат, а не как неудачу. В апокрифах расхождение — самый ценный фрагмент: именно оно показывает, где заканчивается стандарт и начинается реализация.

Каждая работа содержит часть «найти и исправить ошибку»: правило, скрипт или конфигурация с дефектом, который нужно обнаружить по симптому. Это проверяет не память, а понимание — умение отличить ошибку в своём коде от поведения стека.

Маршрут, ветви и зависимости

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

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

Ветви после восьмой темы можно проходить в любом порядке: 09 (альтернативные среды), 10 (идентичность и облако), 11 (специализированные сети). Они не зависят друг от друга, но все опираются на ядро 01–08.

Уровни вопросов

Вопросы в конце темы проверяют разное, и это видно по формулировке. Пять уровней:

• Понимание: объяснить механизм своими словами. «Почему ARP-ответ принимается без запроса?»
• Применение: предсказать результат команды или настройки. «Что покажет ip neigh после поддельного ответа?»
• Анализ: найти причину расхождения. «Правило не сработало — какие три проверки нужно сделать?»
• Проектирование: выбрать защиту под ограничения. «Что дешевле в сети с неуправляемыми коммутаторами: DAI или 802.1X?»
• Синтез: восстановить событие по нескольким источникам. «По pcap и журналу сенсора определите, был ли это скан или штатная работа.»

Вопрос уровня «понимание» не проверяет, умеет ли читатель применять; вопрос «синтез» не проверяет память на поля. Если на вопрос можно ответить одним словом из текста — это не вопрос курса.

Если инструмента нет

Апокрифы рассчитаны на Linux и набор утилит, но не требуют всего сразу. У каждой части есть замена, и она названа в задании: tshark вместо Suricata для разбора, готовый захват вместо генерации кадров, скрипт на scapy вместо hping3. Замена фиксируется в журнале: результат, полученный другим инструментом, — это другой уровень воспроизводимости, и путать его с исходным нельзя.

Чего замена не меняет: механизм. Если нет iodine, DNS-туннель собирается вручную на TXT-записях; если нет SDR, разбирается записанный захват. Приём остаётся тем же, меняется только способ получить байты.

Отдельный случай — живой захват. tshark -i и tcpdump работают через dumpcap, которому права выданы файловыми возможностями; в пользовательском пространстве имён они не действуют, и захват падает с Permission denied. Поэтому в лабораториях встречаются три варианта: захват от root вне пространства имён, готовый pcap из окружения и короткий скрипт на AF_PACKET, который пишет pcap сам. Разбор во всех трёх случаях одинаковый.

Литература

1. NIST. Technical Guide to Information Security Testing and Assessment. — SP 800-115, 2008. https://csrc.nist.gov/pubs/sp/800/115/final
2. MITRE. ATT&CK: Adversarial Tactics, Techniques, and Common Knowledge. https://attack.mitre.org
3. Cotton M., Vegoda L., Bonica R. Special-Purpose IP Address Registries. — RFC 6890, IETF, 2013. https://www.rfc-editor.org/rfc/rfc6890
4. Huston G. IPv6 Address Prefix Reserved for Documentation. — RFC 3849, IETF, 2004. https://www.rfc-editor.org/rfc/rfc3849
5. network_namespaces(7). — Linux man-pages. https://man7.org/linux/man-pages/man7/network_namespaces.7.html
6. Braden R. Requirements for IP Version 4 Routers. — RFC 1812, IETF, 1995. https://www.rfc-editor.org/rfc/rfc1812
7. Huston G. Autonomous System (AS) Number Reservation for Documentation Use. — RFC 5398, IETF, 2008. https://www.rfc-editor.org/rfc/rfc5398

Лабораторная работа 0. Паспорт стенда

• Раздел курса: апокриф 0 «Как работать с апокрифами»

Введение

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

Работа собирает паспорт стенда: версию ядра, доступность пространств имён, наличие инструментов, работоспособность конвейера «захват → разбор», базовые параметры сети. Паспорт сохраняется в файл и прикладывается к журналу остальных работ: по нему видно, на каком уровне воспроизводимости получен результат.

Эксперименты безопасны: создаются только свои пространства имён и свои интерфейсы, внешние адреса не используются.

Цель работы

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

• проверить, что ядро и привилегии позволяют ставить сетевые эксперименты;
• собрать пару пространств имён с veth и убедиться, что стек работает;
• составить таблицу инструментов с версиями и заменами;
• прогнать полный цикл «снять захват — прочитать поля — удалить артефакты»;
• зафиксировать базовую линию сети до экспериментов;
• найти и исправить ошибки в сценарии проверки, который оставляет за собой мусор.

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

Разделы теории «Зачем отдельный нулевой модуль», «Уровни воспроизводимости», «Как читать утверждения», «Формат лабораторной».

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

Уровень воспроизводимости: 1 — пространства имён; живой захват дополнительно требует root вне пространства имён или скрипта на AF_PACKET.

Linux с iproute2, nftables, python3. Для захвата — tshark или tcpdump. Всё выполняется в unshare -rnm; отдельная виртуальная машина не требуется, но приветствуется для работ уровня 3.

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

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

Проверить, что оболочка действительно в новом пространстве имён:

readlink /proc/self/ns/net
ip link show | head

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

Часть 1. Ядро и привилегии

Задание

Записать параметры ядра, от которых зависят последующие работы:

uname -sr
cat /proc/sys/net/ipv4/ip_forward
cat /proc/sys/net/ipv4/conf/all/rp_filter
cat /proc/sys/net/ipv6/conf/all/disable_ipv6
sysctl -n net.ipv4.ip_local_port_range

Проверить доступ к netfilter и к raw-сокетам:

nft list tables
python3 - <<'PY'
import socket
s = socket.socket(socket.AF_INET, socket.SOCK_RAW, socket.IPPROTO_RAW)
print("raw socket ok:", s.getsockname())
s.close()
PY

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

Команды печатают значения без ошибок; nft list tables выводит пустой список, а не отказ в доступе. ip_forward = 0 — нормальное исходное состояние: пересылка включается только там, где нужна. rp_filter записывается как есть: в разных дистрибутивах значение по умолчанию разное, и это влияет на опыты с подделкой источника.

Если unshare недоступен, работа выполняется в виртуальной машине; уровень воспроизводимости в журнале повышается до 3.

Часть 2. Пространства имён и стек

Задание

Собрать два пространства имён, соединить их парой veth, проверить связность и таблицу соседей:

set -e
ip netns add a
ip netns add b
ip link add va type veth peer name vb
ip link set va netns a
ip link set vb netns b
ip -n a addr add 192.0.2.10/24 dev va
ip -n b addr add 192.0.2.20/24 dev vb
ip -n a link set va up
ip -n b link set vb up
ip -n a link set lo up
ip -n b link set lo up
ip netns exec a ping -c 2 -W 1 192.0.2.20
ip -n a neigh show

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

Два эха без потерь, запись 192.0.2.20 в таблице соседей пространства a в состоянии REACHABLE или STALE. Записать время жизни записи и объяснить, почему для проверки ARP-спуфинга важно знать это состояние, а не только адрес.

Уборка — обратным порядком, до следующей части:

ip netns del a
ip netns del b
ip netns list

Часть 3. Инструменты и замены

Задание

Составить таблицу: инструмент, наличие, версия, замена. Проверка — без установки пакетов:

for t in tshark tcpdump nft ip python3 dig unbound-host delv \
         suricata zeek nmap socat hping3 chisel mitmproxy \
         iw hostapd aircrack-ng hashcat mosquitto modprobe; do
  if v=$(command -v "$t"); then
    printf '%-14s %s\n' "$t" "$v"
  else
    printf '%-14s -\n' "$t"
  fi
done
python3 -c "import scapy; print('scapy', scapy.__version__)" 2>/dev/null || echo "scapy -"

Версии, которые важны для текста курса, снять отдельно:

tshark -v | head -1
nft --version
python3 --version

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

Таблица с прочерками там, где инструмента нет. Для каждой прочеркнутой строки — замена из теории нулевого модуля: suricata → tshark с фильтрами, zeek → разбор вывода tshark, iodine → TXT-записи вручную, hping3 → scapy. Замены не эквивалентны: в журнале фиксируется, что часть выполнена на уровне 0 или 1 другим инструментом.

Часть 4. Конвейер захвата

Задание

Снять захват на паре veth, прочитать его и удалить.

Живой tshark -i внутри unshare -rnm обычно не запускается: tshark вызывает dumpcap, у которого права выданы файловыми возможностями, а в пользовательском пространстве имён они не действуют — ошибка выглядит как Couldn't run dumpcap in child process: Permission denied. Поэтому захват ведётся маленьким скриптом на AF_PACKET, а разбор — тем же tshark -r. Захват запускается в фоне, PID сохраняется в файл:

cat > /tmp/sniff.py <<'PY'
import socket, struct, sys, time

iface, out, seconds = sys.argv[1], sys.argv[2], float(sys.argv[3])
s = socket.socket(socket.AF_PACKET, socket.SOCK_RAW, socket.htons(0x0003))
s.bind((iface, 0))
s.settimeout(0.5)
start, pkts = time.time(), []
while time.time() - start < seconds:
    try:
        data, _ = s.recvfrom(65535)
    except socket.timeout:
        continue
    pkts.append((time.time(), data))

with open(out, "wb") as f:
    f.write(struct.pack("<IHHiIII", 0xA1B2C3D4, 2, 4, 0, 0, 65535, 1))
    for ts, data in pkts:
        sec = int(ts)
        f.write(struct.pack("<IIII", sec, int((ts - sec) * 1e6),
                            len(data), len(data)))
        f.write(data)
print(f"{len(pkts)} packets -> {out}")
PY

ip netns add c
ip netns add d
ip link add vc type veth peer name vd
ip link set vc netns c
ip link set vd netns d
ip -n c addr add 192.0.2.30/24 dev vc
ip -n d addr add 192.0.2.40/24 dev vd
ip -n c link set vc up
ip -n d link set vd up
ip -n c link set lo up
ip -n d link set lo up

ip netns exec c python3 /tmp/sniff.py vc /tmp/stand.pcap 5 &
echo $! > /tmp/sniff.pid
sleep 1
ip netns exec d ping -c 3 -W 1 192.0.2.30
wait "$(cat /tmp/sniff.pid)" || true

Разбор:

tshark -r /tmp/stand.pcap -Y icmp -T fields \
  -e frame.number -e ip.src -e ip.dst -e icmp.type
tshark -r /tmp/stand.pcap -q -z io,stat,0

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

В захвате — эхо-запросы и эхо-ответы, в полях видны адреса и типы ICMP. Объяснить, почему захват на vc видит оба направления, хотя ping запускался из пространства d: veth — это линк, и пакет проходит по нему в обе стороны.

Убрать за собой:

ip netns del c
ip netns del d
rm -f /tmp/stand.pcap /tmp/sniff.py /tmp/sniff.pid

Часть 5. Базовая линия

Задание

Зафиксировать параметры, с которыми будут сравниваться результаты следующих работ:

ip -o link show | awk '{print $2, $4, $5, $9}'
ip route show
ip -6 route show
cat /proc/sys/net/core/rmem_max
cat /proc/sys/net/core/wmem_max
nproc
date -Is

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

Таблица «параметр — значение — как меняется». Отдельно отметить MTU: большинство работ с фрагментацией и туннелями опирается на MTU 1500, и его изменение ломает ожидаемые размеры пакетов. Если MTU на интерфейсе не 1500, это записывается в журнал и учитывается при разборе.

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

Задание

Сценарий проверки оставляет после себя пространства имён и процессы, а иногда убивает чужие:

#!/usr/bin/env bash
# stand.sh — черновик проверки стенда

unshare -rnm --propagation private bash -c '
  ip netns add a
  ip netns add b
  ip link add va type veth peer name vb
  ip link set va netns a
  ip link set vb netns b
  ip -n a addr add 192.0.2.10/24 dev va
  ip -n b addr add 192.0.2.20/24 dev vb
  ip -n a link set va up
  ip -n b link set vb up
  ip netns exec a ping -c 1 192.0.2.20
'
pkill -f tshark
rm -f /tmp/stand.pcap
echo "готово"

Найти четыре дефекта и исправить сценарий:

1. pkill -f tshark убивает все процессы с этим именем, включая чужие и запущенные не этим сценарием; нужен PID-файл и проверка, что процесс наш.
2. Нет set -e и обработки ошибок: при сбое ip netns add сценарий продолжит работу и создаст половину стенда.
3. Нет trap, поэтому при прерывании пространства имён остаются; ip netns list после запуска это покажет.
4. rm -f без проверки пути и без создания файла: удаление маскирует отсутствие захвата, а не проверяет его. Кроме того, фиксированное имя в /tmp конфликтует между запусками.

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

Исправленный сценарий:

• начинается с set -euo pipefail;
• объявляет trap cleanup EXIT INT TERM, где cleanup удаляет пространства имён и файлы;
• сохраняет PID фонового процесса в файл и завершает только его;
• проверяет, что захват создан и непуст, до разбора;
• использует mktemp -d вместо фиксированных имён в /tmp;
• печатает итог и код возврата.

Проверить исправление: прервать сценарий по Ctrl+C и убедиться, что ip netns list пуст, а процессов tshark не осталось.

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

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

1. Чем уровень 0 отличается от уровня 1 и почему готовый захват не является «упрощением»?
2. Почему для проверки ARP-спуфинга важно состояние записи в таблице соседей, а не только её наличие?
3. Какие три уровня достоверности утверждений нужно различать и как они помечаются?
4. Почему pkill -f опаснее, чем kill по PID-файлу, даже в собственной лаборатории?
5. Что меняет --propagation private при запуске unshare?
6. Почему захват на одном конце veth видит трафик обоих направлений?
7. Какие параметры ядра влияют на опыты с подделкой источника и фрагментацией?
8. Почему замена suricata на tshark меняет уровень воспроизводимости результата?
9. Зачем фиксировать MTU до начала работ с туннелями?
10. Что должно быть в журнале, если часть работы выполнена не тем инструментом, который указан в задании?

Уборка

ip netns list
pgrep -a tshark || true
rm -f /tmp/stand.pcap /tmp/sniff.py /tmp/sniff.pid
nft list tables

Все три списка должны быть пустыми. Если nft list tables что-то показывает, удалить свои таблицы по именам; чужие не трогать.