Тихий след: уклонение от IDS и анти-форензика

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

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

Тема 22 основной программы разбирала мониторинг, тема 18 — IDS/IPS как класс. Здесь эти системы рассматриваются как противник, у которого есть слепые зоны. Границы: конкретные атаки — темы 02–07; здесь только то, как они выглядят и как их спрятать.

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

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

Классическая работа Птачека и Ньюшема 1998 года описала три класса расхождений: вставка (сенсор видит данные, которых не видит получатель), уклонение (получатель видит данные, которых не видит сенсор) и отказ в обслуживании сенсора ². С тех пор протоколы изменились, но принцип остался.

Как устроены IDS/IPS

Сигнатуры, аномалии и гибриды

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

Классификация и требования к IDS/IPS описаны в NIST SP 800-94 ³. Snort и Suricata — сигнатурные с движком правил и разбором протоколов; Zeek — событийная система, которая пишет журналы и позволяет писать скрипты на языке, близком к доменному ⁴⁵. На практике их ставят вместе: Suricata для алертов, Zeek для контекста.

Inline, tap и fail-open

IPS стоит в разрыве и может отбрасывать пакеты; IDS смотрит копию и только предупреждает. Inline-режим даёт возможность блокировки, но создаёт единую точку отказа: при перегрузке или сбое трафик либо встаёт, либо проходит без проверки (fail-open), либо блокируется (fail-closed).

suricata -i eth1 -c /etc/suricata/suricata.yaml          # IDS: копия пакетов
suricata -r capture.pcap -c /etc/suricata/suricata.yaml -l /tmp/log   # offline
suricata -q 0 -c /etc/suricata/suricata.yaml             # IPS через NFQUEUE

-i не ставит сенсор в разрыв: Suricata получает копию через AF_PACKET и может только предупреждать. Для настоящего inline трафик заводится в очередь netfilter (queue num 0), а Suricata читает её через -q 0 и возвращает вердикт: accept, drop или reject. Без правила queue процесс -q 0 просто ждёт пакетов. Для лабораторной удобнее offline-разбор: результат воспроизводим.

Уклонение на уровне сети и транспорта

Фрагментация и перекрытие сегментов

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

С TCP-сегментами та же логика: перекрывающиеся сегменты с разными данными по одному смещению. Получатель выбирает одну версию, сенсор — другую. Если IDS принимает «первый выигрывает», а стек — «последний выигрывает», полезная нагрузка проходит мимо правила.

# фрагментация при отправке
nmap -f --data-length 24 -p 80 192.0.2.20

TTL, контрольные суммы, опции

Некоторые сенсоры отбрасывают пакеты с неверной контрольной суммой, а некоторые стеки принимают. Некоторые проверяют TTL и отбрасывают «невозможные» значения. Расхождение в любом из этих решений — канал.

Опции IP и TCP тоже разбираются по-разному: один сенсор пропускает пакет с опцией, другой считает его подозрительным. Само наличие необычной опции — признак, поэтому уклонение часто выглядит как «сделать пакет максимально обычным», а не максимально странным.

Уклонение на уровне приложения

Кодирование и нормализация

Сигнатура ищет строку union select. Если запрос закодирован в URL, base64 или UTF-16, сигнатура не сработает, а приложение декодирует и выполнит. Защита — нормализация до применения правил: Suricata умеет декодировать url, base64, utf16 и применять правила к результату.

alert http any any -> any any (msg:"SQLi union select"; \
  http.uri; content:"union"; nocase; content:"select"; nocase; distance:0; \
  classtype:web-application-attack; sid:1000100; rev:1;)

Правило без нормализации ловит только открытый текст. С http.uri движок сам декодирует URL, но не base64 в параметре.

Медленность и распределённость

Сигнатура срабатывает на событие, а не на его отсутствие. Скан, растянутый на сутки, не превышает порог «много за минуту». Логин-перебор с одной попыткой в час не выглядит как атака. Уклонение через темп — самое дешёвое и самое трудное для обнаружения.

Шифрование как универсальный обход

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

Анализ трафика и профили

Размеры, тайминг, JA3 и beaconing

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

tshark -r c2.pcap -Y "tcp.flags.syn==1 && tcp.flags.ack==0" \
  -T fields -e frame.time_epoch -e ip.dst | head -20

Методика разбора захвата и восстановления временных рядов разобрана у Сэндерса ⁶. По этим меткам времени видно интервалы. Среднее и стандартное отклонение интервалов — простейший детектор.

Стеганография в DNS, ICMP и HTTP

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

Анти-форензика

Журналы, время и целостность

После инцидента остаются журналы: syslog, NetFlow, Zeek, pcap. Анти-форензика пытается их исказить: удалить записи, изменить метки времени, подменить pcap. Каждое действие оставляет след: пропуск в нумерации, несоответствие времени, несовпадение контрольных сумм.

