[liberationtech] query

Tue Nov 23 17:16:07 PST 2010

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20101123/b64ebc54/attachment.asc>