[169781] in North American Network Operators' Group
Re: new DNS forwarder vulnerability
daemon@ATHENA.MIT.EDU (Jimmy Hess)
Sat Mar 15 07:39:00 2014
In-Reply-To: <20140314220616.GA69028@wakko.typo.org>
From: Jimmy Hess <mysidia@gmail.com>
Date: Sat, 15 Mar 2014 06:38:11 -0500
To: Wayne E Bouchard <web@typo.org>
Cc: NANOG list <nanog@nanog.org>, Merike Kaeo <merike@doubleshotsecurity.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Fri, Mar 14, 2014 at 5:06 PM, Wayne E Bouchard <web@typo.org> wrote:
> Have we ascertained if there is a typical configuration adjustment
> that can be made to reduce or eliminate the likelihood of impact?
>
I think your best tactic is: Provide specified DNS resolver cache servers.
Don't use CPEs for DNS forwarders.
The trouble is.... a CPE's management/locally-bound IP address is in many
cases... often the same IP address that is a NAT address shared with user
traffic; instead of a dedicated separate IP address that traffic can be
managed and security controlled.
Providing you ensure that the CPE's IP bound address is not overloaded or
shared with user traffic ---- you might try firewalling destination port
53 to the CPE, except from the proper upstream DNS resolvers, since
nothing else should be "replying" to a DNS request made by the CPE.
Look into whether the CPE can use a different, lesser-used UDP port than
53 to forward DNS requests to; use device firewall rules or upstream ACLs
to limit which source IP addresses can talk to the service on the CPE's IP.
To ascertain effectiveness for a specific CPE, you would need to run a
sample exploit with a before and after test.
> (From the description it sounds as though this is not possible but it
> doesn't hurt to ask.)
>
--
-JH
