Slashdot is powered by your submissions, so send in your scoop


Forgot your password?

Ask Slashdot: Experience Handling DDoS Attacks On a Mid-Tier Site? 197

New submitter caboosesw writes "A customer of mine recently was hit by a quick and massive DDoS attack. As we were in the middle of things, we learned that there are proxy services of varying maturity to deal with these kinds of outbreaks from the small and mysterious (DOSArrest, ServerOrigin, BlackLotus, DDOSProtection, CloudFlare, etc.) to the large and mature (Prolexic, Verisign, etc.) Have you guys used any of these services? Especially on the lower price point that a small e-commerce (not pr0n or gambling) company could afford? Is a DDoS service really mandatory as Gartner now puts this type of service in the same tier as SEIM, firewalls, IPS, etc?"
This discussion has been archived. No new comments can be posted.

Ask Slashdot: Experience Handling DDoS Attacks On a Mid-Tier Site?

Comments Filter:
  • by LostCluster ( 625375 ) * on Monday April 09, 2012 @08:02PM (#39625325)

    There's two key strategies to avoid being DDoSed... first, have more processor, network speed, and disk I/O resources than you need for normal load so that the attacker can't fill one of your computers pipes. Then, host your server or servers at multi-connected datacenters which can cut off large users of your server before it reaches your NIC card. Firewalls at the server can't get back the bandwidth lost to needless connections, but firewalls at the datacenter entry points can. Basically, make sure none of your time-sensitive loads reach 100% and you're fine.

    • Basically, make sure none of your time-sensitive loads reach 100% and you're fine

      As long as the people running the datacenter aren't metering the noise that hits the interface set up to catch your traffic, whether or not they pass it along to your server. If you're burning up their resources, somebody's got to pay the pipe(r).

    • by TWX ( 665546 ) on Monday April 09, 2012 @08:13PM (#39625427)
      You forgot a key third strategy- not posting one's dilemma and site to a popular geek news and discussion forum. At least this submitter was smart enough to not post his URL, so he hasn't gotten slashdotted...
    • So basically, surviving a DDoS is nothing more than a brute force battle of attrition where the goal is to have more resources than the other guy can take down.

      • by Minupla ( 62455 ) <> on Monday April 09, 2012 @11:16PM (#39626771) Homepage Journal

        Typically, yes (assuming your OS platform of choice doesn't have some other resource that can be remotely exhausted more cheaply then bandwidth). The problem is one of the standard defender delimas: The attacker needs bandwidth for a short period of time (typically), as their goal is to make you say "Uncle" weather that means paying their ransom, capitulating to some demand or whatever. You as a defender have to incur a cost for your defensive strategy that is either (relatively) low, non-scalable, and continuing (trying to out provision the attacker) or a high cost outsourcing solution. The attacker on the other hand rents 10,000 nodes for 200$/day. Figure that's about 5gigs conservatively (we'll say .5mbit upload as an average per node). Now assuming your data center will handle a sudden 5gig burst without cutting you off (good ones will, cheap ones will just cut you off) your hosting bill just went up by 54TB (5*3600*24/8) per day. That's not going to be sustainable for long.

        That's why the outsourcing solution tends to be the way to go if you're being targeted by anyone willing to spend halfway decent money on attacking you. The ROI from the attacker POV looks pretty good. Say they ransom you for 50K (an average number for such things). If they have to keep you under DDOS for even a week till you cave, (378 TB worth of data) that nets them 48600. That's a pretty good business case from their point of view.

        It's one of those moments when it sucks to be the good guys.


        • This is the first time I've heard of demands for ransom. I suppose it shouldn't be a surprise that's the motive, and come to think of it, it shouldn't be a surprise that corporations aren't eager to admit to having been extorted.

    • Basically, make sure none of your time-sensitive loads reach 100% and you're fine.

      We did that, and then attackers started to flood us with over 10gbit/s of traffic that just flooded the network link and basically forces us to null route the service.

  • by FireballX301 ( 766274 ) on Monday April 09, 2012 @08:10PM (#39625395) Journal
    The load balancer to take the brunt of the attack and distribute traffic to multiple mirrors, and the sysadmin to watch the attack and start blacklisting IP ranges. Your service provider should have some kind of service in place unless you got the cheapest of cheap hosting solutions.

    With that being said, hiring a third party ddos mitigator is entirely a cost benefit analysis that should be done on your end. Can whoever's providing your hosting now provision some extra servers and some harried sysadmins to keep you floating? See if you can ask for additional service support from your current provider.
    • by SethJohnson ( 112166 ) on Monday April 09, 2012 @08:23PM (#39625541) Homepage Journal

      watch the attack and start blacklisting IP ranges.

      In most cases, your customers are going to exist in one or a few countries. It would be valuable ahead of time to add redirect rules to your iptables for entire ranges of IP addresses located in countries that don't host your customers. Redirect these IP ranges to a sacrificial server on a different pipe to the backbone. That way, when some of your customers are abroad and need access to your services, they can still get some amount of response.

      Additionally, you can proactively parse your user accounts for IP addresses and build a whitelist ruleset for your iptables to implement in a defcon 0 situation. Don't use this as a normal operations mode, just when the shit has really hit the fan and you need to block everyone except your known-good account holders.


      • Redirect these IP ranges to a sacrificial server on a different pipe to the backbone.

        More appropriately, have your upstream provider(s) null route these address blocks before they get to your uplink.

    • by Snowhare ( 263311 ) on Monday April 09, 2012 @08:40PM (#39625717)

      Having been the target of an HTTP-DDOS attack, I can tell you that manually blacklisting IP ranges is really ineffective. A DDOS botnet is comprised of thousands of machines that have been randomly infected by whatever vector the botnet operator used: Emails, web drive-by, etc. The result is that the source addresses are scattered widely with little relation between most participating addresses.

      To defend against the attack, I wrote up an automatic firewall blacklisting program that detected and blocked each participating IP address individually in near-realtime. I was blocking more than 31,000 separate addresses before the DDOSers finally gave up trying to down the attacked website. Wierdly, there appears to have been no motive at all for the attack, yet they spent weeks attacking the target machine and actively trying to tune their attack to get past my filtering.

      • by Bert64 ( 520050 )

        Get multiple transit links...
        Advertise your range over the links to the locations where the vast majority of your customers come from, and then advertise everything else over a very slow backup link.
        Most sites cater to local customers, so have 10gb local peering and maybe 10mb international transit... Chances are most of the ddos drones won't be local, and so the attack will quickly destroy the 10mb link while your customers are happily using the 10gb peering.
        If there are ddos nodes local to you, the isps h

    • Load balancing is a given. Even to handle normal traffic you have to distribute it to your front ends somehow. But a sysadmin blacklisting IP address ranges? Oh my. You do not want this task to be done manually. A human, or a team of them, isn't going to be able to keep up with with a distributed attack, and they're going to make mistakes when determining which addresses to block. Remember that in a distributed attack they're not all coming from the same address and there's not much reason to expect them to

  • Lived Through This (Score:5, Interesting)

    by ScentCone ( 795499 ) on Monday April 09, 2012 @08:15PM (#39625459)
    It was a lot cheaper to pay a third party proxy a $400/month rate for 45 days (until the asshats attempting the extortion got bored and went away) than it wold have been to provision more server horsepower, pay for the bandwidth, and pay T&M for the DC's NOC to help with firewalling. A quick DNS change, use the credit card, hold your breath until it stops. Quick, cheap, and you can go on to other things.
    • by Spikeles ( 972972 ) on Monday April 09, 2012 @08:28PM (#39625599)
      Unless the third party proxy were the extortionists DDOSing you.
    • What was the name of the service you used?

      • by ScentCone ( 795499 ) on Monday April 09, 2012 @10:00PM (#39626315)
        For that event, we used Zen Networks. They're at, which describes their services pretty well. Not affiliated in any way, but they did solve the problem for us over the short stretch it was required. Honestly, we didn't shop around much ... the site in question was very much on fire. Not like a slashdotting, of course, but some fairly determined Eastern European punks looking for cash. They made my clients angry enough to have them asking, "Is there something we can do back to these guys?" We didn't, of course. Would have been a waste of time.
        • Yeah, been there. Luckily enough, the guys that tried it with us were incompetent, and we could filter their attack because of it, but always on the lookout in case the next ones that try it are a bit smarter.

    • It was a lot cheaper to pay a third party proxy ...

      How do you determine if the third party proxy has sufficient bandwidth to handle the DDoS + regular traffic?

      • by ScentCone ( 795499 ) on Monday April 09, 2012 @09:57PM (#39626285)

        How do you determine if the third party proxy has sufficient bandwidth to handle the DDoS + regular traffic?

        They have a performance guarantee, and don't get paid if they can't keep up at the promised level. Any of the ones you'll want to use will have a dashboard that shows you a more-or-less-real-time view of the blocks/passes, and how much of the purchased throughput you're using.

    • Definitely. For a mid size site, $400 a month is practically nothing. If you can make your DOS problems go away for that, do it.

    • by Bert64 ( 520050 )

      Not very competent asshats if they didnt notice the proxy setup, and simply continue hitting the original ip ranges...

      • We changed the real server's IP address (on a different block) and pointed the proxy there, after pointing DNS at the proxy. The original IP address stopped listening for anything. They did keep trying to hit it until they realized nothing was there.
  • I'm interested in this. I'm in the process of launching a real-money gambling MMORPG, and gambling sites (well, so I've been told) tend to get extorted. I spoke to Prolexic today and was shocked at how expensive they are: $3000/month minimum, plus setup fees.

    Have any fellow Slashdot readers tried running a gambling site without such protection? Is it reasonable to assume we'll be enough under-the-radar at first to avoid the attacks?
    • What Are The Odds (Score:5, Insightful)

      by sycodon ( 149926 ) on Monday April 09, 2012 @08:24PM (#39625551)

      That all these "services" are part of a protection racket?

      "Oh...having DDOS problems? Just sign up with our service and we can help you out."

        While not as crude as burning down building, DDOS attacks are a perfect persuader to grow your business.

      I figure this is half tin foil hat and half probably real, given the things organized crime has been into in the past. It's perfect actually, you don't have to hurt people, the attacks can't be traced and your "protection" can be fine tuned to avoid looking suspicious.

    • Re:Gambling (Score:4, Interesting)

      by Minupla ( 62455 ) <> on Monday April 09, 2012 @09:44PM (#39626179) Homepage Journal

      I used to run infosec for one of the mid-tier online gaming operations run out of the Caribbean. We got extorted by one of these gangs, and ended up paying Prolexic (they were Digidefense at the time) to solve this for us.

      As for weather you can risk doing without it depends strongly on what your user tolerance for downtime is and how bursty your revenue stream is. The lower the tolerance and/or the more bursty the revenue stream the more vulnerable you are to these sort of attack methodology, as the opposition pays for the time they are actually attacking you, so if you can weather the attack they'll eventually give it up. If on the other hand they can cost you significant sums of cash by taking you out for 6 hrs (say sports betting, target the opening day games), that increases your susceptibility to these attacks.

      Feel free to drop me a line if you have any more questions (my /. listed email will get to me).


  • by microTodd ( 240390 ) on Monday April 09, 2012 @08:19PM (#39625509) Homepage Journal

    Remember this really cool slashdot story about a sysadmin on the receiving end of a DDOS? []

    The original writeup link is dead but I found it here (warning: PDF). This was a really cool story. []

  • Misunderstanding (Score:5, Informative)

    by lanner ( 107308 ) on Monday April 09, 2012 @08:26PM (#39625581)

    The mere question of how to mitigate a DDOS indicates a fundamental lack of understanding of how IP networking and DDOS works.

    You (the ISP customer) have no ability to control what packets are sent to you over your uplink circuits. You can control what you send, but you have no ability to control what you receive.

    Read the sentence above. Repeat as necessary.

    Even if you knew with 100% certainty which packets were "bad" packets and which were "good" packets, if your uplink is saturated, dropping them on your edge router/firewall/whatever is 100% ineffective.

    The best mitigating strategy is that you need to have an agreement with your ISP and plan in place prior to an attack. Identify the hostile addresses, give them to your ISP, and they will null-route those sources either within their core or even at the edges of their networks to prevent entry. Your ISP has the capacity to mitigate a DDOS attack, you as the little customer do not.

    • by Anonymous Coward on Monday April 09, 2012 @08:49PM (#39625775)

      Even if you knew with 100% certainty which packets were "bad" packets and which were "good" packets, if your uplink is saturated, dropping them on your edge router/firewall/whatever is 100% ineffective.

      Your "best strategy" advice is very good, but it is not the "only strategy."

      As others have said, you can also have multiple entry points all sharing the same back end. Each of these entry points can be on their own hosting provider. In principle, you can arrange for the front-end/back-end connection at your front-end provider to NOT share a physical wire with the "public" side of your front-end, so if it gets hit hard it crowd out traffic going to/from the back end.

      Here's an example:

      I run I have servers at 3 sites around the country, 1.666.3.4 1.2.666.4, and

      For some reason, some mining company on Mars thinks I am evil so they keep DDOSing me.

      Hosting provider A is widely connected. I advertise 1.666.3.4 so all but one of A's pipes see direct connections. I use A's remaining pipe to connect back to my back-end. I work with A so the traffic to the back-end never shares a wire or router with incoming traffic. Bang on A's incoming pipes all you want, I'll still be able to talk to my back end unless you crash me entirely.

      I have similar arrangements with hosting providers B and C.

      I put my back end at hosting provider D and, just for grins, have a backup back end on hosting provider E that syncs up regularly with the back-end on D.

    • by Lando ( 9348 )

      Depends on the type of DDOS you are receiving. If it is a distributed DDOS then you can't do much other than having multiple pipes into the system; however, if there are not too many systems launching the ddos then you can have your provider drop those packets before they are sent down the pipe, ie you can determine what gets sent to you.

      For a distributed attack you can host a couple of gateways on a larger pipe that talk to a local backend. When I was handling mission critical stuff back in the day that

      • Re: (Score:3, Funny)

        by Anonymous Coward

        ...a distributed DDOS...

        Would that be a DDDOS? And what would you do if it were a distributed DDDOS? I bet you'd be totally hosed then.

        • by Lando ( 9348 )

                Good point. I guess my mind automatically equated DDOS with a DOS. I've called it DDOS so long that I didn't even think about what DDOS stood for. Thanks for the reference check.

      • by hhw ( 683423 )
        You can have a distributed DDoS protection service, where you BGP anycast the IP range being attacked to multiple cities, and deploy DDoS mitigation equipment to each of those locations. In the event that the attack is concentrated in one region, where your DDoS mitigation equipment is unable to keep up, you can then do a localized null route (that doesn't get advertised to the rest of your iBGP mesh), to drop the traffic for that particular region but still stay up for the rest of the world.
    • Re:Misunderstanding (Score:5, Interesting)

      by Zaelath ( 2588189 ) on Monday April 09, 2012 @09:10PM (#39625945)

      From our experience packet flooding attacks are rare, most are application layer attacks because they're cheaper:

      - If your landing page is dynamic chances are a small site can be choked at the database from a few hundred zombies, and it's much harder to detect the zombies from the genuine clients in a safe automated fashion
      - If you don't have a lot of CPU at your firewall layer you can't create long enough rule tables to stop the bad traffic as you detect it
      - Often you can simplify your rules but just starting by blocking China, Russia, Korea, then smaller countries that are hosting bots.

      If they are genuine flood attacks:

      The idea that your ISP will block a "list of addresses" is comical, it's not nearly responsive enough, and if you're lucky your ISP will agree to block countries and only if you have a business account which you're paying over the odds access fees for. Some will even null route YOUR IP instead of the attackers to save their own infrastructure: []

      ANDREW FOWLER: The Russian cyber attack was so sustained it backed up through Telstra's network, knocking out the whole of Alice Springs, part of Adelaide, and Telstra central in Sydney.

      DAN CRANE, FORMER TECHNOLOGY MANAGER, MULTIBET: And that's when they sort of started to panic a bit I think because all of a sudden it wasn't just a, you know run of the mill attack, this was a pretty hardcore attack because that's when it started, that's when it took out Alice Springs, that's when it degraded Adelaide and that's when it melted their routers in Sydney so that's when they said that's it, we don't want a bar of it.

      ANDREW FOWLER: According to Dan Crane, Telstra stopped accepting any of Multibet's internet traffic from entering Australia.

      Not to mention even creating this list is a continual task. Botnets rent out "so many connections", but the computers that are active at any time rotate in and out of the pool. We saw probably around 1000 computers at a time hitting the firewall, but from a pool of more like 100,000 addresses we discovered over the course of a week. We initially took a strategy of programmatically blocking individual IPs as they came in at a response rate of about 5 seconds with some scripting, but soon moved to blocking entire countries that we didn't do business with and doing some daily post processing of the IP list as well to consolidate IPs into /27s and sometimes as far as /24s

      Our last client to have this issue used Black Lotus and they seemed to do a good job for the price and be quite responsive, though they were still learning their trade at that time... I don't think they were terribly cheap. And botnets are much much cheaper, so unless you're lucky and it's someone that loses interest and not a competitor attacking you it can end up making your web hosting very expensive.

    • by mysidia ( 191772 )

      You (the ISP customer) have no ability to control what packets are sent to you over your uplink circuits. You can control what you send, but you have no ability to control what you receive.

      Yes you do have lots of potential control. It's just expensive to exercise. Because you have to have multiple datacenters and multiple uplink circuits, to have any control (without intentionally breaking connectivity).

      You buy transit and peer with major providers in different datacenters and anycast your server IP a

    • Re:Misunderstanding (Score:5, Informative)

      by Liquid-Gecka ( 319494 ) on Monday April 09, 2012 @09:50PM (#39626229)

      This is a bit of a naive explanation.

      Let me explain how a DDoS mitigation strategy works for many of the companies listed in the summary. They setup datacenters in 10, 15, or more places all hosting a proxy. Some of these solutions use DNS to route traffic around problems (GSLB) while others like CloudFlare use Anycast which is awesome and super hard to get right. Each of these services are typically setup with tons of bandwidth capacity, well over 10Gb, but often times into the 100Gb range. They also often have deals with upstream providers that can filter traffic at the edges meaning it never makes it onto the internet in the first place.

      Since you servers are not exposed to the internet, and the ones are are have far, far more horsepower to deal with this than a DDoS will even manage from the client side they can easily just churn through the attack, discarding connections and never letting them hit your limited servers. This is how they can easily survive Anonymous style DDoS attacks.

      The other thing is to ensure you have turned of every "feature" your load balancer is giving you. SSL termination at the LB, full session management, etc. All of these cost load balancer CPU which is easy to take advantage of, even if there is a DDoS mitigation system in front of your site. You can't just add a few more servers either. Adding capacity to a load balancer is nearly impossible to do mid-attack.

      Even more interesting is that you can often times trick the crappy ddos software by doing things like excessively slow responses (tarpitting) making its loop take ages to try again. This is pretty much using the tactics of a DDoS directly against the attackers.

      Another common tactic is to add attackers to a view in your bind config that resolves your hostname to just for them. This works if you do not have long TTLs and they are using hostnames. If they are using direct IPs then you simply move your traffic to a second IP and drop the one they are attacking. Best case is if you can do this via BGP announcements so the traffic simply will fail to route and everybody wins.

      And yes, I do this professionally but not for any commercial product.

    • by hhw ( 683423 )
      Null routes work on destination IPs only, not source IPs, so if one were to take your advice, they would effectively be doing the attackers' job for them. Null routes are for preventing a DoS attack from affecting other customers/services, not for keeping a server up and available during an attack. The only way to block source IPs on routers is with ACLs, but these are only effective against very simple DOS where a small number of sources are attacking you. For a large scale DDoS, with sources from several
  • by Minupla ( 62455 ) <> on Monday April 09, 2012 @09:11PM (#39625955) Homepage Journal

    I've lived through this (although in my case the twits doing it were holding us for ransom) Prolexic was the solution we went with and I endorse it. The economics of the situation strongly favor outsourcing to a third party. It's a service you'll likely need for a short period of time, provisioning it yourself would entail obtaining equipment and specialized expertise that you would have to commit to over a long period of time. A Prolexic can afford to obtain better equipment, and have specialized staff who can configure it to block the latest attack because they're dealing with it for clients constantly.


  • by Anonymous Coward on Monday April 09, 2012 @09:28PM (#39626065)

    Posting AC as I would prefer not to expose my employer in anyway.

    I went through this exact situation the week before last Thanksgiving last year. I work for a gifting retailer that makes all of its money in Q4. Not a good situation. We're a small - mid sized business with about $20 million in sales from our Ecommerce site.

    We went the cheap route first. The proxy service cost about $500/month and guaranteed 10 Mbps clean traffic to the site. Our DNS was changed swinging our domains to the proxy service and ACLs put in place on the "backend" to only allow connections from our new gateway in the proxy.

    Things were fine for about 24 hours when the attack was stepped up. The service was seeing 450 Mbps inbound to our main domain. That is not a mistake - 450 Mbps is easily attained using a botnet or simply focusing the attention of some lurkers on pastebin links. We now had to change DNS AGAIN to "upgrade" to their better platform that could handle this attack. As we started this work, we also began talking to a couple of the higher end services...

    After the $500/month service capped out and blew a gasket, we made the tough decision to go with the Cadillac. It was costly and they had us over a barrel (day before Thanksgiving, cheap service not working out, "sure would hate to see your site go down on Black Friday" mob pressure). But we knew even half a day of lost demand would pay for the yearly service (yes, it is yearly - no month to month option).

    The difference was amazing. As soon as we had swung our DNS over to the new guys, the attack was mitigated within 5 minutes and abated within 20. This, of course, leads the paranoid to wonder whether it was the service doing the attacking to begin with, but we are a high profile target in the minds of the Occupy movement, so it made sense (I do not share my employers sense of community - it is only a job).

    We have been attacked since then and every time the attack was mitigated within 5 minutes. If you require this type of uptime, build this service into your budget from the beginning.

    • I guess it's expensive to be unpopular.

      • I guess it's expensive to be unpopular.

        No, it's expensive to be hated by a small group of people who happen to not mind being network abusing dicks so they can put on a show of hurting your business. There are plenty of people who don't like the Occupy nonsense, but most of them are too busy doing something constructive to sit around figuring out how to DDoS attack George Soro's hundreds of web properties.

  • No matter how many times I see it, my first thought on seeing "DOS attack" is that a virus downloaded MS-DOS onto a computer.

    Which would almost be the worst thing to happen to a computer.

  • I recommend Akamai's services as a CDN for static content (eliminates a lot of load from your own servers), a proxy for dynamic content (shield/reverse proxy effect services) as well as a protection against (D)DoS attacks. They have a number of great case studies ( [] ) which are well worth the time looking through, as they have successfully mitigated attacks against small, medium and large websites. Their (repackaged) Kona Security Services are surprisingly go
  • I have had a few large spikes and MaxCDN and CloudFlare have kept my site up with no issues, so the real answer is distributed caches and you get what you pay for. - HEX
  • I want to see this website!

  • Don't ask on /. (Score:5, Insightful)

    by Nethead ( 1563 ) <> on Monday April 09, 2012 @11:19PM (#39626793) Homepage Journal

    This is a discussion you need to take to the NANOG list. Don't ask the amateurs, ask the professionals. The answer will involve ACLs, BGP settings, and community strings. If you don't have your own ASN then you need to push the issue upstream and work with your provider. Period. If you do have your own ASN and are running BGP then you need to read the NANOG list (and learn to take shit from Randy Bush, et al. They know what they are talking about.) Asking on /. can only make things worse.

  • 1) acquire a Gibson
    2) change username/password of superuser account from 'god'
    3) profit, since Gibsons easily survive ddos attacks/flooding as evidenced by the documentary released over a decade ago detailing attempts to hack a Gibson
  • Use a mirror in another data-center for your e-commerce website. Post link on the main website to the mirror or mirrors.

    Update mirrors with a script.

    The ideas (prejudices) of monarchy, monotheism, etc. are set firmly in our heads, but why your e-commerce should have only one and only URL? Let it have 2 or 3 URLs.

    We use a mirror for the 4th year, and it is the 4th year of sanity for me.
  • by Ryan Amos ( 16972 ) on Tuesday April 10, 2012 @02:37AM (#39627753)

    To most of the commenters: WTF? You have obviously never been involved in a DDOS attack. Here is why:

    1) A typical DDOS attack in 2012 will send traffic measured in hundreds of MBPS/GBPS down your pipe. Not only is this a massive volume of traffic, but almost all of it is in the form of SYN/ACK packets (which are exponentially more difficult for your frontend servers to handle; especially when they are never followed by a FIN.) This is many orders of magnitude more difficult to deal with than what most sites are scoped for. You cannot just "handle it," we're talking about something that is often 7-8 standard deviations away from your "normal" peak traffic levels. In other words, your infrastructure cannot handle it. Because if you overbuilt your infrastructure to those levels, you are an idiot. DDoS protection services cost a fraction of what it would cost you to build a network that could handle that.
    2) Your normal DDOS doesn't come from one "large user." (hence, the first D in DDoS.) It comes from thousands (or hundreds of thousands) of IP addresses, all at once. Botnets? Yeah, they are real things, and they can be really destructive. And bad people control them, and you may have fired their mother at one point. Who knows why they have it in for you, but they probably will at some point.
    3) Even if your infrastructure could handle an amount of legitimate traffic equal to the volume the DDoS will produce over the span of 6-12 hours, you would then have to pay for it. I promise you, you don't want to be in that position. Most hosting providers probably won't make you pay for all of it, but they will become real interested in what you're hosting that would make someone want to DDoS you in the first place. And your boss will probably make you find a proxy solution to solve the problem; so why not be proactive about it so you can say "Yeah, those /b/tards decided to DDoS us, but I took care of it 3 months ago."

    TL;DR: DDoS proxy services like CloudFlare exist for a reason: it's simply not economically feasible to overbuild your infrastructure to the point where you could survive such an attack. Pay the man, keep your site up, and ignore the punks smashing cars in the street because you have insurance, so fuck em.

  • Obvious solution. You will have invented the reverse slashdot effect [] .

  • Don't pay any heed to what the likes of gartner say, none of these things are "mandatory", they are all a factor of risk vs benefit vs cost...

    If your running a webserver, it only has tcp/80 open and nothing else... Then you add a firewall which sits infront and only allows 80/tcp, what have you gained? You may have an extra point of monitoring, and mitigation against outbound traffic *if* the box gets compromised... But if someone exploits a vulnerability on port 80 it's not going to help you (and there was

  • If your hosting service doesn't have an Anti-DDoS tier or option available, the people at were able to help in a pinch. If your host can change your IP address, you'll get the best results. You point your domain at the BlockDoS provided IP and then set your firewall (or server if firewall not an option) to block any inbound traffic not coming from a second BlockDoS provided IP. The downside is that you lose a lot of request header information and your server logs show all requests coming fro

It is not for me to attempt to fathom the inscrutable workings of Providence. -- The Earl of Birkenhead