just seen my first IPv6 network abuse scan, is this the start for more?
owen at delong.com
Fri Sep 3 12:58:40 UTC 2010
On Sep 3, 2010, at 3:46 AM, Dobbins, Roland wrote:
> On Sep 3, 2010, at 5:14 PM, Igor Ybema wrote:
>> I discovered a external IPv6 host was doing a (rather useless due to the amount of addresses) IPv6 ICMP scan on our network recurring daily and mostly during the nights, sometimes with speeds of 1000 scans per second.
> Not necessarily so useless, as it was hitting your boxen, eh?
> Plus, setting bots to go scan isn't very labor-intensive. All the talk about how scanning isn't viable in IPv6-land due to large netblocks doesn't take into account the benefits of illicit automation.
Uh... He mentioned 1000 addresses/second... At that rate, scanning a /64 will take more than
18,000,000,000,000,000 seconds. Converted to hours, that's 5,000,000,000,000 hours which
works out to 208,333,333,333 days or roughly 570,776,255 years.
If you want to scan a single IPv6 subnet completely in 1 year, you will need to automate
570,776,255 machines scanning at 1000 ip addresses per second, and, your target network
will need to be able to process 570,776,255,000 packets per second.
Yes, you can do a certain amount of table-overflow DOS with an IPv6 scan, but, you really
can't accomplish much else in practical terms.
> Note that hinted scanning, based upon DNS treewalking and so forth, is a useful refinement.
Yes, you can find hosts for which you already know the addresses easily this way. Obviously,
there are a few other tricks that make it easy to find individual targets (such as the convention
of making a router <subnet>::1). However, scanning in IPv6 is not at all like the convenience
of comprehensive scanning of the IPv4 address space.
>> Due to the ammount of IPv6 neighbor discoveries from our routers resulting from this scan the Neighbour table overflow messages appeared on the machines.
> Any noticeable effect on router CPU?
Probably not a lot. Probably even less on the boxes reporting the neighbor table overflow.
Other than generating some noisy error messages, this should have been pretty much a non-
More information about the NANOG