Same source port queries dropped by ServerIron load balancer

[Barry Margolin]

In article <mailman.1074.1270505464.21153.bind-users at lists.isc.org>,
 Kevin Darcy <kcd at chrysler.com> wrote:

> 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?

I think there's a difference between complicity and forcing the client 
to protect itself.  Especially since end users typically can't fix the 
problem themselves (they're usually using caching servers operated by 
someone else -- their ISP or their corporate IT Dept.).  So if someone 
gets blocked by this, what are they supposed to do about it?  Even if 
they can change DNS servers (e.g. switch to OpenDNS or Google DNS), it 
wouldn't be obvious that the problem is one that would be solved by this.

> >> 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?

All the allow-XXX stuff is for privacy, not trust.  And the multiple 
methods of identifying the client are to work around limitations in 
TCP/IP (source addresses can be spoofed) and deal with different 
networking environments.  For instance, TSIG key is often useful when 
you need to transfer two different views to the same slave server, so 
that it can also serve both views; you can't use match-address because 
they're the same address.

-- 
Barry Margolin, barmar at alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***