Who Should We Blame For Friday's DDOS Attack? (fortune.com) 190
"Wondering which IoT device types are part of the Mirai botnet causing trouble today? Brian Krebs has the list," tweeted Trend Micro's Eric Skinner Friday, sharing an early October link which identifies Panasonic, Samsung and Xerox printers, and lesser known makers of routers and cameras. An anonymous reader quotes Fortune:
Part of the responsibility should also lie with lawmakers and regulators, who have failed to create a safety system to account for the Internet-of-Things era we are now living in. Finally, it's time for consumers to acknowledge they have a role in the attack too. By failing to secure the internet-connected devices, they are endangering not just themselves but the rest of the Internet as well.
If you're worried, Motherboard is pointing people to an online scanning tool from BullGuard (a U.K. anti-virus firm) which checks whether devices on your home network are listed in the Shodan search engine for unsecured IoT devices. But earlier this month, Brian Krebs pointed out the situation is exacerbated by the failure of many ISPs to implement the BCP38 security standard to filter spoofed traffic, "allowing systems on their networks to be leveraged in large-scale DDoS attacks..."
If you're worried, Motherboard is pointing people to an online scanning tool from BullGuard (a U.K. anti-virus firm) which checks whether devices on your home network are listed in the Shodan search engine for unsecured IoT devices. But earlier this month, Brian Krebs pointed out the situation is exacerbated by the failure of many ISPs to implement the BCP38 security standard to filter spoofed traffic, "allowing systems on their networks to be leveraged in large-scale DDoS attacks..."
Who should we blame? (Score:5, Insightful)
The people that did it.
Re:Who should we blame? (Score:5, Funny)
Nah, too much effort figuring out who did it. Just blame Russia. Works for everyone else lately.
Re: (Score:2)
Or, if you are a shill for Russia, deflect blame once Russia has been identified.
Re: (Score:1)
What? This is 2016...we should be blaming everyone BUT who did it!
Re:Who should we blame? (Score:5, Insightful)
Also the people who didn't change the default passwords. Looking at the list, most of the devices are not particularly insecure or anything, it's just that their owners did not change the default login credentials but did manage to expose them to the internet.
Also blame the engineers who didn't put in some interlocks, e.g. no requests from outside the LAN until the default password has been changed or simply force the user to change the password the first time they log in.
Re: (Score:2)
Re: (Score:2)
Forgot the password to the device?? Tough shit; back to a factory reset you go!
I'm not sure that anybody who leaves his/her router on default credentials, would have the acumen to change anything else from factory defaults.
Re: (Score:2)
Which is why the default password should be randomly(*) set and uPNP disabled by default.
(*) Not according to some algorithm predictable from the MAC, etc.
Re: (Score:3)
Also blame the engineers who didn't put in some interlocks, e.g. no requests from outside the LAN until the default password has been changed or simply force the user to change the password the first time they log in.
That's the problem. Not end users not changing default passwords - many may not even know that it can or should be changed, and why should they? They're not security managers or IT engineers or so. Having users change the password on first login before they can do anything else, that's the only reasonable way to go. Maybe also add a list of the 1,000 most common passwords out there, and reject all those, make them come up with something a bit more unique, or hackers would still easily get access to the firs
Re: (Score:2)
"Having users change the password on first login before they can do anything else, that's the only reasonable way to go"
Which mostly means that the password will be "password" or something similar.
Better to leave it as some complex random password unless changed.
Even better, have an interlock which requires positive action to allow external access AND a requirement to ACK warning of the consequences if not properly secured (not just a OK, but scroll to the bottom first and warning that failure to read/under
Re: (Score:2)
warning that failure to read/understand properly before clicking OK may result in personal legal liabilities)
Which, considering I'm one of the 95% of the world's population that doesn't live in the country all such warnings are written (i.e. the USA), has no meaning to me. Then there are the many, many people that don't understand English well enough or don't understand computing well enough to even stand a chance of understanding such long, long pieces of legalese.
Re: (Score:3)
The problem with some of these devices is that they also have a hardcoded root password. I have one like that - I kept it behind its own router since I didn't trust it, but took it offline a couple of months ago when I learned that it has a hardcoded root and no new firmware. I had changed the admin password of course, but that really didn't do anything.
I'm no longer going to allow an open port for any device like this, but most people won't know how to set up a vpn for home.
Re: (Score:2)
try opening up Netstat or similar on a private network. None of the internet connections list the router's IP as the endpoint.
Re: (Score:2)
Also blame the engineers who didn't put in some interlocks, e.g. no requests from outside the LAN until the default password has been changed or simply force the user to change the password the first time they log in.
Can you do that? How can a device know a request comes from outside the lan? If I'm not mistaken, unless you use IPv6, in order for an outside request to reach a device on the LAN, you need to NAT it, and then, from the point of view of the device, the request comes from the router, from a local ip.
uPnP comes to the rescue and allows your camera to open a path in from the outside. Yay uPnP!
Disable uPnP in your router.
Re: (Score:2)
A lot of this stuff is consumer electronics, so there isn't any "tech support", just little Jimmy from down the block, who's the only one who ever bothered to read the instructions at all.
And a frighteningly large amount of these devices "phone home" to some master server on the Internet, so they're not exactly cut off from the world.
Re:Who should we blame? (Score:5, Insightful)
Regardless of who is behind it, it's about time that we treat DDoS as the censorship that it is. I'm sick of hacktivists trying to justify bringing down major websites just because they don't like whoever runs it, while at the same time talking about how they are pro democracy and pro free speech. DDoS is the opposite of both, no matter who the target is. People who justify it because they don't like Walmart or whoever are fucking hypocritical assholes.
Re: (Score:2)
Sounds like you want to ban real life protests as well. As all, what is a protest if not a DDoS on a particular location? The whole point is to block and area / road and make lots of noise so people can't ignore you.
Of course, most DDoS attacks are not protests, but you have to draw the line somewhere. Is manually submitting hundreds of bogus web forms censorship? What about sending thousands of letters to a TV company because a show was cancelled? That might make it hard for them to respond to other mail t
Re: (Score:2)
Another point is DDOS attacks are conducted by bot nets of zombified computers, most of us /.ers take a considerable amount of pride in having our infernal machines do our bidding and only our bidding. Having one of my machines commandeered for a DDoS attack would be rankling for me and most here; I don't mind you making a statement with your resources, but trying to use mine to make your statement is just going to piss me off.
If this leads to some senile Grandma pissing her panties in the White House decid
Re: (Score:2)
Re: (Score:2)
The possibility exits that this is a test of capability/public demonstration. "You saw what we did to him, now either pay up/write what we tell you, or your site will go down and stay down." Too Tom Clancy-ish?
I dunno. Can we have some people leaping through doors ahead of flaming explosions?
Re: (Score:1, Redundant)
"The people that did it." First of all you would use the pronoun "who": The people who did it.
But, who *did* "do* *it*?
What is the it that was done, and by whom?
Was it someone who created the botnet? Was it someone who controlled the botnet and directed it to attack a specific target?
Was it the manufacturers of devices who used crappy chips in their products which were vulnerable?
Was it the manufacturer(s) of the chip themselves for even making such product(s)?
Was it our government for failing to regulate
Re: (Score:1)
Re: (Score:2)
I call "Bullshit!" The devices have no access for non corporate interests to investigate. "It's a closed system," "it's a corporate secret." and all the other excuses that led to Fridays event. Volkswagon, not IoT devices; it's time to recognize their falsehoods.
Re: The worst? (Score:4, Insightful)
It struck me that there is a "nuclear option" solution that would be highly illegal but highly effective. Every time one of these shitty IOT devices is found exploitable and the manufacturer doesn't bother to update , scan the whole damn net for that device and tell it to DDOS the manufacturer and not stop. The manufacturer would pretty quickly realise they have to get a patch out if they wish to remain a citizen of the internet. For added niceness make sure the user understands why their baby monitor is attempting to murder it's creator
Re: (Score:2)
Might be better to just patch the damn thing if you have access to it, or at the very least change the settings so that it can't be hacked by anyone else.
I seem to recall an ISP doing this some years back. They realized that the shitty Netgear mode/routers they had bought all had insecure wifi passwords. The password was a hash of the wifi MAC address, the thing that gets broadcast constantly in the clear. Anyway, they sent out updates to all devices to reset the wifi password to something really random and
Re: (Score:2)
A lot of this stuff is running pirated/old firmware which has nothing to do with the original author.
A lot of the time the company in the exporting country selling this stuff to the importer has no idea what the firmware is, isn't the manufacturer and may be several steps removed from the manufacturer (which is why firmware is such a bitch to deal with)
Liabilities have a hard time crossing national boundaries. The buck stops at the importer.
From a consumer point of view, liability stops with whoever sold it
Re: (Score:2)
> but they just sold what the customers wanted, secure in the legal protection of "You can't sue us no matter how much harm our devices cause.
This kind of disclaimer won't hold water in the EU - Consumer protection laws and the laws against unfair terms in contracts see to that.
For full liability indemnity the enduser would have to explicitly sign it away and clicking OK on a shrinkwrap license is not sufficient.
Re: (Score:2)
I hope you're right, but I doubt it. If they can't attack your legal system directly, then they'll try a flank attack via transnational trade treaties. In the particular example of this article, they have extra leverage because the Internet itself is so international.
How do you secure the unsecurable? (Score:1)
Re: (Score:2, Interesting)
I think the best way to handle this is to make people somehow accountable when they participate in a DDoS, whether they do it willingly or not. Personally I think their internet access should be throttled to dialup speed for 60 days if they are conclusively found to be participating, and that 60 days starts over each time they're found participating. It will make them think twice about buying insecure shit.
Re: How do you secure the unsecurable? (Score:2, Insightful)
Ah, the DMCA approach.
I can see it now.
Since we can't figure out how to stop ddos attacks, we create mechanism wherein our Internet equivalent of the RIAA sends ISPs notifications about who is part of a botnet.
The ISP, in turn, immediatly has to notify and throttle users who are part of the botnet. They have to do it otherwise they'll be airing and abetting internet pira...er, ddos attacks, and thus, are open to lawsuits. This creates the proper incentive to rubber stamp... I mean, streamline the process.
Th
Re: (Score:2)
The ISP, in turn, immediatly has to notify and throttle users who are part of the botnet. They have to do it otherwise they'll be airing and abetting internet pira...er, ddos attacks, and thus, are open to lawsuits. This creates the proper incentive to rubber stamp... I mean, streamline the process.
The user, of course, has a chance to contest this throttling in case that the user is not part of the botnet (IP addresses are so easy to spoof these days). So it is totally fair. All they have to do is send a counterclaim and if it is rejected (which it will), they have the option to take this to court.
Did I say a single word about identifying them by IP address, jackoff? No, so put a cock in it.
Besides, we can do more about IP address spoofing.
Re: (Score:2)
Apart from ISPs applying spoofed address filtering, enduser ROUTERS should be filtering this shit too.
Re: (Score:2)
I'm not sure I like putting all the blame on the users. Don't we have a reasonable expectation that we're not going to be sold faulty products? And I can't characterize such brain-dead non-security as anything but "broken".
Maybe we also should force companies to shoulder the cost of a product recall if their device is found to have security issues that can't be automatically patched and fixed. That would add a nice financial incentive for companies to release more secure products.
If a company continues t
Re: (Score:2)
"You are being reasonable, unfortunately, the FCC has no jurisdiction here"
The FTC does though.
Re: (Score:3, Insightful)
"I think the best way to handle this is to make people somehow accountable when they participate in a DDoS, whether they do it willingly or not."
Well, you self important prick, answer me this:
One manufacturer was quickly identified on Friday as contributing a major part of the Attack.
Name them. No, you don't get to scour the Web now, you should _know_ this.
Now, you as an enlightened Consumer goes out Monday to buy a new DVR. How can you tell if it has been compromised? At the least, you are going to have to
Re: (Score:2)
"I think the best way to handle this is to make people somehow accountable when they participate in a DDoS, whether they do it willingly or not"
Absolutely. A strict liability law and hefty fines would make most people think twice, especially after it made a few newspaper headlines.
They may have secondary rights to sue the seller(*) but at the end of the day the USER is the one who connected the device to the network.
(*) The seller has upstream rights to sue the wholesaler, importer and upwards to the maker.
Re: (Score:2)
Inform the user to change the password or to get a new device if its of a poor design that cant be fixed.
WRONG (Score:5, Insightful)
From TFA: "Dormann said instead of hard-coding credentials or setting default usernames and passwords that many users will never change, hardware makers should require users to pick a strong password when setting up the device."
This advice is just plain wrong. It requires educating every single end user on security best practices. Lately I've seen a trend from ISPs for their router admin pages and wifi access points: they come pre-configured with a randomly generated password for each, which is then printed out on a sticker and stuck to the side of the device. Without physical access to the device, nobody would know the credentials for it. This keeps the burden of security within the realm of those who know what they are doing and making good decisions. The act of using a poor password would then end up on the end user, having to type in the secured password, and then change it to something less secure.
Re: (Score:2)
not only this but the inept users whose devices get pawned and used to attack other systems should be held legally responsible for the attacks.
That'll be a million dollars, please... (Score:5, Insightful)
not only this but the inept users whose devices get pawned and used to attack other systems should be held legally responsible for the attacks.
Only up to a point. It's not really fair to expect the random non-computer guy who owns an IoT light bulb to secure it against electronic attack. The company that manufactures the bulb and decides telnet is an appropriate protocol to use to connect to it, on the other hand...
Re: (Score:3)
I agree. I was thinking about cases where for example a device when purchased is secure and then the user changes the password to "password". If they have the capacity to actually log in to a configuration page and change the password, then they should also be held accountable for weakening the devices security by choosing a bad password.
Re: (Score:2)
Depends on state law. I remember when I lived in CT 20 years ago, the Insurance Agent made a point to state that under CT Law at the time while a thief is criminally liable for any damage done to persons/property in a vehicle they stole (they get to go to jail for it), the owner of the stolen vehicle is financially liable for all damage... so, in that case, we blame both.
Re: (Score:2)
1) Build a prison cell for absolutely every American citizen.
2) Pass a law about changing passwords or otherwise securing computers.
3) Fill 'em all up.
Re: (Score:2)
LOL your point is made!
Re: (Score:3)
Lately I've seen a trend from ISPs for their router admin pages and wifi access points: they come pre-configured with a randomly generated password for each ...
This keeps the burden of security within the realm of those who know what they are doing and making good decisions
Next time you look at the device compare the randomly generated password with the mac address. I would put it to you that many of the ISP provided routers with "random passwords" were not at all designed by people who know what they are doing. :-)
Not who... but what should we blame? (Score:1)
Blame DNS. Time for something completely different [youtube.com].
Re: (Score:2)
Re:Not who... but what should we blame? (Score:5, Insightful)
Re: (Score:2)
Unless, of course, you expect the same users who won't even change default passwords to learn about and configure firewalls.
That's the wonderful thing about defaults. Every router I've seen shipped has a default password, and a stateful firewall ENABLED BY DEFAULT.
You don't need users to configure things in a secure way. There's no configuration for NAT so there's no reason to assume that by going to IPv6 the internet would be any less secure.
Re: (Score:2)
Your limited experience is not a suitable basis for drawing a valid conclusion.
Re: (Score:2)
"Every router I've seen shipped has a default password, and a stateful firewall ENABLED BY DEFAULT."
Your limited experience is not a suitable basis for drawing a valid conclusion.
Ok, let's run with that for a second. Are you suggesting ISPs will send you a wireless router without NAT enabled by default? Because NAT by necessity requires a stateful firewall to be running.
Re: (Score:2)
Re: (Score:2)
You're right. Now show me a NAT implementation that works without a stateful firewall enabled.
The two terms serve a different purpose yet you can't have NAT without effectively having the other and I stand by my original comment. Every consumer router currently being delivered does exactly the same thing as a stateful firewall out of the box ENABLED BY DEFAULT, with the minor addition of packet forwarding.
Re: (Score:2)
Re: (Score:2)
Tell me about it. Come back when you know how NAT works.
Re: (Score:2)
IPv6 doesn't mean no more firewalls - it just means no more NAT.
NAT provides some protection by its nature, but honestly, not much. Devices that use UPNP or whatever to open up external firewall ports so you can connect to them are going to be a problem with NAT or not.
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
NAT makes it a _great deal_ more difficult. There is simply no point in most modern environments to installing hardware, whatsoever, without NAT.
So... (Score:2)
However, GP's point was that NAT could make it a little more difficult to get the device hacked in the first place.
So does also any sensible router that I've seen that blocks inbound traffic by default.
(i.e.: router where you explicitely need to open Internet->PC access).
It doesn't matter if they are private IP (v4) addresses, that need NAT and port forwarding (i.e.: port 8080 from the router, should be forward to port 80 on intenal sebserver 10.0.0.x),
or plain normal public IP (generally v6) addresses, that need simply to enable access to some ports on the public intenet (request for port 80 on machine IPv6 2xxx:yyy
Re: (Score:2)
What you're describing is called a packet filter, not a router. The "security" of NAT comes as a by-product of the fact that multiple devices NEED to be on a private RFC1918-style network (assuming we're talking typical consumer-grade NAT), and hence no single device does - by default - receive inbound traffic because they're not addressable in the first place.
99.9% (Score:2)
What you're describing is called a packet filter, not a router.
For 99.9% of the "average joe 6-pack" users, the packet filter is running inside [the linux kernel on the firmware of] their home DSL/cable/FITH router.
So yeah, for most of the clueless user who would be benefiting from NAT, they will be also benefiniting from the fact that the router sitting in their living room is doing packet filtering.
The "security" of NAT comes as a by-product of the fact that multiple devices NEED to be on a private RFC1918-style network (assuming we're talking typical consumer-grade NAT), and hence no single device does - by default - receive inbound traffic because they're not addressable in the first place.
And I'm telling you :
- you DO NOT need to be on an unaddressable private address (192.x.y.z or fxxx:::) to not receive any traffic.
The [packet filtering running inside the
Re: (Score:2)
The "security" of NAT comes as a by-product of the fact that multiple devices NEED to be on a private RFC1918-style network (assuming we're talking typical consumer-grade NAT), and hence no single device does - by default - receive inbound traffic because they're not addressable in the first place.
And I'm telling you :
- you DO NOT need to be on an unaddressable private address (192.x.y.z or fxxx:::) to not receive any traffic.
No shit. Then again, how many "average joe 6-pack" users get assigned anything bigger than a /32 (i.e. a single address) for IPv4, or anything at all for IPv6?
And with only a single globally routable address, you do NEED to be on RFC1918 network.
Obviously this isn't the only way one can do NAT, but it's the only way joe sixpack's router does it.
So please stop with this "NAT increases security".
And I'm telling you, the extra security provided to joe sixpack DOES come from the fact that he's being NATted, since he's still unreachable when any other packet f
IPv6 deployment (Score:2)
And I'm telling you :
- you DO NOT need to be on an unaddressable private address (192.x.y.z or fxxx:::) to not receive any traffic.
No shit. Then again, how many "average joe 6-pack" users get assigned anything bigger than a /32 (i.e. a single address) for IPv4, or anything at all for IPv6?
Here around on our side of the pond ? :
Let me count
- Most of the ISP here around in Europe that I know of (Switzerland, France, Germany) are providing IPv6. /60 or /56 prefix, so each (IPv6-enabled) device on the home network can get its very own 64bits suffix based on the MAC-Address (and
Usually they are 6RD (rapid deployment) [wikipedia.org], i.e.: their network (fiber, xDSL, etc.) is still legacy IPv4,
but their router automatically establish a 6to4 tunnel [wikipedia.org] to the ISP's IPv6 access point,
Usually, most 6rd deployment offer
Re: (Score:2)
Here around on our side of the pond ? :
Let me count
- Most of the ISP here around in Europe that I know of (Switzerland, France, Germany) are providing IPv6.
My former German ISP provided IPv6 in an opt-in pilot project, although they were doing it wrong and changed the routing prefix twice a day, so it was useless. My current German ISP does not provide IPv6. Heck, they don't even give me PPP credentials meaning I cannot use my own gear. (Then again, it's past August now, so next time I ask them they better do...)
Regarding IPv6, I do have a point. (paraphrased)
Ok.
And with only a single globally routable address, you do NEED to be on RFC1918 network.
Obviously this isn't the only way one can do NAT, but it's the only way joe sixpack's router does it.
But with a completely different premise, I'm still right (paraphrased)
Ok.
And I'm telling you, the extra security provided to joe sixpack DOES come from the fact that he's being NATted, since he's still unreachable when any other packet filtering is disabled.
(emphasis mine)
Yup. We've reached a conclusion.
(additional emphasis mine).
I don't really see how that is a conclusion to draw from the above. You do realize I said UNreachable and DISabled
Re: (Score:2)
NAT's inbound "security" is entirely accidental and any decent IPv6 device applies the same firewalling rules for inbound IPv6 as for IPv4
Re: (Score:2)
While this is valid, a way to better secure the network would be to have a PAM setup in DHCPv6, where certain addresses change after a certain period. That way, not only would a spoofing agent have to scour a huge block - it would also have an artificially limited amount of time in which to do it. Reason I mention this is that whenever we get to a point where we determine that /64 is too much wasted area and need to reduce it to /32, we don't make the subnet more insecure by reducing the scan area by a fa
Blame the ISPs (but especially Dyn) (Score:2)
Properly configured DNS secondaries hosted at different ISPs would have completely mitigated the problem for everyone but Dyn. Because Dyn hosts its own secondaries, hitting Dyn downed both primary and secondary servers.
ISPs need a peering pool arrangement for DNS secondaries, where secondaries are distributed over the entire pool.
This is how it was designed to work: multiply connected redundant secondaries.
The worst damage possible in that scenario is the inability to update DNS information hosted at Dyn
The Usual Suspects (Score:5, Interesting)
Hacktivists (Specifically New World Hackers):
Pro - claimed responsibility. Anonymous/offshoots responsible for lots of past DDoS activity.
Cons - Several security firms called BS on the evidence, and cited past history of false claims of responsibility to boost DDoS for hire business. Also the complexity and sophistication make this unlikely.
Cybercriminals:
Pro - probable originators of Mirai botnet, likely responsible for preceding DDoSes of Brian Krebs and OVH.
Con - No stated ransom demands (at least none reported) or other identifiable material benefit. Lacks a direct reason.
North Korea:
Pro - Past history of DDoS and malware attacks. Never claims responsibility. Suffers nothing if the internet goes down.
Cons - Attack only targeted the USA, not perennial NK targets of South Korea or Japan. If this was North Korea, why ignore those two?
Russia
Pro - contacts/influence in Russian cybercrime community. Possible interest in interference in US politics.
Con - No real rhyme or reason for doing so now. Widespread (as opposed to targeted) disruptions likely don't have any predictable impact to swaying the election.
China
Pro - Reports that many of the infected devices were Chinese in origin
Con - China normally steals your business secrets rather than DDoS you. Chinese devices weren't the only ones, too - bad security is everywhere.
US intelligence (NSA et al)
Pro - False flag?
Con - NSA wants to listen in on your data, not shut you off from communicating. Unlikely that there is anyone who supports Wikileaks/Assange/Anonymous/etc that would change their minds over this.
This is by no means a comprehensive list, just off the top of my head.
Re: (Score:2)
Re: (Score:2)
In the words of a certain Dread Pirate, "Anyone who tells you differently is trying to sell you something."
Re: (Score:3)
Even if its encrypted or p2p2 or via a commercial or staging server, VPN or lots of hops, or in unexpected nations or by a few people.
Will they show what their tech can do or save it for "cyber" events?
Strange how well former crypto gov "operators", open-source counterintelligence operations and contractors can work together and in the open wi
Re: (Score:2)
There's also the "Bored Teenager" possibility. Some people just want to watch the world burn [wikipedia.org]. For all we know, this is the work of some kid with lots of free time, fucking around for no benefit and without any real motivation.
Re: (Score:2)
Pro - They misconfigured their own hardware, causing enormous useless trafffic and failures.
Con - A company that charges so much couldn't possibly make a simple configuration mistake!
Re: (Score:3)
Re: (Score:2)
This question isn't about who did it, it's about who's to blame.
The blame here clearly lies on manufacturers that produce products that are insecure by default and lack update policies and procedures to make them secure. There's literally nothing that can be done about this problem on a grand scale.
Re: (Score:2)
You forgot Liberals. Liberals are responsible for everything that is wrong in America, and in fact, the World.
It is because of liberals that I did not have a firearm to use to blow up the computers responsible for this mess, because Obama took my guns already. And because liberals hate God, I could not pray for Jesus to save us. And because liberals are in cahoots with the banks, now I have to pay for their bailout.
Some dumb-ass democratic conservative mod took exception to your insight.
The attackers (Score:5, Insightful)
Ultimately, it's the groups that initiated the DDoS who are to blame. But others have to take some responsibility for failing to do what they could to mitigate the opportunities to initiate attacks:
1. ISPs could implement measures based on RFCs 3704 and 2827 that would make spoofed traffic difficult to impossible to generate.
2. Router makers could implement RFC 3704 and 2827 rules in their firewalls by default, could implement default rules that blocked access to external DNS to everything except the router (with the option for the user to allow some or all access), could provide a separate network for IoT devices that defaults to no Internet access and the user has to specifically authorize access per device, and could make randomized default passwords the standard for factory-default configurations.
3. IoT manufacturers could make randomized default passwords standard and design their devices to not require Internet access to configure.
4. Consumers could acknowledge that they're responsible for their own networks and routinely make use of the available tools to check on the health of their networks and the status of the devices on it.
Re: (Score:2)
This wouldn't involve the ISP, it'd be entirely within the router. The router could access any DNS server, but hosts on the internal side could only access the router's caching DNS server unless the user authorized an exception for them. It wouldn't entirely prevent attacks like this one, but it'd prevent direct attacks and forcing the attacks through multiple levels of caching would blunt the attack to a degree and make it easier to throttle the sources of the malicious requests.
Re: (Score:2)
> This wouldn't involve the ISP, it'd be entirely within the router. The router could access any DNS server,
Until that individual router device fails DNS, as occurs quite frequently, and then _every_ device behind the router becomes quite useless. This happened to various AWS services when their internal DNS for their private customer VLAN's, their "VPC", failed. Running customized DNS from a router is a popular practice and is often done _extremely_ badly, often because the creators of the routers do no
Lawmakers and regulators (Score:2)
I find it unfair to blame lawmakers. The law is not a catch-all program that can be written once for any situations. This is why we regularly elect people to make it evolve
And regulators tried to do what they could we the power they had been granted by lawmakers.
That's Obvious (Score:4, Funny)
The incompetent sysadmin (Score:2)
The main problem was the incompetence of those sites' sysadmins. A TTL under 3600 and all your authoritative nameservers not just with the same provider but on the same platform with the lowest of low, cheap, scum of DNS providers (DynDNS)
Someone tripping over a cable or typing in the wrong command could've caused this. And it's not like Dyn hasn't just unplugged their customers before.
OURSELVES (Score:2)
For allowing such a broken internet design to continue to exist.
For allowing ICANN, RIPE, ARIN and APNIC to continue to exist.
For not adopting IPv6 faster/earlier.
For not adopting DNSSEC faster/earlier.
For not adopting Blockchain based name services faster/earlier and leaving the power at the hands of incompetents.
Just like non-voting during critical government elections, we vote for those attacks to continue by our lack of action.
You want those attacks to stop? DO SOMETHING ABOUT IT.
Re: (Score:2)
Router Packet Inspectors? (Score:2)
Filed under "this is why we can't have nice things" --- How about: upgrading "home" routers to offer some form of packet inspection? Yes I know that sometimes the routers themselves are enlisted in the attack. However, it appears that many IoT devices are setup inside the home/business and are insecure. And homes are adding more IoT devices than they are adding routers - thereby increasing the available munition surface area. Usually it is 1-router and (n)-IoTs.
Maybe this is a trivial solution - but cou
More Regulation! Or Not? (Score:2)
As far as getting the globe to agree on "being nice", well as soon as human trafficking goes away, I'll believe it. Till then, the reality is nobody needs a camera in their toaster, fridge or Amazon echo.... Or if you think you want one, you need your head examined.
Till consumers decide privac
Your mom (Score:2)
Your mom has too many open ports.
Re:Windmills (Score:5, Funny)
I believe global warming increases the severity of these attacks. Look at the facts: it's getting warmer every year, and the intensity of these attacks is likewise increasing.
Re:several people (Score:5, Insightful)
ISPs that don't implement rfc2827
Vendors that don't ship secure devices
The people that did it
Egress filtering would be nice too. If the source address of packets coming out of your network is not in your address space, don't let it out.
Re: (Score:2)
Neither, apparently, would have had any impact on the Dyn DDoS or the Krebs DDoS. The Mirai botnet traffic comes from compromised devices using legitimate source IPs -- no one is spoofing anything.
Re: (Score:2)
If Mirai could spoof source addresses then it could use DNS amplification attacks and the like to send even more traffic. Mirai is particularly impressive because of the amount of traffic it can source without doing that, but that doesn't mean that spoofing prevention had no effect on it.
Re: (Score:2)
Add to this - the retailers who sell said insecure devices.
Re: (Score:2)
I came here to post the same question. I know that 15 or 20 years ago when IPv4 addresses were plentiful that nearly everything was publically-addressable (though often firewalled at the gateway), but I thought nearly everyone from institutions to households had moved to private IPv4 networks. Most IoT devices that I know of that are cloud-enabled connect into a cloud control server from within a private network. Still a security risk, especially if malware gets inside the private network it can attack t
Re: (Score:2)
To the older generation you used a "person" or a timer or a device created for that task that was not networked.
Now that generations only know smart phones and the older generations want to be seen using apps its all network badly and on default passwords.
Blame wifi, default settings on modems, devices, toys. Users wanting to be seen with the IoT without the IoT been on its
Re: (Score:2)
I'm not sure that's quite right. With most home routers you have to go to some effort to place your IoT devices live on the internet. Besides that, most IoT companies already offer cloud access via their own app which doesn't require the IoT device to be open on the internet itself. I'd say this is the standard method of operation of IoT these days (a third-party service), especially for the unwashed masses. For example I've played with a WeMo switch that was cloud enabled but certainly wasn't out on th
Re: (Score:2)
Default admin passwords, guest mode?
All the altered devices with optical, coax, wireline offered huge bandwidth in the up direction on their low cost consumer plans that flooded the net at the same time?
They all add up to a super smart online network that can focus on one task globally?
Its strange how few are really pushing any party political narrative with this one.
No code litter within
Re: DNS... (Score:3)
Re: (Score:2)
When a gun is stolen and used in a crime we seize it as evidence.
When a zombie PC or "IoT" piece of shit is DDoSing something, we should block its traffic and cut off the customer if necessary.