[liberationtech] query

[Ronald Deibert]

Hi Mehdi
And everyone else, thanks for the responses.  These are very helpful.
I'll pass along to the affect party.  I'd rather not give out more  
details without their permission.
I receive a notice from some group or another along these lines about  
once a week.  It is hard to keep up.
Makes me think that some kind of wiki-resource beginning with what  
Mehdi outlines would be good to have
somewhere, translated and updated as the case may be.
Ron


On 3-Nov-10, at 4:55 PM, Mehdi Yahyanejad wrote:

>
> Hi,
>
>
> In most cases, the websites are hit by DoS rather than DDos. Most of  
> the websites out there can be brought down with
> 5-10 machines sending search queries or queries to the archive pages  
> which are not cached.
> A few measures that can be taken assuming the organization has only  
> one server:
>
>
>
> a) protection
>
> 1- Iptables: A properly configured firewall can help a lot. There  
> are a lot of recipes online on how to configure iptables. Basically,  
> no ports other than
> 80/443 should be left open to the rest of the world. Also, the  
> amount of traffic accepted from any ip needs to be capped.
>
> 2- Caching: Any website with decent traffic needs some sort of  
> caching mechanism for highly visited pages. Memcached works great.  
> Most of
> the major web frameworks have plugins for it.
>
> 3- Varnish/Squid: The main web server (apache/nginx) can be shielded  
> by using something like Varnish which caches pages.
>
> 4- CDN: Static content (images or js libraries) can be put on  
> Content Delivary Network (CDN) or on Amazon S3. This lowers the load  
> on the web servers.
>
> 5- Monitoring: A server based monitoring like Nagios can help to  
> show if the server is low on RAM/CPU. Also, a third-party service  
> can help with getting notified
> if the server is down or slow.
>
> 6- Monitoring Logfiles using scripts: Using simple commands which  
> run regularly as a cron task, the web server logs can be monitored  
> for IPs which are sending too many requests.
> Such IPs can be banned for a short period. Banning them indefinitely  
> is not a good idea because of false positives.
>
> b) minimization of the damage:
>
> 1) Allow an alternative reboot option: There should be a way to  
> reboot the servers or take them offline without a need to ssh to the  
> servers. A server under attack will
> have a hard time responding to ssh.
>
> 2) Allow reducing the website's features: there should be a way to  
> remove all the fancy features of the website whenever there is high  
> traffic due to an important
> event or DDoS. Pretty much anything people do to survive the Digg- 
> effect applies here.
>
> 3) Image snapshot: A website under attack can only show read-only  
> version of the content. For wordpress websites, WP Super Cache  
> plugin offers many of these
> features.
>
> 4) Ban the IPs with the most connection: A quick remedy is to block  
> all the ips with most connection open. A command like this can  
> return those IPs:
> netstat -atnp -A inet | grep ":80" | awk -F " " '{print $5} ' | awk - 
> F ":" '{print $1}' | sort | uniq -c | sort -nr | head -5
> Unfortunately, this type of command can block proxy servers too.  
> Creating a allowed IP list ahead of time can be useful.
>
>
>
>
>
>
> Best,
> Mehdi
>
>
>
>
>
>
>
> Shield the application website with a different server running  
> Varnish/Squid.
> The set up can be a little bit complicated
>
>
> On Nov 3, 2010, at 5:52 AM, Ronald Deibert wrote:
>
>> Hi Everyone
>>
>> We get a lot of queries from organizations that have been DDoS'd  
>> who have limited capacity.  I am wondering if anyone on the list
>> knows of a best practices document or website that offers guidance  
>> on a) protection, b) minimization of
>> damage and c) post-atttack response that their webmaster can study?
>>
>> Any help would be appreciated.
>> Ron
>>
>> Ronald J. Deibert
>> Director, The Citizen Lab
>> Munk School of Global Affairs
>> University of Toronto
>> r.deibert at utoronto.ca
>> http://deibert.citizenlab.org/
>> twitter.com/citizenlab
>>
>>
>>
>>
>> _______________________________________________
>> 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.
>

Ronald J. Deibert
Director, The Citizen Lab
Munk School of Global Affairs
University of Toronto
r.deibert at utoronto.ca
http://deibert.citizenlab.org/
twitter.com/citizenlab




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20101103/0ada0655/attachment.html>