Tag Archives: it

General

Legacy weirdness

2007/04/10 – 14:10

It makes me chuckle when I notice some of the weird information my computer gives me as a holdover from the old days. Some people probably don’t remember the days of ‘lower memory’ and ‘upper memory’. Here’s a little reminder about it, in case you need it.

There was a time when a BIOS boot-up report of available lower and upper memory was useful, back when the numbers were like “640k lower, 384k upper” and it was likely someone was running MS-DOS with a memory manager. But my laptop’s BIOS still reports it, in the days of Linux and Windows, when the numbers are “640k lower, 2096512k upper”.

Tags , , | Permalink | Comment (0)
General

SVN v. OSSEC

2007/04/07 – 05:30

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.

Tags , , , | Permalink | Comment (1)
General

Complications

2006/02/21 – 04:20

So, you ever decide to upgrade the storage on your living-room server, buy a hard drive, realize that the hard drive is SATA, which means it won’t work on your server, then figure, “hey, I have SATA on my desktop, might as well try that out”, then realize that your SATA is also RAID-0 capable so you might as well buy another drive and take advantage of that, only to find out after a couple experiments that it’s really not RAID but FakeRAID, and after you find a disk-clone utility that works with FakeRAID, you get the partitions cloned, but now GRUB won’t load due to some error that you don’t understand, so you reinstall the Windows MBR just to see that Windows will at least boot, but you can’t find the XP CD any more so you have to find some random MBR utility on the web and hope it works, but it does indeed work and Windows now boots, but of course Linux doesn’t because neither GRUB nor your installed kernel can deal with FakeRAID, and you finally get GRUB reinstalled but it still gives the error, which is number 18 which turns out to mean that GRUB can’t address your Linux partition through the BIOS, so you figure you might as well try updating the BIOS even though that seems unlikely to fix the problem, and since you don’t have a real floppy in the system and the BIOS makers haven’t graduated into the 19th century or whenever this is and they don’t make a CD-bootable flasher, you have to get the USB floppy from your laptop, make a flash floppy, make a bootable CD from the floppy, boot it only to find that you downloaded the wrong BIOS, repeat that process twice more until you do get the right BIOS, which then stuns you by actually fixing the problem, so now GRUB boots and can get you back into Windows but you still need to get dmraid installed in your initrd in your Linux kernel so you can boot that, which requires that you find a rescue CD that supports dmraid so you can even get to your Linux partition to do the initrd thing, after which you find an article that explains how to install dmraid in initrd, which thankfully works and now you finally are back to the point that everything works again, and it’s kinda cool?

I just did.

Tags , , , , | Permalink | Comment (1)