Hello all,
I had a problem related to OSSEC. I have a sufficient solution for my
tastes, but I don't have the motivation to find a more generic solution.
I'm posting this so that others might find a more generic solution or at
least get help if they have the problem.
The issue is described at http://www.ourada.org/blog/archives/188; the
blog entry is reproduced below.
Steven
------
Learned of an interesting interaction between Subversion (SVN) and <a
href="http://www.ossec.net/";>OSSEC</a>, an intrusion detection system
that happens to be installed on a server I work with. If you're seeing a
problem where Subversion hangs when you're trying to do a checkin, and
you happen to be renaming a number of files, this might be your problem.
I don't offer a complete solution here, but maybe some help.
When you rename a file in Subversion (I've seen this with TortoiseSVN,
Subclipse, and the official command line client, and would expect it in
any client), the client does a check to make sure the new name isn't in
use. It does a PROPFIND on the file and expects a 404, giving an Apache
log entry like this:
<code>
xx.xx.xxx.xx - username [07/Apr/2007:06:11:10 -0400] "PROPFIND
/svn/trunk/blah/blah/newfilename.java HTTP/1.1" 404 297 "-" "SVN/1.4.2
(r22196) neon/0.25.5"
</code>
OSSEC has a rule (31151, in web_rules.xml) that alerts at level 10
whenever there are more than 10 404s (well, 4xxs) from the same IP in
the same 120-second interval. That causes an active response from OSSEC
to ban the IP for 10 minutes.
So, if you rename 10 or more files in a SVN checkin, OSSEC will ban you
for a while. The 31151 rule makes sense in a basic way, in that some
exploits will try to find vulnerable URLs for insecure scripts, etc.,
but it's clearly too heavy-handed when SVN is running.
I don't perceive that sort of URL scan to be a big threat on a
well-maintained server, so one solution is just to drop the rule's level
below the active response threshold. However, it would be somewhat more
sophisticated to do something like "don't trigger if the username field
in the log entry exists and the error is not 401 (unauthorized) and the
method is PROPFIND and the URL is within the domain of the SVN install".
That refinement only works when mod_svn is configured to use Apache
authentication (so that the username field would be in the log) and
requires that you know the URL that SVN was installed under, so it can't
be done that way in the generic ossec install.
You could also make refinements based on IP address or something, but in
my case, the server is used by different remote people on different
dynamically-assigned IPs on different networks.
I don't really know how to express any of that in terms of OSSEC rules
anyway, given that I'd never heard of ossec before an hour ago :-). So I
can't say how OSSEC might mitigate this problem in general, but on an
individual install, you can just drop the rule's level or comment it
out, if you're feeling lucky.