In article <mailman.1074.1270505464.21153.bind-us...@lists.isc.org>, Kevin Darcy <k...@chrysler.com> wrote:
> 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? 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, bar...@alum.mit.edu Arlington, MA *** PLEASE don't copy me on replies, I'll read them in the group *** _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
