[liberationtech] query

Mon Dec 6 04:21:34 PST 2010

While I definitely agree that organizations of sizes needed to consider
and understand the risks of the cloud, and I appreciate Sky's well
informed comments on the economic and administrative challenges, there
some other ways to look at this issue.

First, it is possible to use GAE and other cloud application platforms
that require less lock-in or even migration to them. If you develop  o
your application using J2EE/JSP, then GAE is full compatible with
Tomcat, Jetty, etc any other Java environment. More importantly, there
are some semi-turnkey open-source apps for GAE that turn an app into a
kind of a front-end proxy, web cache server. In this way, you are using
GAE as a shield or repeater of your content, and not the primary host.
You can move this shield app to different app instances across different
accounts as you hit various free quotas. I have also used this approach
to create temporarily, lightweight SSL-enabled front-end proxies. This
type of solution can be implemented by following a simple step by step
how-to, and doesn't require much more skill than setting up Wordpress.

This model also works with Amazon and other root cloud providers, in
that you can use these virtual instances to host Varnish, Squid or some
other cacheing/reverse proxy server, while your back-end actual web tier
sits safely on a box which you never expose to the public. In this way,
you can protect the true location of your hosting, while also allowing
your front-end tier to scale up and down as needed or move to different
IPs and instances, or based on what you can afford. While this approach
does require a bit more skill, one could package up some EC2 machine
images to make it easier for admins.

Finally, I could like to ask if anyone has opinions on the Coral Cache
auto-CDN model, which you can read more about here:
http://www.coralcdn.org/. I have used Coral for distributions of large
files in the past, and also investigated its use as a basic tool for
resisting DOS. What I absolutely love about the model is that there is
zero setup. You simply append ".nyud.net" to your hostname, and it gets
automagically cached. For instance: http://tibetaction.net becomes:
http://tibetaction.net.nyud.net/ and suddenly our site is being
channeled through a large, free cacheing network. I think Coral itself
might have some technical limitations and issues, but I have to believe
a model like this could be useful.

Best,
 Nathan

On 12/03/2010 10:23 AM, Danny O'Brien wrote:
> 
> On Dec 2, 2010, at 8:40 PM, Adam Fisk wrote:
> 
>> These are certainly concerns guys, I agree, but they're outliers in
>> the extreme. Over 99% of the organizations facing these issues, the
>> ones perhaps reading this list, are nothing like WikiLeaks, and
>> they're nothing like counterfeiters. I'm not negating the precarious
>> state of DNS or of the vulnerability of companies to state actions,
>> but I think to overemphasize those threats is doing a huge disservice
>> to most organizations actually facing DDoS attacks.
> 
> 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.
> 
> _______________________________________________
> 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.