journalctl --since "2026-10-19 10:00" --until "2026-10-19 11:00"
sha256sum capture.pcap

Хеш фиксирует целостность файла; цепочка доказательств требует, чтобы хеш был снят до анализа и хранился отдельно.

Что выдаёт правку

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

Инженерия обнаружения

Правила Suricata и скрипты Zeek

Приёмы уклонения классифицированы в матрице ATT&CK ⁷; хорошее правило описывает не атаку, а инвариант: «HTTP-запрос не должен содержать одновременно union и select в URI», «DNS-запрос не должен иметь метку длиннее 50 символов». Инвариант устойчив к вариантам.

alert dns any any -> any any (msg:"DNS long label"; \
  dns.query; pcre:"/^[^.]{50,}\./"; \
  threshold: type limit, track by_src, count 1, seconds 60; \
  classtype:bad-unknown; sid:1000200; rev:1;)

Базовые линии

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

cat conn.log | zeek-cut id.orig_h id.resp_h id.resp_p | \
  sort | uniq -c | sort -rn | head -20

Числа: порог, окно и цена ошибки

Пороговое правило задаётся двумя числами: сколько событий и за какое окно. Правило «30 SYN за 60 секунд» срабатывает на скане со скоростью 0,5 пакета в секунду и выше; чтобы его обойти, нужно опуститься ниже — и тогда полный перебор 65 536 портов занимает больше суток.

Отсюда компромисс: короткое окно ловит быстрые сканы и пропускает медленные, длинное — наоборот, но требует больше памяти и даёт больше ложных срабатываний. На практике ставят два правила: короткое для быстрых атак и длинное для медленных.

Цена ошибки тоже измерима. Сенсор на 10 Гбит/с при среднем размере пакета 500 байт обрабатывает около 2,5 млн пакетов в секунду; при перегрузке он начинает отбрасывать пакеты, и часть трафика проходит без проверки. Поэтому inline-сенсор всегда имеет бюджет производительности, а не «работает, пока хватает».

пакетов/с = 10e9 / (500 * 8) = 2,5e6

Итоги темы

IDS видит копию трафика, а не оригинал; расхождение между копией и получателем — основа уклонения. Фрагментация, перекрытие сегментов и кодирование работают там, где сенсор не нормализует данные до применения правил.

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

Анти-форензика не делает следы невидимыми, а создаёт противоречия; обнаружение строится на инвариантах и базовых линиях, а не на списке сигнатур. Следующая тема выходит за пределы провода — в эфир.

Литература

1. Ziemba G., Reed D., Traina P. Security Considerations for IP Fragment Filtering. — RFC 1858, IETF, 1995. https://www.rfc-editor.org/rfc/rfc1858
2. Ptacek T. H., Newsham T. N. Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection. — Secure Networks Inc., 1998.
3. Scarfone K., Mell P. Guide to Intrusion Detection and Prevention Systems (IDPS). — NIST Special Publication 800-94, 2007. https://doi.org/10.6028/NIST.SP.800-94
4. The Suricata Documentation. — https://docs.suricata.io/
5. The Zeek Documentation. — https://docs.zeek.org/
6. Sanders C. Practical Packet Analysis. 3rd ed. — No Starch Press, 2017.
7. MITRE ATT&CK. Defense Evasion. — https://attack.mitre.org/tactics/TA0005/

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

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

1. Почему сенсор IDS не является точкой, через которую проходит трафик, и как это влияет на обнаружение?
2. Что означает «вставка» и «уклонение» в терминах Птачека и Ньюшема?
3. Почему inline-режим одновременно даёт больше контроля и больше риска?
4. Какие расхождения между сенсором и стеком эксплуатируются чаще всего?
5. Почему сборка фрагментов и нормализация считаются базой, а не улучшением?
6. Как кодирование полезной нагрузки обходит сигнатуру и что этому противопоставляют?
7. Почему медленная атака не видна пороговому правилу?
8. Что остаётся от трафика, если всё содержимое зашифровано?
9. Как отличить джиттер C2 от естественной вариативности?
10. Почему удаление строки из журнала обнаруживается, даже если файл выглядит целым?
11. Что такое базовая линия и почему без неё порог произволен?
12. Почему правило-инвариант устойчивее правила-сигнатуры?

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

IDS — система обнаружения вторжений, работающая на копии трафика.

IPS — система предотвращения, стоящая в разрыве и способная блокировать.

Нормализация — приведение данных к каноническому виду до применения правил.

Defragmentation — сборка фрагментов перед анализом.

Beaconing — периодические обращения к C2 с характерным интервалом.

JA3/JA4 — отпечатки TLS-клиента.

Fail-open — режим, при котором при сбое трафик пропускается без проверки.

