Slashdot Mirror


Ask Slashdot: What Should We Do About the DDoS Problem?

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?

44 of 312 comments (clear)

  1. BCP38 by falzbro · · Score: 5, Informative

    https://tools.ietf.org/html/bcp38

    1. Re:BCP38 by sigmabody · · Score: 2

      Came here to say this, saw it was already stated. Simple, easy, and straightforward... at least the tech part. Make the top-level backbone ISP's reject traffic from any downstream ISP's which don't implement BCP38, and the problem would be gone in a week or less.

    2. Re:BCP38 by Guspaz · · Score: 2

      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.

    3. Re:BCP38 by PlainWhiteTrash · · Score: 5, Insightful

      BCP38 is a fantastic idea. Being in a position in which I serve as a consultant to many indie-ISPs' network administrators on a frequent basis, I strongly encourage sane enforcement of source IP data at ingress-toward-the-ISP from customer-facing links. Many of my clients implement this. The trouble is, it doesn't help with many modern DDoS's. It certainly helps with the common traffic-amplification attack types, but many distributed bot-net based attacks now directly the target service by impersonation of legitimate client implementations. This will do nothing for those. The server side will see the many thousands or more of IPs that are attacking them, and see them correctly, but the trouble is, there are way too many to manage and they look like legit clients. Complicating things, it's likely that many of the infected machines ARE also LEGIT customers / clients. Implementing BCP38 is and will remain a good thing. But as DDoS strategies evolve, and upload speeds on consumer links increase in terms of throughput, this strategy not be a long term solution to many categories of DDoS.

    4. Re:BCP38 by Zocalo · · Score: 4, Informative

      If I read the GP's post correctly they were not suggesting that the backbone ISPs implement BCP38, but that they don't peer with edge ISPs that don't implement it.

      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.

      --
      UNIX? They're not even circumcised! Savages!
    5. Re:BCP38 by craigm4980 · · 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 practical, but I do think it is technically possible (costs and performance aside).

      Note that other limited bandwidth fair delivery systems (email, physical mail, Tor hidden services etc) all have the same set of problems.

      Given that you can purchase DoS (distributed or not), there is the question on if enabling this (or doing it) is illegal. The legal solution either doesn't work, or bans proxies like Tor. Thus I don't consider it a valid solution.

      There is also the approach of changing service models: some services can operate by simply publishing messages (DNS is an example, but so are news sites without user interaction). These don't have to depend on the packet switched network directly, and can use distributed content based models, like Freenet that get around the problem of having to host your own stuff. I don't see how this can generalize too well (there's lots of overhead and latency), but Bitmessage is an interesting example of using publication + encryption for private messaging.

      Also there are cost and payment based approaches: suppose I had to pay the cost of delivering and processing my packet to send it to you, or provide some significant proof of work. Ripple does this but that's just one example. I'm not aware of ideas for how to scale this to IP scales (the stateless packet based nature makes it really hard). I think Skycoin is trying, but they aren't far enough along convince me it's possible.

      Now for my crazy ideas: Suppose we could deploy a system for pay for processing to establish a session with the service, and after that we could continue to the the session, and perhaps resume it long into the future (ex: you get a shared secret or a private key, and put it in a cookie). Once authenticated, you could then use a network that only allows solicited traffic. This is possible: for example once connected to a Tor hidden service, you have a route to it which can be closed off if you abuse it, but other people are unable to flood the route, and the service could stop accepting new routes leaving your existing connections safe from DDoS. Tor hidden services don't have an DDoS resistant way to "sell" routes/sessions, but that could be fixed (Send bitcoins to proper address, and the details you need will be published encrypted with your public key. Of course the bitcoin network has DDoS problems of its own, but lets not recurse here, assume you have something to fill that role that is DDoS resistant, maybe like Ripple?).

      So we have a proposed design that solves this problem for Tor hidden services. We should now be able to exploit the homomorphisms here and fix and the internet (IP) and email (left as exercise for the reader, but I recommend adding a key selling scheme to Pond if you care about privacy, because screw plain text email). So focusing on the internet, if you then had a system where only people owning valid sessions could transmit to the service (at some other IP or set of IPs) enforced at entry to the internet (ISP level I guess), then you have a setup where DDoS can't effect existing users which is a huge win, and if you make get an auth system to be DDoS resistant (needs some payment or proof of work setup) then it's pretty much DDoS resistant.

      So how can we filter traffic based on permission/keys/session to particular addresses? We could allocate some massive block of IPv6 address

  2. you need to kill the botnets by new+death+barbie · · 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.

    --

    It's supposed to be completely automatic, but actually you have to press this button.

    1. Re:you need to kill the botnets by itzly · · Score: 2

      The next question becomes then: how do you kill the botnets, especially since the malware is only getting more and more sophisticated ?

    2. Re:you need to kill the botnets by kdub007 · · Score: 4, Interesting

      You can only kill the malware that is behind these DDoS's by completely eliminating security flaws in software. That is not reasonable to expect. Hell, even the NCC-1701-D (Starship Enterprise) got viruses. If they can't even fix this problem by the 24th century, I don't see how we can expect to fix it now. As long as there are people looking for exploits, the problem will exist.

      --
      The correct answer is 42.
    3. Re:you need to kill the botnets by kdub007 · · Score: 2

      Please... Macs get viruses. For *NIX folks...ever heard of Shellshock? Blaming Windows Users is ignorant. That said, Microsoft has a long road ahead before Windows becomes hardened.

      --
      The correct answer is 42.
    4. Re:you need to kill the botnets by Anonymous Coward · · 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.

    5. Re:you need to kill the botnets by plover · · Score: 2

      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 always be a security vulnerability. Either they have to outsource their trust (digital signatures on programs, antivirus programs, etc) or there needs to be a new way to compartmentalize and isolate authentication and authorization.

      --
      John
  3. RFC 3514 by Anonymous Coward · · Score: 5, Funny

    Widespread adoption of the security flag should help quite a bit.

  4. Social Problem by bill_mcgonigle · · 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.

    --
    My God, it's Full of Source!
    OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
  5. a simple, academic solution. by nimbius · · Score: 3, Funny

    Im a full-time computer science researcher and its not mentioned often, but the only real way to stop a DDoS is toET$)##515E@[NO CARRIER]

    --
    Good people go to bed earlier.
  6. ISP idiocy by NorthWay · · 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.

    1. Re:ISP idiocy by sjames · · Score: 2

      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 configured.

  7. Re:Because it is the Same by peragrin · · Score: 3, 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

    --
    i thought once I was found, but it was only a dream.
  8. nuke it from orbit. by confused+one · · Score: 2

    It's the only way to be sure.

  9. If I were an attacker by abelenky17 · · 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.

  10. Here's One Idea: by sea4ever · · Score: 5, Interesting

    I've actually thought about this and come up with the following TCP extension:

    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.

    1. Re:Here's One Idea: by PlainWhiteTrash · · 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 routers facing the links to my network via a simple authenticated http call.

      This is actually a useful technique as long as you're not target of a really massive attack.

      There have to be limits or you run out of router / switch filtering resources or CPU resources (depending on the implementation). If we ignore or resolve those limitations, this works if you have a significant but not massively adopted solution on offer. Where it fails is the point where the traffic trying to get to you is no longer just congesting the links that carry traffic from your ISP to you, but rather now that traffic is so massive that it congests your ISPs upstreams' links into your ISP. It's impractical to have the core backbone maintain these filters, as the size would create a new kind of scale limit in the network. Thus, you're now denied service by way of congesting your ISPs upstream links rather than your ISPs links to you.

    2. Re:Here's One Idea: by m.dillon · · Score: 4, 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

  11. Re:Much like MTU handling by SecurityGuy · · Score: 2

    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.

  12. Re:Carriers by lavaboy · · Score: 5, Informative

    I work for a carrier. Together with companies like Arbor Networks, we already have systems in place that can mitigate most volumetric attacks, and many more intelligent attacks. Unfortunately, it's not cheap. Customers have to be willing to implement (and pay for) the protection services that most serious ISPs already offer as options on their IP traffic products. Keywords for your search are Pravail and PeakFlow.

    --
    Steve -- If you have to call it a system, you don't know what it is.
  13. That isn't neutral by jbmartin6 · · Score: 2, Interesting

    Any solution would violate net neutrality.

    --
    This posting is provided 'AS IS' without warranty of any kind, implied or otherwise.
  14. Re:Two things by NEDHead · · Score: 2

    Wrong target. Hunt down and kill the people that run the botnets. Publicly. Grotesquely.

  15. Re:Much like MTU handling by PlainWhiteTrash · · 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 scale that these devices handle, they mostly are stateless forwarders unconcerned with the higher level protocols above IP and unconcerned with maintaining session / state information on the traffic flows through the router/switch. This allows the hardware's specialized ASICs to forward the packets without having to retain any history of "sessions" or spend precious CPU time matching each packet to a session.

  16. The "NO CARRIER" joke by Anonymous Coward · · 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.

    1. Re:The "NO CARRIER" joke by derfy · · Score: 5, Funny

      I ran
      ET$)##515E@[NO CARRIER]
      though perl and it installed Ubuntu 14.04.
      Weird.

  17. NASA solved this problem. by Anonymous Coward · · 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 (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.

  18. treat botnets like cancer by bigpat · · Score: 2

    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 botnets, that they would choose not to manage the problem effectively is a business decision and not a technical one.

    1. Re:treat botnets like cancer by bigpat · · Score: 2

      That is why it has to be the ISPs looking at the packets. We are talking about denial of service type attacks, mostly, so there are going to be plenty of packets to do a proper trace. They can trace the IP spoofed packets routing within their networks and they can see what outside network they are actually coming from. And if the end result is going to be disconnecting from that outside network if the partner ISP doesn't effectively deal with the problem computers then that should be sufficient incentive for that other network operator to trace the packets back to their real origination. If you have cooperation between the ISPs then you shouldn't have a problem locating problem computers. And if you don't have at least this basic level of cooperation then you shouldn't be connecting to their network in the first place. Spoofing should be a simple matter of egress filtering anyway. If you ensure that all outbound packets are actually coming from IP addresses on your network, then that should stop these kinds of attacks originating from your network.

  19. Re:Carriers by AK+Marc · · Score: 3, Insightful

    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.

  20. Re:Carriers by jeffmeden · · Score: 4, 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.

  21. Re:Carriers by fustakrakich · · 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.

    --
    “He’s not deformed, he’s just drunk!”
  22. Re:Carriers by PlusFiveTroll · · Score: 2

    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 cases.

  23. Re:Carriers by AK+Marc · · Score: 2

    Most contracts will allow termination of service for malicious activity.

  24. Re:Laws, yeah, right by AK+Marc · · Score: 2

    I have worked for 5 ISPs in the past 15 years. Every one of them had DPI. They all expect laws like this and have things in place for when they do. Sure, the backbone providers with no consumer connections don't bother, but (almost) every ISP that sells consumer connections does have them today. The expense is $0.

    It's very economical.

  25. Re:Carriers by AK+Marc · · Score: 2

    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.

  26. Re:Carriers by v1 · · Score: 2

    It's trivial to cut off service, yes, but if an ISP and upstream providers to cut off all offending networks from access, the internet would pretty much go silent.

    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 victim. You or me? Not gonna bother. US? Red Alert Ban Hammer Time!

    So, your upstream pulling (or threatening to pull) your plug is precisely what's needed to motivate those ISPs. Some are lazy. Most are just too cheap to invest in fixing the problem and would rather bank the dollars than spend them to fix "someone else's problem". Make it their problem. Light a fire under their seat and watch them redirect a processes they already have in place, to fix the problem.

    --
    I work for the Department of Redundancy Department.
  27. Re:Carriers by AK+Marc · · Score: 2

    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.

  28. Re:Carriers by Trane+Francks · · Score: 2

    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 problem, however, is that one does not merrily obstruct a business's capacity to DO business without incurring legal ramifications (dependent upon the jurisdiction in which the service is being hosted/operated).

    It is what it is, Mark. It's a simple problem with a veritable rat's nest of legal implications to solve.

    Happy New Year to you, sire. :)

    --
    ...a FreeDOS contributor: http://www.freedos.org/
  29. Re:Carriers by Trane+Francks · · Score: 2

    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 your crap and if you go out of business because of it - even if you're totally innocent - well, that's just tough luck, innit?

    --
    ...a FreeDOS contributor: http://www.freedos.org/