|
DNS queries from random internet hostsI don't know how long this has been going on, but I discovered this on my edge firewall this morning. x.x.x.240/28 is a public subnet leased by me, and pppoe0 is the WAN port of my firewall: tcpdump -n -i pppoe0 dst net x.x.x.240/28 and dst port 53
10:09:23.928376 IP 87.246.166.31.21006 > x.x.x.254.53: 8102+ A? v.www.gx911.com. (33)
10:09:24.111117 IP 97.99.47.74.60945 > x.x.x.254.53: 18991+ A? s.www.gx911.com. (33)
10:09:24.140011 IP 40.34.240.99.15530 > x.x.x.254.53: 25584+ A? dskhmwicu.www.gx911.com. (41)
10:09:24.297337 IP 4.167.251.43.124 > x.x.x.254.53: 11259+ A? gwrchymebrrewxu.www.999qp.net. (47)
10:09:24.307803 IP 35.179.21.73.22704 > x.x.x.254.53: 18709+ A? yokambnhvokctit.www.999qp.net. (47)
10:09:24.307858 IP 89.7.126.213.11494 > x.x.x.254.53: 54654+ A? clkzg.www.999qp.net. (37)
10:09:25.099320 IP 103.32.106.34.13413 > x.x.x.254.53: 8810+ A? c.www.999qp.net. (33)
10:09:25.474856 IP 80.235.225.10.32483 > x.x.x.254.53: 2785+ A? ktdbkknuu.www.jn176.com. (41)
10:09:25.474918 IP 51.118.30.61.33066 > x.x.x.254.53: 15646+ A? jiatwcevd.www.jn176.com. (41)
10:09:25.518342 IP 19.63.245.148.6165 > x.x.x.254.53: 38133+ A? abcdesguijxyz.www.jn176.com. (45)
10:09:25.722565 IP 104.45.197.15.37228 > x.x.x.254.53: 4037+ A? x.www.hcq99.com. (33)
10:09:26.300012 IP 115.67.167.174.35383 > x.x.x.254.53: 44711+ A? c.www.gx911.com. (33)
10:09:26.395084 IP 115.122.66.67.9530 > x.x.x.254.53: 17218+ A? wqljzyhstcq.www.gx911.com. (43)
10:09:27.696572 IP 113.122.17.29.61458 > x.x.x.254.53: 7441+ A? nbpqrfghvjklz.www.jn176.com. (45)
10:09:27.854510 IP 64.139.96.46.56645 > x.x.x.254.53: 11872+ A? ysdgbpj.www.gx911.com. (39)
10:09:28.845949 IP 61.34.114.57.59518 > x.x.x.254.53: 14706+ A? jdphyugky.www.gx911.com. (41)
10:09:29.327934 IP 18.50.16.224.12613 > x.x.x.254.53: 57360+ A? cwdimot.www.hcq99.com. (39)
10:09:29.408703 IP 72.30.153.190.9725 > x.x.x.254.53: 48793+ A? iyrkaty.www.hcq99.com. (39)
10:09:31.423869 IP 123.95.61.148.12373 > x.x.x.254.53: 37949+ A? y.www.gx911.com. (33)
10:09:31.661014 IP 51.175.17.235.30026 > x.x.x.254.53: 60177+ A? tvn.www.999qp.net. (35)
10:09:32.172517 IP 51.245.58.209.40636 > x.x.x.254.53: 53562+ A? hcp.www.gx911.com. (35)
10:09:32.973654 IP 90.46.31.169.53254 > x.x.x.254.53: 43295+ A? ympql.www.gx911.com. (37)
10:09:33.056384 IP 122.50.205.72.48559 > x.x.x.254.53: 18637+ A? ojqqochvw.www.hcq99.com. (41)
10:09:33.056432 IP 4.239.129.168.34695 > x.x.x.254.53: 43137+ A? wbephgtmjuoeeuv.www.hcq99.com. (47)
10:09:33.056469 IP 81.142.150.165.13764 > x.x.x.254.53: 42390+ A? rrfiaylgw.www.hcq99.com. (41)
10:09:33.061850 IP 51.202.26.42.32191 > x.x.x.254.53: 10778+ A? hfrtxzjiu.www.hcq99.com. (41)
10:09:33.282703 IP 23.16.116.12.40493 > x.x.x.254.53: 3188+ A? ulf.www.jn176.com. (35)
10:09:33.282765 IP 103.67.213.168.41009 > x.x.x.254.53: 43221+ A? ibc.www.jn176.com. (35)
10:09:33.420262 IP 115.15.244.181.54998 > x.x.x.254.53: 46580+ A? jdjzpni.www.jn176.com. (39)
10:09:33.691600 IP 79.25.214.29.28754 > x.x.x.254.53: 7638+ A? pvkblzusm.www.gx911.com. (41)
10:09:33.834781 IP 26.154.165.87.54406 > x.x.x.254.53: 21923+ A? r.aa.cp375.com. (32)
10:09:34.090594 IP 84.130.8.115.44408 > x.x.x.254.53: 29448+ A? jgvrwjcsrjcozzm.www.gx911.com. (47)
10:09:34.992280 IP 112.243.175.52.36125 > x.x.x.254.53: 13487+ A? mepwqjyjbvj.www.gx911.com. (43)
10:09:35.048734 IP 73.203.12.11.39842 > x.x.x.254.53: 2828+ A? abpdrsthijkyz.www.999qp.net. (45)
10:09:35.964594 IP 10.112.82.122.25435 > x.x.x.254.53: 31314+ A? yayjnlcnijx.www.999qp.net. (43)
10:09:36.107063 IP 69.158.204.207.21518 > x.x.x.254.53: 53196+ A? ttngsyx.www.jn176.com. (39)
10:09:36.658590 IP 84.38.17.174.46587 > x.x.x.254.53: 44561+ A? nqzqvue.www.hcq99.com. (39)
10:09:37.360375 IP 40.239.72.150.38517 > x.x.x.254.53: 38472+ A? g.www.gx911.com. (33)
10:09:37.412026 IP 50.5.22.68.30287 > x.x.x.254.53: 17430+ A? qrhpyewfl.www.gx911.com. (41)
10:09:37.894305 IP 23.136.155.231.50936 > x.x.x.254.53: 59291+ A? bvk.www.999qp.net. (35)
10:09:37.894364 IP 121.252.17.126.377 > x.x.x.254.53: 32273+ A? rpaowke.www.999qp.net. (39)
10:09:37.894556 IP 71.226.226.117.28220 > x.x.x.254.53: 30178+ A? vtz.www.999qp.net. (35)
10:09:37.896985 IP 79.48.82.198.60711 > x.x.x.254.53: 50770+ A? wvpacmjdj.www.999qp.net. (41)
10:09:39.317651 IP 34.27.78.144.36551 > x.x.x.254.53: 36942+ A? rkyvz.www.hcq99.com. (37)
10:09:39.618948 IP 100.191.182.208.31825 > x.x.x.254.53: 53430+ A? rix.www.gx911.com. (35)
10:09:39.822192 IP 122.97.215.169.51310 > x.x.x.254.53: 43479+ A? vtepudvjz.www.999qp.net. (41)
10:09:40.294786 IP 22.205.199.136.61213 > x.x.x.254.53: 34501+ A? o.aa.cp375.com. (32)
10:09:41.161477 IP 42.100.169.28.63973 > x.x.x.254.53: 7337+ A? abcqeftuijkym.www.jn176.com. (45)
10:09:41.182724 IP 38.30.188.84.1171 > x.x.x.254.53: 21692+ A? abpdefthvjxym.www.jn176.com. (45)
10:09:41.401170 IP 66.170.85.231.55100 > x.x.x.254.53: 59221+ A? x.www.jn176.com. (33)
10:09:41.882099 IP 103.69.72.226.4975 > x.x.x.254.53: 57928+ A? mhk.www.gx911.com. (35)
x.x.x.254 is an internal address of my router which acts as default gateway to internal hosts on this public subnet. My firewall drops everything on the WAN to that address, so these apparent DNS queries are all dropped by the firewall. But this raises some questions for me. 1. Why am I seeing a steady stream of DNS queries when I'm dropping them all (51 queries in 18 seconds)? As you can see on line 36, some of the requests are even coming from RFC1918 addresses. 2. Why do they appear to come from an apparently unlimited variety of random internet hosts? 3. Why are they querying an apparently small set of unresolvable domains? 4. Why are they all aimed at a single address in my leased subnet? I have tried googling the x.x.x.254 address to see if it is listed as a DNS server somewhere, but I got no hits. |
|
Wily_One Premium Member join:2002-11-24 San Jose, CA |
Wily_One
Premium Member
2014-Feb-11 1:31 pm
Verify those queries are not reaching the server, and that your DNS server is not acting as an open recursive. |
|
|
They are not. I can see them being dropped in the firewall log.
I think that hole may have been open at some point, but that would have been over a year ago. Maybe it was flagged as open recursive back then and still lives on some lists. |
|
Wily_One Premium Member join:2002-11-24 San Jose, CA |
Wily_One
Premium Member
2014-Feb-11 1:44 pm
That could be it. But if that 10.112.82.122 source address really came from the WAN interface, that's not normal and most likely a malicious attempt. |
|
1 recommendation |
Yes, I brought that to my ISP's attention and they fixed it already. They're very responsive. » TSI breaking RFC1918? |
|
Wily_One Premium Member join:2002-11-24 San Jose, CA |
Wily_One
Premium Member
2014-Feb-11 1:54 pm
Ah, very good. IP spoofing of DNS queries is often an attempt at reflection attacks against a target public address. (Why they would spoof a non-routable internal address is beyond me.) |
|
BinkVillains... knock off all that evil join:2006-05-14 Colorado |
to clarknova
Do you have any other traffic going to any of those IPs? Some kind of IP accounting/NetFlow would be great. |
|
1 recommendation |
I just checked a half dozen and I have no other connections to any of those sampled.
My ISP already admitted to not doing any uRPF, so I'm satisfied at this point that these are probably spoofed addresses trying to exploit what was once an open recursive DNS server. At least the ISP is now filtering some invalid source addresses, but not the whole bogon table, and certainly not the whole rest of valid addresses that continue to be spoofed.
I'm blocking an average of 15 Kbps on the WAN between this and the normal probes. At the end of the day it's not enough traffic to cause me any issues. Just an interesting learning experience. |
|
|
to clarknova
Good learning from this end as well, thanks for sharing clarknova . Funny thing is while we got all the tools in the (IT) world to prove the traffic is moving, we don't have a tool to determine / prove intent of the actual operator. Given the volume and nature of the DNS queries, I'd be inclined to subscribe to the theory of malicious intent -- malware, DNS amp attack, et al. Some thoughts for you - if your ISP is not doing URPF, any possibility of doing it on your own edge device? No reason not to stop RFC1918 / bogon addresses from getting any further than they should, both in and out. - have you recently reviewed your firewall rules recently? You mentioned DNS "MAY" have been open before. It may be a good idea to review them now, just to make sure there's no other surprises lurking around. - 2nd Bink 's suggestion of IP Accounting / xflow / IPFIX. Syslog / pcap only goes so far, I've found. My 00000010bits Regards |
|
|
said by HELLFIRE:if your ISP is not doing URPF, any possibility of doing it on your own edge device? Yes. I only allow known local source IPs out of my network, and I block all local and bogons at the ingress. said by HELLFIRE:have you recently reviewed your firewall rules recently? I review them quarterly. I'm pretty sure I recall that when I first obtained the /28 subnet I allowed everything in to the whole subnet. I don't recall how much time passed before I realised that I was unintentionally allowing outside traffic to the gateway as well. Live and learn. said by HELLFIRE:2nd Bink's suggestion of IP Accounting / xflow / IPFIX. Not tools that I'm familiar with, but I will look into them. Thanks for the input. |
|
|
to clarknova
Took a look at your post to TSI said by TSI Gabe:The issue here is source validation. The issue is that we can't enable uRPF in Vancouver due to some
technical limitations with multi-homing etc. ...I'm no routing / multihome expert, but I'm REALLY wondering what the heck is with that statement. Unless it's just the nature of a 0.0.0.0 route being fed to you by two pipes... said by clarknova:Not tools that I'm familiar with, but I will look into them. Thanks for the input. I don't know if you ever posted up what you were using for an edge device. IP Accounting's a feature on Cisco gear. Two seconds to enable, and you just do "show ip accounting." xflow I use in a generic fashion for Netflow, sflow, jflow, et al, while IPFIX is the IETF / RFC standard for all that. If the gear supports it, should be easy enough to enable and use, you just need the collector software and you're off to the races. Regards |
|
|
It's a pfsense device. I'm just looking through available addon packages and the ones that look possibly relevant are darkstat, pfflowd, softflowd, vnstat2, iftop, and bandwidthd.
Any recommendations? |
|
1 recommendation |
to clarknova
Never worked / heard of any of them, but alittle Google-fu turned up the following darkstat -- network traffic / protocol statistics pfflowd -- turns PF status to netflow datagrams. softflowd -- "flow-based network traffic analyser capable of Cisco NetFlow data export." Dur?!?! vnstat2 -- traffic monitor, tho a quick look at the homepage makes me think it's more geared to VOLUME based statistics than protocol based statistics iftop -- seems kind of the same as well bandwidthd -- seems the closest to what you want for xFlow / IPFIX functionality. Also seem to recall you had a Ubiquti Edgemax, right clarknova According to this it can do Netflow, so all you'd need is the netflow collector software. Regards |
|
tubbynetreminds me of the danse russe MVM join:2008-01-16 Gilbert, AZ |
to HELLFIRE
said by HELLFIRE:I'm no routing / multihome expert, but I'm REALLY wondering what the heck is with that statement. i can influence egress policy on my network -- but i cant control how traffic ingresses into my network. i can use things like communities or med, but that doesnt mean the other side has to obey it -- especially if monetary implications are attached. q. |
|
|
Thanks for the response tubbynet ...not to drag this off topic, but got an actual example / diagram / scenario of that, just so I can visualize? Regards |
|
|