On Thu, 31 Jan 2013 16:43:37 +0000, Stuart Henderson wrote:
On 2013/01/31 15:29, Jon Morby wrote:
If unicast RPF were a default part of the configuration of end user
CPE
we'd see a dramatic reduction in this sort of crap killing the
networks. (but yes they'd probably find some even more ingenious way
to
generate crap)
In a lot of cases the end user machines behind CPE routers are NATted
so they won't be spoofing the source address anyway - I would imagine
the
bigger source of spoofed packets would be exploited servers etc. And
clearly most CPE vendors are taking a special approach to avoid being
affected by this on IPv6 ;)
On the CPE side I think the bigger problem is with caching DNS
forwarders
open to anyone (which seems like it may be a default on some CPE
routers,
or at least on some ISP default configurations), obviously answering
the
spoofed queries and bombarding the supposed source.
I used to be able to send IP packets using any source address directly
through my home cable modem.. that hasn't been possible with any ISPs
I've used in the last 5 years, but there probably are still a few
somewhere in the world.
Having said that, I think a lot of these kinds of attacks actually
originate from complicit rogue malware ISPs that have deliberately setup
servers such that they're able to spoof.. whether they have 'hacker
clients' or 'hacked clients' or 'fake clients that (oops!) got hacked'
or they're actually just doing it themselves is kindof beside the point.
BCP-38 isn't going to help when people just turn it off.
Unless the attack persists for a very long time, coordinating the
effort to trace the flow of spoofed dns queries will probably take
longer and you'll lose the trail. Even if you trace it back it'll just
turn out to be a 'hacked client' and nobody can prove anything.
It's slightly easier to trace this if it's your nameserver that's being
used as one of the relay/reflectors rather than if you're the target
since you're closer to the true source of the fake queries.
Probably the most productive thing one can do is try and contact the
operators of the relay/refelector nameservers and try to get them to
stop answering requests from outside their own networks.
In the long run though I suspect this attack would still work fairly
well (although with less of an amplification) using authorative
nameservers - which obviously don't have the option of simply ignoring
the internet.
I guess it's something we'll just have to live with for now.. :/
Robert
