2

Last time I've got warings about DNS Amplification Attack from NFOservers.com DDoS notifier

2015-12-30 23:28:52.609178 IP (tos 0x0, ttl 54, id 42635, offset 0, flags [+], proto UDP (17), length 1500) my.dns.ip.addr.53 > 63.251.20.x.18150: 41159| 20/0/1 cpsc.gov. MX hormel.cpsc.gov. 5, cpsc.gov.[|domain]                                    
2015-12-30 23:28:52.609632 IP (tos 0x0, ttl 54, id 42636, offset 0, flags [+], proto UDP (17), length 1500) my.dns.ip.addr.53 > 63.251.20.x.18150: 41159| 20/0/1 cpsc.gov. MX stagg.cpsc.gov. 5, cpsc.gov.[|domain]                                 ..
2015-12-30 23:28:52.610109 IP (tos 0x0, ttl 54, id 42637, offset 0, flags [+], proto UDP (17), length 1500) my.dns.ip.addr.53 > 63.251.20.x.18150: 41159| 20/0/1 cpsc.gov. MX hormel.cpsc.gov. 5, cpsc.gov.[|domain]

For info

my.dns.ip.addr.53 - my VIP - external IP DNS address

63.251.20.x.18150 - dont know what this IP address range is

My server have to offer recursive queries for internal company network I have configured in bind9 section:

 acl "trusted" {
 172.16.0.0/16;
 localhost;
 localnets;
 };
options {
...
allow-query { any; };
allow-recursion { trusted; };
allow-query-cache { trusted; };
...
}

I configured also RRL - Response Rate Limit:

rate-limit {
responses-per-second 5;
window 5;
};

Looks like my DNS server (bind9) refused bad queries like in the log: http://pastebin.com/A3XGwh04

but I would like block such queries by iptables. I'd do some research and found block by IPTABLES:

iptables -A INPUT  -p udp -m udp --dport 53 -m string --from 50 --algo bm --hex-string '|0000FF0001|' -m recent --set --name dnsanyquery --rsource
iptables -A INPUT  -p udp -m udp --dport 53 -m string --from 50 --algo bm --hex-string "|0000FF0001|" -m recent --name dnsanyquery --rcheck --seconds 10 --hitcount 1 -j DROP

but when I test my server from test machine with command: dig +nocmd @my.ip.dsn.addr domain.com any +multiline +noall +answer I'm getting no answer from dns and in addition logs still are full of queries with cpsc.gov so I decided to back my default iptables configuration

Next research i've found that soultions made by conntrack but it may cause NAT problems. My DNS is NAT'ed

When used another soultion found here on other topics:

iptables -A INPUT -p udp --port 53 -m hashlimit --hashlimit 1/minute --hashlimit-burst 5 -j ACCEPT
iptables -A INPUT -p udp --port 53 -j DROP

got nagios warrings - SOA sync problem, domain SLAVE not found etc

My next try:

iptables --insert INPUT -p udp --dport 53 -m string --from 40 --to 56 --algo bm --hex-string '|637073632e676f76|' -j DROP -m comment --comment "DROP DNS Q cpsc.gov"
iptables --insert INPUT -p udp --dport 53 -m string --from 40 --to 50 --algo bm --hex-string '|6370736303676f763f|' -j DROP -m comment --comment "DROP DNS Q cpsc.gov"
-A INPUT -p udp -m udp --dport 53 -m string --string "cpsc.gov" --algo bm --from 40 --to 50 -m comment --comment "DROP DNS Q cpsc.gov" -j DROP

but still queries in logs

I'm still researching solution but maybe anyone here is much experienced with such attacks and can help me block queries like: cpsc.gov

query-errors: info: client 93.48.40.139#54822 (cpsc.gov): rate limit drop REFUSED error response to 93.48.40.0/24

Any help is appreciated.

VERY Important: Even if I disable recursion for ALL, my logs are full of warings like rate limit drop REFUSED error response to thats why I want block it by iptables.

