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