[liberationtech] query

[Jen Savage]

There are some new interesting post ddos attacks on layer 7 that
resemble slowloris and that are probably going to make these types of
attacks far more common and potentially unavoidable. Although I like
to think someone will propose a worthy solution if they just think
about it enough.

See here: http://www.darkreading.com/vulnerability_management/security/attacks/showArticle.jhtml?articleID=228000532

-Jen


On Thu, Nov 4, 2010 at 11:00 AM, Hal Roberts
<hroberts at cyber.law.harvard.edu> wrote:
> 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.
>
> _______________________________________________
> 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.
>