Slashdot Mirror
Slashdot Asks: How Can We Prevent Packet-Flooding DDOS Attacks? (oceanpark.com)
Just last month Brian Krebs wrote "What appears to be missing is any sense of urgency to address the DDoS threat on a coordinated, global scale," warning that countless ISPs still weren't implementing the BCP38 security standard, which was released "more than a dozen years ago" to filter spoofed traffic. That's one possible solution, but Slashdot reader dgallard suggests the PEIP and Fair Service proposals by Don Cohen:
PEIP (Path Enhanced IP) extends the IP protocol to enable determining the router path of packets sent to a target host. Currently, there is no information to indicate which routers a packet traversed on its way to a destination (DDOS target), enabling use of forged source IP addresses to attack the target via packet flooding... Rather than attempting to prevent attack packets, instead PEIP provides a way to rate-limit all packets based on their router path to a destination.
I've also heard people suggest "just unplug everything," but on Friday the Wall Street Journal's Christopher Mim suggested another point of leverage, tweeting "We need laws that allow civil and/or criminal penalties for companies that sell systems this insecure." Is the best solution technical or legislative -- and does it involve hardware or software? Leave your best thoughts in the comments. How can we prevent packet-flooding DDOS attacks?
I've also heard people suggest "just unplug everything," but on Friday the Wall Street Journal's Christopher Mim suggested another point of leverage, tweeting "We need laws that allow civil and/or criminal penalties for companies that sell systems this insecure." Is the best solution technical or legislative -- and does it involve hardware or software? Leave your best thoughts in the comments. How can we prevent packet-flooding DDOS attacks?
Why not both?
Why is it so hard to grasp the concept that both a problem and a solution can be more than ONE THING?
-=This sig has nothing to do with my comment. Move along now=-
Set up correct secondary DNS servers.
If the secondaries had not been hosted at the same company, but instead at various companies around the world, the attack would have had no effect on anything but traffic.
This is, by the way, how multiply connected networks are supposed to work.
This could be easily accomplished at no additional cost by having a peering-pool arrangement between all the host registrars, so that we ended up with a multiply connected redundant network.
Kind of how we designed the thing to work in the 1960's and 1970's, and DNS itself in the 1980's.
But a lot harder for law enforcement to issue DNS-based takedowns on, of course. Since it would route around the damage and keep functioning. As designed.
and whatever you do do, don't pave paradise and put up a parking lot!
Technical measures that prevent address spoofing are quickly becoming obsolete anyway; AFAICT, the recent attacks on Krebbs and Dyn, the two biggest DDoS attacks ever, didn't use spoofed source addresses. A spoofed address is only useful in an amplification attack, where you send a small request which provokes a much larger response; then if you don't spoof the source address, you get a huge firehose of responses coming at you and it's you that gets DDoSed, not the target.
In this case, the attackers didn't bother spoofing source addresses, because they didn't use an amplification attack; they just used a huge botnet all making ostensibly-valid requests and each device dealing with the response individually. It looks like the only way we have of preventing this sort of attack is to make the devices secure - easier said than done.
Slashdot - News for Nerds, Stuff that Matters, in ISO-8859-1 Has just realised that beta makes this signature redundant
another one is happening right now
http://downdetector.com/status/level3/map/
I fail to understand why ISPs aren't blocking packets from customers (bots) that have a source address that is impossible from that location. They know the end point address out subnet already.
Years ago (when i was stupid, times were tough and everything was done on a shoestring) I had a BSD box that "load balanced" two connections (ADSL & WISP). The WISP one caught packets not being correctly SNATed, dropped them and told me.
with permanent disconnection of service.
It's their discount IoT shitpieces that are facilitating them.
"Fix it, take it offline, or find a new provider. Have a nice day."
Death is a little extreme. Let's just remove their hands. That way we can publicly shame them & they won't be able to do anything offensive or illegal again
Correct me if I'm wrong.
If a manufacturer made a device that connected to the public phone system, that could be compromised and made to call thousands of people at random, they'd soon find themselves facing product recalls, fines, import bans, and liability for the disruption caused.
Why should IoT devices be any different?
Some shitty noname Chinese remote webcam manufacturer hardcoded 'admin' as the password and tunnels through routers using uPnP to listen on the internet? Import ban that shit. Slap on a fine. Seize any of their American assets or property to pay it. They'll soon get the message that security can't be neglected. It's not hard to fix this stuff given the will.
As most of this traffic was "genuine", i.e. not spoofed, not faked, not bouncebacks, not violation of the protocol, etc. it's hard to do much about it. Even if you were running protocols where each packet had to be part of an authenticated stream, you would still have the same problem.
The only technical solution I can think of is a protocol with which you can communicate with an upstream host and have them implement a filter of your choice to the traffic they send you before it comes down your line.
Quite literally "please block anything from these IP's or traffic that matches this pattern".
But I cannot imagine such a thing ever be implemented as it pushes the burden further and further upstream and the top-layer will be overwhelmed with traffic and their filters running hot all day long, especially if they have millions of customers all specifying complex rules.
There's no way I can see to stop something like this, where millions of random devices starting genuine full connections and responding as any other client, without just rate-limiting (which rate-limits your other genuine clients) or engaging in the packet conversation as you normally would (which would be enough to cause a DoS in itself).
Even if you can spot a pattern, it'll be changed in the next iteration, or dynamically and randomly generated in time. It's like spam-filtering at packet-speeds, and as stupendously unreliable.
Previously, it was faking source IPs, which can be solved by ISPs being required to only allow their announced ranges. Now, with just millions of valid connections, a DoS is indistinguishable from a service just suddenly becoming incredibly popular with real users.
Any method, protocol, or setup where they have to connect to you like that and you perform some kind of check or measure against their connection (even, say, setting up a TLS session) can be replicated by the botnet just as easily.
There's no solution to what is effectively "junk mail" inside a TCP/UDP packet.
Woah, hold on there Billy. Just because internet infrastructure is terrible and the owners maybe doesn't want to fix or improve things (or any things really), doesn't mean you can just cry for bloody murder every time it is proven than technology is woefully inadequate or unsafe and insecure.
There is a reason send/return pathes are not included.
Go look at how many bytes addresses for 10 hops would take. Now scale that up to the maximum of 255 (most routers TTL-kill connections over 40-60 hops to avoid routing loops. Lack of connectivity to remote sites when key routers go down is often due to this limitation even if alternate paths are available. Good for reducing traffic, bad for 'worst case connectivity' reliability/redundancy.) The real solution long term would be a 'push back' anti-DDOS system where ips/ranges considered to be spamming the host can be 'pushed' back to routers, which in turn could push IP blacklist information to the next router back when incoming packet floods are recieved, and pass the block to the next router back until it is blocked at the originating ISP. As with the 'include all hops' idea it requires a *LOT* of overhead, which backbone switches/routers cannot afford and which most edge routers are not specced to handle.
However, were this to be done it would provide the least strain on the network for the most bandwidth savings, since it would over time reduce the bandwidth pressure on all but one participating link (since the border link between participating and non-participating ISPs would still be DDoSed) and lower the packet load on all other hops which in turn would have more resources available to provide normal traffic and analysis for said pushback service.
Maybe someone could mock it up for us on OpenWRT with a few 100M/1G routers that could handle the header analysis load so that it remains an unpatented idea (if someone has not already patented it.) And if not, write a royalty free RFC for future implementation. The basic idea could be applied to every other internetworking protocol, given sufficient cpu/memory. It should also ensure all well behaving programs would not be filtered since the threshold to blockage would require saturating a link beyond an acceptable percentage of throughput, which existing mechanisms should deter via voluntary rate limiting.
When you use p2p for everything a DDOS will increase service reliability.
I see this similar as the spam problem: push the pain back to the source. We need blacklists of hacked devices and bot nets. They should simply not be allowed to through any major routers. This way the end users will notice: they are effectively cut off the internet. It will also add market pressure to manufacturers (when customers riot against them).
Technically the blocking on routers should be quite cheap. The router can collect a list of source IPs that it sees. Periodically it can reduce that list into a list of known blacklisted IPs by consulting an online service. Then it can install rules to block those IPs until the next cycle. This is not time critical as we don't need very short reaction times, 15 minutes to an hour should be sufficient. It also quite efficient as the router only needs to maintain the minimal required set. It scales: as more and more routers become part of that blocking infrastructure the load (size of the blocking set) is distributed.
As long as data transfer on DSL lines seems to be "free" to the user, the user will not care very much about the possibility that his device is used in a DDOS attack. I believe even the prospect of a minor additional charge (e.g. $10 per year) by malicious traffic for the end user would do much good for the willingness of the user to accept inconveniences which make the IoT devices more secure against arbitrary access.
Murder? Hacking off of hands? Finally AC shows his true colours.
Sharia! i just read a law named Sharia
And suddenly that name
Will never be the same
To me...
(With apologies to Leonard Bernstein)
How about making DDos'ing Not illegal, forcing the industry to fix this type of issue?
Sigh!
Make it criminal for end-user ISPs to send out spoofed packets. This needs to go thru the UN, with a UN enforcement body.
Make it an obligation for all ISP (including backbone providers) to disconnect any customer who send spoofed packets for at least x minutes. If this is done in the US, then nothing in the US would be DDoS'ed. But many foreign ISPs would lose access to the US Internet until they got things fixed. If EU is included, we probably have 70-80% of the internet being safe from DDoS.
Tyranny is a tough job, but someone's gotta do it.
How about getting all the leet folks making IoT gadgets to actually do QA on the garbage they release so they can't be 0wn3d to begin with?
Just a thought here, but just because you can slap out a release in 15 minutes doesn't mean you should!
Since it can't comply with BCP38 without ISP intervention, which most ISPs seem intent on ignoring, I suggest a complete UDP ban. If that means rewriting DNS and NTP, so be it. As for telnet, it can do die in a fire, as any sane person would use SSH.
There already is a solution to this. We've done it already with email and with the increasing compromised accounts/junk message spam on iMessage getting throttled.
If someone is part of a botnet, then when someone reports being DDoS'd, they report it and the higher level ISP's should be notified. Cut them off temporarily, give them the same message that violators of MPAA/RIAA are given on their ISP's where they get a standard message that they are a shithead instead of loading normal pages and have to call in to an ISP to get the ban lifted.
"Your computer is running outdated software, is actively infected. We'll lift the ban for a few hours, but if you're still part of the botnet after 3 hours, you're banned again until you call us again."
Something along those lines. If you're running an infected system and get reported, then fuck off and either call a family member that knows computers or take it to a shop and have it cleaned.
"Well kids, you tried your best, and you failed. The lesson is, never try." -Homer Simpson
Get the apps out of the desktops and cell phones. Ban the apps until the hardware and software is secure.
Get free AV and consumer grade AV products to scan the users home networks with the same passwords and test every device found as a default setting.
Tell the user about the type of devices they have networked and the poor quality security some have.
Get some real security from the 5 eye nations and find out who is doing the command and control.
If its a person or bad country whats the problem with finding the origins?
Domestic spying is now "Benign Information Gathering"
It's been said before here, so allow me to offer a "how" for the obvious and already mentioned "secure the damn crap people hook up to the net".
This will only work with legislature. Sorry to all my libertarian friends here, but yes, there are times when the only way to sort out a problem is government intervention. These times are when you have to force people to do something for the "greater good" when they themselves would have a (smaller) profit from not giving a shit. And if there has ever been a good example, it's this. People don't give a shit about their IoT devices being insecure, because it does not affect them directly, but these insecure devices threaten the usability of the internet for all of us.
This is one of the reasons organizations like the FCC were created. Remember that sticker? Few people notice it nowadays because, well, it's a given that devices don't create harmful interference and that they don't go bananas if they are subject to any, but this was anything but certain in the early days of electronics. And no, that sticker itself doesn't do jack, of course, but it is a promise that the manufacturer has to live up to or face a heavy fine and ban of his device.
We need something like this for the IoT devices. "This device will not cause trouble on the internet and cannot be hijacked from there". Live up to it or see your device recalled. It pains me to ask for this, but it's time to create a government entity that deals with this. Or maybe hand it to the FCC so they start doing something useful again.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Fools shouldn't have access to a car, but they're more than capable to pass a driving test. Or with parenting, as long as they're able to have sex, they are allowed to have offspring. No matter how many cool secure protocols are developed, if a user leaves the factory username/password, that user is going to be harmful for 3rd parties (DDoS, lack of privacy, etc).
This is not a technical or legal problem. This problem is people not using their brains. The law may say insecure internet-capable gadgets are forbidden, but there will always be the clever guy who gets them elsewhere (cough china, chough ebay) just because they are cheap.
May be, the same way an idiot that causes a car crash is legally responsible, as parents are of their offspring, internet users may be need to be legally responsible if an electronic device is used for something like this. You cannot get rid of idiots, but may be you can make them responsible for their negligence...
Why not just create devices that don't behave in such a manner to begin with? I'm actually surprised that IoT devices aren't usually hooked up to a router and is NATted to the wider internet. So scanning and infection must be only on entities that do have non private ip addresses, like companies, in which case, maybe the cso needs a quick brush up on the whole internet thing.
In any case i'm also surprised that the affected users didn't quickly set up a region based sinkhole to soak up errant requests. Also since the requests have easily identifiable non valid strings, it would have been easier to filter out legitimate queries on the firewall. It would be easier to do this before a real flood, to have some form of playbook on hand.
... the solution is an always broadcast system (aka 'bandwidth is always maxed'). The current system we use is push pull, and we worry about "using all available bandwidth" when you want to something else. You want a system that just pushes packets constantly to a dumb terminal and the device can't request anything from anyone, packets can only travel in one direction. Instead of websites "Serving" a request, they push their site to everyone, aka every ISP would have a local copy of the site on an internal lan isolated from the net that basically gets a "push copy" form a master list. Basically you'd have to rearchitect many aspects of the net from interactive to broadcast only.
You could start by not giving IP addresses to kettles and toasters.
Just fucking do it already.
The problem with BCP38 is a lot of AS have a business model of allowing shit through their network.
However, dealing with that should be easier than this path nonsense.
One possible answer would be to insist that the stupider devices (embedded stuff like dishwashers, boilers, even DVRs) would only be able to communicate via some sort of home hub (purpose built for IoT *not* a generic router). This could provide services such as data buffering/caching as well as firewalling/rate limiting to prevent a) direct access to the devices from the wider Internet and b) the 'proliferation of misbehaviour'. Yes it's one more device but possibly pretty cheap - esp if running open source software - which would also improve security.
Define classes of security: A: Tested by 3rd party sec authority to standard xyz, perhaps sub levels. $$$ B: Tested by 3rd party sec authority $$ C: Tested internally $ D: Not tested bus assumed secure E: Not secure (yes we should have this) If you make software or a product you have to choose a sec class. Then classes regarding deployment 1: Full outbound access to the internet 2: Partial outbound access to internet 3: No outbound access to internet If you install or deploy you have to notify client of deployment class. So if a network installer deploys, or a customer demands Z1 they deserved to get fined for participation in a Bot Net. Build legislation around a non financially restrictive model.
Which works if we're just talking PCs. How is Joe Sixpack supposed to know the camera system his electrician friend hooked him up with for a slab of beer is causing his internet to get blocked?
Reading this is fairly eye opening as it explains the different methods attackers use to gain access to your NAT-"firewalled" IoT device. It was also a useful reminder that IoT items aren't just "IP cameras", but routers, printers, and other stuff that most people have had for years.
You can skip to page 34 for the most important problem with most of the headline devices though (which also explains why owned cameras is a big thing, but less so owned routers): insecure "cloud" servers that provide connectivity to your IoT devices when you're off network. For example, it provides the connectivity that allows an app on your phone to access your baby camera remotely.
The servers typically provide way too much information, and often provide access to the entire camera, not just the video stream. As a result, hackers can, by scanning a range of camera IDs using the server at minimum find out what the public and NAT IPs are. They may be able to send arbitrary packets, including those to backdoor debugging ports, depending on the server, without even needing passwords.
Outside of using that server, hackers become more dependent upon heavy, probably noticeable, scanning, making it increasingly difficult if you don't already have compromised hardware.
My takeaway? Go after the manufacturers. There's stuff they can do right now by patching just two things: the gateway servers they are running right now, and the apps that use them. Yes, in this case, it's worth doing - those here saying "Oh they're all fly by night, you can't reach them" forget that if that were truly the case, there wouldn't be a problem, because the gateways they're running wouldn't be up.
Someone is running the gateways. Those people can fix them right now, and need to.
You are not alone. This is not normal. None of this is normal.
against manufacturers of insecure IP cameras, IP DVRs, IP Refrigerators, IP microwave ovens, etc., This should make them recall their devices in bulk, fix them and more importantly think about securing them properly in the future instead of admin/password, admin/admin, and the like..
So we're going to have to handle it at the routing level. We're going to need a web of trust routing system and when some provider goes full retard and fails to block malicious traffic originating from their network, their peers null-route and refuse to carry their traffic until they fix it.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Sorry, but I don't play "bot". It's fairly simple to configure an outbound firewall... why the ISP's don't build that into their devices and block the flood on the edges is beyond me. We have aspiring AI that loves patterns, why not turn "WATSON" (or similar) loose teach him/her what to look for and provide a control channel that can be used to tune each edge device?
Mostly cloudy by the Beach
It's amazing to me that people are clamoring for legislative solutions now when this sort of problem has pretty much always existed. Remember all those insecure home Win boxes that were pwned and used for DDoS attacks a decade or more ago? Sure, there is an order of magnitude more IoT devices now, but the network and resource limits are also an order of magnitude bigger. We're not going to magically legislate good security from either companies or home users. Even when well intentioned they'll make mistakes. We need to make the network more resilient.
If I had more time on my hands, and less regard for law, I might write a botnet that finds all these insecure devices (by cutting'n'pasting the Mirai source code), takes them over, and closes the telnet and ssh ports behind itself. And that's all -- all it does is stop other botnets from taking over the device. If I were a president or prime minister, I might ask one of my intelligence agencies to do it for me.
I've wondered if companies like Google and FB - who are no doubt getting DDOSed all the time in various ways - could start trying to inform users if they notice them browsing from the same IP address as a DDOS source.
A big notice on FB or the Google search page that says "there is suspicious activity coming from your IP address" might at least get people to contact their local nerd to ask them what the hell that warning is all about. I don't expect users to be able to identify the source of the problem (unless they can be REALLY specific, like "it's your X-Cam IP Camera Mark II that is causing the problem.. but even then?), but maybe just an alert would prompt them to think about taking some action.
Probably wishful thinking but I would imagine it's a fairly low cost test to run for them. Google at least have stuff to do this already (e.g., if they detect suspicious activity for your account from unusual IP addresses).
> If someone is part of a botnet, then when someone reports being DDoS'd, they report it and the higher level ISP's should be notified
Ugh. Do you not understand that there are MILLIONS of IPs involved?
How exactly do you propose to send out millions of authenticated block requests fast enough to be effective (i.e., minutes). And how do you do that when the majority of the people receiving the requests are in other countries? And that spoofing these requests would make a site disappear, and would be a perfectly effective attack on its own?
If you think you have a solution to that problem, then you don't really understand the problem.
Governments can't be trusted to enforce laws vigorously that are politically sensitive, as prosecutions of DDOS cases might be (who to prosecute? are you going to charge another government? etc). So go with big big civil penalties. There'll always be someone who will sue anybody--like the 9/11 victims families in the US trying to sue Saudi Arabia against the wishes of the US govt.
Seriously, there is absolutely no need to connect fridges, cars, toasters, kettles and other shit to the internet. This is not progress, and it will not make people's life easier. Just different.
I was 100% unaffrected by the DDOS attack on DNS because I run a cacheing DNS server that I set to break the rules of DNS. I cache DNS until I get an update.
a DNS request is passed through to the main servers, if I get no response in 100ms I fall back to cached information. cached information does not expire for 30 days
so unless some obscure site that changes it's IP constantly decides to hop IP's during the DDOS attack I have zero issues.
Do not look at laser with remaining good eye.
1. Put on your grey hat.
2. Make a ginormous botnet.
3. DDoS Stack Overflow and GitHub until you itdoesnt work any more.
The problem is now resolved.
The Internet of "Things" is the first problem - companies that don't know the first thing about network security are putting a Rpi in everything they make and putting it on the Internet without a second thought to how to make things secure.
I recently had to replace my HVAC system and the contractor installed one of those Internet-enabled Thermostats that I could access with an app on my phone. The damn thing tries to open up not one, not two, but THREE ports on my router using upnp. THREE servers running in a THERMOSTAT.
This is the problem with DDoS attacks today. Any 1337 h4x0r can take over a million IoT devices in an hour and use them to DDoS anything.
There needs to be a certification body for IoT devices, much like UL for electrical things and FCC for radio things and such. A regulatory body for "network things" would go far to stop this shit.
Everyone just wanted profit. Companies would just release buggy codes in devices which will also be consumed regardless of price.
The penalty for mildly inconveniencing me is always death.
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
Currently devices that operate using radio waves are regulated to ensure that they do not do something they are not supposed to do. For example, the FCC requires that phones operate only on specific frequencies and not others. This is done not so that government can control things, but so that devices can work in proximity to each other with minimal to no interference. Violating these laws carries both criminal and civil penalties.
What we need is to certify that devices attached to the internet have a certain level of security, that the user can access the pass word and all of the services the device is capable of delivering, and to ensure that a device that is sold to perform a set of tasks does only that. What we have now is a bunch of unregulated general purpose systems connected to the internet with no way to control their behavior because they can do a lot more than advertised. Kinda like the early days of radio.
Simple.
If you jailbreak your device, you take responsibility for security.
Heck, I think that's one reason that the FCC hates jailbreaks, because it causes the product to be altered and lose its certification.
That's a dumb argument. That's like arguing that we don't punish murderers because all they did was prove that a skull is inadequate to stand up to an axe.
DELIBERATELY damaging something isn't just showing a weakness - its destructive, and rather pointless.
"People who think they know everything are very annoying to those of us who do."-Mark Twain
IoT devices may exist to make our lives easier, but the real reason they're connected 24/7 is so some sleazy firm can data mine which settings on your vibrator get you off the fastest. Remove the market for that bullshit either via stronger privacy laws, fines, or all of the above and you remove the vectors.
Users are a big part of this problem. Yes, the whole user/pass auth mechanism is past it's prime, but in most cases, it's all we have. For that reason, users/administrators must take a large share of the blame for recent events. Deploying anything with the default auth credentials in place in an Internet-facing location is, to say the least, irresponsible. When this much damage can be cause by such actions, it should hurt.
The referenced article about PEIP doesn't even mention UDP, only TCP. Aren't most DNS requests UDP?
Maria is a bit of a la he botnet. Hard to say if properly implemented DNS response rate limiting would have helped based on the volumetric size of the attack and Dyn's available bandwidth. Also, BCP38 is a snap to setup and is not taxing on the router; just . . . admins have to stop being lazy.
Path recovery/tracing has been a dead topic for > 20 years now, with the occasional irrelevant paper still getting published. The fact of the matter is that all proposals require far too many expensive changes and hence are never going to make in in practice. Sad but true.
Personally, I think we should start to drop ISPs that do not do egress-filtering and maybe make that a legal requirement for backbone operators. I do not see this changing unless we force ISPs to finally start following sound practices. With that we could at least identify where the worst of it is coming from.
And next, we should require ISPs to warn and then disconnect users that operate bot-net members. If they fail, drop their global connectivity.
I do not really see any other options. Laws (except allowing backbone operators to force ISPs to finally start using good networking practices) will not help.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
They wouldn't need to be sent in minutes, these attacks are lasting hours and even days. Even once the attack is over those devices are still compromised.
Why not legislate that all devices which require a username and password, force the user to change it before a device will work and connect to the internet. And force the devices to only accept complex passwords.
Complex passwords are easy to remember, pick a long word then type in 1337. A 'w' becomes \/\/ etc, greatly increasing length, numeric and symbol entry, yet the base word can be simple to remember. Use 2 or 3 words and you have huge passwords.
Amazon /-\/\/\/-\Z0|\| becomes 15 char.
(Yes basics like this will just go into a firstcheck list for brute force, but still...)
Fair question.
We need a trade for this. Just like you call pest control when you have a mouse, you call someone to find out what hacked device is connected to your network.
they report it and the higher level ISP's should be notified. Cut them off temporarily
Cool you just found a way to DoS someone without thousands of machines involved!
Like most Joe Sixpacks he will call his ISP support (to complain or to request help) and they can tell him that his camera system is infected/exploited. He'll then call his friend asking for help... and depending on the amount of knowledge his friend has... will either throw out the system, replace it with a new one, or patch the system.
That approach will most certainly result in 2 terrible consequences. The first is regulatory capture, wherein the incumbents use the regulatory system to prevent competitions. The second is that this will most certainly create a significant barrier for entry for small businesses, and create a significant lag time that will actually make security worse.
As long as the Chinese government is on board, using a reactive approach that can, if the attack is crippling, be crippling to negligent corporations, is likely to be effective, without presenting a significant barrier to innovation.
That just changes the attack plan. Want to disrupt the internet? Why send millions of packets to one address when you can send one complaint each to millions of addresses?
Suddenly, when trying to prevent individual sites to go down, you have created a monster that lets one person take down entire regions with the same bandwidth requirements.
We need a Department of Bricking (DOB).
An agency of the federal government that is staffed, funded, and mandated to find and brick every device on the internet.
Don't want your device bricked? Secure it.
Device bricked? Your problem. Maybe you should complain to the vendor.
Add a simple UDP/ARP style protocol that can only be exchanged between two devices (NEVER propagates) allowing the downstream devise to say to the upstream one "Hey, I'm being overrun! start throttling/masking new connections/packets from everywhere/mask" or "hey, I'm feeling better now, let some more stuff through" along with flag bits to allow the downstream device to indicated suspicion of or certainty of DOS attacks (so upstream equip can help track and stop).
When a server gets hammered, it signals the upstream router, which begins discarding packets (perhaps randomly, perhaps using a network address mask) and if flags say the sever thinks (possibly because it is tracking the activity enough to recognize an attack) it's being attacked, then the upstream router may relay the information uphill for further diagnostics. If the router itself is being overrun, then it generates its own "I'm being hammered" packet and sends that upstream with its own info/status flags possibly informed by the downstream flags (probably the "hammered" packet should include bitflags from the sender, and a separate set of bitflags that are a logical OR of the flags from all downstream systems, and a separate set of bitflags for the originator of the complaint - it would still be a single nice UDP style packet.
people can fix much more rapidly and efficiently and inexpensively.
NEWS FLASH #1: Government = Unaccountable Bureaucrats + (Politicians * (lobbyists + cronies))
NEWS FLASH #2: Government Regulations = hundreds or thousands of pages of unreadable legalese churned out by Government and enforced by Government (see news flash #1)
A government solution would be piles of new regulations that will get warped and mutated over time as individual words get altered by tiny patches applies via obscure clauses in future regulations/legislation that the public never even becomes aware of. It would also lock-in stupid, primitive, "fixes" even as technical people come up with faster, better, more elegant solutions and then find that they cannot implement them.
All that's needed is slightly smarter networking hardware/software to allow communicate about attacks and send up a virtual emergency flare when under attack to allow the other devices on the network to cooperatively track and shut down the attack.
Remember: denial of service attacks are generally legitimate network packets but just being sent in a tidal wave. Politicians would try to legislate solutions without understanding even the basics. The network, on the other hand, could in an automated fashion figure out all the machines hammering a server and then just reduce the number of packets allowed toward that server from those machines and report to the owners of those machines. It could also figure out all the machines that are hammering a server during an attack and signal that they are part of an attack.
TECHNICAL SOLUTIONS are what's needed, NOT the solutions mandated by politicians whose campaigns are funded with money from certain "solution providers"
There is no one person or class of persons who essentially owns this. The problem is a confluence of a number of factors, and so far all I see is fingerpointing as to whose job it is to clean up this mess.
First you have manufacturers that don't give a crap. Their objective is to turn out crap as cheaply as possible, and they only need to work well enough that the customer won't return it to the store.
You have the retailers. Most of whom don't know much about the items themselves. All they care is that customers not return them for being broken or too hard to configure.
You have consumers. They want cheap shit, and it needs to be totally idiot-proof to get working. Some will go out of their way to purchase directly from overseas e-stores just to save a few bucks. If it is too hard to configure, they will return the item, but they will seldom return something because it has default telnet credentials that the user cannot change.
You have ISPs. They added UPNP to their routers to support lamers and other sorts of devices. And you also have ISPs who have not yet added support for the RFC to control forged addresses. And you have ISPs who strongly believe that their job is to deliver packets, and they want no part in filtering anything that comes from a customer machine.
You have the standards body that came up with UPNP. They assumed that people building the objects would do a halfway decent job, and they blindly open up whatever ports the device behind the firewall asks for.
You have the standards body that decided that DNS should be both TCP and UDP. Yeah, I know it is faster, but it is also far easier to do an attack with a forged sender.
And then you have people who run the networks and machines that are under attack. They bear the brunt of it, but for the most part they don't have much of a role.
Given that nobody wants to take ownership of this, to me it means that we will never have complete cooperation. We will never get all of the ISPs on board. We will certainly never get all of the consumers on board, and we will certainly never get all of the retailers on board.
Massive class action suits against makers and suppliers may concentrate a few minds?
And solution would be that simple, such a product should not work, except for its own admin portal, until default password is changed. And this way we would just have 5% or all these devices and servers available on the internet.
And the solution could be implemented for IP cameras, database servers etc.
Yes we will have easy passwords for sure, but not the defaults one and the whole "eco system" would shrink
Hackers rely on systems communicating back to them when they are hacked. Systems need to stop communicating to everyone by default. System egress traffic should be restricted to required external services (DNS, NTP, Updates) and only expose system services to the minimum networked systems that are needed.
A lot of people say "white listing" traffic is to hard to do, but there is a fairly new Open Source project intended to use a high level of automation to auto generate egress/ingress firewall rules based on the system configuration to make it easy. It includes a Remote Config module that is designed for IOT devices using the linux kernel.
https://wiki.entpack.com/wiki/modules/remote_config
Full disclosure, I am the lead developer for EntPack.
Nah. Jailbreaks are going to be a small percentage of users, so shipping secure gear will result in all but a small percentage of the gear being secure, rather than the current case of only a small percent being secure (that owned by folks who take the time to secure it).
There is no cost to vendor laziness, stupidity and intentional collusion with governments to weaken security.
There are two basic ways to change this equation:
1. Make customers care about security enough to put vendors on notice.
2. Empower big brother to regulate and enforce standards
I am strongly not interested in #2. Given the world wide nature of the network going down this path is also rather fruitless.
#1 is a pipe dream yet one way to make it a reality is for end users to pay a higher price such as prospect of getting their devices whacked instead of just silently taken over without their knowledge.
The way this should work if your system accepts incoming connections from the Internet and:
1. It has known vulnerabilities
OR
2. Weak credentials with a prescribed entropy threshold
You should be allowed to hack system in order to serve notice to owner. If there is no action after a period of time you would be allowed to have your payload automatically alter the system to disable network connectivity.
There are possible technical solutions. In the case of the Mirai botnet attacks, the released source code identifies the affected devices. Device manufacturers can be mapped to MAC addresses. ISP's could filter traffic from known vulnerable hardware devices to known DDoS attack targets.
Is this an easy solution? No. Is this a comprehensive solution? No. Would ISP's want to take on this responsibility? No. But is it technically possible? Yes.
Given that many system vendors refuse to patch remote exploits in their products legislation may be needed. Like Internet providers they should have an abuse email where they reply to inquiries.
Also product EOL should not be an excuse to stop providing security patches. Not when the bug has been fixed in "upstream" products. Yes I am talking about Samsung and others that doesn't distribute existing upgrades of Android.
Finally there should be constant scanning for vulnerable devices which should be disconnected from Internet by the ISP:s.
Making more laws against hacking is useless as criminals usually don't care. However neglect or ignorance by manufacturers, isp:s and end users can be regulated and punished.
Sounds like you have never
heard that recording before.
OpenDNS (not hit) as a DNS (sub 4% of my time online) & 50 file fav. sites @ top of hosts I spend 95++% of time online on them (run in kernelmode speed via tcpip.sys) avoiding DNS to get to them doing that way, resolving them faster from local system RAM instead.
APK
P.S.=> A "1-2 punch" that in this case worked (I'm upper east coast USA too)... apk
"Attack is the secret of defense; defense is the planning of an attack." -- Sun Tzu
“All a prevent defense does is prevent you from winning" -- John Madden
“The bomber will always get through. The only defense is in offense, which means that you have to kill more women and children more quickly that the enemy if you want to save yourselves." -- Stanley Baldwin
“The best defense is a good offense." -- Vince Lombardi, Jack Dempsey
all quotes from the web, so there's a 60/40 chance they're worng.
The Russians have won. They have made the world a cesspool of distrust, greed, fear and hate.
just like anything that radiates electrical energy needs a FCC certification, there ought to be a standardized security grade. not backwards like the FCC (A is wide open, B is filtered for home use), but like in grammar school. D and F doesn't get past customs. C limited to devices that are not ordinarily connect to anything approaching our Connected Internet. B and A for residential, and A for data centers.
if this is supposed to be a new economy, how come they still want my old fashioned money?
exactly how vital is it to have refrigerators ordering food on their own, and sock drawers starting the washer?
if this is supposed to be a new economy, how come they still want my old fashioned money?
Manufacturers are the root cause and economics are a big issue. If you sell a 40 or 100 dollar IoT device how frequently are you, the manufacturer, going to continue to provide updates and do so proactively? There is no ongoing revenue and only cost for doing that and the money/margins aren't there. Smartphones are not phones but computers that cost $600, yet we see manufacturers stop providing updates in 18-24 months (Apple excepted). Look at routers that are 2 years old or so rarely if ever do we see an update. On our PCs Microsoft provided updates to Windows XP for 7 years and so that is what consumers think is happening but it isn't. if we can't get smartphones updated after 2 years what hope is there of the $99 and $199 IoT devices.
Let's face it, getting manufacturers to provide updates for 5 or 7 years or more isn't going to happen. But it isnt just the device manufacturers. Devices now last a very long time and the economics of updates don't work for the makers. Cisco EOL'ed a perfectly fine firewall I had at our office. The hardware is just fine, I suspect the costs of building and testing new releases and updates for security issues was just too painful. Likely no one wanted to work on the old code, if there was even anyone who knew or understood it. I suspect programmers not wanting to do long term maintenance of old stuff and wanting to move on to the next new thing is part of the problem. Even there is it the device makers fault as well. promotions and high salaries go to the new stuff and maintenance is considered for the "dead enders", and those folks know they'll get laid off and their jobs off shored. So you have to move to the new projects and tech and leave a place that keeps you on maintenance.
And the regulatory/legal situation is also to blame. Read a shrink wrap license or any software license. They all say that the makers aren't responsible for the fact that its software and doesn't really work.
It needs to start with a legal framework gets rid of the shrink wrap licenses and denial of liability, forced arbitration and the like. But then we'd hear complaints about innovation being throttled and excess costs and the like.
But don't expect action from Congress as long as they can pass the buck to the FCC, FTC, CPSC, the companies, the Executive Branch, etc.
just drop all packets. Problem solved.
But I will. If you spit it up into two sections, then the attacker will simply attack both servers. How many secondary servers would you need before the attack is spread too thin to deny service? Who knows.
That's easy. You put ALL of them in the peering pool. If you don't put your servers in the peering pool, then an attack can take you down... but no one else. Good luck getting customers in the future.
It's very easy: 10,000 DNS servers means a 1:10,000 chance of them hitting both your primary and secondary servers for your domain. Unless it's YOU the bad guys are attacking, instead of the DNS infrastructure (and if it's YOU, you have other problems), then it's unlikely that both your primary and secondary will get hit.
But don't forget that the companies are paying for all this bandwidth.
Yes. And to make it fair, you scale your presence in the pool by the number of domains you are personally hosting. If you host 1,000 domains, then at most you will also be secondary for 1,000 domains. If you host 1,000,000 domains, then you will host at most 1,000,000 secondaries.
This is why it's a peering pool.
Even if their services stay online they're spending $$$ to keep them online while the attacker isn't spending any money.
One company is an acceptable casualty. It's likely, however, that the Bad Guys(tm) were either targeting a number of specific domains, or they were targeting Dyn itself.
Either way, you'd set up collective defense resources for all pool members (that way, even if they were just going after Dyn, you could still afford to go after the culprit).
Holding the CEO and other executives legally responsible for the insecurity of their networks would be a start. Of course, that'll never happen. And it wouldn't stop a damned thing in other countries. Is it really so shocking that penny pinching ISPs have shitty, insecurity networks that (a) no one actively monitors, or (b) give enough of a shit to do anything when they are made aware of a problem? And those are the "good actors"! There are plenty of ISPs across the globe that simply do not care what their customers do, as long as the bill is paid. (the unending spam in your inbox should've taught you that long ago.)
The only technical means of doing anything about it would be for Cisco, Juniper, etc. to turn on uRPF permanently, with ZERO option to ever disable it. That won't stop an attack, but at least you'll know who is attacking you.
Many/most of these IoT devices are behind ISP-provided home routers. Require the ISP's to run an automated suite of white hat attacks against every new home device *the first time* a device tries to access the Internet through a home router. Call this the "device registration" process. Develop blacklists of devices that are known bad actors. Refuse to have the router pass packets to/from those devices that fail the registration process. It is far from perfect of course (many ways to circumvent it), but it would reduce the size of these low hanging fruit botnets. So, you attach your smart tea cup to your home network. The first time this device is opened to the Internet, your router/ISP runs a scan against it. It looks for open telnet with "password" as the password, vnc with no password, etc, etc, etc. Fail the tests, and you are informed that this insecure device cannot receive or transmit over the Internet. (Though it will still remain active within your home network, behind the router.) ISP's could add a requirement to their terms of service that the user certifies that they will not install insecure devices onto the public Internet and that they understand that they will not be allowed to access the Internet with such devices. The ISP could generate a report for the user indicating in what way the new device is insecure and what measures need to be taken to make it "Internet safe." Or something like that.
Some messages are best delivered by brick...
That introduces a new attack, where I can knock a legit actor offline by falsely reporting. Just like the MPAA/RIAA you've cited, who managed to get legitimate videos removed from YouTube, and innocent customers ejected from ISPs.
This is the best suggestion I've read so far!
APK Hosts File Engine 9.0++ SR-4 32/64-bit https://www.google.com/search?...
Ads rob speed, security (malvertising) & privacy (tracking).
Hosts add speed (hardcodes/adblocks), security (bad sites/poisoned dns), reliability (dns down), & anonymity (dns requestlogs/trackers) natively.
Works vs. caps & PUSH ads.
Avg. page = big as Doom http://www.theregister.co.uk/2... & ads = 40% of it.
Hosts != ClarityRay blockable (vs. souled-out to admen inferior wasteful redundant slow usermode addons)
Less power/cpu/ram + IO use vs. DNS/routers/addons/antivirus (slows you) + less security issues/complexity.
Compliments firewalls (blocking less used IP addys vs. hosts blocking more used domains) & DNS (lightens dns load).
Gets data via 10 security sites.
APK
P.S. - Safe https://www.virustotal.com/en/... (Verified by Malwarebytes' S. Burn "seen the code & it's safe" http://forum.hosts-file.net/vi... )
After addressing this with people on ./ and also technical minds with 30+ years of experience from a couple of companies I work with indirectly, I have come to this:
If the great minds discuss the details of a solution on the Internet in order to form a collective end, the information used to and the end solution are visible by the designers/exploiters of said attacks. This can lead to 'ways around it' or new methods which haven't been addressed yet because the current attack modes are still working (duh, I know).
If we(people/companies/government) keep discussions secret, and don't allow the attackers to have ANY way of having knowledge of the solution, we are violating the free knowledge concepts that we love today. It also introduces a few things that we hate and talk about today -
In summary, all I have come up with is control of the operating systems through open source methods. Example: Users run Linux or Windows; doesn't matter. Every machine is forced to have an open-source solution installed on it to circumvent the attack processes with a 'wrapper' around it to prevent the removal/termination of it by malware (effectively, malware with a good and open-source process; Yayware?). This software, whether it's introduced into the IP stack as a driver or external intercepting software, it becomes another form of spam control, at least if the last part (external software) is used.
That's my idea, but it has several flaws, too. First one is force - who's going to accept force, and if people are willing to accept it, will it be from OS vendors/maintained through update sources, or will it be an external piece of 'Yayware' that many will use but those with a lack of knowledge/experience in computer use (the majority) will bother to accept it or even "know what this weird thingy is about; 'I only use my computer to look at my family's photos, print, and the the weather from the icon thing on the desktop my son put there to take me to the forecast'"? That sort of thing. I'm sure most if not all of you have witnessed that and bitten your fingernails to step aside from those 'slow computers' loaded with bloatware, possibly malware, who knows what else, because it's 'not your place' to fix that machine up without breaking functionality for the end user....... Yeah.
This doesn't address the issue of foreign products being uncontrolled. Solution - we won't allow your product to be sold in [our Country] unless the source is released and can be reviewed within [our Country] and all devices with this firmware will be overwritten using the source reviewed and compiled within [our Country]. *thumb down with a fart noise* - yeah, like that's gonna happen, for so many reasons that are obvious.
If we can work through the previously-mentioned ignorance part, through education and awareness, we might have a leg to stand on. I don't think I need to say what the chances of that happening are. *thumb down with a BIG fart noise*