Learned of an interesting interaction between Subversion (SVN) and OSSEC, 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:
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"
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.