Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I am thinking about putting my whole linux server under version control using git. The reason behind it being that that might be the easiest way to detect malicious modifications/rootkits. All I would naively think is necessary to check the integrity of the system: Mount the linux partition every week or so using a rescue system, check if the git repository is still untempered and then issue a git status to detect any changes made to the system.

Apart from the obvious waste in disk space, are there any other negative side-effects?

Is it a totally crazy idea?

Is it even a secure way to check against rootkits since I most likely would have to at least exclude /dev and /proc ?

share|improve this question
4  
I would vote for "a totally crazy idea", too many implications. Changes to files will occur all the time and will make upgrade procedures a nightmare. –  forcefsck Mar 17 '11 at 15:46
    
@forcefsck - why would file changes occur all the time? Shouldn't they just occur during a system upgrade? –  Tobias Hertkorn Mar 17 '11 at 16:13
    
Just a thought, why not use something like dirvish or rsync with --link-dest? If you use dirvish to make your backups it will give you a nice report for each backup showing what changed. You can rsync in --dry-run mode to compare the current state against your backup. If you use dirvish you will be using a tool that is well-tested as a backup system. –  Zoredache Mar 17 '11 at 16:37

4 Answers 4

That's a "Bad Idea" (tm). Aside from all else, your repository will run slow as all heck, and get worse as every revision is kept.

Try centralised management, like puppet / cfengine / chef. That'll keep things as you expect, and revert unexpected changes.

Combine that with something like iwatch to get emails of unauthorised file alterations.

Combine that further with rpm/deb files if needed to roll out custom applications.

Throw in something like rkhunter or chkrootkit now and then for kicks and you should be good to go.

Job done.

share|improve this answer
    
+1 for Bad Idea -- Centralized management (puppet/cfengine/chef/radmind/etc.) will give you the ability to ensure that your system is configured according to your defined requirements, and most can also be used as a "tripwire" type system to tell you when stuff changes that shouldn't have. –  voretaq7 Mar 17 '11 at 15:56
    
I think its really a bad idea. Ok you can see which files are new and changed. But if you run git it needs a lot of cpu to unpack and calculate your files. If you do this on the whole mashine it takes a lot of time. –  Stony Mar 17 '11 at 15:57
    
I'll throw another one on that list; etckeeper will do the git repo, except only for /etc. –  Shane Madden Mar 17 '11 at 15:59
    
repositories like git are increadibly fast. And I am not worried about CPU or IO since the server I have in mind has scheduled downtimes (hence the possibility to mount it using a rescue system) –  Tobias Hertkorn Mar 17 '11 at 16:08
    
What I don't understand: how do the centralised management systems guarantee that there are no false positives - the system is compromised + the tools used to check the system are compromised = false positive –  Tobias Hertkorn Mar 17 '11 at 16:12

Another alternative is to set up tripwire, which is GPL'ed software that spiders through all the important files on your system and determines which have changed in ways you have defined as unacceptable. Change can be defined as simply as mtime, through inode number, all the way to cryptographically-strong checksums.

It takes some setting up and tuning if you don't want to get a whole lot of reports every night about changed files in /var/run, changes in DHCP client files in /etc, and the like, but if you do go to that trouble, it can be very helpful indeed.

The database of file properties is signed with a key not known to the machine, which helps you have confidence that no tool has maliciously changed the database or the tripwire binaries. For complete certainty you can burn a copy of the tripwire tools and databases to a read-only medium, which can be mounted on the server and used to verify all changes since the disc was burned, if a complete forensic analysis is needed.

If you're going to do this, it's quite important to get tripwire set up and running before the machine is deployed into production, or you can never be completely sure that some malicious user didn't have a chance to infect the machine before it was tripwired.

share|improve this answer

@Sirex provided a very good answer already, but if you want to make a step further with security, the best way to deal with it is first prevention then detection.

Try setting up a system with / filesystem mounted read-only. Make /tmp a separate ramfs mounted with noexec,nodev option. For the system to work, you really only need /var to be mounted read-write. So under /var mount an fs with rw,noexec,nodev and remove write permissions to /var/tmp (afaik, it is rarely needed by daemons and that should be configurable). Also use a security patch for your kernel to further limit access to resources by users, try grsec for example. Use a firewall with the most restrictive rules possible.

Some distributions provide extensive documentation on system hardening. For example:

share|improve this answer

I don't think this is likely to work, but as an experiment I'd like to see what happens if you do this with just the /etc folder. That's where most of the configuration information is kept.

share|improve this answer
3  
Just /etc is being done. Check out kitenet.net/~joey/code/etckeeper (etckeeper) –  Tobias Hertkorn Mar 17 '11 at 16:06
    
etckeeper works really nicely, I find it very useful. –  Zoredache Mar 17 '11 at 16:39

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.