Apache directives to avoid DDOS

[Nouha Terzi <no...@gmail.com>]

Hi,

As suggested here:
https://community.qualys.com/blogs/securitylabs/2011/11/02/how-to-protect-against-slow-http-attacks
Modifying those directives can protect against slow HTTP attacks and make
the attacks more difficult to execute:

- LimitRequestFields
- LimitRequestFieldSize
- LimitRequestBody
- LimitRequestLine
- LimitXMLRequestBody
- TimeOut
- KeepAliveTimeOut
- ListenBackLog’s
- MaxRequestWorkers
- AcceptFilter

Does someone already configured a svn apache server to handle slow http
attacks?
Is there any known impact of theses apache directives?

Thank you in advance.
-- 
Nouha

Re: What happens when revision numbers are not chronological?

[Stefan Sperling <st...@elego.de>]

On Mon, Jan 30, 2012 at 11:06:19AM -0500, Alexander Shenkin wrote:
> Hi Folks,
> 
> I've used an import script to import two bunches of files in the same
> repository.  This import script sets the commit time of each file
> (svn:date property) to the original modified-time of the file.  So, when
> I added the second batch of files, the dates associated with the
> revision numbers are no longer chronological.  That is, rev 5 might have
> an svn:date of 1/1/2011, and rev 6 might have an svn:date of 1/1/2010
> for example.
> 
> I'm not planning on doing anything overly complex with svn - i probably
> won't be branching or merging.  However, I would like to be a little
> more educated about the risks that I am running.  Anyone know?
> 
> thanks!

See the warning at the bottom of this page:
http://svnbook.red-bean.com/en/1.7/svn.tour.revs.specifiers.html#svn.tour.revs.dates

Basically, you are confusing the binary search algorithm that is
invoked when you pass a date argument to the -r option. Other than
that, there is no harm.

Re: What happens when revision numbers are not chronological?

[Alexander Shenkin <su...@shenkin.org>]

thanks all for your helpful replies.

On 1/30/2012 1:13 PM, Ryan Schmidt wrote:
> On Jan 30, 2012, at 10:06, Alexander Shenkin wrote:
>
>> I've used an import script to import two bunches of files in the same
>> repository.  This import script sets the commit time of each file
>> (svn:date property) to the original modified-time of the file.  So, when
>> I added the second batch of files, the dates associated with the
>> revision numbers are no longer chronological.  That is, rev 5 might have
>> an svn:date of 1/1/2011, and rev 6 might have an svn:date of 1/1/2010
>> for example.
>>
>> I'm not planning on doing anything overly complex with svn - i probably
>> won't be branching or merging.  However, I would like to be a little
>> more educated about the risks that I am running.  Anyone know?
> You will not be able to use the date syntax to specify revisions. For example:
>
> svn log -r '{2012-01-01}:{2012-01-11}'
>
> This is not guaranteed to return sensible results if your revisions are not in ascending chronological order. I'm not sure what it will do, but I wouldn't be surprised if it returned revisions outside the requested range, and/or did not return the revisions that are in the requested range. If I remember correctly, the Subversion repository of the Apache Software Foundation has non-chronological revisions, so you could do some tests against their repository if you're curious.
>
> But that's the only problem I know of.
>
>
>

Re: What happens when revision numbers are not chronological?

[Ryan Schmidt <su...@ryandesign.com>]

On Jan 30, 2012, at 10:06, Alexander Shenkin wrote:

> I've used an import script to import two bunches of files in the same
> repository.  This import script sets the commit time of each file
> (svn:date property) to the original modified-time of the file.  So, when
> I added the second batch of files, the dates associated with the
> revision numbers are no longer chronological.  That is, rev 5 might have
> an svn:date of 1/1/2011, and rev 6 might have an svn:date of 1/1/2010
> for example.
> 
> I'm not planning on doing anything overly complex with svn - i probably
> won't be branching or merging.  However, I would like to be a little
> more educated about the risks that I am running.  Anyone know?

You will not be able to use the date syntax to specify revisions. For example:

svn log -r '{2012-01-01}:{2012-01-11}'

This is not guaranteed to return sensible results if your revisions are not in ascending chronological order. I'm not sure what it will do, but I wouldn't be surprised if it returned revisions outside the requested range, and/or did not return the revisions that are in the requested range. If I remember correctly, the Subversion repository of the Apache Software Foundation has non-chronological revisions, so you could do some tests against their repository if you're curious.

But that's the only problem I know of.

What happens when revision numbers are not chronological?

[Alexander Shenkin <su...@shenkin.org>]

Hi Folks,

I've used an import script to import two bunches of files in the same
repository.  This import script sets the commit time of each file
(svn:date property) to the original modified-time of the file.  So, when
I added the second batch of files, the dates associated with the
revision numbers are no longer chronological.  That is, rev 5 might have
an svn:date of 1/1/2011, and rev 6 might have an svn:date of 1/1/2010
for example.

I'm not planning on doing anything overly complex with svn - i probably
won't be branching or merging.  However, I would like to be a little
more educated about the risks that I am running.  Anyone know?

thanks!

Re: Apache directives to avoid DDOS

[Stefan Sperling <st...@elego.de>]

On Mon, Jan 30, 2012 at 03:56:52PM +0100, Nouha Terzi wrote:
> Hi,
> 
> As suggested here:
> https://community.qualys.com/blogs/securitylabs/2011/11/02/how-to-protect-against-slow-http-attacks
> Modifying those directives can protect against slow HTTP attacks and make
> the attacks more difficult to execute:
> 
> - LimitRequestFields
> - LimitRequestFieldSize
> - LimitRequestBody
> - LimitRequestLine
> - LimitXMLRequestBody
> - TimeOut
> - KeepAliveTimeOut
> - ListenBackLog’s
> - MaxRequestWorkers
> - AcceptFilter
> 
> Does someone already configured a svn apache server to handle slow http
> attacks?
> Is there any known impact of theses apache directives?
> 
> Thank you in advance.

I wouldn't recommend changing any of these from the defaults,
unless you are 100% sure that there is a real threat to your server
because of the default value of one or more of these options.

Have you actually had the problem described in the blog post?
Keep in mind that this is a blog. Have you already checked the
official Apache HTTPD documentation? Maybe it discusses the
implications of changing the default values.

>From the options in this list, KeepAliveTimeOut is probably most
relevant to Subversion. If you set this too low Subversion clients
will have problems with dropped connections during checkout and update
operations. Subversion clients sometimes need to do some amount of
local processing (such as copying a temporary file) before they will
send another request. If the server has dropped the connection before
the local operation has finished the client will error out.

I have no idea how you could distinguish between a Subversion client
doing some local processing and a malicious client that sends some
requests and then waits in order try a "slow HTTP attack" as described
in the blog post.

I would say don't worry about this unless you can prove that somebody
is using this strategy to deny access to your server.