Dotaz: Ktery proces dela udp query port 53

[MP]

Ahoj,

mam mailovy server s postfix+opendkim+dovecot+amavis+spamassassin+clamav. Docela si ted lamu hlavu, ktery z techto procesu ignoruje resolv.conf a dela si vlastni lookup. Hledal jsem a zkousel co jsem mohl (krome auditd a podobnych technik) a tim odchytit nelze nic (tcpdump bohuzel proces neukaze, netstat taky nechytne apod). Nevi nekdo jak to dohledat?

Diky, M.

---

---

Odpovědi

[majales]

Zdravím. Bylo by dobré ještě uvést distribuci a verzi.. v současné době se toho dost mění, viz např. systemd-resolved v Ubuntu 18 LTS, který nahrazuje starší resolvconfd. A jak se to projevuje s tím "neukázněným" lookupem? Čím více to osvětlíte, tím snáz to půjde rozluštit..

[MP]

Jo pardon. Debian 8 bez systemd.

12:47:26.277334 IP X.12033 > c.gtld-servers.net.domain: 48675% [1au] A? miat.com. (37)
12:47:26.277555 IP X.36698 > m.gtld-servers.net.domain: 41093% [1au] AAAA? miat.com. (37)
12:47:26.277660 IP X.23231 > i.gtld-servers.net.domain: 42459% [1au] MX? miat.com. (37)
12:52:47.272427 IP X.57694 > ns4-208.azure-dns.info.domain: 37846% [1au] TXT? selector1-batashoeorganization-onmicrosoft-com._domainkey.batashoeorganization.onmicrosoft.com. (123)      
12:52:47.314011 IP ns4-208.azure-dns.info.domain > X.57694: 37846*- 1/0/1 TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCrZKTAXRNPuqgg2V82jK+050KRORyjEBmZWDbDZPTVDhEsls+//jta3VrKs2ONzQXrb4OWcGXFOupWCroQ+W5Ymo5sX92QeXIvYeNKWuJ2AxxqffFgde1KtU00w+YyH4pCwFMVjBh+c9VMJt09eKbYzJw8CBocqDGT4MfcV5AgfQIDAQAB;" (371)  

Kdyz zakazu pristup na dns, tak zatim jsem si vsiml, ze dkim timeoutuje, ale nemam stopro jistotu, ze je to jen timhle. Provereni dkim/postfix na nastaveni resolvingu - vse je na default z balicku, cili dns...

[a1bert]

tohle by ti to hledani mohlo trochu "zuzit"

iptables -I OUTPUT -j LOG -p udp --dport 53 --log-uid

[MP]

Bohuzel, unknown option --log-uid

[alkoholik]

Podezrele. Prozradis nam vystup iptables -j LOG --help ?

[MP]

Tak oprava, skutecne tam ten parametr je. A co jsem ted testoval, je to reseni me otazky, jak zjistit proces.

[drunkezz]

tipol by som ze lsof alebo ss alebo ked nie autitctl tak systemtap to urcite chytia

D>

[Michal Kubeček]

Audit bude asi nejjednodušší, asi by šlo použít i kprobe, ale to by bylo komplikovanější. V každém případě je ale potřeba dávat pozor na to, že je potřeba hlídat sendmsg() i connect(), protože je na aplikaci, jestli použije connected socket nebo ne.

[pc2005]

strace by mohl chytit otevření socketu.

[Michal Kubeček]

Těžko říct, co myslíte "otevřením", ale (1) ze socket() to nepoznáte, (2) connect() tam nemusí být a hlavně (3) na použití strace byste potřeboval vědět, který proces vás zajímá - což je přesně ta informace, kterou se tazatel snaží zjistit.

[pc2005]

3) zná množinu možných kandidátů, dokonce má hlavního kandidáta. Takže se dá porovnávat čas ze strace s výskytem paketu z třeba tcpdump.

[Aleš Kapica]

Vylistování stavu portů (vybrané porty):

root@stroj~# netstat -tupan
tcp        0      0 0.0.0.0:111             0.0.0.0:*               NASLOUCHÁ  547/rpcbind
…
tcp6       0      0 :::111                  :::*                    NASLOUCHÁ  547/rpcbind
…
udp        0      0 0.0.0.0:111             0.0.0.0:*                           547/rpcbind
…
udp6       0      0 :::111                  :::*                                547/rpcbind
…
udp6       0      0 :::723                  :::*                                547/rpcbind
…

Vylistování procesů používajících určité číslo portu:

root@stroj~# lsof -i :111
COMMAND PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
rpcbind 547 root    6u  IPv4  17986      0t0  UDP *:sunrpc 
rpcbind 547 root    8u  IPv4  17087      0t0  TCP *:sunrpc (LISTEN)
rpcbind 547 root    9u  IPv6  17088      0t0  UDP *:sunrpc 
rpcbind 547 root   11u  IPv6  17090      0t0  TCP *:sunrpc (LISTEN)

[Michal Kubeček]

Nebo rovnou použít "ss -nup dport == :53". Jenže problém je v tom, že na DNS dotaz, který typicky obnáší jeden paket s dotazem a jeden paket s odpvoědí, nepotřebujete connected socket a i když ho aplikace použije, stejně nemáte záruku, že se trefíte zrovna do toho krátkého okna, když ten socket bude existovat a bude connected.

[Filip Jirsák]

