Ask Slashdot: What Should We Do About the DDoS Problem? 312
An anonymous reader writes: Distributed denial of service attacks have become a big problem. The internet protocol is designed to treat unlimited amounts of unsolicited traffic identically to important traffic from real users. While it's true DDoS attacks can be made harder by fixing traffic amplification exploits (including botnets), and smarter service front ends, there really doesn't seem to be any long term solution in the works. Does anyone know of any plans to actually try and fix the problem?
BCP38 (Score:5, Informative)
https://tools.ietf.org/html/bcp38
Re: (Score:2)
Re:BCP38 (Score:5, Informative)
The place to implement BCP38 is definitely as close the edge of the network as possible, long before it gets near the core of an ISP's network, let alone starts hitting up their BGP peers; ideally on the CPE, but failing that on the first capable router on the ISP's network. Why more So-Ho routers don't implement at least partial BCP38 by default has always baffled me; they usually have *one* network, seldom more than two, and often just a single IP on the LAN side, with the entire rest of the internet is on the other - how hard can it be to correctly block spoofed packets by default? That still leaves networks with their own IP allocation that are multi-homing with multiple upstream ISPs, but if someone is that big/technically inclined then they ought to be able to implement BCP38 themselves (I do this at my SoHo), work with their ISPs to sort out the config on their upstream routers, or just man up, do their own BGP and effectively act as an ISP.
Re: (Score:2)
Why more So-Ho routers don't implement at least partial BCP38 by default has always baffled me
SoHo routers are using the cheapest, easiest to deploy software possible. They don't care if that means handing out 9 year old software bugs [threatpost.com] in millions of units. The only way I see BCP38 gaining traction in that market is if it just works out of the box in Linux, with minimal configuration involved. Then the SoHo vendors who just grab Linux derived routing software will gain that capability. If that catches on to where it becomes feature checkbox material--"our new router protects against DDOS attacks
Re: (Score:2)
It would have to happen at the CPE. Otherwise bots would get smarter, and in places like residential connections if your IP was 8.8.8.8 you just fake coming from 8.8.8.10 which is legitimate for the ISP to send traffic from, but would implicate the wrong customer when it came to blocking.
Re:BCP38 (Score:5, Insightful)
Re: (Score:2)
On paper, no, but it might still have benefits. I implemented SPF with "-all" for several domains some years ago which, on paper, merely allows recipients checking SPF to negatively weight/discard emails falsely claiming to be from those domains - it does absolutely *nothing* to prevent spammers from spoofing the domains, yet within two weeks of the SPF records going live the domains stopped being used for joe-jobs and we never saw a single bounce, p
Re: (Score:2)
bcp38 stops people from using fake IP addresses. That does not solve the problem in general. If my pipe (or collection of pipes) is bigger than your pipe, I can still destroy your service. While it seems like many people here don't think you can do better, there are some more options.
First let me say this is not my field. It's been a couple years since I studied BGP, but since I don't see anyone posting robust solutions, I'll provide my hand waving arguments and proposals. I will not claim any of this is
Re: (Score:3)
It still stops botnets from spoofing their IPs, which (if widely implemented) does open the door to ISPs to block the IPs known to belong to a botnet.
you need to kill the botnets (Score:5, Insightful)
DDoS attacks are only possible because of the ready availability of huge networks of compromised computers. Fix that, and the world becomes a better place.
Also, this peace on earth thing has been a while coming, you might want to take a look at that. too.
And flying cars.
Re: (Score:3)
Re:you need to kill the botnets (Score:4, Interesting)
Re: (Score:2, Insightful)
You can only kill the malware that is behind these DDoS's by completely eliminating security flaws in software.
Tricking a user into running an application, like so many of the web popups do, does not exploit a security flaw.
Re: (Score:2)
You can only kill the malware that is behind these DDoS's by completely eliminating security flaws in software
How do you stop users from double-clicking miley_cyrus_nude.jpg.exe?
The ability to run an executable is not a security flaw.
Re: (Score:2)
How do you stop users from double-clicking miley_cyrus_nude.jpg.exe?
Microsoft could start by changing the default Windows Explorer settings to always show file extensions and not have a configuration option that turned off the display.
No, it wouldn't stop everyone from doing stupid things, but it might help a few people make better decisions.
Re: (Score:3)
No, it wouldn't stop everyone from doing stupid things, but it might help a few people make better decisions.
Hardly.
Attacker: It's Christmastime, so just install this greeting card program that has dancing cats!
Above Average Victim: Might this be a virus?
A: But dancing cats!
AAV: OK! *click*
Attacker: It's Christmastime, so just install this greeting card *click* program that has dancing cats!
Average Victim: You had me at greeting card! Oh, look! Dancing cats!
If you are going to allow people to own their own computers, and make their own decisions about what software they're going to run on them, they will alwa
Re: (Score:2)
How do you stop users from double-clicking miley_cyrus_nude.jpg.exe?
Name it that. It's enough.
Re: (Score:2)
While you're eliminating all security flaws, make sure you take care of the PEBKAC problem. No matter how secure your OS and software, an insecure user will result in the system being compromised.
"What? Windows is calling me because my computer has viruses in it? Sure, I'll run this tool that this stranger-who-called-me told me to run to fix this."
"Ooh. Someone I've never talked to e-mailed me a file that contains naked photos of $CELEBRITY. Looks like I just need to disable my anti-virus and firewall
Re: (Score:2)
You can only kill the malware that is behind these DDoS's by completely eliminating security flaws in software. ...
Wrong.
There's multiple times of DDoS's. Let's get that out of the way.... we're talking about botnet based DDoS here. Solutions are different for other types.
Given a botnet attacking one or more targeted hosts, it's relatively easy to identify a large number of the hosts involved in the attack.
While illegal, once you have that, it's quite feasible infiltrate at least a subset of those hosts. Go from there and infiltrate the botnet as a whole (determine command and control stuff, determine other bots, take o
Re: (Score:2)
dumb users that install malicious software because some web popup told them to.
How about dumb users that suffer from 0-day exploits in their up-to-date OS ? I doubt they'll be happy if they are kicked off the internet for something they can do nothing about, and can only get back online after they've waited for a bugfix and reinstalled their entire machine.
Re: (Score:2)
How about dumb users that suffer from 0-day exploits in their up-to-date OS ? I doubt they'll be happy if they are kicked off the internet for something they can do nothing about, and can only get back online after they've waited for a bugfix and reinstalled their entire machine.
Talk about out of context!
I proposed two solution that could take out botnets that do NOT rely on either:
* completely eliminating both security flaws
* dumb users that install malicious software because some web popup told them to.
0-day exploits falls into the former. Yes, they'd get destroyed, alterered, or kicked off by their ISP in the proposed solutions. Tough luck, but if your computer is part of a botnet, it deserves to be kicked off (at the very least). Fix it and then ask to have your service re-esta
treat botnets like cancer (Score:3)
Treat it like cancer. If you can identify a single IP address, then the affected ISP should notify the ISP that owns the IP address to disable the connection of whatever computer was using it at the time. If the ISP refuses to comply in a timely manner then cut off all routing to and from that ISP network. Basically like what has been done to and from North Korea. And keep that network unreachable until a human negotiated settlement is reached. ISPs have the knowledge, resources and power to deal with
Re: (Score:2)
This has problems too. What if someone outside of your ISPs network fakes your IP? What if another computer inside your ISP network fakes your IP?
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Not all traffic
Re: (Score:2)
RFC 3514 (Score:5, Funny)
Widespread adoption of the security flag [ietf.org] should help quite a bit.
rfc2549 (Score:2)
There are related packet-protraction proposals [slashdot.org] that would help.
Re: (Score:2)
Re: (Score:2)
Social Problem (Score:5, Insightful)
The internet protocol is designed to treat unlimited amounts of unsolicited traffic identically to important traffic from real users
It's a packet-switched network, so for anything else to be true, somebody along the line somewhere has to make that decision. But only you can make that decision when it hits your gear (and you could prioritize there, at your expense).
What the Internet lacks is a reliable social scheme for managing problems. One could imagine a guild of operators and paths of trust where a member could send a signed shutdown message through the network to known-offenders, putting his reputation on the line with every such action, per the review of the end-connection provider.
But network engineers tend to not want to socialize with each other or extend trust. Protecting the downside at the expense of the upside is a very common human foible - it kept our ancestors from being eaten.
Much like MTU handling (Score:2)
Send some sort of ICMP message upstream that indicates your maximum capacity for handling traffic. It's a DOS vector in itself, but you could minimize it.
Re: (Score:2)
Indeed something along that line is what I think the Internet protocol needs. While IP is freely packet-switched and may appear stateless when you glance in the specs, TCP/IP routers and hosts are actually session-based internally and the number of concurrent sessions is limited.
It is not only intentionally malicious code that can cause denial of service: legitimate programs that are merely badly designed can also do it.
Then it is not the network and the other services running over it that should be punishe
Re: (Score:2)
Indeed something along that line is what I think the Internet protocol needs. While IP is freely packet-switched and may appear stateless when you glance in the specs, TCP/IP routers and hosts are actually session-based internally and the number of concurrent sessions is limited.
I feel like this is a trap.
You have a creepily low user id. So much so that you probably were around for the beginnings of IP network as a mass-market communications mechanism.
However, I would suggest that your contention that TCP/IP routers (generically speaking) are session based is incorrect. Particularly, this is incorrect with respect to the vast majority of the core internet routing and Layer 3 switching infrastructure as employed by ISPs and carriers. In order to achieve the massive traffic s
Re: (Score:3)
Almost. We need a way to tell upstream that we reject particular traffic, so don't send us any more of it. Getting a DDoS from X.X.X.X? Dear ISP, blackhole X.X.X.X for $TIME. ISPs should, in turn, do the same. It's complicated a bit because by nature a DDoS doesn't come from one IP, but many, and further IP spoofing, but I don't see how it can be fixed at the endpoint.
Re: (Score:2)
I'm not saying it's the begin-all, end-all solution. I'm just saying that until you have an AI algorithm that can discriminate legit traffic from illegit traffic, you're forced to use something that will, in effect, transfer your firewall rules upstream. It would have to be combined with other measures (monitoring point-of-origin networks, anycast, ISP application specific logic (eg. TCP traffic shaping of ISP client hosts' SMTP traffic)).
Re: (Score:2)
Re: (Score:2)
Huh - DDoS traffic looks like a virus signature now?! An IDS filters traffic based on (pre-distributed) rules. They look for virusses. DDoS traffic is legit traffic, but just too much of it. I don't see how you could stop a DDoS on a router by turning it into an IDS.
Re: (Score:2)
Because it is the Same (Score:2)
Re:Because it is the Same (Score:4, Interesting)
The ISP are already doing deep packet inspections to throttle traffic. Why don't they use dpi to monitor botnet attacks and filter those? Even if they do it like av and patch afterwards. You can limit older botnets at least
Comment removed (Score:4, Funny)
The "NO CARRIER" joke (Score:5, Informative)
ET$)##515E@[NO CARRIER]
For the younger /. readers out there: this is an old joke that dates back to the days when we used to have to use actual telephone modems to connect to the Internet.
Noise on a phone line could produce garbage characters, and if you weren't using an error-correcting protocol the garbage could show up as if you had typed it. If you were using a "dumb terminal" directly with a modem, whatever the modem received would be printed. And, a modem might actually return the string [NO CARRIER] to your terminal when a connection dropped. (If you were using a computer and an Internet routing protocol like SLIP or PPP, the checksums would be unlikely to be correct in the face of the garbage. Neither the "line noise" garbage characters nor the [NO CARRIER] string would appear in that case.)
So, this joke implies a catastrophic event that first causes noise on the line and then disconnects the line. Now you know, and knowing is half the battle!
P.S. Any resemblance of the "line noise" string to Perl code is purely a coincidence.
Re:The "NO CARRIER" joke (Score:5, Funny)
I ran
ET$)##515E@[NO CARRIER]
though perl and it installed Ubuntu 14.04.
Weird.
Re: (Score:2)
+3 Informative at the moment. Now I feel old.
ISP idiocy (Score:5, Interesting)
So I attended a local security talk a couple of months back and there I asked a security expert from my ISP (Telenor - Norway) if they blocked outgoing packets with source IP address differing from the real sender address.
"No" he said.
WTF? I am sure there is some legitimate reason for being able to send such a packet, but I can't think of any, and the contract should be amended to say "no spoofed source address unless agreed upon".
Sending spoof packets should make the ISP auto-throttle them if not just black-hole.
Re: (Score:3)
I can't think of a single good reason why spoofed packets should be allowed out at all. I would say they should filter them by default. IF someone comes up with an actual good reason they need to send such packets, perhaps it could be considered on a case by case basis but I really doubt any such exception requests will prove reasonable.
Note that in dual homing it might be reasonable to send packets out with source addresses from a particular range not assigned by the ISP but that range can be validated and
Re: (Score:2)
I can't think of a single good reason why spoofed packets should be allowed out at all.
It takes CPU resources to filter them out.
Re: (Score:2)
Re: (Score:2)
Not a lot if it's done with bitmasks. Many ISPs do egress filtering already. The rest should.
nuke it from orbit. (Score:3)
If I were an attacker (Score:3, Interesting)
If I were an attacker looking to design the next generation of sophisticated DDoS attacks, the first thing I'd do is post a question to SlashDot asking about the next generation of defenses.
Here's One Idea: (Score:5, Interesting)
Routers all maintain a reasonably sized set of source/destination/timer triplets. If a packet comes in from 'source' and is headed to 'destination', drop it. When 'timer' expires, drop that rule.
A special new "Add rule 'source,destination,timer'' packet is added, to be sent to a router. This causes the router to initiate a 3-way handshake with 'destination' to confirm that they requested the new rule, and if so, they add the rule to their table and set the expiration timer.
The idea is simple: If you're being DDoS'd, you don't have much bandwidth, but you always have bandwidth available between you and the first router, so you can always send them special packets telling the first hop router to drop all packets that you suppose are malicious, with a small timer so that you can renew it. After that's done, you should have eased the traffic enough to send more table-update packets to the second hop routers, and then to the third hop routers, and so on, until you've pushed the 'timed reject rule' right back up the traceroute chain until its at the source's doorstep and can go no further. At that point, not only are you free from the DDoS, the routers themselves no longer have to handle the traffic, either, as you've cut it off very near to the source.
The rule expiration timer makes it so that you need to actively maintain the rules or they'll disappear, and furthermore, it makes it so that when the DDoS stops, normal traffic can resume just fine. You can always 'peek' to see if the DDoS is ongoing by letting a few timers expire and watching to see if the malicious traffic is still coming through. If it is, update the rules and block it for some more time.
Re: (Score:2)
A special new "Add rule 'source,destination,timer'' packet is added, to be sent to a router. This causes the router to initiate a 3-way handshake with 'destination' to confirm that they requested the new rule, and if so, they add the rule to their table and set the expiration timer.
How would you prevent malicious use of the "do not send to the source/destination" packets?
Re:Here's One Idea: (Score:5, Informative)
Unfortunately all this will accomplish is that you will lock yourself out of legitimate sites, because a lot of the DDOSing out there uses spoofed IP addresses. So now all the DDOSer has to do is spoof, say, google.com's primary IPs and you lock yourself out of google when you block the IPs.
Until network providers start validating source IPs from their non-transit customers and require their transit customers to validate source IPs for non-transit packets, there's basically no solution that will work.
-Matt
Re: (Score:2)
Already implemented with routing protocols. Take a look at e.g. https://tools.ietf.org/html/rf... [ietf.org]. Of course, not every small shop has expertise to set up BGP peering with their ISP, nor do the ISPs provide the service..
Re: (Score:2)
It's actually a pretty good idea.
Some proprietary (ISP specific) implementations of similar mechanisms actually exist.
There are numerous ways that you (as ISP) can expose, to your above-average-network-engineering-capabilities-wielding downstream client, a mechanism by which you allow this downstream client to edit an egress filter rule-set on IP traffic headed toward same said downstream client.
I have had such an arrangement with ISPs whereby I can insert a groomed config snippet into my providers' edge
Seem it would be easy to identify on the ISP side (Score:2)
How about a capability limit? Should be pretty obvious when suddenly an IP address starts getting hit with a lot of traffic. I would think that you could use the data of what the regular traffic is, and when it suddenly spikes by 1000x then you know an attack is on the way. So why couldn't an ISP, who is sending the packets to the server, slow it down when suddenly your getting a way higher number of packets to this server?
That isn't neutral (Score:3, Interesting)
NASA solved this problem. (Score:3, Interesting)
The problem is that the Internet is Distributed, but websites are Centralized. The brilliant folks who designed the Internet accidently let morons design the web atop it. The way the web is currently hosted is a stupid idea, and that's the real problem: Storage is not decentralized.
The solution has been dubbed Disruption Tolerant Networking. There's no reason my neighbor shouldn't be pulling the cute cat video I linked them to from my own damn browser cache. When you think about it, caching services and co-location is a form of distributed data storage, so let's cut out the middle man and do this shit right: Every node needs to be a cache too, including the endpoints.
Essentially, to fix the problem you can just run HTTP over a distributed system like Bittorrent, but with better higherarchical caching to maintain locality where applicable. The more traffic, the more availability you get. Yes, you can leach, but in a properly system a ton of requests for the same resource
The problem is that if we do this then the NSA will not be able to spy on our traffic: There's no way to know that the resource I'm downloading is for me, it could be for my neighbor. You'd have to put snoopers between every single endpoint, at every switch. Currently they take data at places like Room 641A [wikipedia.org] (which was around before 9/11, so the warrantless spying wasn't a response to that).
If the Internet gets a proper distributed data store system built atop it, then mesh networking will happen. The powers that be REALLY don't want that to happen, that's why the FCC is so strict about limiting packet radio's use. HAM radio folks have been using store and forward for decades, and that's basically what we need. Hint: A single RF antenna has a natural one-to-many broadcast property that a single CAT6 cable does not.
So, the answer is: YES, there is a solution, but NO you can not have it...yet. I've had nothing but some pretty scary blowback from my own attempts to fix this fucking obvious problem: Hurrr, let's put centralized data silohs atop a distributed network, Durr. Fucking idiots!
If we want to progress as a species and have nice things like DDoS free networks for off-planet colonies' Space Internet (DTN takes into account problems caused by lightspeed limitations) then we'll have to get over the fear of the populace being able to control its government and just roll out something like HTTP/BT.
There are things like Freenet, but they're not built for speed they're built for anonymity, which was a dumb move. If only they would have built that network for speed and had an anonymity option, then it would actually be worth a damn.
Simple Linux (Score:2)
Look, its 2014, if the best your machine can handle is DOS its just time to upgrade, the hardware. If it is already newer hardware than say 1996, then upgrade to linux.
I know we all loved doctor dos back in the day but its time to give it up already, but by the same token, anyone still using it has to qualify as a senior citizen themselves....they are not a problem just leave them alone ffs!
Re: (Score:2)
Not only that, but we're talking about DDOS, not just DOS.
So these people are probably maintaining large beowulf clusters of XTs and ATs, Even if Linux can be installed on them, it's still a non-trivial effort simply because of the number of machines involved.
Logistics is the name of the game.
Re: (Score:2)
but in the end you just can't expect to reason with the guy who is still rescuing the thin-net terminators from the scrap heap. Just give him your old token ring port activator and wish him a happy new year.
Helpful steps (Score:2)
Global Cops (Score:2)
We need the global equivalent of a police force. We no longer live in a world divided by borders. We need an elected (not appointed) global government, with global laws, and with a world police force that can go after people whose crimes cross international boundaries.
OK.. now tell me one reason why this is a really bad idea. And then tell me how you would address that specific problem.
Re: (Score:2)
It seems like a bad idea because it would result in a tyranny of the majority.
Just trying to pick some things that aren't super controversial as an example here, (since bringing up religion or Israel/Palestine is going to derail this thought experiment): properly elected representative world government would probably vote to ban pornography, or marijuana, and I don't want this.
Both of these things are very much legal where I live.
You could address it by writing a well thought out and intellectual world co
Solutions exist (Score:2)
Multi-domains housed website (Score:2)
The Primary Discipline (Score:2)
If the services being attacked are distributed then the distributed attacks are less likely to be effective as there are fewer choke-points.
From a Viewdata Corp of America [slashdot.org] proprietary white paper: "Rational and Overview of Requirements for a Videotex Local Programming Capability" by Jim Bowery circa 1982, section "The Primary Discipline":
Nope (Score:2)
Why would anyone want to fix the problem?
DDOS mitigation services make money. DDOS attack services make money. The people who are targets are not going to do anything other than pay someone to help them stay on the air.
There is not even enough interest to take even reasonable and relatively trivial steps to fix DNS (draft-eastlake-dnsext-cookies-05) instead full steam ahead with DNSSEC we don't care about consequences.
BCP38 adds little additional value should the few broken protocols deployed in sufficien
Re: (Score:2)
The problem will always be has always been people. The trouble is somebody somewhere is malicious and lots of people all over the place are rubes. That is it in a nutshell. We don't see the big drive-by-malware and worms of the past very often anymore. The fact is most of the time someone has to run a trojan and often someone has to run a torjan with privileges.
Your real options are,
1) Take general use, user programmable computers away from most folks and give them iPad like devices that only run signed
Distributed denial of service... (Score:2)
...can only be defeated by distributed service. If your service comes from everywhere, then it's a zero sum game, and the attackers will give up.
Other acceptable answers include:
Take away the incentive... why are DDos's happening in the first place? Fame? Money? LOLz? Maybe you can't take away that third one.
Re: (Score:2)
this wouldn't stop infecting computers acting as botnets, but there's no single solution to fix it all, so egress filtering like this would help massively.
So - how do we persuade ISPs to stop allowing spoofed packets leaving their networks? What can we do to either hurt their marketing or force them to implement this?
Re: (Score:2)
Most network providers (about 80% of the Internet) do this on the other end, doing ingress filtering. There should be little functional difference between an ISP refusing to let spoofed packets leave their network, versus an ISP refusing to let spoofed packets enter it, if the two ISPs in question were directly connected.
Re: (Score:2)
So you think we could change human nature in a couple decades? I don't think we could do it in centuries. Kids love to draw on the wall, even when you tell them not to and they grow out of that phase if given the right environment, but I defy you to find any city of more than a 500 people which has never had any graffiti. It is a basic human impulse to try to make an impact on your surroundings and so long as there is an internet, someone will want to make an impact on it in ways that are not that different
Re:Carriers (Score:5, Informative)
Re:Carriers (Score:4, Insightful)
Re:Carriers (Score:5, Interesting)
Wrong answer. What can the carrier do to block the sending of DDoS, not keep up customers being DDoS'd? Customers participating in DDoS attacks should be disconnected. Anything else is negligence by the carriers. But ISPs make more money leaving them on and defending from attacks, rather than stopping the attacks. It's criminal, and should be treated as such.
If only it were as easy. DDoS attacks come from botnets. Botnets don't come from somewhere, they come from *everywhere*. If they played the "cut off the offenders" game they would need one hell of a huge IP-level blacklist, or they would cut off literally every link they had since compromised hosts are everywhere. If you are going to say "just force the end ISP to disconnect them" then again it's amazingly complicated since an ISP in Georgia (the country) isn't going to listen to some twat in the UK or US complain about a certain group of hosts that are participating in a DDoS, just like ISPs in those countries wouldn't listen to some ahole in Georgia complain about a DDoS host since he might just want to take it offline for political reasons and there isn't nearly enough international cooperation to keep up good relationships between all the concerned parties. Moving up a tier, there is too much good traffic coming from any given ISP to simply write it off as blocking the whole thing.
Re: (Score:2)
Re: (Score:3)
And they are not going to. A sizable percentage of an ISPs customers have some kind of bot on it. Since almost everyone these days has a NAT router if one computer out of ten has a bot on it, the entire network goes down. Customers get pissed. Bills don't get paid. Long arguments with tech support over who's problem it is. Some of these bots are wireless clients that move around too.
Or, they can do what they are doing now and neglect the problem. My money is on the continued neglect except in the worst of c
Re: (Score:3)
Re: (Score:3)
A compromised system that is operating without the knowledge of its owner does not constitute malicious activity. Malicious activity, by its very definition, is intentional.
So the Botnet owner isn't doing anything malicious when they perform a DDoS? Again, I think your logic is contrived and quite stupid, trying to defend negligent users who are financing attacks.
I said that the DDoS is malicious activity, and the connection is linked to that, and thus can be shut down. You are disagreeing. That makes you dumb or a liar. Which is it?
It amazes me how many people defend compromised computers and those performing DDoSs.
Re: (Score:3)
It occurs to me that reading comprehension may not be your strong suit. I have yet to see a single comment here that defends compromised computers or DDoS.
You said that the connection participating in a DDoS isn't engaged in a malicious activity. I count that as defense of the compromised computers.The issue of malicious intent has nothing whatsoever to do with the botnet operator and everything to do with the owner of the compromised computer(s)/network.
Ah, it's you who can't read. I said "malicious activity" not "malicious intent" The computer is doing something malicious, even if the user didn't explicitly perform the act.
That said, there ARE ramifications of simply turning off the tap that are not so simply dealt with as you seem to wish were the case. Were it so easy and legally simple, it already would not be an issue, IMO.
It's already a violation of ToS, so shut them off. If that's a problem, change a law to make it no longer a problem.
Re: (Score:3)
This is getting to become a circular argument, and I'm in no mood to argue. I cannot be more clear: One cannot simply 'pull the plug' on a network that provides service without opening up a complex can of legal worms. There's absolutely _zero_ doubt that DDoS activity is malicious by nature and intent by the botnet operator. There's absolutely _zero_ doubt that pulling the plug would help mitigate the damage to systems on the receiving end of attacks from such compromised systems/network. The fundamental pr
Re: (Score:3)
It's very economical.
Re: (Score:3)
I think that's exactly why it's necessary. Most ISPs take very little notice of an obviously infected customer's machine, unless of course it's trying to pour its spam through their SMTP server. Then they immediately get their panties in a twist and pull your plug until you clean up your machine.
The difference here of course being who is the vi
Re: (Score:3)
Yep. Canada has some weird rules. For example, if you have servers in a rack and the feds want to do a search and seizure a la US style, not gonna happen. If the servers are essential for the running of your business, the most the feds can do is to copy all the relevant data. They can't actually seize the servers lest it causes your business damage.
It's actually a pretty good law in that it respects the ideal of innocent until proven guilty beyond reasonable doubt. In other countries, they can just take you
Re: (Score:2)
That's great! Why don't you go convince every single carrier in the world to do this!
Meanwhile we will use real world solutions. Let us know when you are done, then we can stop using those services.
Re: (Score:2)
Re: (Score:2)
Great! Then it shouldn't be no problem for you. If you read my post you would know I support you and applaud your effort!
Why don't you switch them all over to IPv6 while you're at it?
Digital Signing (Score:2)
I don't know if the carriers are implementing anything, which is really where this would have to happen.
Mmmm... just spitballing, there are two things that come to mind: (1) create a more asymmetric internet or (2) significantly reduce anonymity.
If you route machines with major penalties for any connections outside of machines they have connected to in the past week or month, for example, or if you require ISP-level configuration for peer-to-peer (at least logging into your ISP's web site to enable it), you could begin to reduce the usefulness of DDoS. On the anonymity side, you can strongly prefer authentic
Re: (Score:3, Interesting)
If you want to find the source, you need to find the profit center. This stuff isn't being done for free. A real investigation will lead to a place that most people will find most unappealing.
And jail? Please! This fetish with imprisonment needs to stop.
And we don't want ISPs filtering anything. It only provides pretext for filtering everything. They are supposed to be a dumb pipe. Let the end points do the filtering.
Re: (Score:2)
It's not a matter of cost, it's a matter of coming up with a design that would actually eliminate DDOS. I'm fairly convinced it can't be done. Fundamentally, a DDOS looks like a bunch of legitimate service requests made to a server whose purpose is to answer the requests. Essentially, a DDOS is the death by a thousand cuts. No particular source of the DDOS packets individually looks like a problem.
Consider a web server. How can you decide that this page request is from a legitimate user viewing the page but
Re: (Score:2)
Unsecured http probably can't be saved because of it's design. But persistent connections should be easier to protect because the legitimate connections are distinguishable.
Presumably xbox and playstation use some kind of persistent connection. If not, they should.
Re: (Score:2)
It doesn't much matter if your odds of connecting in the first place are thousands to one against.
If you do something like penalizing packets with the syn flag set, the ddos guys will just flood with RST packets or data packets that look like they're part of a stream, or switch to UDP.
Remember, by the time the packets get to a router you control to tailor the rules, it's too late. Your uplink is flooded. So, any rules that might be applied have to work well for everyone out there.
Re: (Score:3)
Wrong target. Hunt down and kill the people that run the botnets. Publicly. Grotesquely.
Re: (Score:2)
Your post should be bookmarked by all of Slashdot to use as an actual example of a slippery slope.
how severe are they, should they be? (Score:2)
>. The penalties exacted for actually being the party behind a massive DDoS (when it can be proven objectively and conclusively) are not currently nearly severe enough.
What are the penalties now, and what do you think they should be?