Score:0

Server

DNS Resolver and Request Port Filtering

vinz

12/3/22, 8:24 AM

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

158

2 + 0

domain-name-system

Score:1

Server

NiKiZe

12/3/22, 9:35 AM

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)

0 + 4

vinz

12/3/22, 11:53 AM

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?

NiKiZe

12/3/22, 11:58 AM

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

12/3/22, 2:25 PM

"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?

NiKiZe

12/3/22, 3:14 PM

Reference to RFC added.

Score:1

Server

Patrick Mevzek

12/3/22, 2:28 PM

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.

0 + 11

NiKiZe

12/3/22, 3:07 PM

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

12/3/22, 3:19 PM

That "archaic legacy of the past" is well codified in RFC 6335, for instance.

Patrick Mevzek

12/3/22, 3:20 PM

@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

12/3/22, 3:21 PM

@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

12/3/22, 3:22 PM

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

12/3/22, 3:25 PM

@PatrickMevzek The IANA clearly does not see it that way.

Patrick Mevzek

12/3/22, 3:27 PM

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

NiKiZe

12/3/22, 3:28 PM

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

12/3/22, 3:29 PM

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

NiKiZe

12/3/22, 3:48 PM

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

12/3/22, 4:01 PM

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

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: DNS Resolver and Request Port Filtering

TH: ตัวแก้ไข DNS และการกรองพอร์ตคำขอ

RO: Rezolvarea DNS și filtrarea portului de solicitare

RU: DNS Resolver и фильтрация портов запросов

VI: Trình giải quyết DNS và lọc cổng yêu cầu

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.