[dns-operations] Use of Views/ACLs to defeat DNS rebinding/pinning attacks?

Roland Dobbins rdobbins at cisco.com
Tue Aug 7 18:31:48 UTC 2007


On Aug 7, 2007, at 11:17 AM, Simon Waters wrote:

> The problem is you can't constrain DNS because of a problem in  
> application X,
> because there are many applications that use the DNS, and the  
> subset of all
> these constraints means that no workable DNS model might be left that
> satisfies all of them simultaneously.

Who's talking about constraining DNS?  My question/suggestion  
centered around rewriting DNS query results for a specific application.

> Given the evolution of the web so far, probably the only realistic  
> security
> model is whitelisting trusted sites (by domain) for Javascript,  
> Flash, Java,
> ActiveX (or disable ActiveX completely) etc, along side security in  
> depth.

This isn't realistic at all, given that legitimate/popular  
destination sites are being compromised left and right and malicious  
code is injected into them.  Disabling Java/JavaScript/Flash isn't  
realistic, either, given that so many Web sites today require these  
technologies in order to function.  We can't put that genie back in  
the bottle, unfortunately.

> If you think that a switch between remote and local IP addresses  
> should be
> detected and handled, it is probably best to deploy this into  
> browsers (or
> plugins), since these applications have the best chance of  
> identifying when
> such a change is malicious. It also avoid committing to DNS as the  
> name
> providing system (which given the history of Microsoft's name  
> resolution, is
> probably not something you want to hard code).

All I'm looking for is the capability to configure DNS servers to do  
this, if the operator wishes to do so, not change default behaviors  
or anything of the sort without extensive community discussion and  
buy-in.  Again, I see such a capability as being useful for many  
applications, this just being one of them.

> But it seems relatively clear that it is the responsibility of the  
> security
> manager of the application in question to identify a change of IP  
> address (or
> unusual IP addresses in a DNS response), and behave sensibly.  
> Clearly if some
> check on IP addresses by the security managers were in place, the  
> current
> ugly caching behaviour could be removed, and people could switch to  
> using DNS
> to do funky things with load balancing for the web and the like.

Concur, but I don't want to make the perfect the enemy of the merely  
good.

;>

>
> i.e. If you make a DNS request, and get a well formed answer, it is  
> the
> requestors responsibility to make sense of the response.

How does this jive with changing the default BIND 9 behavior to  
disallow recursive requests from outside the IP addresses contained  
in one's zone files?

>
> I see no problem with the ISC or someone producing client code and/ 
> or an API,
> or other tools, suitable for such a security manager - since the  
> problem is
> common between Java, Flash, Javascript, and a number other Internet
> applications, but I don't think the checks belong in the core  
> protocol or
> name servers themselves.

Nobody's asking for a check - just a match/filtering capability  
similar to what's already there today w/Views.  Really, a supplement  
to Views, nothing new.

> Afraid it boils down to people made compromises in building the  
> web, don't
> start from here ;)

I wasn't looking for a discourse on the design and implementation  
philosophy of the DNS, just a way to do some tactical filtering/ 
rewriting of DNS responses, heh.  Since there doesn't seem to be a  
definitive answer on whether this is possible using BIND w/ACLs and  
Views today, I guess it's time to roll up my sleeves and play in the  
lab.

Thanks for the discussion, wide-ranging as it was.

;>

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at cisco.com> // 408.527.6376 voice

	Culture eats strategy for breakfast.

            -- Ford Motor Company





More information about the dns-operations mailing list