Spoofing ASNs (Re: SNMP DDoS: the vulnerability you might not know you have)
hschiller at google.com
Thu Aug 22 22:28:04 UTC 2013
This is the RFC that is being violated:
6.2 <http://tools.ietf.org/html/rfc5625#section-6.2>. Interface Binding
Some gateways have been observed to have their DNS proxy listening on
both internal (LAN) and external (WAN) interfaces. In this
configuration, it is possible for the proxy to be used to mount
reflector attacks as described in [RFC5358
The DNS proxy in a gateway SHOULD NOT, by default, be accessible from
the WAN interfaces of the device.
Implemented correctly, CPE receives DNS request and proxies the request
internally. Usually they are only listening on the LAN side. Sometimes
they take DNS requests from the WAN side. When a local DNS cache is not
defined, these requests can leak out to whatever cache is defined. In some
cases, the CPE retains the IP address that originally sourced the packet.
So you end up with external caches responding to requests from 3rd
parties. Add to that spoofing the original packets to the bad CPE and you
have that CPE proxying your DNS amplification attack to other caches.
Don't blame the cache. The attacker was intending that the CPE amp
CPE should disable DNS proxying by default and require a restricted list of
sources (LAN, vpn, etc) when enabled. Also/alternatively require cache to
On Sun, Aug 11, 2013 at 5:45 AM, Florian Weimer <fw at deneb.enyo.de> wrote:
> * Jared Mauch:
> > Number of unique IPs that spoofed a packet to me. (eg: I sent a
> > packet to 18.104.22.168 and 22.214.171.124 responded).
> That's not necessarily proof of spoofing, isn't it? The system in
> question might legitimately own IP addresses from very different
> networks. If the system is a router and the service you're pinging is
> not correctly implemented and it picks up the IP address of the
> outgoing interface instead of the source address of the request,
> that's totally expected.
> I'm not saying that BCP 38 is widely implement (it's not, unless
> operators have configured exceptions for ICMP traffic from private
> address, which I very much doubt). I just think you aren't actually
> measuring spoofing capabilities.
More information about the NANOG