Утечка запросов к службе имён: проверка своими руками

Надоело верить сайтам-проверялкам. Заходишь на такой, он рисует зелёную галку, и что дальше? Он видит один свой запрос из браузера, а у меня прогон на десять часов, три утилиты и системный планировщик сверху.

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

Первую половину я нащупал, дальше буксую: часть имён всё равно вылезает, и я не понимаю, кто их спрашивает.

sudo tcpdump -nn -i any port 53

Направление верное, доводить его надо в три шага.

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

а как понять кто именно спросил, там же только адрес машины

Так и сделал, стало намного тише. Настя Лужина, хороший вопрос, я его тоже задавал: по дампу процесс не виден, нужен другой инструмент.

Инструмент вот, ловит имя процесса прямо на системном вызове.

sudo bpftrace -e 'tracepoint:syscalls:sys_enter_sendto /args->addr != 0/ { printf("%s %d\n", comm, pid); }'

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

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

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

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

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

#!/bin/bash
set -e
resolvectl flush-caches
timeout 60 tcpdump -nn -i any -c 1 'port 53 or port 853' > /tmp/leak.txt 2>/dev/null &
SNIF=$!
curl -s -o /dev/null --proxy socks5h://10.0.0.5:1080 https://example.org/
wait $SNIF || true
if [ -s /tmp/leak.txt ]; then echo "на проводе шум, прогон не запускаем"; exit 1; fi
echo "тихо, поехали"

спасибо, забрала себе скрипт

Добавлю сбоку, раз тема живая. Вся эта возня с буквой h имеет смысл только тогда, когда посредник сам умеет разбирать имена и делает это на своей стороне. По сокетной схеме такое работает нормально, по схеме http для шифрованных сайтов тоже, потому что имя уезжает в команде на открытие трубы.

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

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

Про две машины точно подмечено. Я в такие моменты держу сторожа прямо в планировщике на обеих, отчёт падает в общий журнал, расхождение видно сразу.

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

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

netmon, допиши в памятку сброс кеша браузера отдельно. Он держит своё соответствие имён и адресов в памяти вкладки, и первые минут двадцать после правки конфига картина будет старой.