[liberationtech] query

Thu Nov 4 09:00:54 PDT 2010

Hi Ron and all,

We have a report on ddos attacks against ind media due out soon (within 
a week or so we hope).  The very brief take aways (keeping in mind that 
the report is about 20k words!) are:

* DDoS attacks (including both application and network attacks) against 
ind media and human rights sites are common across a range of countries 
and even outside of political crises.

* There is a huge difference in the ability to defend against these 
attacks between the couple dozen organizations at the core of the 
Internet (Tier 1 ISPs, hypergiant websites, giant CDNs) and the rest of 
orgs further to the edge of the Internet.

* There are a range of things a competent sys admin even at the edge of 
the Internet can do to mitigate application attacks (which some folks 
are calling dos attacks); mostly they reduce to properly optimizing a 
webserver for high traffic (optimize web server, avoid dynamic pages 
where at all possible, cache where not, backup by mirroring to multiple 
locations including at least one big free host like blogger).

* For network attacks, the problem is that even moderately large attacks 
don't get to the target machine (they kill the link in front of the 
machine), so the attack has to be addressed by the hosting provider (and 
potentially upstream).  The best choices are to 1) pay a lot for ddos 
protection from a Tier 1 ISP or equivalent (though some seem willing to 
help for thousands rather than the market hundreds or tens of thousands 
of dollars per month), 2) find a guardian angel org that will help at 
lower cost, or 3) host on blogger or similar.

* Most sites suffer from a range of different attack modes in addition 
to DDoS (filtering, intrusion, defacement, etc), so sites should 
consider the broad range of vulnerabilities rather than just DDoS.

* The best mode we've found for protecting against DDoS and other 
attacks is to identify and support local technology experts in affected 
communities that can serve as hubs for targeted sites and act as 
liaisons between the targeted sites and the big core Internet 
organizations that are uniquely capable of dealing with these attacks 
(especially network attacks) and mostly eager to help if given the right 
place to plug in.

-hal

On 11/3/10 6:59 PM, Ronald Deibert wrote:
> 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 <mailto: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 <mailto: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.