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