Curl User
  • 43
  • 1
  • 8
  • 3
    Why do you have this recursive DNS server exposed to the Internet? – Michael Hampton Jan 10 '16 at 15:36
  • @Brian An ACL is already in place for recursion, and the question states that turning recursion off isn't feasible. The focus needs to be more on why the recursive server *has* to accept incoming queries from the internet to begin with. – Andrew B Jan 10 '16 at 15:38
  • For some reason you're redacting `63.251.20.x`. Are we to assume that this is a device that you own? If so, is `my.dns.ip.addr` supposed to be a DNS server that you own? It's trivial to tell the company associated with the `x` that you've redacted, so please focus on communicating to us the roles of these devices. (and if you're redacting an IP you don't own, it's confusing, please don't) – Andrew B Jan 10 '16 at 15:42
  • @Andrew B my.dns.ip.addr is my VIP - external IP address my Bind9 DNS server – Curl User Jan 10 '16 at 15:55
  • @ALL Even if I disable recursion for ALL my logs are full of queries anyway thats why I want block it by iptables. – Curl User Jan 10 '16 at 15:57
  • Okay. And what is `63.251.20.x`? Do you own the device? This is very pertinent because you're telling us that the ACL is *not* causing this traffic to stop. – Andrew B Jan 10 '16 at 15:57
  • @Andrew B dont know this IP address. Probably its IP attacked by DDoS – Curl User Jan 10 '16 at 16:00
  • Thanks. Don't redact IP addresses that you don't own, people will make some incorrect assumptions. Last question: that IP address is associated with a company who rents game servers. Are you also their customer? (i.e. is your server also a `63.251.20.x` address?) – Andrew B Jan 10 '16 at 16:02
  • @Andrew B nope we dont use any of their service. I dont know 63.251.20.x IP range – Curl User Jan 10 '16 at 16:03
  • fwiw I get a REFUSED response when I query 194.126.216.11 and timeout when I query 63.251.20.99. – kasperd Jan 10 '16 at 16:33
  • 1
    We're starting to see a lot of confusion over whether or not DNS RRL is intended for use with recursive DNS servers. Rather than waste a lot of time in this Q&A explaining that, [I've created a separate canonical Q&A to address it](http://serverfault.com/questions/748035/what-rate-limiting-options-are-provided-by-isc-bind/). You should disable `rate-limit`. – Andrew B Jan 10 '16 at 16:36
  • 1
    I dont know why all focus on Bind configuration instead of iptables about which I asked :s – Curl User Jan 10 '16 at 16:44
  • @CurlUser this may not help you much because it is intended for authoritative servers only, but you might look at [this post](http://serverfault.com/questions/744613/block-any-request-in-bind/744620#744620) to see how to discard any answers from your server that are anything other than NOERROR. Disclaimer: I have never tried this on a recursive server and it may cause the moon to crash into the earth. You will still see the requests in your logs, but the attacker or spoofed victims won't see your response. Turn off rate limiting and ignore the noise. – Aaron Jan 10 '16 at 17:06
  • @Aaron what about this https://github.com/smurfmonitor/dns-iptables-rules iptables package ? I can't there cpsc.gov :/ – Curl User Jan 10 '16 at 17:13
  • @CurlUser Maybe because there is a discrepancy between the packet trace you posted and the configuration you posted. And maybe because it is better to restrict queries though configuration of the DNS server than through iptables rules. – kasperd Jan 10 '16 at 17:14
  • 1
    @CurlUser Blacklisting is very high maintenance and you also have to be very sure that the IP addresses are not spoofed. I don't envy anyone having to maintain that. If you are going that direction, you might consider looking into proper DDoS mitigation solutions. Also, that list isn't being maintained. Look at the last update times. – Aaron Jan 10 '16 at 17:14
  • 1
    @Aaron anyway I would like to test solution described https://github.com/smurfmonitor/dns-iptables-rules but cann't get properly decoded hash for cpsc.gov and properly iptables rule for block all queries contain cpsc.gov :/ I don't want waste my CPU by such queries - thats why i wanna block it by iptables – Curl User Jan 10 '16 at 17:17
  • @CurlUser Complicated iptables rules can also consume lots of CPU time. It is better to spend the CPU time in user mode than in iptables rules. First of all you are more likely to experience a negative impact on the system if the kernel CPU usage goes up than if the CPU usage of a single user mode process goes up. Moreover iptables is not designed to process DNS requests, trying to make it do so will at best use more CPU time than code designed to do so and at worst produce incorrect results. – kasperd Jan 10 '16 at 17:43
  • Realizing this question is fairly old at this point, but for those who come across it in the future as I just did. The correct --from position for the --hex-string '|0000FF0001|' search is 40. Not 50. 40 for UDP or 52 for TCP. Also it should be in the RAW table PREROUNTING chain. You can find this detailed here: https://forums.centos.org/viewtopic.php?f=51&t=62148&sid=3687bf227875a582ba08964fca178dd2 Using 50 instead of 40 will render the rule significantly impotent. – NOYB Jun 28 '20 at 09:04

2 Answers2

3

Honestly, it looks like your ACL is working as intended:

query-errors: info: client 93.48.40.139#54822 (cpsc.gov): rate limit drop REFUSED error response to 93.48.40.0/24

You're still getting the queries, but you're refusing to provide an answer to them. The rate limiting code is being invoked because the queries are still coming in volume and having to be refused by the nameserver.

As for the rest, a few things:

  • Don't use rate-limit with a recursive nameserver. It's not intended for use with recursive nameservers and generates those unnecessary log messages. That solves the log spam.
  • iptables isn't really going to help with this. If your goal is to make it to where the software never sees the queries, even if they're going to be rejected with a response of REFUSED anyway, that's well-intentioned but misguided. Either way your server is having to process the queries. One is having the kernel drop the traffic, the other is letting the software drop the traffic.

The value of preventing the software from seeing the bogus queries is mostly aesthetic. Most DNS admins aren't going to waste kernel cycles on doing something that the software is already doing. Whether you're dropping the traffic on the floor with a firewall or sending REFUSED packets back, your server has been put into a list of open resolvers and botnets are unlikely to stop sending you the traffic.

If you really want this traffic to go away, it's strongly recommended that you do not provide an internet facing listener on a recursive server that only services your devices. That way your DNS server doesn't have to waste userspace CPU rejecting the traffic or kernel CPU dropping the traffic.

Even if you go through with this as a learning exercise or with a goal of not sending any reply packets at all, this is a solution that doesn't scale. The DNS records being used in these attacks change every day, as does the IP address which is frequently spoofed.

You've asked for advice from people who "[have] experienced with such attacks", and constantly refusing unsolicited traffic is pretty normal for an internet facing DNS server. Doubly so for one that was formerly an open resolver. This type of solution is what those admins would usually not do, though I wish you well all the same.

Andrew B
  • 31,858
  • 12
  • 90
  • 128
0

If you want to explore with iptables DNS rate limiting and filtering you might investigate doing something like this.

Details on the root any/all query filter string match are here:
https://forums.centos.org/viewtopic.php?f=51&t=62148&sid=3687bf227875a582ba08964fca178dd2

*raw
:PREROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:DNS_DROP - [0:0]
:DYN_DROP - [0:0]

-A PREROUTING -i lo -j ACCEPT
-A PREROUTING -i eth0 -s <our.net.work.space>/21 -j ACCEPT
-A PREROUTING -m recent --rsource --update --seconds 86400 --name DYN_DROP_LIST -j DROP
-A PREROUTING -p udp -m udp --dport 53 -j DNS_DROP
-A PREROUTING -p tcp -m tcp --dport 53 -j DNS_DROP

-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -o eth0 -d <our.net.work.space>/21 -j ACCEPT
-A OUTPUT -m recent --rdest --update --seconds 86400 --name DYN_DROP_LIST -j DROP

## Permanent DNS drop list (ipset)
-A DNS_DROP -m set --match-set PERM_DNS_DROP src -j DROP

## DNS - UDP progressive rate limit
-A DNS_DROP -p udp -m hashlimit --hashlimit-above  1/sec --hashlimit-burst  5 --hashlimit-mode srcip --hashlimit-srcmask 24 --hashlimit-htable-expire  10000 --hashlimit-name DNS_LIMIT_UDP  -j DROP
-A DNS_DROP -p udp -m hashlimit --hashlimit-above 10/min --hashlimit-burst 10 --hashlimit-mode srcip --hashlimit-srcmask 24 --hashlimit-htable-expire 120000 --hashlimit-name DNS_LIMIT_UDP2 -j DROP
-A DNS_DROP -p udp -m hashlimit --hashlimit-above  4/min --hashlimit-burst 15 --hashlimit-mode srcip --hashlimit-srcmask 24 --hashlimit-htable-expire 240000 --hashlimit-name DNS_LIMIT_UDP3 -j DROP

## DNS - TCP progressive rate limit
-A DNS_DROP -p tcp -m hashlimit --hashlimit-above  6/sec --hashlimit-burst 30 --hashlimit-mode srcip --hashlimit-srcmask 24 --hashlimit-htable-expire  10000 --hashlimit-name DNS_LIMIT_TCP  -j DROP
-A DNS_DROP -p tcp -m hashlimit --hashlimit-above 60/min --hashlimit-burst 60 --hashlimit-mode srcip --hashlimit-srcmask 24 --hashlimit-htable-expire 120000 --hashlimit-name DNS_LIMIT_TCP2 -j DROP
-A DNS_DROP -p tcp -m hashlimit --hashlimit-above 24/min --hashlimit-burst 90 --hashlimit-mode srcip --hashlimit-srcmask 24 --hashlimit-htable-expire 240000 --hashlimit-name DNS_LIMIT_TCP3 -j DROP

## DNS - UDP & TCP root any/all query filter
-A DNS_DROP -p udp -m string --hex-string "|0000ff0001|" --algo bm --from 40 -j DYN_DROP
-A DNS_DROP -p tcp -m string --hex-string "|0000ff0001|" --algo bm --from 52 -j DYN_DROP

## Dynamic Drop List
-A DYN_DROP -m recent --rsource --set --name DYN_DROP_LIST -j DROP
NOYB
  • 191
  • 6