<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 03-Aug-18 14:00, Petr Menšík wrote:<br>
<blockquote type="cite"
cite="mid:%3Cf3eb9507-2b53-083e-74cc-f6857fb40e59@redhat.com%3E">
<pre wrap="">Hi!
Our internal support reached to me with question, why are some queries
bound to low ports silently dropped. I have found there is feature for
that, that will silently drop queries from selected ports.
I admit queries from such low ports are wrong. But why are some ports
allowed when some ports are not? Should not it be configured by firewall
instead?
Just try this command:
$ sudo dig @127.0.0.1 -b 127.0.0.1#32 localhost
If bind is running on local interface, it will drop the query. If any
other server is running there, it will respond.
Does such feature make sense in year 2018? Can you remember what was
motivation to implement it? Is it wise to still enable it by default,
without at least configure option to disable it?
1.
<a class="moz-txt-link-freetext" href="https://gitlab.isc.org/isc-projects/bind9/commit/05d32f6b0f6590ca22136b753309f070ce769000">https://gitlab.isc.org/isc-projects/bind9/commit/05d32f6b0f6590ca22136b753309f070ce769000</a>
</pre>
</blockquote>
Those particular ports are reserved for services that have the
rather odd property that any junk set to them will result in a
response. E.g. simply opening a connection to daytime will result
in a response with the current date and time in some (unspecified)
ASCII format. Daytime returns a 32-bit time - that will overflow
"soon"; you should be using NTP instead.<br>
<br>
They were designed for diagnostic purposes at a time when the
internet was young and friendly.<br>
<br>
Suppose someone knows of a server running one of those services
(they have mostly been replaced/blocked for this and other reasons).<br>
<br>
If that someone were able to spoof a request from one of these ports
on that server to your named, responding with anything - including a
FORMERR response, would result in another response. Named would
take that as another ill-formed request, and reply... In an
infinite loop using whatever bandwidth is available. This amounts
to a denial of service attack on both servers, for the cost of a
single packet/connection. Dropping these packets is the right thing
to do, since the non-named services are acting correctly (according
to their specifications). And if operating according to their
specifications, none of those servers would ever *initiate* a
connection to anyone - including named.<br>
<br>
As for why other low-numbered ports are not dropped: unlike these,
they may have legitimate needs for name resolution. You could
configure a firewall to drop these - and probably should. But it
certainly doesn't hurt for named to protect itself from this
particular attack.<br>
<br>
I should note that your example used port 32 - which is not dropped
by the commit that you cited. Port 32 is not assigned by IANA.<br>
<br>
[Although this is a security issue, I'm not revealing anything new
here. The commit is 12 years old. It has been standard advice for
many years not to run these services on the public internet. If
anyone IS running them(I think NIST is still running the time
services), they should know the risk, and at least rate-limit
requests from any given client IP...]<br>
<br>
<pre class="moz-signature" cols="72">Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
</pre>
<br>
<br>
</body>
</html>