We run a distributed network of PoPs in the cloud and get easily many times this, as well as massive ssh brute force attempts and other more bizarre forms of scan/attack. I sometimes look up the IPs and check them out and they are ancient cameras, routers, and things like Windows 2000 Server instances sitting on the Internet running malware.
Can you share what is the methodology you are using for determining the source IP is an IoT device? Are you just nmap'ing them and using OS/TCP finger printing?
I had the same question for how OVH was determining that X amount were IPs cameras vs X amount were DVRs etc.
A lot of people including numerous EU regulators would think that posting such a list of IPs is very tacky. At Google I would be reprimanded and probably fired just for producing a list like this, or even writing a tool that was capable of producing a list of non-anonymized IPs of clients.
Now that I got that out of my system: where's all the v6 traffic?
As system administrator of my home network, it worries me that a device on my network might be involved in an attack like this, and I would never know.
Maybe the target of such an attack could gather a list of IP addresses used in the attack, then pass them to Google, who might warn on their search homepage if you browse from one of the IPs on the list? (e.g. "Some of your internet devices may be at risk, click here to find out more") I know IP addresses are a poor proxy for identity, but it could be a step in the right direction.
Google already has a similar mechanism in place where they require captchas from IP addresses that abused Google APIs previously.
The combination of that with Google Shield might actually work to inform the users, but then again users are confronted with similar warnings from abusive ad networks all the time, and probably learned to click them away fast and forget about it.
Simply set up your firewall to drop outgoing packets with source address not belonging to your subnet.
The DDOS slaves are usually sending packets with spoofed source ip addresses
Ironically enough, this is a place where I think that remotely managed routers (like the OnHub) might be a fantastic solution for the average Joe. Dynamically identify problematic traffic patterns, and block them at the home router.
It would be an 80% solution at best, and I wouldn't want one; but I trust Google more than I do my mom when it comes to managing the packets coming out of her network.
In all seriousness, this is only going to become worse in the future. Can't wait until the day when smart fridges, toasters and bicycle locks join in on a multi-Tbps attack and break the entire internet.
Internet providers will curb it by reverse-firewalling all consumer connections, maybe with support from the copyright abuse lobby, so as to kill P2P and any other advanced internet usage for that matter.
I wonder if at some point a government or two will just decide that the dubious benefit of a wired fridge isn't worth the national security risk of increasing existing botnets by an order of magnitude?
It's unfortunately way too easy to find such devices. A quick scan of the (less scary) end of the ipv4 address space and I was able to find ~15k cameras and I was only searching for a couple of models for fun... Here was the result: http://opencam.ma.rtin.so/ -- most of the pins probably wont work anymore, as it's a couple of years old.. Still crazy.
Jesus I was just thinking about the consequences of no patch routine in the IoT device world. And, here it is. :)
Imagine having to internationally co-ordinate patching of 150000 devices. Because the alternative is that 150000 homes will have their NATed IP-addresses blocked from each service being attacked.
That would mean blocking the ISP, and every ISP, so it's the end of blocking because there won't be any legitimate traffic left.
The manufacturers must be both sued for selling exploitable devices and educated about how to write secure software.
There is another post on the home page of HN about the security of the Linux kernel https://news.ycombinator.com/item?id=12589894 That's very important for this kind of issues because many of those devices are probably running on some Linux distribution.
you dont have to coordinate any patching, just null route end users who are the source of DOS and let them deal with it. Its them who opted for $25 with free shippintg 720p 'Cloud based, works with your iphone' nanny cam.
And now let's apply such a scenario to autonomous vehicles, on land and in air.
but rather than causing a virtual DDOS, now in physical space. shutting down a whole city, for the lulz.
IoT and AV show that the "Facebook" method of software development - move fast, break things, agile/scrum, whatever label is used for non-engineering, will not work for the next stage.
ditto the skills of most young CS grads. most companies can't even secure their shitty email services - but cars is easier?
a whole new supply chain for code needs to be developed, from languages to curriculums. take what the airline industry has been doing and commoditize it, it must be braindead easy to build a secure and robust piece of code for this new world.
I remember when the ntp exploit came out few years ago datacenter where we have a rack contacted me saying the Supermicro IPMI devices on the Supermicro servers were participating in an amplification attack.
I was like wtf! Matter was quickly resolved of course, also they learned a lesson and moved ipmi ips to 10mbit limited connnections not 1gbit.
Tho ideally a local ip that accessible only via a vpn would have been the best option for remote management but yeh, little steps I suppose with some providers.
I think the reason we have such bad security is that non-technical end users just don't care. You can try a dozen different approaches to getting them to care about security, but they often cannot be bothered with it.
Thus, if you want to go the legal/penalty route, you need to sue the end users. The entity that owns the house/office that installed the unpatched CCTV camera is effectively responsible for the behavior of that camera. If they then want to shift the responsibility to the manufacturer, that's their choice (and effort).
What it will do is make users consider a bit more carefully when choosing devices and manufacturers, and it will make manufacturers have to consider (and promote) their security and patching practices to maintain marketshare.
It should be easier managing devices that have access to the Internet on the router level.
Most can't understand access restrictions, IP Tables or installing custom firmware. There needs to be a common standard, API on each router to manage devices connecting to the Internet and seeing which devices do and don't.
This would open the doors to creating apps etc and possibly help mitigate threats from unknown Chinese IoT devices.
I manage a huge fleet of raspberry pi in my jobs. There are geographically everywhere.
I wish that there will not be found by some bad guy, but I know our system and I'm 100% sure that will happen one day. We have a basic level security, like so many other startup in that field though.
Feels like how things might have been when home electricity was first becoming pervasive.
Lots of dubious devices and a laisez-faire approach to eg. electrocution risks and fire hazards.
After enough public outcry regulation is introduced, standards are developed and enforced and your television is no longer at risk of bursting into flames or frying the cat.
Or, in today's world, of being conscripted into a global botnet and DDOS'ing your neighbours.
This isn't bad enough, not yet, for some kind of protocol that allows source quench / notify a remote ISP of a suspected infected host and suppress traffic from said host.
It would need to be out of band, and I suggest it use OpenPGP for signatures (chain of trust from IP allocating bodies), actually it would also need to query a database of allocated IP ranges.
the problem is more complicated than you make it out to be. DDoS aren't always some special kind of packet or traffic that is easy to identify, it is just a flood of normal looking traffic from a ton of compromised sources
Most IoT devices wouldn't produce any significant revenues from Bitcoin Mining because they don't have anywhere near the computational power of dedicated Bitcoin mining devices.
A DVR might have a chance to make an impact if it had a GPU that was used to encode video that could be co-opted to mine Bitcoin, but I think most DVR's use special video encoding chips rather than a general purpose GPU.
I think the only hardware they would have that could mine Bitcoin would be their general purpose CPU, which is probably under-powered anyway.
A DVR would be more easily monitized as a node in a Botnet that does DDoS attacks, email spamming, or network scanning.
One resource they do have though is drive space. a DVR botnet could sell unused DVR HD space using a service like Maidsafe [1]
[+] [-] justinsaccount|9 years ago|reply
We see upwards of 2 million unique ipv4 sources scan us on port 23 every day. These are all compromised IoT devices and routers.
In the past hour we saw 350k+ unique sources.
In just the past 3 minutes that number is 168,230
Top sources in the past 3 minutes:
We see 2000pps of this shit all day every day. No one cares.[+] [-] khc|9 years ago|reply
[+] [-] pritambarhate|9 years ago|reply
>We see upwards of 2 million unique ipv4 sources scan us on port 23 every day. These are all compromised IoT devices and routers.
What is the unique connection between port 23 and IoT devices? Genuinely Curious.
Thanks.
[+] [-] api|9 years ago|reply
[+] [-] bogomipz|9 years ago|reply
I had the same question for how OVH was determining that X amount were IPs cameras vs X amount were DVRs etc.
[+] [-] VikingCoder|9 years ago|reply
127.0.0.1
I keep counter-attacking him, but he's always one step ahead of me!
[+] [-] honkhonkpants|9 years ago|reply
Now that I got that out of my system: where's all the v6 traffic?
[+] [-] nacnud|9 years ago|reply
Maybe the target of such an attack could gather a list of IP addresses used in the attack, then pass them to Google, who might warn on their search homepage if you browse from one of the IPs on the list? (e.g. "Some of your internet devices may be at risk, click here to find out more") I know IP addresses are a poor proxy for identity, but it could be a step in the right direction.
[+] [-] ge0rg|9 years ago|reply
The combination of that with Google Shield might actually work to inform the users, but then again users are confronted with similar warnings from abusive ad networks all the time, and probably learned to click them away fast and forget about it.
[+] [-] vadiml|9 years ago|reply
[+] [-] fulafel|9 years ago|reply
Anyone know of a good open source solution that doesn't require a huge amount of fiddling?
[+] [-] falcolas|9 years ago|reply
It would be an 80% solution at best, and I wouldn't want one; but I trust Google more than I do my mom when it comes to managing the packets coming out of her network.
[+] [-] fivesigma|9 years ago|reply
In all seriousness, this is only going to become worse in the future. Can't wait until the day when smart fridges, toasters and bicycle locks join in on a multi-Tbps attack and break the entire internet.
[+] [-] praptak|9 years ago|reply
[+] [-] FilterSweep|9 years ago|reply
Because connecting your toaster and fridge over a local network, and running updates via your PC/laptop would be just too complex
[+] [-] M_Grey|9 years ago|reply
[+] [-] luhn|9 years ago|reply
[+] [-] martin_|9 years ago|reply
[+] [-] DanBC|9 years ago|reply
EDIT: I'm going to be spending hours on this today!
[+] [-] INTPenis|9 years ago|reply
Imagine having to internationally co-ordinate patching of 150000 devices. Because the alternative is that 150000 homes will have their NATed IP-addresses blocked from each service being attacked.
Just wow...
[+] [-] pmontra|9 years ago|reply
The manufacturers must be both sued for selling exploitable devices and educated about how to write secure software.
There is another post on the home page of HN about the security of the Linux kernel https://news.ycombinator.com/item?id=12589894 That's very important for this kind of issues because many of those devices are probably running on some Linux distribution.
[+] [-] rasz_pl|9 years ago|reply
[+] [-] dharma1|9 years ago|reply
Getting manufacturers to patch, and users to update these embedded linux devices is going to be pretty hard
[+] [-] petre|9 years ago|reply
[+] [-] pinaceae|9 years ago|reply
but rather than causing a virtual DDOS, now in physical space. shutting down a whole city, for the lulz.
IoT and AV show that the "Facebook" method of software development - move fast, break things, agile/scrum, whatever label is used for non-engineering, will not work for the next stage.
ditto the skills of most young CS grads. most companies can't even secure their shitty email services - but cars is easier?
a whole new supply chain for code needs to be developed, from languages to curriculums. take what the airline industry has been doing and commoditize it, it must be braindead easy to build a secure and robust piece of code for this new world.
[+] [-] throwaway1974|9 years ago|reply
I was like wtf! Matter was quickly resolved of course, also they learned a lesson and moved ipmi ips to 10mbit limited connnections not 1gbit.
Tho ideally a local ip that accessible only via a vpn would have been the best option for remote management but yeh, little steps I suppose with some providers.
[+] [-] vadiml|9 years ago|reply
[+] [-] Retr0spectrum|9 years ago|reply
[+] [-] pixl97|9 years ago|reply
If I am 8.8.8.8 and I fake 8.8.4.4, you still get my traffic, and someone else gets the complaint.
[+] [-] thesehands|9 years ago|reply
[+] [-] jimjimjim|9 years ago|reply
[+] [-] blunte|9 years ago|reply
Thus, if you want to go the legal/penalty route, you need to sue the end users. The entity that owns the house/office that installed the unpatched CCTV camera is effectively responsible for the behavior of that camera. If they then want to shift the responsibility to the manufacturer, that's their choice (and effort).
What it will do is make users consider a bit more carefully when choosing devices and manufacturers, and it will make manufacturers have to consider (and promote) their security and patching practices to maintain marketshare.
[+] [-] wiredfool|9 years ago|reply
[+] [-] zcam|9 years ago|reply
[+] [-] ge0rg|9 years ago|reply
[+] [-] dax1928|9 years ago|reply
[+] [-] CommanderData|9 years ago|reply
Most can't understand access restrictions, IP Tables or installing custom firmware. There needs to be a common standard, API on each router to manage devices connecting to the Internet and seeing which devices do and don't.
This would open the doors to creating apps etc and possibly help mitigate threats from unknown Chinese IoT devices.
[+] [-] dehef|9 years ago|reply
I wish that there will not be found by some bad guy, but I know our system and I'm 100% sure that will happen one day. We have a basic level security, like so many other startup in that field though.
[+] [-] ffggvv|9 years ago|reply
[+] [-] jessaustin|9 years ago|reply
[+] [-] erpellan|9 years ago|reply
Lots of dubious devices and a laisez-faire approach to eg. electrocution risks and fire hazards.
After enough public outcry regulation is introduced, standards are developed and enforced and your television is no longer at risk of bursting into flames or frying the cat.
Or, in today's world, of being conscripted into a global botnet and DDOS'ing your neighbours.
[+] [-] mjevans|9 years ago|reply
It would need to be out of band, and I suggest it use OpenPGP for signatures (chain of trust from IP allocating bodies), actually it would also need to query a database of allocated IP ranges.
[+] [-] api|9 years ago|reply
Something needs to be done about DDOS at the backbone and tier-1 level of the Internet or we are going to lose the public Internet.
[+] [-] solotronics|9 years ago|reply
[+] [-] SG-|9 years ago|reply
[+] [-] gravypod|9 years ago|reply
[+] [-] deftnerd|9 years ago|reply
A DVR might have a chance to make an impact if it had a GPU that was used to encode video that could be co-opted to mine Bitcoin, but I think most DVR's use special video encoding chips rather than a general purpose GPU.
I think the only hardware they would have that could mine Bitcoin would be their general purpose CPU, which is probably under-powered anyway.
A DVR would be more easily monitized as a node in a Botnet that does DDoS attacks, email spamming, or network scanning.
One resource they do have though is drive space. a DVR botnet could sell unused DVR HD space using a service like Maidsafe [1]
[1] https://maidsafe.net
[+] [-] zodPod|9 years ago|reply