Something is leaking my DNS

[joegreat]

I hate to ask because I think this will lead me into a deep rabbit hole, but I was wondering if I/we should be taking a more proactive approach to the WAN side of the router in terms of letting your cable modem (or whatever) be susceptible to this kind of activity. Do you think that it would be worth adding more commonly exploited ports to the above iptables so that remote sources trying to access invalid services on my modem are dropped? For example, I don't run a SMTP server, so maybe doing this to port 25 would make sense. The only port I use for remote access is port 1194 for OpenVPN. Would it make sense to try and block all other ports or will that potentially cause more problems than what it is worth,

Well, the rabbit hole you are looking at is called "white listing": You disable all ports and only allow the ones you need!

The real trap here is that you can potentially do this for the well-known ports or system ports up to port 1023, plus you can look into the list from 1024 to 49151 for the registered ports (=common usage) - but you will not be able to do anything similar about the "un-registered" ones and for the higher port numbers, which are used dynamically by the services/applications accessing internet.

But at least the known/default services are then protected!

 

[ColinTaylor]

Hi @Goobi, thanks for the update.

My take on it is this: There will always be a continuous "noise" of traffic hitting your WAN interface, i.e. DHCP network broadcasts, etc. Receiving a few rogue DNS requests a day (or even an hour) is a drop in the ocean.

Even though you have set up ipset to drop the DNS packets this would have happened anyway with the default firewall rule. The only reason you saw them was because you specifically looked for them. If you look for SSH, FTP, etc you see those as well.

So, what to do? Well, I guess the only thing that would make a difference would be to use iptables/ipset to create a white list of sources that are allowed to access any ports you choose to open to the outside world (OpenVPN in your case).

Just my 2 cents.

 

[ColinTaylor]

The real trap here is that you can potentially do this for the well-known ports or system ports up to port 1023, plus you can look into the list from 1024 to 49151 for the registered ports (=common usage) - but you will not be able to do anything similar about the "un-registered" ones and for the higher port numbers, which are used dynamically by the services/applications accessing internet.

That's not quite correct. Remember that the firewall is "stateful" so any incoming traffic that is in response to an outgoing request is allowed in regardless of whether it is on a high-port or not. We are only concerned about unsolicited traffic that is hitting server ports that we have setup, and therefore we know what port they are running on.

 

[Nullity]

Hi Guys,

I am here to report back. This has become very interesting and I thank you for your suggestions and feedback. While I originally thought that something from within my network was leaking DNS, a careful look at tcpdump data shows that was not the case. You can see a remote source IP using port 53 and terminating at my cable modem.

I think the working theory of this being a DNS amplification attack is right on. The victim of the attack does appear to be a company called CloudFlare. In particular, it's DNS servers.

If I take a look at one of the dumps, we can see requests for x99moyu.net. If I run dig against this domain name, I get the following:

# dig +short x99moyu.net NS
darwin.ns.cloudflare.com.
uma.ns.cloudflare.com.

Since neither I or this remote IP (from dump) are owned by Cloudflare, we can reasonably assume that one of these IPs is spoofed. Given the victim of the attack (Cloudflare) and how the attack operates, the address most likely being spoofed here is mine!

I did not like the idea of my IP participating in any attack so after a couple of days of watching these requests trickle in, I decide to try ASAT's suggestion about setting up a tripwire on the WAN side of the router. I modified to log any drops so what I ended up with is:

ipset -N bannedhosts iphash
iptables -I INPUT -i eth0 -p tcp -m multiport --ports 53 -j SET --add-set bannedhosts src
iptables -I INPUT -i eth0 -p udp -m multiport --ports 53 -j SET --add-set bannedhosts src
iptables -I INPUT -m set --match-set bannedhosts src -j logdrop
iptables -I INPUT -m set --match-set bannedhosts dst -j logdrop
iptables -I OUTPUT -m set --match-set bannedhosts src -j logdrop
iptables -I OUTPUT -m set --match-set bannedhosts dst -j logdrop
iptables -I FORWARD -m set --match-set bannedhosts src -j logdrop
iptables -I FORWARD -m set --match-set bannedhosts dst -j logdrop


The bannedhosts ipset shows the following bad actors captured:

210.5.183.234 -->Hong Kong
213.219.84.227 -->Estonia
63.134.200.200 --> Arizona (US)
80.69.147.202 --> Russia
61.35.16.29 --> South Korea
66.86.78.244 --> North Carolina (US)
195.189.29.130 --> Kazakhstan
218.90.188.222 --> China
88.147.150.52 --> Russia
117.141.117.145 --> China
201.40.135.70 --> Brazil

It appears that this x99moyu.net is coming from several sources and not just China but I think they are all related and probably have the same source.

This ipset/iptables combination seems to have resolved the issue from the standpoint that these packets are being dropped as soon as they hit my cable modem.

