[liberationtech] query

[Mehdi Yahyanejad]

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.

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