[SOLVED] DNS query to Barak-Online.net every 5 mins
-
ah. thank you. Its shutdown now.
All i have running is bsnmp, dhcp and dnsmasq…....
If this doesn't work, I will plug in a monitor and keyboard and disconnect all network connections except wan.
-
OK - Here is the latest.
1. After adding a monitor and keyboard to pfsense, I disconnected the LAN interface.
– No DNS requests sent to that domain [barak-online.net], or any for that matter - Good, and expected. However…...
2. I was curious to know if just a link up on the LAN port would do anything. So, I grabbed an old netgear 4 port hub and attached to the LAN interface on pfsense. Note: there are NO HOSTS on the hub.
-- Right away I seen DNS queries on the WAN side to Barak-Online.net - WTH?
-- I then disconnected to confirm. Yep, queries stopped.3. Still attached to the hub, I changed the IP addr on the LAN to 0.0.0.0/32
-- Right away, dns queries went out again
My thoughts: I am now pretty sure it is coming from the router/pfsense. No hosts attached with just a link up indication on pfsense router is sending dns queries.
Trying to find what process is sending them, but not sure how to trace that. Maybe something to monitor sockstat and grab it when that process start the dns query?
Any ideas would be appreciated. Hope I provided enough detail, if not, just ask and I will gather.
Thanks
-
forgot to add what is running right now:
# ps -aux USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 11 200.0 0.0 0 32 ?? RL Mon06PM 4625:11.91 [idle] root 0 0.0 0.0 0 224 ?? DLs Mon06PM 2:56.95 [kernel] root 1 0.0 0.0 3200 584 ?? ILs Mon06PM 0:00.01 /sbin/init -- root 2 0.0 0.0 0 16 ?? DL Mon06PM 0:00.02 [g_event] root 3 0.0 0.0 0 16 ?? DL Mon06PM 0:04.76 [g_up] root 4 0.0 0.0 0 16 ?? DL Mon06PM 0:02.73 [g_down] root 5 0.0 0.0 0 16 ?? DL Mon06PM 0:00.00 [crypto] root 6 0.0 0.0 0 16 ?? DL Mon06PM 0:00.00 [crypto returns] root 7 0.0 0.0 0 16 ?? DL Mon06PM 0:00.00 [sctp_iterator] root 8 0.0 0.0 0 16 ?? DL Mon06PM 0:00.66 [pfpurge] root 9 0.0 0.0 0 16 ?? DL Mon06PM 0:00.00 [xpt_thrd] root 10 0.0 0.0 0 16 ?? DL Mon06PM 0:00.00 [audit] root 12 0.0 0.0 0 384 ?? WL Mon06PM 5:13.19 [intr] root 13 0.0 0.0 0 32 ?? DL Mon06PM 0:00.00 [ng_queue] root 14 0.0 0.0 0 16 ?? DL Mon06PM 0:04.93 [yarrow] root 15 0.0 0.0 0 512 ?? DL Mon06PM 0:02.77 [usb] root 16 0.0 0.0 0 16 ?? DL Mon06PM 0:01.04 [acpi_thermal] root 17 0.0 0.0 0 16 ?? DL Mon06PM 0:00.02 [acpi_cooling0] root 18 0.0 0.0 0 16 ?? DL Mon06PM 0:00.08 [pagedaemon] root 19 0.0 0.0 0 16 ?? DL Mon06PM 0:00.00 [vmdaemon] root 20 0.0 0.0 0 16 ?? DL Mon06PM 0:00.00 [pagezero] root 21 0.0 0.0 0 16 ?? DL Mon06PM 0:00.09 [idlepoll] root 22 0.0 0.0 0 16 ?? DL Mon06PM 0:00.28 [bufdaemon] root 23 0.0 0.0 0 16 ?? DL Mon06PM 0:13.43 [syncer] root 24 0.0 0.0 0 16 ?? DL Mon06PM 0:00.28 [vnlru] root 25 0.0 0.0 0 16 ?? DL Mon06PM 0:00.34 [softdepflush] root 38 0.0 0.0 0 32 ?? DL Mon06PM 0:00.65 [zfskern] root 69 0.0 0.0 0 16 ?? DL Mon06PM 0:00.13 [md0] root 260 0.0 0.0 6908 1396 ?? INs Mon06PM 7:44.88 /usr/local/sbin/check_reload_status root 262 0.0 0.0 6908 1284 ?? IN Mon06PM 0:00.00 check_reload_status: Monitoring daemon of check_reload_status root 271 0.0 0.1 5248 3148 ?? Is Mon06PM 0:00.01 /sbin/devd root 776 0.0 0.3 31364 10180 ?? SNs 6:26AM 0:00.90 /usr/sbin/bsnmpd -c /var/etc/snmpd.conf -p /var/run/snmpd.pid root 2881 0.0 0.0 5784 1184 ?? Is Mon06PM 0:00.00 /usr/local/bin/minicron 240 /var/run/ping_hosts.pid /usr/local/bin/p root 3376 0.0 0.0 5784 1232 ?? I Mon06PM 0:00.07 minicron: helper /usr/local/bin/ping_hosts.sh (minicron) root 3649 0.0 0.0 5784 1184 ?? Is Mon06PM 0:00.00 /usr/local/bin/minicron 3600 /var/run/expire_accounts.pid /etc/rc.ex root 4110 0.0 0.0 5784 1232 ?? I Mon06PM 0:00.00 minicron: helper /etc/rc.expireaccounts (minicron) root 4204 0.0 0.0 5784 1184 ?? Is Mon06PM 0:00.00 /usr/local/bin/minicron 86400 /var/run/update_alias_url_data.pid /et root 4675 0.0 0.0 5784 1232 ?? I Mon06PM 0:00.00 minicron: helper /etc/rc.update_alias_url_data (minicron) root 7562 0.0 0.1 15268 3492 ?? Is Mon06PM 0:00.01 /usr/sbin/sshd root 7651 0.0 0.0 7036 1364 ?? Is Mon06PM 0:00.01 /usr/local/sbin/sshlockout_pf 15 root 7655 0.0 0.0 7036 1320 ?? Is Mon06PM 0:00.01 /usr/local/sbin/sshlockout_pf 15 root 7793 0.0 0.0 6872 1560 ?? Is Mon06PM 0:00.00 dhclient: em2 [priv] (dhclient) _dhcp 13741 0.0 0.0 6872 1676 ?? Ss Mon06PM 0:00.61 dhclient: em2 (dhclient) root 16057 0.0 0.0 6956 1680 ?? Ss Mon06PM 0:01.00 /usr/sbin/syslogd -s -c -c -l /var/dhcpd/var/run/log -f /var/etc/sys root 16526 0.0 0.1 27572 6100 ?? S 6:47AM 0:00.10 /usr/local/bandwidthd/bandwidthd root 16787 0.0 0.1 27572 5488 ?? S 6:47AM 0:00.07 /usr/local/bandwidthd/bandwidthd root 16981 0.0 0.1 27572 5296 ?? S 6:47AM 0:00.06 /usr/local/bandwidthd/bandwidthd root 17036 0.0 0.1 27572 5188 ?? S 6:47AM 0:00.07 /usr/local/bandwidthd/bandwidthd root 17085 0.0 0.0 0 0 ?? ZN 6:47AM 0:00.03 <defunct>root 19460 0.0 0.0 7928 1616 ?? Ss Mon06PM 0:00.21 /usr/sbin/cron -s root 19679 0.0 0.2 15264 7164 ?? SNs 6:47AM 0:00.30 /usr/local/bin/ntpd -g -c /var/etc/ntpd.conf -p /var/run/ntpd.pid root 20835 0.0 0.1 26168 4564 ?? Ss 8:45AM 0:00.04 sshd: admin@pts/0 (sshd) root 21653 0.0 0.0 0 0 ?? ZN 9:11AM 0:00.10 <defunct>root 23281 0.0 0.0 8984 1552 ?? Is Mon06PM 0:00.01 /usr/sbin/inetd -wW -R 0 -a 127.0.0.1 /var/etc/inetd.conf root 23386 0.0 0.0 2716 968 ?? IN 9:11AM 0:00.00 sleep 55 root 29493 0.0 0.2 17852 7212 ?? Ss Mon06PM 0:00.55 /usr/local/sbin/ipfw-classifyd -n 8 -q 700 -c /tmp/httpShaper.l7 -p root 29674 0.0 0.0 7168 1892 ?? Is Mon06PM 0:00.11 /usr/local/sbin/filterdns -p /var/run/filterdns.pid -i 300 -c /var/e root 38889 0.0 0.0 2716 968 ?? SN 9:11AM 0:00.00 sleep 60 root 49378 0.0 0.1 24220 4728 ?? S Mon06PM 0:01.57 /usr/local/sbin/lighttpd -f /var/etc/lighty-webConfigurator.conf root 49949 0.0 0.5 139048 21868 ?? Is Mon06PM 0:00.05 /usr/local/bin/php root 50115 0.0 0.5 139048 21868 ?? Is Mon06PM 0:00.05 /usr/local/bin/php root 50137 0.0 0.8 141096 32872 ?? I Mon06PM 0:00.13 /usr/local/bin/php root 50649 0.0 1.3 149928 53852 ?? I Mon06PM 0:09.86 /usr/local/bin/php root 60410 0.0 0.1 16312 4540 ?? INs 6:47AM 0:00.00 /usr/pbi/squid-amd64/sbin/squid -D proxy 60764 0.0 0.2 24504 7996 ?? SN 6:47AM 0:00.27 (squid) -D (squid) proxy 61035 0.0 0.0 2716 904 ?? IN 6:47AM 0:00.00 (unlinkd) (unlinkd) root 63739 0.0 0.0 5780 1372 ?? SNs 8:43AM 0:00.00 /usr/local/sbin/dhcpleases -l /var/dhcpd/var/db/dhcpd.leases -d XXX root 72962 0.0 0.0 8296 1864 ?? IN 6:27AM 0:00.09 /bin/sh /usr/local/pkg/sqpmon.sh root 77504 0.0 0.0 3200 928 ?? SNs 6:47AM 0:00.08 /usr/local/sbin/pfflowd -n 192.168.32.189:2055 -s 192.168.32.1 -S an root 79026 0.0 0.0 3200 928 ?? SNs 6:47AM 0:00.08 /usr/local/sbin/pfflowd -n 192.168.32.189:2055 -s 192.168.32.1 -S an root 82176 0.0 0.0 8296 1928 ?? SN 6:26AM 0:00.69 /bin/sh /var/db/rrd/updaterrd.sh root 84975 0.0 0.0 0 0 ?? ZN 9:04AM 0:00.08 <defunct>nobody 85591 0.0 0.1 10100 3184 ?? S 1:03PM 0:00.92 [dnsmasq] root 87814 0.0 0.1 13488 4600 ?? Ss 6:47AM 0:00.04 /usr/local/sbin/openvpn --config /var/etc/openvpn/server1.conf root 88818 0.0 0.0 0 0 ?? ZN 8:44AM 0:00.06 <defunct>dhcpd 89520 0.0 0.3 17104 12500 ?? Ss 1:03PM 0:00.15 /usr/local/sbin/dhcpd -user dhcpd -group _dhcp -chroot /var/dhcpd -c root 7473 0.0 0.0 19480 1844 v0 Is Mon06PM 0:00.01 login [pam] (login) root 7658 0.0 0.0 8296 1800 v0 I Mon06PM 0:00.00 -sh (sh) root 9538 0.0 0.0 8296 1804 v0 I Mon06PM 0:00.00 /bin/sh /etc/rc.initial root 19299 0.0 0.1 11748 3056 v0- S Mon06PM 0:00.90 /usr/sbin/tcpdump -s 256 -v -S -l -n -e -ttt -i pflog0 root 19387 0.0 0.0 5780 1092 v0- S Mon06PM 0:00.20 logger -t pf -p local0.info root 41991 0.0 0.1 8268 2696 v0 I 5:31AM 0:00.01 /bin/tcsh root 42974 0.0 0.1 10212 2828 v0 I+ 5:31AM 0:00.02 bash root 21194 0.0 0.0 8296 1880 0 Is 8:45AM 0:00.00 /bin/sh /etc/rc.initial root 22755 0.0 0.1 8268 2736 0 I 8:45AM 0:00.01 /bin/tcsh root 23778 0.0 0.1 10212 2828 0 S 8:45AM 0:00.01 bash root 38948 0.0 0.0 7992 1544 0 R+ 9:12AM 0:00.00 ps -aux</defunct></defunct></defunct></defunct>I turned the other services back on when I realized they were not the cause.
-
Ok just did a sniff for well over an hour 73 minutes on my wan for dns.. no barak anything..
-
Ok just did a sniff for well over an hour 73 minutes on my wan for dns.. no barak anything..
Arrrgh!!! Thanks for looking.
-
dude this is the strangest thing I have heard of in a long time..
Not sure exactly how you would track it down - with udp being stateless, might be hard to track down the PID via the source port of the traffic. You might get lucking if you can catch it fast enough.. you mention every 5 minutes, is it on the dot every 5.. If so you might be able to time it and catch the pid from the source port of the queries.
In linux something like this would work https://www.rfxn.com/projects/linux-socket-monitor/
But I don't know of how to do this in freebsd currently.
-
Indeed…. one of the oddest things i've seen. The query is "on the button" @ 5 mins.
11:37:49.382567 IP (tos 0x0, ttl 64, id 47829, offset 0, flags [none], proto UDP (17), length 62) 50.150.18.229.64683 > 208.67.222.220.53: 355+ A? barak-online.net. (34) 11:37:49.406707 IP (tos 0x20, ttl 53, id 0, offset 0, flags [DF], proto UDP (17), length 78) 208.67.222.220.53 > 50.150.18.229.64683: 355 1/0/0 barak-online.net. A 62.0.18.221 (50) 11:37:49.406763 IP (tos 0x0, ttl 64, id 40068, offset 0, flags [none], proto UDP (17), length 62) <wan ip="">.42359 > 208.67.222.220.53: 356+ AAAA? barak-online.net. (34) -- 11:42:49.380485 IP (tos 0x0, ttl 64, id 8495, offset 0, flags [none], proto UDP (17), length 62) <wan ip="">.28282 > 208.67.222.220.53: 357+ A? barak-online.net. (34) 11:42:49.407708 IP (tos 0x20, ttl 53, id 0, offset 0, flags [DF], proto UDP (17), length 78) 208.67.222.220.53 ><wan ip="">.28282: 357 1/0/0 barak-online.net. A 62.0.18.221 (50) 11:42:49.407770 IP (tos 0x0, ttl 64, id 46238, offset 0, flags [none], proto UDP (17), length 62) <wan ip="">.63695 > 208.67.222.220.53: 358+ AAAA? barak-online.net. (34) -- 11:47:49.379369 IP (tos 0x0, ttl 64, id 4524, offset 0, flags [none], proto UDP (17), length 62) <wan ip="">.56574 > 208.67.222.220.53: 359+ A? barak-online.net. (34) 11:47:49.404707 IP (tos 0x20, ttl 53, id 0, offset 0, flags [DF], proto UDP (17), length 78) 208.67.222.220.53 ><wan ip="">.56574: 359 1/0/0 barak-online.net. A 62.0.18.221 (50) 11:47:49.404765 IP (tos 0x0, ttl 64, id 63486, offset 0, flags [none], proto UDP (17), length 62) <wan ip="">.35980 > 208.67.222.220.53: 360+ AAAA? barak-online.net. (34) -- 11:52:49.380716 IP (tos 0x0, ttl 64, id 15559, offset 0, flags [none], proto UDP (17), length 62) <wan ip="">.5139 > 208.67.222.220.53: 361+ A? barak-online.net. (34) 11:52:49.410157 IP (tos 0x20, ttl 53, id 0, offset 0, flags [DF], proto UDP (17), length 78) 208.67.222.220.53 ><wan ip="">.5139: 361 1/0/0 barak-online.net. A 62.0.18.221 (50) 11:52:49.410210 IP (tos 0x0, ttl 64, id 36986, offset 0, flags [none], proto UDP (17), length 62) <wan ip="">.35073 > 208.67.222.220.53: 362+ AAAA? barak-online.net. (34) -- 11:57:49.381595 IP (tos 0x0, ttl 64, id 34228, offset 0, flags [none], proto UDP (17), length 62) <wan ip="">.29016 > 208.67.222.220.53: 363+ A? barak-online.net. (34) 11:57:49.407406 IP (tos 0x20, ttl 53, id 0, offset 0, flags [DF], proto UDP (17), length 78) 208.67.222.220.53 ><wan ip="">.29016: 363 1/0/0 barak-online.net. A 62.0.18.221 (50) 11:57:49.407463 IP (tos 0x0, ttl 64, id 8312, offset 0, flags [none], proto UDP (17), length 62) <wan ip="">.5555 > 208.67.222.220.53: 364+ AAAA? barak-online.net. (34) -- 12:02:49.379956 IP (tos 0x0, ttl 64, id 38215, offset 0, flags [none], proto UDP (17), length 62) <wan ip="">.27535 > 208.67.222.220.53: 365+ A? barak-online.net. (34) 12:02:49.405307 IP (tos 0x20, ttl 53, id 0, offset 0, flags [DF], proto UDP (17), length 78) 208.67.222.220.53 ><wan ip="">.27535: 365 1/0/0 barak-online.net. A 62.0.18.221 (50) 12:02:49.405369 IP (tos 0x0, ttl 64, id 27631, offset 0, flags [none], proto UDP (17), length 62) <wan ip="">.29510 > 208.67.222.220.53: 366+ AAAA? barak-online.net. (34) -- 12:07:49.380314 IP (tos 0x0, ttl 64, id 10174, offset 0, flags [none], proto UDP (17), length 62) <wan ip="">.41151 > 208.67.222.220.53: 367+ A? barak-online.net. (34) 12:07:49.406860 IP (tos 0x20, ttl 53, id 0, offset 0, flags [DF], proto UDP (17), length 78) 208.67.222.220.53 ><wan ip="">.41151: 367 1/0/0 barak-online.net. A 62.0.18.221 (50) 12:07:49.406915 IP (tos 0x0, ttl 64, id 62668, offset 0, flags [none], proto UDP (17), length 62) <wan ip="">.39686 > 208.67.222.220.53: 368+ AAAA? barak-online.net. (34)</wan></wan></wan></wan></wan></wan></wan></wan></wan></wan></wan></wan></wan></wan></wan></wan></wan></wan></wan>Even when I disconnect the lan port and reconnect, it keeps the same time. That has to be "hardcoded" in the process. I mean if its looking for linkup first, then that should be T0 and start from there. However, that is not the case.
I did catch the source port before my original post. I tracked in diagnostics/states before it cleared. It still pointed to my pfsense box; I also noticed no connection is made to the resolved IP address from the DNS query.
What I am stepping through now?
1. Saving config
2. Removing one package at a time and check
3. Download pfsense 2.1 amd64 from diff mirror (last md5 from BluegrassNet was good)
4. Re-install w/o additional packages and check.
5. Add one package at a time while checking.I don't remember asking Santa for this; maybe I was bad? :)
-
update:
Booted to LiveCD without any packages.
No DNS queries to that site yet [30mins]… also confirms not coming from LAN.
Will install bare install to HD, then install one new package at a time.
-
DOH!!!! It was an alias.
Odds are, I made a bonehead mistake….checking configs now.
Bottom line, when I remove the alias, the queries stop (of course). This would explain the behavior and sourced from pfsense ;)
Odd part is, I put that there to stop the queries from going out in the first place and it's likely I cleaned the host that first sent the request.
(put myself in a loop) :)
I'll report back later - even if I discover it's my blunder. At least I know ext aliases are resolved every 5 mins - LOL
-
Yep. That is what it was.
I set up an alias to block the traffic to that domain and forgot about it. I assume I removed the host which originally sent the request and in the process, exacerbated the problem by building an alias and fw rule to block the traffic to the resolved addy.
Silly me!
-
Well atleast there is an answer ;)
-
Yea man. Thanks for jumping in.
BTW.. Just donated:
Confirmation number: 8RN66929KY7900047Great product - complimented by great folks.
-
Awesome thread, like a textbook exercise in troubleshooting. :)
I wonder what was calling out to the URL originally?Steve
-
Me too! My curiosity has been growing since.
I will restore one of the PC images on a VM this weekend and report back.
Thanks… I hope this helps someone with a similar issue - self inflicted or not LOL