Hi all,

I am experiencing a classic problem with HIDS.
I am using this tool to detect any malicious modification of my filesystem.

However, if an attacker can modify the filesystem, he can also modify my HIDS database.

I am looking for a solution to protect my database from corruption.

I thought of storing them on another PC having a read-only NFS share.
But is not it going to downgrade the performance of the HIDS ?

Other ideas ?
I precise, the server does not have any CD/DVD reader.

Thanks

Well, encryption and digital signatures are the most common method for protecting databases which reside on the filesystem the HIDS is monitoring. That said, you are already aware that using read-only media anyway is a really good idea. How big is your database file? Can you put it on a floppy disk? Using a read-only network share for the database shouldn't affect performance in most cases. Just make sure you get a notification from the HIDS if it can't access the share.

You may be interested in the discussion on this recent aide thread.

One way to find out for sure: test it. What sort of performance do you need for the HIDS anyway? How often are you running integrity checks?

Not a perfect solution, but could you create a cdrom image file and mount that. The iso6990 filesystem itself is read only. You could create an md5sum of the image and store that offline.

.
Please note that thread was based on specific requirements wrt Aide (a passive file integrity checker). Like Samhain Aide can understand the server-client paradigm (with the aid of a third party app), but the *real* difference is Samhain can be used as active file integrity checker, can test conditions Aide can't and can obscure and verify its own config and database.


If you ever did a 'mkisofs' of a directory of readable files and then 'cat -v'ed the ISO you'd seen all the plaintext is there, meaning it wouldn't need much to edit it OTF, IMHO. If you keep )a copy of) the database on the localhost I'd encrypt it instead.

About NFS, yes I can try.
My only problem is that i have to "sell" this solution to the IT manager. I would like to have roughly an idea of ther performance, if not, this solution will be rejected straight !

About encrypting the database, I imagine that the HIDS is hosting a secret (a passphrase). This secret is used to perform symetric encryption of the database.
I have the feeling that the problem is only switched to the management of the secret.

An attacker who can corrupt a file, can corrupt the database, and so can read root read-only file hosting the secret.

Am I wrong ?

Thanks

What are you using for HIDS

if you are using something like tripwire it uses signed and encrypted databases and and time you recreate the database the is a password that must be used.

The people that write the HIDS know security pretty well.

Also you are not the first person to think of the fact that someone could modify the database so most HIDS have that protection built-in. It just depends on what type of HIDS you are running

if you really want to go crazy look at grsecurity. You can install it and create a policy to hide files at a kernel level.

It is not about getting crazy, it is about being coherent: if one reach the root level and can alter the filesystem, he can also read a file hosting a secret, no ?

On the aide thread I pointed you to I was specifically referring to the chattr + lcap approach. That doesn't address your needs?

With grsecurity with the policy enforced root cannot even see the hidden files. They are locked by the kernel and the policy states what can and cannot access the files. You can hide the passwd file from bash but allow the useradd/del/mod or passwd program to see it. If the program does not need access to the file then it wont get access. You can even restrict what capabilities a program can use. If a program doesnt need network capabilites then they are restrict from using sockets. The policy is hidden and locked from the system and you can restrict what root can do. If you want you can make it so root can't even delete files from his home dir. It uses a MAC (mandatory access control) policy. Grsecurity can block about 99% of buffer overflows, return-to-c attacks, and most other vulns. The Grsecurity team are the ones who create ASLR (address space layout randonization) AKA PAX which is used by almost every major distro there is. But it is only a small portion of grsecurity.

Fedora, red hat, suse, centos, ubuntu, debian and most others all use PAX. Slackware is the only major distro that i know of that does not.

So getting root of a MAC system is alot harder than on a non-MAC system. Grsecurity is similar to SELinux but adds alot of extra kernel protections including memory protection, chroot restrictions, burst log restrictions, and tcp/udp restrictions.

On most of the systems i deploy with GRSecuity root is just a user. Grsecurity adds another admin account that is restricted only by the kernel. The new admin account is not a user account on the system like root. It is a part of grsecurity and this users cannot be logged into by any remote application. (ie. ssh, telnet, ftp, gnome, kde) you have to take the role of the admin from whichever account you set to allow role transitions.