[liberationtech] query

Mon Dec 6 22:44:42 PST 2010

Danny, I can give you a non-GAE example:  Let's talk about a real host I will call "HM" just for the sake of discussion - it turns out that if you exceed a certain CPU limit, "HM" will "throttle" you - your CPU usage gets capped so it doesn't interfere with other users on the same server.  They say this is a feature, but it is also effectively an "internal DoS" and takes place regardless of whether the server has spare CPU time available or not.  And of course other hosts like "NS" and "GD" will "call for a human sysadmin" who will kick you off their servers if you repeatedly use too much CPU time.  So yes, there are tactics you can use that are based on technical (as opposed to legal) terms of service, not just flooding the web server with slow requests.

I could just hit some self-hosted WordPress(.org, not .com) sites with a couple dozen HEAD requests every second - each one targeting a page that has to be built from scratch and is out-of-cache, and they'd be exiled to Elba pretty fast.

[Sky]

On Dec 6, 2010, at 8:08 PM, Danny O'Brien wrote:

> 
> On Dec 6, 2010, at 2:01 AM, Adam Fisk wrote:
> 
>> I'm a bit confused by your comment, Danny. I completely agree there
>> are other attacks worth thinking about, but we're currently talking
>> about DDOS right? I think we have to keep these various attack vectors
>> separate if we want to offer solutions. There are certainly issues
>> with DNS, and I honestly am not particularly familiar with DDOSing
>> DNS, but it's an issue regardless of whether or not you're hosted on
>> the cloud.
> 
> My point was a bit more meta, and I may have muddled it by throwing in apparently specific yet in fact mostly hand-waving examples. Sorry.
> 
> I was primarily picking up on what I thought you were saying: that rolling through a list of current outlier attacks on cloud-hosted apps was doing a "disservice" to people who were actually suffering DOS attacks, because such discussions are a distraction. Outliers can switch to common practices very quickly, though, and I don't think it's a disservice to consider them, especially as a very large number of us *do* advise moving to cloud-host services in almost every case, so our concern has mostly moved from what the concrete advice is to what the next problems we will face will be.
> 
> To pluck at the outliers in the original thread: domain name seizure is quickly building a statutory head of steam in a lot of jurisdictions; and AWS's shutdown of WikiLeaks *was* disturbing, not so much because they did it, but because it was clearly an arbitrarily made decision and they had no process in place[1].
> 
> Anyway, if you're still confused, just forget everything I wrote, and assume I said what Sky said. He made the point far more effectively than me. Also, you agreed with him!
> 
>> 
>> Your point about the public quotas on GAE makes sense if you don't
>> sign up for billing. There's no limit I know of to your maximum daily
>> budget though. Sure, you pay some money, but it's far cheaper than
>> setting up your own capacity to deal with a big attack. The daily
>> limit you choose also isn't public, and you don't pay anything in the
>> much more common case where you never come near the free limits. I'm
>> curious to know what other GAE-specific attacks you could imagine. The
>> thing about Google is they can withstand a lot -- I can't imagine
>> needing another provider, but I'm happy to be proved wrong.
>> 
> 
> Hmm. Now I have to substantiate my vague hand-waving. My impression was that GAE had some fixed resource quotas as well as ones that you can pay to expand, and that those fixed quotas were publicly known. Said hand-waving was based on http://www.carlosble.com/2010/11/goodbye-google-app-engine-gae/ and http://code.google.com/appengine/docs/quotas.html . 
> 
> I don't know of any generic GAE attacks, but as Sky says what we mostly see these days is application-level DOS attacks aimed at popular applications like WordPress, so my fevered imagination assumes that any widely-distributed GAE-written application could suffer the same kind of application-specific attacks. 
> 
> I don't actually know of any widely-used GAE-written CMSs that are used by DOS-attacked groups, which is both good for potentially defending the capabilities of GAE, and bad for actually moving DOS-attacked groups to the platform.
> 
> In practice, the cloud solution for attacked sites tends to be "switch to a LiveJournal or Blogspot account until the attack ends" because that minimizes the time to switch, the need for technical knowledge at the victim's end, and DOS-related costs. 
> 
> Also I would advise them to go back in time and change the TTL on their DNS so that they can swiftly redirect to another site, advice that only really works on the second DOS.
> 
>> The issue with attackers moving on to other strategies is also a best
>> case scenario isn't it? They move on to other strategies when one
>> strategy is thwarted. Isn't the the whole goal?
> 
> I wish. The issue is to push attackers onto strategies which are more costly, and less effective. The danger, to paraphrase Saint Schneier, is that you make a tradeoff and that tradeoff actually makes the situation worse, because it allows another strategy that's cheaper and *more* effective. 
> 
> To use another hand-wavy example, I have a worry that popped up in the discussion over Hal's paper that we may be swapping out denial-of-service for denial-of-funding -- attacks aimed at users of Amazon or other services, which seek not to bring systems down, but maximize the financial costs to the victim.
> 
> d.
> 
> [1]Talking of which, did anyone else note that the terms of service that AWS quoted at in the WikiLeaks case (http://aws.amazon.com/message/65348/ )?
> 
> “you represent and warrant that you own or otherwise control all of the rights to the content… that use of the content you supply does not violate this policy and will not cause injury to any person or entity.”
> 
> ... appears to be taken from the terms of use for accessing the AWS *website* (http://aws.amazon.com/terms/), and intended for content that was posted to their developers forums?
> 
> Also, the bit they excluded by ellipsis included the phrase "including any Third Party Software, that you post; that the content is accurate", implying that they would also happily bounce some one for simply being insufficiently perfect in their knowledge.
> 
> Given how asymmetric ToS usually are, I'm sure that there were better clauses to cite, but it really didn't make me feel comfortable that AWS didn't even appear to have handed off their explanation to a lawyer to sharpen up.
> 
>> 
>> -Adam
>> 
>> 
>>> 
>>> I know what you mean, but I'd challenge the idea that the dangers of cloud provision and domain name attacks aren't a concern to these groups.
>>> 
>>> Organizations who suffer from DOS suffer from it because it's the cheapest most effective way to silence a voice online, given certain opposing groups' technical skills and access to resources. As soon as you mitigate away the risk of a DOS, a new cheapest most effective way rises to the top of the list, and that's where the new attack will be aimed.
>>> 
>>> I'm not sure where you get your 99% figure from, but my experience is that a DOS-proof host doesn't sit around long before the attackers start looking for other low-cost possible attacks, which include (but isn't limited to) weaknesses in domain and cloud management. It makes sense to understand what those are. For instance, without getting into a cloud religious war, shifting to GAE means that the limits and quotas on your website's resources are public, which means that attackers have a clear target to aim for in order to trigger a shutdown. If I build my NGO's web presence on GAE, and we go over that quota, there isn't a wider field of Google App Engine providers other than Google that I can bounce to.
>>> 
>>> Similarly, while Wikileaks is an outlier in some ways, the idea of moving a DOS from the host to the DNS provider, as we've seen happen to WL in the last day, is something that will work well against a wide range of arrangements. It's something we should attempt to anticipate when giving advice.
>>> 
>>> Are your attackers just script kiddies who would be stymied by a move to a cloud provider? Well, maybe, but we can only determine that by talking about the characteristics of the attacker not the last attack. Reacting to DOS attacks by just saying, oh move to GAE or Livejournal or Amazon S3, risks reactively solving the last problem without anticipating what the new one might be. Most importantly, we don't want to put groups into a situation where they throw a lot of time or money into a "anti-DOS" solution that only buys them a little more time because the attackers can switch their attack strategy with far less bother.
>>> 
>>> d.
>>> 
>>> 
>>>> -Adam
>>>> 
>>>> 
>>>> On Fri, Dec 3, 2010 at 3:25 PM,  <liberationtech at lewman.us> wrote:
>>>>> On Thu, Dec 02, 2010 at 10:29:21AM -0800, chris at eff.org wrote 2.4K bytes in 53 lines about:
>>>>> : Well, recall that my advice hinged on the assumption that the cloud
>>>>> : provider was not your threat actor. Maybe that's not looking like too
>>>>> 
>>>>> Going one level higher in the nested stack of things to worry about:
>>>>> your top level domain being taken away.
>>>>> 
>>>>> As the USA (ICE take down of some .com domains) and Libya (take down of
>>>>> bit.ly) have recently reminded us, your domain name may not be safe
>>>>> either.
>>>>> 
>>>>> --
>>>>> Andrew
>>>>> pgp key: 0x74ED336B
>>>>> _______________________________________________
>>>>> liberationtech mailing list
>>>>> liberationtech at lists.stanford.edu
>>>>> 
>>>>> Should you need to change your subscription options, please go to:
>>>>> 
>>>>> https://mailman.stanford.edu/mailman/listinfo/liberationtech
>>>>> 
>>>>> If you would like to receive a daily digest, click "yes" (once you click above) next to "would you like to receive list mail batched in a daily digest?"
>>>>> 
>>>>> You will need the user name and password you receive from the list moderator in monthly reminders.
>>>>> 
>>>>> Should you need immediate assistance, please contact the list moderator.
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Adam Fisk
>>>> http://www.littleshoot.org | http://adamfisk.wordpress.com |
>>>> http://twitter.com/adamfisk
>>>> _______________________________________________
>>>> liberationtech mailing list
>>>> liberationtech at lists.stanford.edu
>>>> 
>>>> Should you need to change your subscription options, please go to:
>>>> 
>>>> https://mailman.stanford.edu/mailman/listinfo/liberationtech
>>>> 
>>>> If you would like to receive a daily digest, click "yes" (once you click above) next to "would you like to receive list mail batched in a daily digest?"
>>>> 
>>>> You will need the user name and password you receive from the list moderator in monthly reminders.
>>>> 
>>>> Should you need immediate assistance, please contact the list moderator.
>>> 
>>> 
>> 
>> 
>> 
>> -- 
>> Adam Fisk
>> http://www.littleshoot.org | http://adamfisk.wordpress.com |
>> http://twitter.com/adamfisk
> 
> _______________________________________________
> liberationtech mailing list
> liberationtech at lists.stanford.edu
> 
> Should you need to change your subscription options, please go to:
> 
> https://mailman.stanford.edu/mailman/listinfo/liberationtech
> 
> If you would like to receive a daily digest, click "yes" (once you click above) next to "would you like to receive list mail batched in a daily digest?"
> 
> You will need the user name and password you receive from the list moderator in monthly reminders.
> 
> Should you need immediate assistance, please contact the list moderator.