Dropping queries from some well-known ports

[Petr Menšík]

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
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: ***@redhat.com PGP: 65C6C973
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
bind-***@lists.isc.org
https:

[Matus UHLAR - fantomas]

Post by Petr Menšík
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?
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

aren't those port descriptions self-explaining enough?

what is the point of this question at all?
services are not supposed to bind those low ports, and if anyone wants to do
that, they should be aware of possible isss they create.
--
Matus UHLAR - fantomas, ***@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
99 percent of lawyers give the rest a bad name.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
bind-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

[Grant Taylor via bind-users]

Post by Petr Menšík
Hi!

Hi,

Post by Petr Menšík
Our internal support reached to me with question, why are some queries
bound to low ports silently dropped.

Please clarify if you're saying "bound to" as in the code that
originated the query came from said port or if you mean queries that are
going to said port on the DNS server?

Post by Petr Menšík
I have found there is feature for that, that will silently drop queries
from selected ports.

That's new information to me.

Post by Petr Menšík
I admit queries from such low ports are wrong.

I feel like such queries (from) low ports may be "unexpected", but I
don't know that it's "wrong" per say.

Post by Petr Menšík
But why are some ports allowed when some ports are not?

Based on the small list five ports, I'm guessing that these ports caused
a problem and as such are blocked.

Post by Petr Menšík
Should not it be configured by firewall instead?

I'm guessing that named filters the problematic ports as a function of
protecting it's own stability or otherwise desired behavior.

I would expect that firewalls are more for security of the system.

Different scopes of problem use different solutions.

Post by Petr Menšík
If bind is running on local interface, it will drop the query. If any
other server is running there, it will respond.

Bind has chosen to operate in this manner. Other daemons may or may not
make the same choice.

Post by Petr Menšík
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?

I suspect that bind chose to drop these specific source ports because
they likely will result in more traffic back from the client. As such,
sort of causing a feedback loop. Mind you, this is just a guess.

Post by Petr Menšík
1.
https://gitlab.isc.org/isc-projects/bind9/commit/05d32f6b0f6590ca22136b753309f070ce769000

[Carl Byington]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Post by Petr Menšík
1.
https://gitlab.isc.org/isc-
projects/bind9/commit/05d32f6b0f6590ca22136b753309f070ce769000

If I am reading the code correctly, that commit implies that building
bind with -DNS_CLIENT_DROPPORT=0 will disable that feature.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEAREKAAYFAltko7UACgkQL6j7milTFsHUtACfUT6pSUq0TIoHpQI6mN3LFGqv
EGIAn2FZ/8xVzcI3Ewg/Latryo0Vxq05
=/+BG
-----END PGP SIGNATURE-----



_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
bind-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

[Timothe Litt]

Post by Petr Menšík
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?
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.