On 4/4/2010 3:33 PM, Barry Margolin wrote:
In article<mailman.1058.1270395730.21153.bind-us...@lists.isc.org>,
Kevin Darcy<k...@chrysler.com> wrote:
On 4/1/2010 9:19 PM, Barry Margolin wrote:
In article<mailman.1048.1270148466.21153.bind-us...@lists.isc.org>,
Kevin Darcy<k...@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
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
