Same source port queries dropped by ServerIron load balancer
Mark Andrews
marka at isc.org
Sun Apr 4 19:31:18 UTC 2010
In message <4BB8B33B.4070906 at chrysler.com>, Kevin Darcy writes:
> On 4/1/2010 9:19 PM, Barry Margolin wrote:
> > In article<mailman.1048.1270148466.21153.bind-users at lists.isc.org>,
> > Kevin Darcy<kcd at chrysler.com> wrote:
> >
> >
> >> Re-use of source ports for DNS queries is a bad security practice. I
> >> cast my vote in favor of penalizing it, in the default configuration of
> >> any device that responds to DNS requests.
> >>
> > It's really not the job of a load balancer or server to force clients to
> > use good security practices.
> >
> Trouble is, when everyone carves out their little area of responsibility
> such that enforcing good security practices is "not my job, man", then
> very few things enforce security practices, and ultimately they don't
> get enforced at all.
>
> Certainly a load-balancer can legitimately refuse to serve queries that
> are suspect, can it not?
Suspect of what? I could be using SIG(0) or TSIG or IPSEC or 0x20 or ...
to secure the queries. It's not the load balancer's job to ensure that
client can't be spoofed. I could be just be asking lots of questions
and have re-used the source port. As a client I just need to keep the
qid unique for any outstand queries to this server from this port.
> E.g. that are malformed in particular ways that
> indicate hostile intent. So, where in the spectrum of "suspectness" can
> we draw the line and say, everything on that side, I trust to answer,
> and everything on the other side of the line, I don't? I think a client
> that re-uses source ports is untrustworthy. Therefore I think it's a
> reasonable default to decline to service queries from such clients.
A client that re-uses source ports is 100% normal. It may not be
up to current best practice but there is nothing abnormal about it.
> I realize that such a default setting may not be very popular. A lot of,
> er, unsophisticated customers for such devices may not realize or
> understand the default setting and then may have a tough time
> understanding why they have difficulty serving DNS to certain clients.
> But this is a matter of notification/documentation and education. The
> manual should have in big red letters "IF YOU WANT TO SUPPORT CERTAIN
> LEGACY CLIENTS THAT DO NOT CONFORM TO BEST CURRENT SECURITY PRACTICES,
> YOU NEED TO CHANGE THE DEFAULT SETTING". At least then, the customer is
> made aware of the insecurity that they are enabling by changing the
> setting. This may also be a factor if there is ever any question about
> legal liability in the case of a security event.
>
> > I suspect this is actually a bug, but the vendor is using the security
> > value of it as an excuse to lower its priority.
> >
> That may also be true, if I were dealing with the vendor I'd point out
> that if it is a deliberate security design, it should only be a default
> and there *must* be a way to turn it off. I can think of lots of
> internal environments where the clients and servers, and their
> interaction is considered secure, but there is a re-use -- or apparent
> re-use -- of source ports, and in those particular cases the
> load-balancer shouldn't be refusing service. If there is no way to turn
> off this "security feature", then it should be possible to embarrass the
> vendor into admitting that it's really a bug rather than a designed-in
> feature.
>
>
> - Kevin
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka at isc.org
More information about the bind-users
mailing list