Comware

I've received an email stating that my MSR 1003-8 could be used for a DNS DDOS Amplification attack. The MSR 1003-8 provides DNS to LAN clients and has Google DNS listed as the upstream DNS servers.

I would appreciate guidance on how to prevent the MSR 1003-8 being identified as a potential source of DNS DDOS Amplification attacks.

thx.

Hi @Mark_Gregory !

Since your router provides DNS proxy services for internal clients, I think the most straight-forward option is to deny incoming DNS requests on the WAN interface. Thus the router will be dropping all DNS requests coming from the Internet and nobody will be able to use it for DNS amplification attacks. Just one note - keep in mind that you need to deny only incoming requests, incoming DNS replies from Google DNS servers must be allowed, otherwise you will break the DNS proxy function.

Hope this helps!

thx Ivan_B

I added a rule on the external interface to deny all incoming TCP to port 53.

I'm not sure what you mean by "incoming DNS replies from Google DNS servers must be allowed" - what rule do I use to ensure that this occurs?

Hi @Mark_Gregory !

There are two approaches in security:

1. Allow specific traffic and block all the rest. We can call it 'whitelisting'. This requires specific 'permit' ACL rules and general 'deny any' at the end of the ACL.

2. Block specific traffic and permit all the rest. So called 'blacklisting'. This requires specific 'deny' ACL rules and general 'permit any' at the end of the ACL.

Now to the DNS - when a DNS client sends a request to server, it uses UDP (or TCP) protocol, destination port is always 53, source port is normally an ephemeral port, the range varies depending on the OS used, but the safe choice is all ports greater than 1023. When DNS server gets this request, it replies back using same transport protocol (UDP or TCP), source port of the reply message will be 53 and destination port will be the same ephemeral port used in the request.

Having all these details in mind now we see that:

To explicitly match incoming DNS replies you need an ACL rule with source IP of the DNS server/-s and source TCP and UDP port 53 and destination port greater than 1023.
To explicitly match incoming DNS requests you need an ACL rule matching 'any' source IP and destination TCP and UDP port 53. Because DNS servers listen on port 53. Source port does not matter here, so we match all of them.

Substitute word 'match' with either 'permit' or 'deny' according to your security model. If you use 'whitelisting', it will be 'permit', if 'blacklisting' is used instead, then it will be 'deny',

Pay attention that you need to block or allow BOTH transport protocols - TCP and UDP. DNS has always been designed to use both UDP and TCP port 53 with UDP being the default, and fall back to using TCP when it is unable to communicate on UDP, typically when the packet size is too large to push through in a single UDP packet.

Hope this helps!

thank you Ivan_B. I'm using option 1 - whitelisting, as I notice with the HP MSR 1003-8 manual it says that any traffic not matched to a rule is dropped.

I suppose my question was should the deny go at rule 0 or at the last rule - in my case say rule 10 - and my thoughts are that this rule should go at the end - rule 10.

It's pretty specific rule, so I would place it in the beginning of the ACL before any other rules. In general rules must be sorted in the following way - the most specific ones placed on the top (in the beginnig) and less specific placed after. For example, if you want to allow DNS replies only and drop the rest of the traffic, if you place 'drop any any' in the beginning of the ACL, the 'permit udp source-port 53' will never have a chance to match. More or less that't the logic of how ACL work.

And don't forget that you will need two rules - one for TCP and one for UDP. I don't really remember if Web GUI has something like a shortcut to configure both TCP and UDP at once, but in CLI these must be two different rules.

For example, if Google DNS you use is 8.8.8.8, then both rules look like:

rule 1 permit tcp source 8.8.8.8 0.0.0.0 source-port eq dns destination port gt 1023
rule 2 permit udp source 8.8.8.8 0.0.0.0 source-port eq dns destination port gt 1023

thx Ivan_B, your comments are appreciated.

I've found an example and it has the deny any any as the last ACL ie the highest rule number. This clarifies what I need to do to ensure that only ports that I've opened can be accessed.