However, scanning in IPv6 is not at all like the convenience of comprehensive scanning of the IPv4 address space.
Concur, but I still maintain that lots of illicit automation plus refined scanning via DNS, et. al. is a viable practice.
These are very big numbers, so I don't see how.
Consider you have a dual stack deployment.
what are the most likely ipv6 numbering schemes you're likely to use to
In my case, there are seven numbering schemes in use.
If I query one of your hosts in the forward zone and get back and a and
a aaaa record what can I likely conclude about the numbering scheme for
joelja-mac:~ joelja$ host ns3.xxxxxx.net
ns3.xxx.net has address xxxx.xxx.0.81
ns3.xxx.net has IPv6 address xxxx:xxx:1::81
In my case, this will only help you find the other hosts which have DNS entries in IPv6. Any host which does not have an AAAA record already uses a different numbering scheme entirely.
Even the hosts that do have AAAAs are broken up into different numbering ranges based on my own criteria.
if you do stateful dhcp v6 assignment what are the likely constraints as
to the size of the pool you're going to use for that subnet.
1. Stateful DHCP on a subnet is the exception, not the rule.
2. On networks with DHCP, I would give at least a 48 bit pool.
This is like brute force password guessing... there's some high
probability answers that are low hanging fruit you reach for them, they
don't exist you move on.
In other words, you'll get lucky on a few networks where the administrator failed to move beyond IPv4think.
If you use easy to guess/remember host/service names and put them
in public DNS then those IP addresses are in some sense already public
(whether IPv4 or IPv6). The definition of "easy to guess" is pretty
much everything which has ever been used in a wordlist for password
cracking programs (plus the code which generates variants of same).
Real attackers are going to flood
your DNS servers, not do brute force IPv6 ICMP scans. Even a pure
brute force DNS scan of all 10 character long hostnames (asuming
a-z0-9) is going to take around 5000 times fewer queries then a full
ICMP v6 scan of a /64. (Which at an attack speed of 1000pps is still
going to take around 100,000 years.)
Good luck getting 1000 dns answers per second from most zones.
I suspect a useful DNS scan would be limited to something more like 200 qps.
Even then, you'll trip over my query rate limiter unless you use a whole lot of hosts to do the scan.
For machines which you want to make it REALLY hard to find, but
need publicly accessible addresses, you shouldn't put them in publicly
queryable DNS servers at all and use a random number generator to
generate their static IPv6 addresses. Even if you put a thousand of
these machines in a single subnet, it is going to take half a million
years at reasonable packet rates before even one of them is
Or better yet, have the, cycle through privacy addresses using dynamic updates tom private name server.
Hmm, thinking about it in terms of passwords might help. Many
people consider a totally random 10 character monocase+numbers
password to be reasonably secure against brute force attacks. ICMP
scanning a /64 is thousands of times more difficult and all it gives
you is the existence of the machine. Even if you find that needle in
a hay stack , you don't get access to its resources.
About 6,000 times to be slightly more precise.
36^10 is. ~3,656,158,440,000,000
2^64 is. 18,446,744,073,709,551,616 addresses.
I took a quick look at the paper that SMB linked to and I would
argue that for wide area attacks, packet sniffing is going to be how
people find your "hidden" addresses. Compromising SMB wi-fi hotspot
hardware and logging every address accessed is one possibility. Or
just compromise people's laptops and have them run network sniffers
which generate "seen" address lists which are forwarded to dummy gmail
I think that's much more likely.