I hate to ask because I think this will lead me into a deep rabbit hole, but I was wondering if I/we should be taking a more proactive approach to the WAN side of the router in terms of letting your cable modem (or whatever) be susceptible to this kind of activity. Do you think that it would be worth adding more commonly exploited ports to the above iptables so that remote sources trying to access invalid services on my modem are dropped? For example, I don't run a SMTP server, so maybe doing this to port 25 would make sense. The only port I use for remote access is port 1194 for OpenVPN. Would it make sense to try and block all other ports or will that potentially cause more problems than what it is worth?

Thanks in advance for your feedback.

If the DNS Amplification or spoofing assumption is accurate, the victim is you, not Cloudflare.

For Cloudflare to be the victim, you would need to be running an open DNS server, and someone would send a DNS query from a spoofed Cloudflare IP to your DNS server, causing you to send unsolicited DNS responses to Cloudflare.

 

[ColinTaylor]

If the DNS Amplification or spoofing assumption is accurate, the victim is you, not Cloudflare.

Yes, you're absolutely correct. It's not DNS Amplification it's a Water Torture attack (https://blog.secure64.com/?p=377).

I confused myself because the two techniques are similar, but not the same . In this case the objective is to overload the target DNS server with randomly changing unresolvable names (as can be seen in the dump).

ululepwnmnkz.www.x99moyu.net
snmzqp.www.x99moyu.net
qlatyp.www.x99moyu.net

Edit: It's still possible that the attack is coming from his network, but given how tightly he's locked it down it seems unlikely.

 

[Nullity]

Yes, you're absolutely correct. It's not DNS Amplification it's a Water Torture attack (https://blog.secure64.com/?p=377).

I confused myself because the two techniques are similar, but not the same . In this case the objective is to overload the target DNS server with randomly changing unresolvable names (as can be seen in the dump).

ululepwnmnkz.www.x99moyu.net
snmzqp.www.x99moyu.net
qlatyp.www.x99moyu.net

Edit: It's still possible that the attack is coming from his network, but given how tightly he's locked it down it seems unlikely.

I hadn't heard of that attack. Interesting.


Though, it looks like the Water Torture Attack is aimed specifically at DNS servers (that authoritatively resolve), not DNS clients. Is OP running a DNS server?

 

[ColinTaylor]

Though, it looks like the Water Torture Attack is aimed specifically at DNS servers (that authoritatively resolve), not DNS clients.

Correct.

Is OP running a DNS server?

I don't believe so.

As I understand it (but I could be wrong) the target is some authoritative DNS somewhere that is being attacked by bots. Even though he is not sending the requests he is getting the replies because they are spoofing his (and others) IPs to hide their tracks. That way there appears to be a low volume of legitimate requests coming in from all over the place, rather than a concentrated attack from a smaller group.

 

[Nullity]

Correct.
I don't believe so.

As I understand it (but I could be wrong) the target is some authoritative DNS somewhere that is being attacked by bots. Even though he is not sending the requests he is getting the replies because they are spoofing his (and others) IPs to hide their tracks. That way there appears to be a low volume of legitimate requests coming in from all over the place, rather than a concentrated attack from a smaller group.

Ah, that makes more sense. He is not being attacked, he is only seeing the remnants of someone else spoofing his IP. The volume is so extremely low, I would not suspect direct attack, unless the attacker was unskilled, practicing, or ???

I think my ISP still allows IP spoofing, but the spoofed IP must be part of the subnet of the upstream gateway router. Or they may allow it without restriction. Dunno why any ISP still allows a packet that obviously did not originate from within their network to then leave their network...

 

[bluepoint]

Could it be result of vulnerability that is being exploited? I'm not sure if it's related I'm no DNS knowledgeable, it's for you experts to determine. https://isc.sans.edu/forums/diary/CVE20157547+Critical+Vulnerability+in+glibc+getaddrinfo/20737/
https://googleonlinesecurity.blogspot.ca/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html

 

[Goobi]

Thanks for the feedback everyone. I do think that I am not the target of the attack because I only get about 2-3 requests per hour. It seems to make more sense that I am one of many spoofed IP address taking part in this type of attack.

I went ahead and disabled that wire trap ASAT recommended since as Colin mentioned the default firewall rule would drop this rouge request. Just for grins I went ahead and enabled logging of all dropped packets and boy was I blown away by all of the suspicious traffic being dropped. The usual bad actor countries trying just about every port you can try. I block incoming traffic from entire countries so some of that dropped traffic may also be a result of those rules as well.

Thanks again for all the feedback everyone. I learned a great deal investigating this and your collective feedback helped make sense of what I was seeing. It's a cruel world on the wan side of your router! It's almost best not to look because the volume of suspicious traffic hitting your modem Is scary even though it's being dropped.

 

[Nullity]

Monitor egress traffic with a certain level of paranoia, but unrelated ingress traffic should mostly be disregarded unless you have a damn good reason to suspect they are related to internal leaks/infiltration.

As normal, non-service-providing internet user, I would hesitate spending much of my time monitoring ingress.

Running a honeynet can be educational, but be careful.

The black-hat internet is largely motivated by money nowadays, rather than hacker curiosity. Think of the internet from the POV of these scanners, and realize that low hanging fruit or high-value targets are the primary concern. (I say this as an amateur.)