1

Situation: Server (Win 2008R2) is being used in a DNS (amplification) DDoS attack. Amplification factor is already down to 1: Set the DNS server to non-recursive and removed all root hints -> DNS replies server failure for non-authoritative domains -> incoming DNS request size EQ outgoing DNS request size.

Still, even without amplification we are still unwillingly participating, if only as a simple deflector (since most likely the destination address has been spoofed to direct the DNS response traffic to the DDoS target).

Question: Is there and if yes, what is, the easiest way to prevent DNS responses for specific domain DNS requests? Reason behind that question is, that all those malicious DNS requests are for the same domain but from varying IPs. So IP blocking is not really that effective.

So how to filter out those DNS requests for specific domains and where (can the DNS server handle this or does that have to be done on the firewall?)?

Philip Allgaier
  • 268
  • 1
  • 5
  • 18
  • 1. If you've disabled recursion then the server should only answer for zones that it is authoritative for, so I don't see how it could still be an "unwilling participant". 2. How do you know that it is still an "unwitting participant"? What are the symptoms you're seeing? – joeqwerty Jun 06 '13 at 14:04
  • @joeqwerty This type of attack usually leverages source address spoofing on UDP packets, so amplified or not, he will still be an unwilling participant in a reflection attack – Mathias R. Jessen Jun 06 '13 at 14:06
  • @joeqwerty As Mr. Jessen already pointed out, I assume that there is some address spoofing going on. For each incoming DNS request, there is still an outgoing DNS request visible in Wireshark, so I am most likely still participating, even if only as a reflector and not an amplifier. – Philip Allgaier Jun 06 '13 at 14:09
  • The server should only be answering `NXDOMAIN`. If you want to do more than that, you need a firewall. – gparent Jun 06 '13 at 14:14
  • @gparent From the looks of it, the DNS server seems to return SERVFAIL instead. When doing a manual nslookup via CMD with -DEBUG, the first query response is SERVFAIL and then NXDOMAIN results. XXX>nslookup -debug directedat.asia ------------ Got answer: HEADER: opcode = QUERY, id = 1, rcode = SERVFAIL header flags: response, want recursion questions = 1, answers = 0, authority records = 0, additional = 0 QUESTIONS: 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa , type = PTR, class = IN – Philip Allgaier Jun 06 '13 at 14:25
  • You're right, that's what I meant. It's responding more than once to the queries? – gparent Jun 06 '13 at 14:26
  • @gparent Yes, for one nslookup 7 answers for some reason (at least in debug mode). – Philip Allgaier Jun 06 '13 at 14:27
  • Apparently this is possible with pfsense/snort. http://www.plugged.in/network/snort-rules-for-isc-org-and-ripe-net-dns-amplification-attacks.html – Nic Jun 07 '13 at 07:43

2 Answers2

3

Is there any particular reason why your server has to answer to external queries at all ?

Ideally, you would setup an external resolver for your public resolver (used to resolve all resources that must be accessed externally: MX, web server, etc), use the windows DNS server only for your internal network and block all incoming DNS queries at your perimeter.

There is one thing, however, that you simply cannot prevent: as soon as you have a DNS server that answers to external queries, even if it's only for your own domain, it can be used in a DNS bounce attack. You can configure it to prevent DNS amplification but not to prevent simple bounces. It shouldn't be a big deal unless you're getting DDoS'ed yourself though.

Edit:

The typical way to setup dns in small(ish) structure is the following:

  • You use an internal DNS server inside your network boundary. That server is only accessible from the internal network and VPN'ed hosts and networks.
  • For external resolution, you configure the internal server to forward queries to either your gateway device (typically a multi-purpose DLS modem-router) or directly to your ISP's DNS server. You MUST allow this traffic to flow through but you can limit it quite tichtly.
  • If you own a public domain, you use an external DNS server to host it (well, usually at least two servers). These server should be configured to answer to queries for zones they are authoritative on and ONLY to these queries. (There are many offers for DNS hosting and pretty much all domain hosting comes with such an offer).
Stephane
  • 6,432
  • 3
  • 26
  • 47
  • So, for the internal-only DNS approach, I would block all incoming UDP 53 traffic except for my white-listed internal IPs from my internal servers and the IPs assigned to VPN connections? Otherwise if I would stay with the two-fold approach (DNS serving both internal and external names), there is nothing I could do to prevent the DNS reflection situation other than blocking the IPs either manually or looking for some sort of automatic solution (e.g. if one IP sends too many UDP packs within a certain time-frame)? – Philip Allgaier Jun 06 '13 at 14:38
  • 1
    You simply cannot prevent DNS reflexion if your DNS is authoritative for a public domain. You can prevent DNS traffic amplification by making sure it only answers to legitimate queries, though. – Stephane Jun 07 '13 at 06:58
0

The amplification attack works very well even with recursion turned off and when domains are queried that the server is not authoritative for.

The incoming UDP packet (with fake IP) is 72 bytes if I recall, and if the dot (.) zone is not set up with zero records, the response can be as high as 720 bytes....a factor of 10.

  1. Be sure recursion is off if it is an authoritative server.
  2. Set up the dot (.) zone with no records, an SOA is fine and will not change response size.

After doing this the response will be around 90+ bytes so the bulk of the amplification effect is gone.

As far as filtering queries for specific domains I think the only Microsoft OS that will do that is Server 2016 with the new DNS query policy. The only major update to DNS I see, is the response rate limiting that bind has had for years.

Like others have said, if it is a recursive for an internal network or specific clients, block all access to port 53 except those IPs you want to allow.

As a side note I will take a small wager that many of those getting nailed with the fake queries, it will be a query for freeinfosys.com

Philip Allgaier
  • 268
  • 1
  • 5
  • 18
Universal4
  • 31
  • 2