just seen my first IPv6 network abuse scan, is this the start for more?
Hi, Since recently we noticed "Neighbour table overflow" warnings from the kernel on a lot of Linux machines. As this was very annoying for us and our customers I started to dump traffic and tried to find the cause. 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. Due to the ammount of IPv6 neighbor discoveries from our routers resulting from this scan the Neighbour table overflow messages appeared on the machines. Are there more people who have seen this behaviour recently? Is this a start of hackers/spammers onto the IPv6 network? This is the first scan I have seen. I already contacted the ISP for the source address. No answer yet. If I have more news I will post them here. regards, Igor Ybema the Netherlands
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. Note that hinted scanning, based upon DNS treewalking and so forth, is a useful refinement.
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? ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Sell your computer and buy a guitar.
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- event. Owen
On Sep 3, 2010, at 7:58 PM, Owen DeLong wrote:
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. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Sell your computer and buy a guitar.
On Sep 3, 2010, at 9:49 40AM, Dobbins, Roland wrote:
On Sep 3, 2010, at 7:58 PM, Owen DeLong wrote:
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.
See http://www.cs.columbia.edu/~smb/papers/v6worms.pdf --Steve Bellovin, http://www.cs.columbia.edu/~smb
Steven Bellovin wrote:
Or my lame take on the matter http://geekmerc.livejournal.com/1421.html -Jack *saves yours to read up later*
On Sep 4, 2010, at 12:19 AM, Steven Bellovin wrote:
I've seen it and concur with regards to worms (which don't seem to be very popular, right now, excepting the 'background radiation' of old Code Red, Nimda, Blaster, Nachi, SQL Slammer, et. al. hosts). I believe that hinted scanning is still viable, and I'd argue that the experience of the OP who kicked off this thread is an indication of same. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Sell your computer and buy a guitar.
Forgive the top posting, but Lookout is the corporate standard. Now, on to the topic at hand. Why would you scan the address space in the first place? Wouldn't it be easier to compromise a known host and look at the ARP table? Or better yet, the router on the edge? If it's moving packets, something on the network has mapped the MAC address to its IP at some point. Jamie -----Original Message----- From: Dobbins, Roland [mailto:rdobbins@arbor.net] Sent: Friday, September 03, 2010 3:42 PM To: NANOG list Subject: Re: just seen my first IPv6 network abuse scan, is this the startfor more? On Sep 4, 2010, at 12:19 AM, Steven Bellovin wrote:
I've seen it and concur with regards to worms (which don't seem to be very popular, right now, excepting the 'background radiation' of old Code Red, Nimda, Blaster, Nachi, SQL Slammer, et. al. hosts). I believe that hinted scanning is still viable, and I'd argue that the experience of the OP who kicked off this thread is an indication of same. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Sell your computer and buy a guitar.
Forgive the top posting, but Lookout is the corporate standard.
It prevents you from typing at the bottom? How quaint :-)
Now, on to the topic at hand. Why would you scan the address space in the first place?
Maybe because you haven't really thought about the magnitude of the task? Maybe you feel that there's some likelihood of certain addresses being used? We've seen stupid things under IPv4, and it seems certain that IPv6 won't be immune to stupid vendor tricks.
Wouldn't it be easier to compromise a known host and look at the ARP table?
Maybe; however, it's not clear that this would be useful in generating a complete list of available hosts, though it would certainly provide the opportunity for finding more of them.
Or better yet, the router on the edge? If it's moving packets, something on the network has mapped the MAC address to its IP at some point.
And if it isn't moving packets, then maybe nothing has. The devices on a network that are just idling and may be forgotten or unloved may be at a fairly high risk for exploits and all that. Eventually this sort of thing is going to be a problem, as the number of network- attached devices is exploding. What's going to be more interesting is the number of devices that are (re-)programmable; we'll eventually see malware networks that are able to target more than just your CPE/router device, and will have attack vectors against your ATA, your TV, your DVR, your fridge, etc. The trick is to find those devices, but even in a bad case scenario, where you might have to scan the network to find additional devices to infect, the use of scanning alone isn't practical, but scanning for devices from a given manufacturer's MAC assignment pool might be, especially if you've essentially got forever in which to do it, and certainly sitting there passively on the network snooping is very practical. The fact that many people walk around with a cell phone that has a high speed processor and lots of memory in it says a lot about where consumer electronics is going, and that we're likely to be seeing a lot more of this sort of low-level bad guy activity that is able to target a list of heterogeneous targets. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
On Tue, 07 Sep 2010 09:03:12 EDT, Jamie Bowden said:
Now, on to the topic at hand. Why would you scan the address space in the first place? Wouldn't it be easier to compromise a known host and look at the ARP table? Or better yet, the router on the edge? If it's moving packets, something on the network has mapped the MAC address to its IP at some point.
Remember that although there are some truly scary black hats out there, the vast majority of them are even less technically savvy than your average trainee banana eater, and will do things so mind-bogglingly stupid that you have to roll a saving throw at -5 to disbelieve ;) True incident I worked on sometime last century: I get called about this AIX box, it's been hosed for "a while", and they can't login to run the one application they ran literally once a year that they kept this box around for. Preliminary indications are /etc/passwd is scrozzled. So I boot off an install CD and start looking. Takes about 10 seconds to figure out the box was hacked. I'm amazed - the machine wasn't fully hardened, and was *way* behind on patches. On the other hand, it *was* at least tcp-wrappered, and the attacker managed to fingerprint it as an AIX box without setting any of the wrappers off. The guy whacked it with either a telnetd or ftpd exploit, and by looking at process accounting, I was able to verify it worked on the *first* try. I'm suitably impressed at this point - even 15 years ago, AIX wasn't common enough that most black hats kept exploits in their back pockets (much less know enough to use them on the first try). Guy whacks the box on the very first try, and then it gets interesting. Guy says 'cat > /etc/paswd^[[D^[[Dswd' because he doesn't realize his exploit rootshell doesn't have line editing. Guy tries to get in on a second session, realizes his attempt to set a root backdoor didn't work, so he does this for his second try: cat > /etc/passwd foo::1:0::/: ^D Yep. 1. Not zero. And > not >>. So then when he tries to come in via telnet again, inetd won't do it because inetd.conf says 'root' and there's no 'root' in /etc/passwd anymore. Actual forensics work: about 15 mins. Convincing myself it was a damned lucky ankle-biter and not a uberhacker leaving a false trail: most of an 8-hour day. Or as I said on another list - "Sometimes the data makes a lot more sense if you ask yourself 'What if the Three Stooges were hackers?'". And there's no indication that the bell curve of black hat clue levels has shifted any since last century.
Sent from my iPad On Sep 3, 2010, at 11:19 PM, "Dobbins, Roland" <rdobbins@arbor.net> wrote:
On Sep 3, 2010, at 7:58 PM, Owen DeLong wrote:
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.
Care to elaborate? I'm betting you could find a handful of hosts on my network that are published in DNS (in which case you either already had their names, so, not sure what the scan does for you). I bet you would not easily find the rest. The prefix is 2620:0:930::/48. Have fun, you have my permission to sweep the address space twice. If we are still alive when you think you found everything, or, enough to have learned something from scanning that is meaningful and couldn't have been learned without scanning, send me your information and I'll let you know how well you did. Owen
----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>
Sell your computer and buy a guitar.
On Fri, Sep 3, 2010 at 9:49 AM, Dobbins, Roland <rdobbins@arbor.net> wrote:
On Sep 3, 2010, at 7:58 PM, Owen DeLong wrote:
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. 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.) 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 discovered. 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. 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 accounts. Bill Bogstad
On 9/3/10 11:25 AM, Bill Bogstad wrote:
On Fri, Sep 3, 2010 at 9:49 AM, Dobbins, Roland <rdobbins@arbor.net> wrote:
On Sep 3, 2010, at 7:58 PM, Owen DeLong wrote:
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 number hosts. 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 that net? 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 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. 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.
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.)
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 discovered.
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.
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 accounts.
Bill Bogstad
Sent from my iPad On Sep 4, 2010, at 4:12 AM, Joel Jaeggli <joelja@bogus.com> wrote:
On 9/3/10 11:25 AM, Bill Bogstad wrote:
On Fri, Sep 3, 2010 at 9:49 AM, Dobbins, Roland <rdobbins@arbor.net> wrote:
On Sep 3, 2010, at 7:58 PM, Owen DeLong wrote:
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.
I do...
what are the most likely ipv6 numbering schemes you're likely to use to number hosts.
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 that net?
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 discovered.
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 accounts.
Bill Bogstad
I think that's much more likely. Owen
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.
Since I mentioned a thread about technology prognostication... Right now 1000 pps per host seems like a number that is on the high end of what could go reasonably unnoticed by a comprised bot-machine. I'm sure if we roll back our clocks to IPv4's origination we'd have never imagined 1000pps scans. If history is any judge, the technology will grow faster and farther than we can see from here. Designers will put stupid kludges in their code [because the space is so vast] like picking Fibonacci numbers as "unique" inside of large sections of space -- who knows. The point is that while every smart person thinks this is a lot of space for current attack technology, in some period of time, it may not seem to difficult and safe to hide in. Moreover, when every enterprise has a /48 or better, network admins are going to need to be able to track down machines/devices/ear pieces/what have you on a better basis then trapping them when they speak up. There is a huge potential for sleepers in IPv6 space that we don't see any more in IPv4 (because the tools are better). Eventually someone will find an approach to do this kind of surveying and then make it cheap enough everyone can do it. (how often do security-admins use NMAP/Nessus/what have you to survey their own space -- an IPv6 analog will *need* to be created eventually). Just my thoughts, Deepak
In a message written on Fri, Sep 03, 2010 at 04:33:23PM -0400, Deepak Jain wrote:
Moreover, when every enterprise has a /48 or better, network admins are going to need to be able to track down machines/devices/ear pieces/what have you on a better basis then trapping them when they speak up. There is a huge potential for sleepers in IPv6 space that we don't see any more in IPv4 (because the tools are better). Eventually someone will find an approach to do this kind of surveying and then make it cheap enough everyone can do it. (how often do security-admins use NMAP/Nessus/what have you to survey their own space -- an IPv6 analog will *need* to be created eventually).
If you are the network admin, walking the L2 devices MAC tables and comparing with the L3 devices ARP/ND/whatever tables is likely more efficient for sparse address space. Also keep in mind, IPv6 devices will often have multiple addresses, and may move addresses quite regularly. For instance, I use "privacy" or "temporary" addresses, my machine hops to a new IPv6 address every 10 minutes. A scan will likely be out of date before it completes for these sorts of addresses. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
I was not attempting to defend security through obscurity. It doesn't ultimately help at all. However, compared to the network and other resource costs of scanning, even at more than a billion pps, I think there will be more effective vectors of attack that are more likely to be used in IPv6. In IPv4, an exhaustive scan is quite feasible. In IPv6, scanning a single subnet is 4 billion times harder than scanning the entire IPv4 Internet. My point isn't that hiding hosts in arbitrarily large address space makes them safe. My point is that scanning is not the vector by which they are most likely to get discovered. Owen Sent from my iPad On Sep 4, 2010, at 6:03 AM, Deepak Jain <deepak@ai.net> wrote:
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.
Since I mentioned a thread about technology prognostication...
Right now 1000 pps per host seems like a number that is on the high end of what could go reasonably unnoticed by a comprised bot-machine. I'm sure if we roll back our clocks to IPv4's origination we'd have never imagined 1000pps scans.
If history is any judge, the technology will grow faster and farther than we can see from here. Designers will put stupid kludges in their code [because the space is so vast] like picking Fibonacci numbers as "unique" inside of large sections of space -- who knows.
The point is that while every smart person thinks this is a lot of space for current attack technology, in some period of time, it may not seem to difficult and safe to hide in.
Moreover, when every enterprise has a /48 or better, network admins are going to need to be able to track down machines/devices/ear pieces/what have you on a better basis then trapping them when they speak up. There is a huge potential for sleepers in IPv6 space that we don't see any more in IPv4 (because the tools are better). Eventually someone will find an approach to do this kind of surveying and then make it cheap enough everyone can do it. (how often do security-admins use NMAP/Nessus/what have you to survey their own space -- an IPv6 analog will *need* to be created eventually).
Just my thoughts,
Deepak
On 9/3/2010 17:12, Owen DeLong wrote:
I was not attempting to defend security through obscurity. It doesn't ultimately help at all.
However, compared to the network and other resource costs of scanning, even at more than a billion pps, I think there will be more effective vectors of attack that are more likely to be used in IPv6. In IPv4, an exhaustive scan is quite feasible. In IPv6, scanning a single subnet is 4 billion times harder than scanning the entire IPv4 Internet.
My point isn't that hiding hosts in arbitrarily large address space makes them safe. My point is that scanning is not the vector by which they are most likely to get discovered.
Even so, it won't stop the uninitiated from scanning the crap out of IPv6 space. ~Seth
On Sep 4, 2010, at 7:12 AM, Owen DeLong wrote:
My point is that scanning is not the vector by which they are most likely to get discovered.
I do agree with this, definitely, with regards to blind scanning. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Sell your computer and buy a guitar.
Hi,
Since recently we noticed "Neighbour table overflow" warnings from the kernel on a lot of Linux machines. As this was very annoying for us and our customers I started to dump traffic and tried to find the cause. sounds for me as an typicall IPv6 DoS attack. (see RFC3756)
Sheng Jiang has discussed this issue in his draft: http://tools.ietf.org/html/draft-jiang-v6ops-nc-protection-01 regards, -F
On Sep 3, 2010, at 6:43 PM, Matthias Flittner wrote:
sounds for me as an typicall IPv6 DoS attack. (see RFC3756)
GMTA. Suggest checking to see if the targets have in fact been compromised (perhaps co-opted as botnet C&Cs, malware drop sites, et. al.?), and are being targeted by a rival gang. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Sell your computer and buy a guitar.
Sheng Jiang has discussed this issue in his draft: http://tools.ietf.org/html/draft-jiang-v6ops-nc-protection-01
If I understand the RFC correctly it is based on an attack within the same subnet. Looks a lot like arp-flooding. However this scan was from a external host. The only traffic I saw on the subnet was normal/valid NA lookups from the router towards an increasing IPv6-address (starting with ::1, then ::2 etc). On the router side I clearly saw the icmp traffic from the source doing a scan on these destination hosts. None of these IPv6 addresses are alive so no succes in scanning for comprised machines. regards, Igor
On Sep 3, 2010, at 7:02 PM, Igor Ybema wrote:
The only traffic I saw on the subnet was normal/valid NA lookups from the router towards an increasing IPv6-address (starting with ::1, then ::2 etc).
This could be a deliberately-induced DDoS due to the annoying ND stuff in IPv6, or just an ICMP sweep. Did it seem to concentrate on certain ranges, were the target addresses progressive, et. al.? ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Sell your computer and buy a guitar.
However this scan was from a external host. The only traffic I saw on the subnet was normal/valid NA lookups from the router towards an increasing IPv6-address (starting with ::1, then ::2 etc). On the router side I clearly saw the icmp traffic from the source doing a scan on these destination hosts. typically this fill the NC with faked entries and exhaust the node's cache resources. "This interrupts the normal functions of the targeted IPv6 node."
In other words: The attacker sends a lot of ICMPv6 echo requests to your /64 subnet. Your router has to resolve this addresses internaly (each NA is stored in NC of the router). The node's cace resources are exhausted and no "normal" NA could be stored. I think that was your problem. Unfortunately is there no standardized way to mitigate this attacks, yet. However there are many approaches which could help or could be discussed. (like http://www.freepatentsonline.com/20070130427.pdf or other) best regards, -F
On 9/3/10 7:43 AM, Matthias Flittner wrote:
Since recently we noticed "Neighbour table overflow" warnings from the kernel on a lot of Linux machines. As this was very annoying for us and our customers I started to dump traffic and tried to find the cause. sounds for me as an typicall IPv6 DoS attack. (see RFC3756)
Sheng Jiang has discussed this issue in his draft: http://tools.ietf.org/html/draft-jiang-v6ops-nc-protection-01
That's what happens when you rip all the security assumptions and requirements out of neighbor discovery! The original design wasn't subject to any of these problems, because: (1) Every request was assumed to be authenticated. Every system was assumed to have a public/private key pair, or a unique secret burned-in at manufacture, paired with its MAC address. A thing you have and a thing you know. [There were supposed exceptions for light bulbs, but good security practices dictate that light bulbs aren't globally accessible. Nowadays, I wouldn't agree to a light bulb exception, as even the puniest system on a chip has plenty of room to store a key pair, and far more processing power than we were using in the old pizza box sized cell phones!] (2) Every router wouldn't send anything from upstream until the downstream had registered its local address and been assigned one or more global dynamic addresses. Back in the day, we'd already seen subnets bigger than the 30 allowed by thinnet, we actually discussed the ARP pollution problem, and we designed to eliminate it. And by "we", I don't include the folks that mangled present-day neighbor discovery. I used to have a recording of one of them made at Xerox PARC claiming the existing ethernet process was good enough, we didn't need that extra stuff for security, mobility, unidirectional satellite links, hidden (radio) terminals, etc. On 9/3/10 9:07 AM, Matthias Flittner wrote:
typically this fill the NC with faked entries and exhaust the node's cache resources. "This interrupts the normal functions of the targeted IPv6 node."
In other words: The attacker sends a lot of ICMPv6 echo requests to your /64 subnet. Your router has to resolve this addresses internaly (each NA is stored in NC of the router). The node's cace resources are exhausted and no "normal" NA could be stored. I think that was your problem.
Unfortunately is there no standardized way to mitigate this attacks, yet.
However there are many approaches which could help or could be discussed. (like http://www.freepatentsonline.com/20070130427.pdf or other)
That caused me to burst out laughing! Wow, all it takes is another 15 years, and more folk just rediscover lessons learned in the first 15 years.... Now, they "patent" it. Kinda fails the "skilled in the art" test.
Inline... On Sep 4, 2010, at 15:24, William Allen Simpson <william.allen.simpson@gmail.com> wrote:
On 9/3/10 7:43 AM, Matthias Flittner wrote:
Since recently we noticed "Neighbour table overflow" warnings from the kernel on a lot of Linux machines. As this was very annoying for us and our customers I started to dump traffic and tried to find the cause. sounds for me as an typicall IPv6 DoS attack. (see RFC3756)
Sheng Jiang has discussed this issue in his draft: http://tools.ietf.org/html/draft-jiang-v6ops-nc-protection-01
That's what happens when you rip all the security assumptions and requirements out of neighbor discovery! The original design wasn't subject to any of these problems, because:
(1) Every request was assumed to be authenticated. Every system was assumed to have a public/private key pair, or a unique secret burned-in at manufacture, paired with its MAC address. A thing youdoubt hhave and a thing you know.
What we get instead is much like what happens in ipv4 (a flood of arp traffic). There are Implementation specific techniques that can be used to mitigate the cost of that traffic both to the router and the local net.
[There were supposed exceptions for light bulbs, but good security practices dictate that light bulbs aren't globally accessible. Nowadays, I wouldn't agree to a light bulb exception, as even the puniest system on a chip has plenty of room to store a key pair, and far more processing power than we were using in the old pizza box sized cell phones!]
Ask on 6lowpan about that, I doubt that they would agree.
(2) Every router wouldn't send anything from upstream until the downstream had registered its local address and been assigned one or more global dynamic addresses.
Back in the day, we'd already seen subnets bigger than the 30 allowed by thinnet, we actually discussed the ARP pollution problem, and we designed to eliminate it.
Right, and when you in v4 have a couple wireless nets that's are /20s the background load can be considerable across all of them and you need to mitigate accordingly.
And by "we", I don't include the folks that mangled present-day neighbor discovery. I used to have a recording of one of them made at Xerox PARC claiming the existing ethernet process was good enough, we didn't need that extra stuff for security, mobility, unidirectional satellite links, hidden (radio) terminals, etc.
On 9/3/10 9:07 AM, Matthias Flittner wrote:
typically this fill the NC with faked entries and exhaust the node's cache resources. "This interrupts the normal functions of the targeted IPv6 node."
In other words: The attacker sends a lot of ICMPv6 echo requests to your /64 subnet. Your router has to resolve this addresses internaly (each NA is stored in NC of the router). The node's cace resources are exhausted and no "normal" NA could be stored. I think that was your problem.
Unfortunately is there no standardized way to mitigate this attacks, yet.
However there are many approaches which could help or could be discussed. (like http://www.freepatentsonline.com/20070130427.pdf or other)
That caused me to burst out laughing!
Wow, all it takes is another 15 years, and more folk just rediscover lessons learned in the first 15 years....
Now, they "patent" it. Kinda fails the "skilled in the art" test.
participants (15)
-
Bill Bogstad -
Deepak Jain -
Dobbins, Roland -
Igor Ybema -
Jack Bates -
Jamie Bowden -
Joe Greco -
Joel Jaeggli -
Leo Bicknell -
Matthias Flittner -
Owen DeLong -
Seth Mattinen -
Steven Bellovin -
Valdis.Kletnieks＠vt.edu -
William Allen Simpson