Dropping queries from some well-known ports

[Timothe Litt]

On 03-Aug-18 14:00, Petr Menšík wrote:
> 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.
> https://gitlab.isc.org/isc-projects/bind9/commit/05d32f6b0f6590ca22136b753309f070ce769000
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.

They were designed for diagnostic purposes at a time when the internet
was young and friendly.

Suppose someone knows of a server running one of those services (they
have mostly been replaced/blocked for this and other reasons).

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.

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.

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.

[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...]

Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed. 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20180803/34b88908/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4577 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20180803/34b88908/attachment.bin>