Není mi úplně jasné, jak jste přišel na to, že nějaký proces ignoruje resolv.conf. To máte resolv.conf nakonfigurovaný tak, že DNS názvy překládáte pomocí DNS serveru, který běží na jiném portu, než 53? Nebo dokonce používáte jiný protokol? Můžete uvést, jak konkrétně máte resolv.conf nastavený?

[MP]

Jednoduse, dns servery pro lokalni sit jsou na lokalni siti, ale vyse uvedene requesty jsou zachyceny jednak pres tcpdump na externi sitovce, jednak na centralnim firewallu.

resolv.conf:

search domain.tld
nameserver X.X.X.X
nameserver Y.Y.Y.Y

X/Y jsou na stejnem subnetu jako dns servery.

[Filip Jirsák]

Že jsou ty požadavky zachycené na síťovce toho stroje (předpokládám, že to myslíte „externí síťovkou“) je samozřejmé, resolver se přece musí zeptat ven, ve vašem případě DNS serverů v lokální síti. U paketů zachycených na centrálním firewallu (předpokládám mezi lokální sítí a internetem) záleží na tom, zda mají jako zdroj přímo váš počítač nebo ten lokální DNS server. V druhém případě by to opět bylo normální, v prvním případě byste měl začít kontrolou toho, jak máte nastavený lokální resolver. Vy jste uvedl konfiguraci /etc/resolv.conf, ale ještě je potřeba zjistit, zda resolver tuto konfiguraci používá.

[MP]

Takze jeste jednou.

Ve stroji jsou 2 sitovky:

a] interni pres kterou maji jit dns requesty na interni dns servery. Ty tam chodi.

b] externi (verejna ip), dotazy z teto sitovky (ip) jsou registrovany na tcpdumpu i na centralnim firewallu z dane externi ip

nsswitch.conf

hosts: files dns
networks: files

Vzhledem k bodu a] lokalni resolver funguje spravne.

[GeorgeWH]

Ved si grep-ni /etc na tu IP dns servera, kam smeruju requesty. Ak ju system pouziva, tak ju niekde musi mat nastavenu.

[alkoholik]

Optimisto:

Nameservers (string)

Provides a comma-separated list of IP addresses that are to be used when doing DNS queries to retrieve DKIM keys, VBR records, etc. These override any local defaults built in to the resolver in use, which may be defined in /etc/resolv.conf or hard-coded into the software.

[GeorgeWH]

No ved len strielam od brucha, kedze viac info nemame. A za pokus to stoji.

[Bherzet]

Kdyz vidi v tcpdumpu dotazy na DKIM klice, tak je skoro jiste, ze to mu dela OpenDKIM.
Nevybavuju si, ze bych krome Bindu videl jeste nekde hardcodovane DNS servery.

[MP]

Ano, zasah do cerneho, byl to opendkim, jak jsem tusil. Velmi nenadsene jsem teda "hardcodoval" ip pro dns servery do konfigurace. Nesnasim hardcodovane ip.

Vyreseno.

[lertimir]

Prostě si to napsal do konfigurace.

[Filip Jirsák]

Takze jeste jednou.

To není „ještě jednou“, to poprvé píšete informace, které měly být už v původním dotazu.

OK, informace o konfiguraci systému zveřejňovat nechcete a máte nějaký důvod myslet si, že problém je v nějaké aplikaci a ne v resolveru. Vzhledem k tomu, že máte nějakou nestandardní konfiguraci Debianu 8, je docela odvážné takhle rovnou odstřihnout jednu ze dvou možných příčin problému, ale to je váš problém. Pak mi jako nejpoužitelnější řešení připadá to výše uvedené s logováním paketů spolu s identifikátorem procesu v iptables – a pokud vám příslušný modul v iptables chybí, budete ho asi muset doinstalovat.

[lertimir]

Souhlas s tím co napsal Filip. Úvaha, že nějaký z uvedených procesů ignoruje resolv.conf, je založena na nějakých vstupních informacích, které uvedeny nebyly, a je chybná. Resolver, tedy proces/knihovna, který se dotazuje DNS, by měl být funkční jen jeden v systému. Žádná z těch aplikací vlastní resolving nedělá, aplikace požádá resolver, aby lookup vyřešil a vrátil výsledek. Problém by mohl být v tom, že z nějakého důvodu jsou funkční dva resolvery s jinou konfigurací, i když moc nevím jak. Možná současně je uveden externí DNS systém v resolv.conf a současně cachující rekurzivní DNS server běžící na systému. Ale zatím je to věštění z křištálové koule. Na analýzu by bylo potřeba popsat problém, co se skutečně děje. A výpisy resolv.conf, ps -ef, a popřípadě záchyt tcpdump s cílovým portem 53.

[MP]

Zadny typ dns serveru/proxy na tom stroji nebezi.

Mimochodem, zrovna postfix ma parametr, kterym se da ignorovat defaultni dns. Obdobne opendkim, atd.

[lertimir]

Jenže pak to musím napsat explicitně do konfigurace a pokud budu vědět kam se ptá tak bych to v konfiguracích měl najít. Ani nevíme, jak se ptá? má jeden server cizi, který mu má dělat rekurzi. Nebo dělá iterativní doptávání od rootových serverů. Na co se ptá? na A, MX? nebo ještě na něco jiného?

[MP]

Tcpdump odchycenych requestu je kousek pod mym uvodnim prispevkem. Pta se na A, MX, dkim klice atd.