Score:0

DNS Resolver and Request Port Filtering

gd flag

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).

Score:1
in flag

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)

vinz avatar
gd flag
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?
in flag
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.
Patrick Mevzek avatar
cn flag
"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?
in flag
Reference to RFC added.
Score:1
cn flag

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.

in flag
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" ?
Michael Hampton avatar
cz flag
That "archaic legacy of the past" is well codified in RFC 6335, for instance.
Patrick Mevzek avatar
cn flag
@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.
Patrick Mevzek avatar
cn flag
@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.
Patrick Mevzek avatar
cn flag
And the source port does not mean anything anymore today. In the past, the "r" commands (rlogin, rtelnet, etc.) just based their authentication on that, believing that if source port was lower than 1024 then it was "privileged" and hence ok. This proved wrong design wise, hence noone does that anymore today, nothing security wise can be derived just from the source port used.
Michael Hampton avatar
cz flag
@PatrickMevzek The IANA clearly does not see it that way.
Patrick Mevzek avatar
cn flag
@MichaelHampton IANA is not the one deciding what **source** ports an OS uses. This is different from destination ports, obviously. Assignment (what IANA deals with) is only a synchronization mechanism for targets. And this is archaic too, if every application used `SRV` records, we wouldn't even have to register port numbers as any of them would support any protocol.
in flag
You are right, nothing prevents <1024 from being used, but it is unlikely, and any DNS response going to port 80 or 443 can be considered invalid, worst case client should retry. It might be better to actually try an implementation that actually uses a sport in the range we are arguing about ;)
Patrick Mevzek avatar
cn flag
@NiKiZe "You are right, nothing prevents <1024 from being used, but it is unlikely," That is only your subjective call, and there is no reference backing that statement.
in flag
I'd say it is statistical, but will collect data, thanks. So far no connection or documentation found that goes against it, will be happy to learn about any case that actually does.
Patrick Mevzek avatar
cn flag
@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.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.