LINUX.ORG.RU

Linux, Debian, Jessie - понять какое приложение шлет DNS запросы

 ,


0

2

Всем привет!

Озадачился тут интересной ситуацией касательно «полтергейста» с ДНС запросами от Linux хоста. Постараюсь объяснить кратко и ёмко - есть Linux Debian Jessie:

No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux 8.3 (jessie)
Release:	8.3
Codename:	jessie

# uname -a
Linux rep 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u2 (2016-01-02) x86_64 GNU/Linux

Живет этот линукс на KVM виртуалке. Всё, что установлено на этом хосте, было поставлено туда через apt-get/dpkg с официальных репозиториев. Инет этот хост видит строго через NAT, напрямую в Инет не торчит. ДНС сервер в /etc/resolv.conf прописан локальный, из той же сети что и хост (хост - 192.168.80.102, днс сервер - 192.168.80.101). Недавно, чисто случайно, включив полное логирование ДНС обращений на ДНС сервере 192.168.80.101 обратил внимание что хост 192.168.80.102 (тот самый про который идет речь) периодически пытается отрезолвить хосты google.com, security.debian.org, packages.debian.org и др. Выглядит это примерно вот так в логах unbound, который и является резолвером -

Mar 30 15:35:29 192.168.80.101 unbound: [6109:0] info: 192.168.80.102 packages.debian.org. A IN
Mar 30 15:35:29 192.168.80.101 unbound: [6109:0] info: 192.168.80.102 packages.debian.org. AAAA IN
Mar 30 15:35:29 192.168.80.101 unbound: [6109:0] info: 192.168.80.102 ftp.us.debian.org. A IN
Mar 30 15:35:29 192.168.80.101 unbound: [6109:0] info: 192.168.80.102 ftp.us.debian.org. AAAA IN
Mar 30 15:35:44 192.168.80.101 unbound: [6109:0] info: 192.168.80.102 www.google.com. A IN
Mar 30 15:35:44 192.168.80.101 unbound: [6109:0] info: 192.168.80.102 www.google.com. AAAA IN
Mar 30 15:35:44 192.168.80.101 unbound: [6109:0] info: 192.168.80.102 www.google.nl. A IN
Mar 30 15:35:44 192.168.80.101 unbound: [6109:0] info: 192.168.80.102 www.google.nl. AAAA IN
Mar 30 15:36:25 192.168.80.101 unbound: [6109:0] info: 192.168.80.102 ftp.uk.debian.org. A IN
Mar 30 15:36:25 192.168.80.101 unbound: [6109:0] info: 192.168.80.102 ftp.uk.debian.org. AAAA IN
Mar 30 15:36:41 192.168.80.101 unbound: [6109:0] info: 192.168.80.102 security.debian.org. A IN
Mar 30 15:36:41 192.168.80.101 unbound: [6109:0] info: 192.168.80.102 security.debian.org. AAAA IN
Mar 30 15:36:41 192.168.80.101 unbound: [6109:0] info: 192.168.80.102 ftp.uk.debian.org. A IN
Mar 30 15:36:41 192.168.80.101 unbound: [6109:0] info: 192.168.80.102 ftp.uk.debian.org. AAAA IN

То же самое мне говорит и Suricata, которая настроена у меня в роли IDS в PASS-режиме и которая установлена на еще одной, соседней виртуалке, и видит весь трафик через «iptables TEE» для анализа.

Два дня я пытался выяснить - а что же это происходит на хосте, что пытается всё время резолвить google.com/.nl, а еще *.debian.*. Решил начать с *.debian.* - думал может какой скрипт через крон проверяет обновления. Но у меня используется локальный репозиторий и домены *.debian.* вообще нигде не фигурируют -

# grep -ri debian .
Binary file ./trusted.gpg.d/debian-archive-jessie-automatic.gpg matches
Binary file ./trusted.gpg.d/debian-archive-jessie-security-automatic.gpg matches
Binary file ./trusted.gpg.d/debian-archive-squeeze-stable.gpg matches
Binary file ./trusted.gpg.d/debian-archive-squeeze-automatic.gpg matches
Binary file ./trusted.gpg.d/debian-archive-wheezy-automatic.gpg matches
Binary file ./trusted.gpg.d/debian-archive-wheezy-stable.gpg matches
Binary file ./trusted.gpg.d/debian-archive-jessie-stable.gpg matches
#

