0

During DNS amplification attacks on a DNS server, I observed that some DNS requests have for couple IP/port something like 104.49.96.196:80. I understand this is spoofed IP, but is it ok to consider filtering the port of the DNS request? I believe we should not expect a port > 1023. Is it a safe assumption? In that case, I believe this is an easy win to spot and not reply to DNS amplification attack (if the packet reach the DNS server and not dropped by the WAF).

Improve this question

2 Answers 2

Reset to default
1

No, it is not a safe assumption. Do not try to filter on ports, this won't yield useful consequences. How a client handles its local ports it is its own business and hence as a server you can expect to get traffic from all ports. The Unix split at 1024 is an archaic legacy of the past that means nothing anymore basically today.

If you want to combat DNS amplification, besides "standard" measures (like making sure you really need to handle all the traffic that you get, that is you are not wide open), one of the most often used way nowadays is RRL or basically rate limiting.

Look at https://www.infoblox.com/dns-security-resource-center/dns-security-solutions/dns-security-solutions-response-rate-limiting-rrl/ for an introduction on the subject and at https://www.isc.org/docs/DNS-RRL-LISA14.pdf for a more technical presentation.

Improve this answer
11
  • Do you have reference to any RFC that makes the declaration in RFC6056 "an archaic legacy of the past that means nothing anymore basically today" ? Commented Aug 3, 2021 at 15:07
  • 1
    That "archaic legacy of the past" is well codified in RFC 6335, for instance. Commented Aug 3, 2021 at 15:19
  • @NiKiZe There is nothing in the RFC that mandates anything. The sentence is "However, ephemeral port selection algorithms should use the whole range 1024-65535." Note that it is "should" and not "SHOULD" (or even "MUST") which makes a BIG difference in IETF world, see RFC2119 for explanations on that. Commented Aug 3, 2021 at 15:20
  • @MichaelHampton Not mandatory, see comment above. It is a minor case "should". That is not an IETF specification mandating anything, just a best current practice out of what happens today. Commented Aug 3, 2021 at 15:21
  • 2
    @NiKiZe (and @MichaelHampton) maybe it is not clear, but in theory I kind of agree with you. My point is that I want to convey to OP that combatting DNS amplification/DDOS problems should not rely on filtering source ports, because that will be fragile and limited. Commented Aug 3, 2021 at 16:01
1

DNS clients should have source port of > 1023.

If it is < 1024 it should only be source port 53 if it comes from some other DNS server - but that is unlikely.

Verify with tcpdump port 53

By looking at RFC6056 and simplification with some samples we might go further and say that any well behaving IP stack should not have (had) a source port lower than 49152 (first ephemeral port). However section 3.2 contradicts this, and so does the samples.

But until anyone can provide reference to RFC that redefines RFC6056, it is safe to say that sport <= 1023 is not valid.

If there for some reason is a request that fails, the client should retry, and hopefully get a successful request. (Even if this would fail, I would ignore those implementations)

Improve this answer
4
  • I totally agree with you. My concerns was more about implementing that filtering on the port? can it have a downside I miss? Is there any well known DNS resolver (I did not find any info about that) that implements this filtering? Commented Aug 3, 2021 at 11:53
  • As a rule, nothing should have a source port < 1024, unless that application also listens on that port, and the only thing that should send DNS requests directly to your server is other DNS servers. As such there should not be any issues. Any client should have fallback dns servers as well, so unlikely that you will actually have a client failure, at worst a delay. Commented Aug 3, 2021 at 11:58
  • "As a rule, nothing should have a source port < 1024, unless that application also listens on that port, " Can you give some references from where this rule comes from? Commented Aug 3, 2021 at 14:25
  • Reference to RFC added. Commented Aug 3, 2021 at 15:14

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.