[liberationtech] query

[Adam Fisk]

I'd like to re-emphasize Chris's original answer to this thread -- use
the cloud. To me, the likelihood of thousands of competent sysadmins
appearing in organizations that are typically notorious for lacking
tech expertise is low, despite everyone's best intentions. To
accomplish this would also put a strain on the resources of
organizations that typically don't have resources to spare.

I'd strongly recommend using cloud solutions, and especially Google
App Engine, as Chris recommended. In most cases it's much easier to
deploy your sites to the cloud even outside of DDoS attacks. GAE is
also free for the amount of traffic most of these sites get, not to
mention the amount of money you'll save employing fewer programmers,
and it saves immense amounts of time in areas such as not having to
back up your database, not worrying about scalability, etc. Not
worrying about DDoS attacks is just another reason among many. I'd
also strongly recommend GAE over Amazon because it's much less work
and requires even less expertise to handle something like a DDoS
attack. You still have to know what you're doing on that front with
Amazon. With GAE you don't.

All the Best,

-Adam


On Wed, Nov 24, 2010 at 2:16 PM, justin saunders <justin at tao.ca> wrote:
> A how-to on best hardening/security practices for sysadmins would be
> great. In the absence of a more dedicated wiki resource, perhaps
> something on Wikiversity or Wikibooks would be in order? It could go
> nicely here:
>
> https://secure.wikimedia.org/wikibooks/en/wiki/Subject:Information_technology
>
> or here:
> https://secure.wikimedia.org/wikibooks/en/wiki/Subject:Computer_networking
>
>
> justin
>
>
> On 03/11/10 07: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.
>
>



-- 
Adam Fisk
http://www.littleshoot.org | http://adamfisk.wordpress.com |
http://twitter.com/adamfisk