Цепочка доказательств — документированная последовательность работы с данными, подтверждающая их целостность.

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

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

• Ptacek, Newsham — классическая работа об уклонении; читается как первоисточник.
• NIST SP 800-94 — требования к IDS/IPS и их классы.
• Документация Suricata — правила, нормализация, режимы работы.
• Документация Zeek — события, скрипты, журналы.
• RFC 1858 — фрагментация как вектор; коротко и по делу.
• MITRE ATT&CK, Defense Evasion — таксономия приёмов сокрытия.

Углубление

Асимметрия сборки. Разные стеки по-разному выбирают данные при перекрытии: одни предпочитают первый сегмент, другие последний. Сенсор, который не знает политику цели, вынужден выбирать одну, и любая ошибка становится каналом.

Шифрование и метаданные. Даже при полном шифровании остаются размеры пакетов, направления и тайминг. По ним можно отличить интерактивную сессию от передачи файла, а туннель — от обычного HTTPS.

Логи как цель. Атакующий, который хочет скрыть след, сначала смотрит, куда пишутся журналы. Централизованный сбор и неизменяемое хранилище делают локальную правку бесполезной; именно поэтому архитектура важнее настроек.

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

Лабораторная работа 8. Тихий след

• Раздел курса: апокриф 8 «Тихий след: уклонение от IDS и анти-форензика»

Введение

Работа ставит сенсор между клиентом и сервером и проверяет, что он видит, а что пропускает. Сначала правило ловит открытую атаку, затем та же атака проходит во фрагментах, затем правило исправляется. Отдельные части посвящены профилю C2-канала, DNS-туннелю и искажению журнала.

Если Suricata недоступна, её роль выполняет tshark с фильтрами: результат воспроизводим, но без встроенной нормализации, и это ограничение фиксируется в журнале.

Цель работы

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

• поднять сенсор в разрыве и проверить, что трафик проходит;
• написать правило Suricata и убедиться, что оно срабатывает;
• обойти правило фрагментацией и перекрытием сегментов;
• исправить правило так, чтобы обход перестал работать;
• найти DNS-туннель скриптом Zeek по длине и энтропии;
• построить профиль beaconing и подобрать порог;
• исказить журнал и найти признаки правки;
• найти и исправить ошибку в пороговом детекторе.

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

Разделы теории «Как устроены IDS/IPS», «Уклонение на уровне сети и транспорта», «Уклонение на уровне приложения», «Инженерия обнаружения».

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

Уровень воспроизводимости: 2 — Suricata и Zeek; 0 — разбор готового pcap.

Linux с suricata, zeek, tshark, nmap, python3, tc. Всё в unshare -rnm. Для IPS-части нужен транзитный узел: sensor — маршрутизатор между двумя парами veth, трафик проходит через хук forward, где стоит правило queue.

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

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

Часть 1. Сенсор и первое правило

Задание

Собрать сегмент client — sensor — server. На sensor включить пересылку, завести транзитный трафик в очередь netfilter и запустить Suricata в IPS-режиме:

ip netns exec sensor sysctl -w net.ipv4.ip_forward=1
ip netns exec sensor nft add table inet ips
ip netns exec sensor nft add chain inet ips forward '{ type filter hook forward priority 0; policy accept; }'
ip netns exec sensor nft add rule inet ips forward queue num 0
ip netns exec sensor suricata -q 0 -c /etc/suricata/suricata.yaml >/tmp/suricata.log 2>&1 &
echo $! > /tmp/suricata.pid
sleep 2

Написать правило на HTTP-запрос с параметром cmd=:

alert http any any -> any any (msg:"HTTP cmd parameter"; \
  http.uri; content:"cmd="; nocase; \
  classtype:web-application-attack; sid:1000300; rev:1;)

Проверить:

ip netns exec client curl -s "http://192.0.2.20/?cmd=id"
grep 1000300 /var/log/suricata/fast.log

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

Правило срабатывает, в журнале есть запись с sid. Записать, какие поля правила отвечают за протокол, направление и содержимое. Действие alert в IPS-режиме пропускает пакет; чтобы заблокировать, в правиле меняется alert на drop — проверить это отдельным запуском.

Часть 2. Обход фрагментацией

Задание

Повторить запрос, разбив TCP-сегмент на мелкие фрагменты:

ip netns exec client nmap -f --data-length 8 -p 80 192.0.2.20

Для HTTP-запроса удобнее собрать пакеты вручную:

from scapy.all import IP, TCP, Raw, send, fragment
pkt = IP(dst="192.0.2.20") / TCP(dport=80, flags="PA") / \
      Raw(b"GET /?cmd=id HTTP/1.0\r\nHost: x\r\n\r\n")
for f in fragment(pkt, fragsize=16):
    send(f)

