Same source port queries dropped by ServerIron load balancer

Sten Carlsen stenc at s-carlsen.dk
Sun Apr 4 18:24:27 UTC 2010



On 04/04/10 17:41, Kevin Darcy wrote:
> 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? 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.
The question I saw being raised was not if such queries wer trustworthy
or not; but whether it is the job of a load balancer to judge the inner
workings of an application protocol.

I tend to agree that the load balancer should just hand the packets on
to whoever is there to answer the questions/serve the content.

This would be the reason we have heard so much about broken
routers/bridges/firewalls/... that will not allow EDNS packets, because
they were once suspect.

When DNSSEC/NSEC/... is completely implemented, who will then reevaluate
if this load balancer is in need of a change? maybe there will be nobody
to fix it? Let each part of the system do the job it was put there to do
and not try to do what it does not really understand how to do in the
long run. Otherwise you ask for trouble for your successor.

>
> 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
>
>
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!" 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20100404/29e39f24/attachment.html>


More information about the bind-users mailing list