Threat Level: green Handler on Duty: Xavier Mertens

SANS ISC: DNS queries for "." SANS ISC InfoSec Forums

Participate: Learn more about our honeypot network
https://isc.sans.edu/honeypot.html

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
DNS queries for "."
For what it is worth, I'm not seeing the OpenDNS IP that tjrical saw.

I do see that the bag guys don't completely shift to new targets.

The top spoofed DNS requests I'm seeing are now from: 63.217.28.226 (started 4 days ago) then 64.57.246.146 (started today) then 76.9.16.171 (started 9 days ago) and last, 67.192.144.0 (started today).
Andrew

41 Posts
re: my earlier post, the OpenDNS IP was not part of the attack. It was querying the same domain almost 200 times in about 1 minute, but it was not querying for the \".\" domain.
Andrew
2 Posts
IP's I've seen so far:
63.217.28.226
64.57.246.146
66.230.128.15
66.230.160.1
67.192.144.0
69.50.137.175
69.50.142.11
69.50.142.110
70.86.80.98 (started this morning around 6:20am est)
76.9.16.171
204.238.82.20
206.71.158.30
216.240.131.173
Andrew
6 Posts
Started seeing 64.57.246.123 at 6:07am EST.
Dave

2 Posts
Also seeing 72.20.3.82; and 72.249.127.168 now
Dave
6 Posts
I'm seeing the same two new addresses as sdewndr 72.20.3.82 and 72.249.127.168 today and also 69.64.87.156 ... all three new addresses are name and webservers for pharmacy spammers. Perhaps the bad guys are expanding their campaign to squeeze competitors, or new players with different goals are entering the fray.
Andrew

41 Posts
I'm seeing quite a few IPs hitting my DNS servers. One such example: 72.249.127.168
Andrew
1 Posts
Seen nearly all of the IPs, thanks people for the list, please keep it coming. I carefully compared the lot with my list and I've no new ones. Right this second I'm seeing same three as Andrew from Vancouver. I block on input in iptables, and then use the 45 rule with a --limit log, hope it lasts (the rule that is!).
Anonymous
Now seeing 78.140.132.25 as of about 5:30am est
Anonymous
seeing 76.9.20.244 as of 6:10am est
Anonymous
also saw one hit pointed at 65.173.218.96 (isc.sans.org) on 1/29/09 at about 4:30pm est
Anonymous
My servers saw 78.140.132.25 and 76.9.20.244 this morning but for only 14 and 17 minutes, respectively, and was finished very close to 4:00 AM PST. Both targets are pill spammers' web and/or DNS service, and one of them is a shared webhost. Meanwhile, the packet rate dropped from a very consistent buzz down to ZERO and near-zero for periods as long as several hours. Perhaps the bad guys are tinkering with their network, or perhaps they are switching to concentrated bursts to show off the level of control they have of their network.
Andrew

41 Posts
Looks like 208.76.253.253 was added as a target. Started seeing queries on 01/30/2009 at 22:07 UTC.
Dshield

10 Posts
208.76.253.253 is the address for the email server and webserver for ScamFraudAlert.com and response time to that site is suffering. This time, it's not a DNS attack per se, as the spoofed packets are not heading to a DNS server. It is a straightforward bandwidth-based denial of service.
Andrew

41 Posts
Starting around 8pm est or so Friday night, we started seeing these: 208.76.253.253; 64.27.1.194; 70.86.80.98; 71.6.131.81; 65.23.129.220. The last four started around 4am est at about the same time. First time I've seen that. Intensifying?
Andrew
6 Posts
Funny thing is, my server has never amped, yet I still see a ton of these queries. I suspect the attacker is satisfied even when attacks are unamped since the refused response makes it essentially an even trade with the benefit of added indirection.

You can block the inbound query

# and provide a level of indirection
iptables -N logdrop
iptables -A logdrop -j LOG
iptables -A logdrop -j DROP
iptables -I INPUT -i eth0 -p udp -s ! 192.168.0.0/16 --destination-port 53 -m string --algo kmp --from 30 --hex-string \"|010000010000000000000000020001|\" -j logdrop

or blocked the reject outbound altogether:

iptables -A OUTPUT -p udp -d ! 192.168.0.0/16 --source-port 53 -m string --algo kmp --from 30 --to 31 --hex-string \"|8105|\" -j logdrop

I have to do more thinking on the latter. It seems lame delegation could introduce inefficiencies to the DNS system if this were widely adopted, though negative caching might take care of that.
Andrew
2 Posts
Actaully the 8105 rule would only effect reject packets in reply to recursive queries so it's fine. It essentially turns off the reject response behavior when recursion is off. iptables -A OUTPUT -p udp -d ! 192.168.0.0/16 --source-port 53 -m string --algo kmp --from 30 --to 31 --hex-string "|8105|" -j DROP
Andrew
2 Posts
We have seen these ip's so far:
63.217.28.226
66.230.128.15
66.230.160.1
69.50.142.11
69.50.142.110
69.64.87.156
72.20.3.82
72.249.127.168
76.9.16.171
76.9.31.42
204.9.88.13
204.9.94.145
206.71.158.30
208.76.253.253
216.201.82.19
220.181.168.251

208.76.x.x and 220.181.x.x being the most recent. Also a few mins after our system started dropping 208.76.253.253 querys through a script, we saw this entry once in our log which resolves to isc/bind ????

client 149.20.52.143#56538: query 'VERSION.BIND/CH' denied

Andrew
3 Posts
Regarding the queries from 149.20.52.143,
see: https://www.dns-oarc.net/node/109
Dshield

10 Posts
After a hiatus of several days the method has resumed with spoofing 89.149.221.182 which is the website for seopharmacy.com ... perhaps we can also expect to see 89.149.209.161 which is the sole NS address listed for that domain.
Andrew

41 Posts

Sign Up for Free or Log In to start participating in the conversation!