Same source port queries dropped by ServerIron load balancer

Kevin Darcy kcd at chrysler.com
Mon Apr 5 22:10:45 UTC 2010


On 4/4/2010 3:33 PM, Barry Margolin wrote:
> In article<mailman.1058.1270395730.21153.bind-users at lists.isc.org>,
>   Kevin Darcy<kcd at chrysler.com>  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.
>>      
> There's a well-defined place where security is supposed to be enforced:
> the firewall.  I suppose the device in question may be a combination
> firewall and load balancer.
>    
There's a difference between the product category "firewall" and the 
actual *role* "firewall" (which I believe is classically defined as a 
device which applies policy-based security controls.to network traffic 
flowiing between entities at differing levels of trust, or similar 
wording). Just because a "load-balancer" (according to product category) 
may not be labelled as a "firewall" on its front panel plate, or in a 
diagram of the network topology, doesn't mean it can't or shouldn't be 
serving that role in the network/security infrastructure. As for the 
singular "a well-defined place", there's nothing wrong with having 
multiple levels of security and security enforcement, or multiple levels 
of "firewalls" (the role not the product category) in the environment. 
http://en.wikipedia.org/wiki/Defense_in_depth_(computing)

> But a firewall in front of a server should be protecting the server, not
> protecting the clients from themselves.
>    

Preventing any complicity in the poisoning of a client's cache is 
certainly a legitimate security policy objective, is it not?
>> 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.
>>      
> Since when does a DNS server need to "trust" the client?  The server
> just answers questions, it doesn't incorporate any information from the
> client (except for dynamic DNS updates, but these are almost always
> clients inside the security perimiter).
>    

I'm not sure exactly what point you're trying to make. If DNS servers 
never need to trust their resolving clients, then why does BIND have 
multiple ways of identifying clients (either source address/range or 
TSIG key), which then can be used in any of the "allow-" stuff 
(-transfer, -query, -query-cache, -recursion), or by "match-clients" as 
a basis for "view" selection, and so forth?

                                                                         
                                                         - Kevin





More information about the bind-users mailing list