Снять захват на сенсоре и проверить, сработало ли правило.

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

Правило не срабатывает: первый фрагмент не содержит строки cmd=. Объяснить, что должен сделать сенсор, чтобы поймать запрос.

Часть 3. Исправление правила

Задание

Включить сборку фрагментов в конфигурации Suricata (defrag: yes) и повторить часть 2. Затем добавить правило, которое ловит саму фрагментацию как признак:

alert ip any any -> any any (msg:"Tiny fragment"; \
  ip.frag_offset; less than 8; \
  classtype:bad-unknown; sid:1000301; rev:1;)

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

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

Часть 4. Перекрытие сегментов

Задание

Отправить два TCP-сегмента с одинаковым смещением и разными данными: первый без полезной строки, второй с ней. Проверить, что видит сенсор и что получает сервер.

from scapy.all import IP, TCP, Raw, send
ip = IP(dst="192.0.2.20")
t1 = TCP(sport=40000, dport=80, flags="PA", seq=1000) / Raw(b"GET / HTTP/1.0\r\n")
t2 = TCP(sport=40000, dport=80, flags="PA", seq=1000) / Raw(b"GET /?cmd=id HTTP/1.0\r\n")
send(ip / t1); send(ip / t2)

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

Сервер обрабатывает одну версию, сенсор — другую; правило срабатывает или нет в зависимости от политики сборки. Сформулировать, какая политика безопаснее и почему.

Часть 5. DNS-туннель и Zeek

Задание

Поднять DNS-туннель из темы 05 и написать скрипт Zeek, который помечает имена с длиной метки больше 50:

event dns_request(c: connection, msg: dns_msg, query: string, qtype: count, qclass: count)
    {
    local labels = split_string(query, /\./);
    if ( |labels| > 0 && |labels[0]| > 50 )
        print fmt("long label: %s from %s", query, c$id$orig_h);
    }

Запустить:

zeek -r tunnel.pcap local script.zeek

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

Zeek печатает длинные метки; обычный трафик не помечен. Объяснить, почему порог по длине работает не на всех туннелях и что добавляет энтропия.

Часть 6. Профиль beaconing

Задание

Сгенерировать трафик с фиксированным интервалом и с джиттером, затем сравнить интервалы:

for i in $(seq 1 20); do curl -s -o /dev/null http://192.0.2.20/; sleep 5; done

Снять захват и вычислить интервалы:

tshark -r beacon.pcap -Y "http.request" -T fields -e frame.time_epoch | \
  python3 -c "import sys; t=[float(x) for x in sys.stdin]; print([round(b-a,2) for a,b in zip(t,t[1:])])"

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

Интервалы почти одинаковы; при добавлении случайной задержки (sleep 5.$RANDOM) разброс растёт. Объяснить, почему джиттер не делает канал невидимым и какой признак остаётся.

Часть 7. Искажение журнала

Задание

Записать несколько событий в файл, зафиксировать хеш, удалить одну строку и сравнить:

printf "event1\nevent2\nevent3\n" > /tmp/audit.log
sha256sum /tmp/audit.log
sed -i '/event2/d' /tmp/audit.log
sha256sum /tmp/audit.log

Затем восстановить строку и проверить, совпадает ли хеш.

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

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

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

Задание

Детектор должен срабатывать на 30 запросов в минуту от одного источника, но срабатывает на каждый запрос:

alert http any any -> any any (msg:"too many requests"; \
  threshold: type limit, track by_src, count 30, seconds 60; \
  sid:1000400; rev:1;)

Найти причину: type limit ограничивает частоту алертов, а не считает события. Заменить на type both или type threshold и объяснить разницу.

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

Правило, которое срабатывает на 30-м запросе, и объяснение трёх режимов threshold.

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

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

1. Почему IDS видит не то же, что получатель?
2. Чем вставка отличается от уклонения?
3. Почему сборка фрагментов обязательна для правил?
4. Что такое перекрытие сегментов и как его обрабатывают разные стеки?
5. Почему нормализация важнее количества сигнатур?
6. Как темп активности обходит пороговые правила?
7. Что остаётся видимым в шифрованном канале?
8. Почему джиттер сам становится признаком?
9. Как Zeek помогает найти туннель, который Suricata пропускает?
10. Что доказывает хеш файла и чего он не доказывает?
11. Чем type limit отличается от type both?
12. Как строится базовая линия для детектора аномалий?

Уборка

kill "$(cat /tmp/suricata.pid)" 2>/dev/null || true
ip netns exec sensor nft delete table inet ips 2>/dev/null || true
pgrep -a "suricata|zeek|tshark" || true
for n in client server sensor; do ip netns del $n 2>/dev/null; done
ip link del br0 2>/dev/null
rm -f tunnel.pcap beacon.pcap /tmp/audit.log script.zeek