На хосте стоит apt-mirror, но отключен в /etc/cron.d/apt-mirror.

Потом полез изучать кто же так усердно пытается отрезолвить google. Залез в /etc, сделал поиск, но и тут тишина -

# cd /etc/
root@rep:/etc# grep -ri google .
./grub.d/05_debian_theme:# Copyright (C) 2010  Alexander Kurtz <kurtz.alex@googlemail.com>
./mime.types:application/vnd.google-earth.kml+xml						kml
./mime.types:application/vnd.google-earth.kmz						kmz
./nginx/mime.types:    application/vnd.google-earth.kml+xml  kml;
./nginx/mime.types:    application/vnd.google-earth.kmz      kmz;

Дальше вообще отключил cron, но логи на ДНС сервере опять появляются.

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

Я пошел дальше и поставил на хосте snoopy (логирует все запуски через execve в системе) - ничего не обнаружено. Поставил на роутере tcpdump, через который хост видит Инет - кроме ДНС запросов к локальному ДНС ничего больше не происходит, то есть траф больше никакой никуда не идет.

Также, в этой же локалке, поднята еще пачка схожих ВПСок на Debian Jessie со схожим конфигом - у них таких аномалий не замечено.

★★★

Ответ на: комментарий от anonymous

А как посмотреть куда шлет ДНС запросы systemd? Я ультраконсервативный товарищ, systemd для меня еще диковинка =)

FreeBSD ★★★ ()
Ответ на: комментарий от FreeBSD

можно посмотреть tcpdump-om трафик на 53 порт udp и через «fuser -vn udp <номер порта>» посмотреть что за процесс. Но это будет работать только с долго работающими процессами.

С другой стороны, если временно в dns-е подменить некоторые имена на недоступные ip ( или зафильтровать к ним доступ), то посмотреть кто к ним обращается будет проще (netstat -tnp) - tcp-коннект обычно долго выполняется.

А в хронтабе нет каких-нибудь заданий на проверку обновлений ?

vel ★★★★★ ()
Последнее исправление: vel (всего исправлений: 1)
Ответ на: комментарий от vel

С другой стороны, если временно в dns-е подменить некоторые имена на недоступные ip ( или зафильтровать к ним доступ), то посмотреть кто к ним обращается будет проще (netstat -tnp) - tcp-коннект обычно долго выполняется.

В том то и дело, что днс через UDP работает, а там всё по-быстрому - отправил себе пакет и ничего ждать не надо =)

А в хронтабе нет каких-нибудь заданий на проверку обновлений ?

Нету ничего, я даже останавливал крон для проверки.

В общем похоже нужно зубрить на тему auditd и уже смотреть дальше, других вариантов пока не вижу.

FreeBSD ★★★ ()

Скриптик с чем-то вроде netstat -utvpn | awk '{print $5,$7}' | grep ':53' и дальнейшим отловом pid'а может помочь. Но если слишком кратковременно, то тут уже надо бы логгирование налаживать на все исходящие пакеты. Не скажу сейчас, может ли такое iptables по owner'у делать, но в теории можно все запросы на udp/tcp:53 ловить.

shell-script ★★★★★ ()
Ответ на: комментарий от FreeBSD

auditd ничего не поймал - по ходу он ловит только заново запускаемые процессы, например nslookup он отловил, а вот то что делало резолвы google - нет.

Пришлось ставить SystemTap. Дальше воспользовался советом отсюда (auditd тоже кстати отсюда) - http://serverfault.com/questions/192893/how-i-can-identify-which-process-is-m...

Оказалось запросы шлет NSCD, который стоит у меня для авторизации по LDAP. Заменил ему конфиг на такой же как и на других соседних хостах, вроди перестал ломиться.. Не знаю как, но похоже он как то надолго закешил что я когда-то резолвил google.com и после этого он пытался опять их отрезолвить даже спустя несколько дней.

Теперь будем знать про такую адскую вещь как SystemTap =)

FreeBSD ★★★ ()
Ответ на: комментарий от shell-script

Ну так в том то и проблема изначально что залогировать пакеты и их содержимое - не проблема. Проблема была в том чтобы найти источник. С задачей справился только SystemTap.

FreeBSD ★★★ ()
Ответ на: комментарий от FreeBSD

я был удивлен, что в iptables -j LOG нет опции типа --log-pid для локально отправляемых пакетов. uid/gid - есть, в pid - нет, хотя инфо берется из одной структуры.

vel ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.