AIDE Intrusion Detection Over SSHFS
To explain why and how I've done this, I'm going to talk a little about my home-security
measures/architecture, which I'm not too comfortable about. However, security-through-obscurity isn't security at all so here goes...
I've used AIDE (the intrusion detection program, not the Android IDE) for years now to improve my confidence that nobody is poking around on the home machines I have open to the internet.
I have my internet-visible machines on their own separate subnet under a dedicated router. I call it a DMZ, even though I'm not 100% sure that's technically accurate in my case.
Anyway, my normal trusted subnet sits under a different router, so I can be fairly confident nothing can get in from the DMZ to my trusted subnet. However, to run the intruder detection checks, I have a machine on the trusted subnet ssh in to each of the DMZ machines in turn (copying the static-linked binary and database over each time before running the check).
Ubuntu and OpenBSD have AIDE packages, which made the process fairly painless. However, problems arose when I tried to set up the same system on a TinyCore server.
I absolutely LOVE TinyCore. It is indeed tiny, and runs in RAM on some seriously old low-end hardware. The recommended minimum specs are a Pentium 2, 64MB RAM, plus some swap space. I'm actually running a chat server on an old thin client I got for a tenner off ebay.
The problem arises because, as far as I am aware, TinyCore does not have a supported AIDE package. My only option seemed to be to compile AIDE from source on another TinyCore machine/VM and copy it across. Bleh. EFFORT.
So I started casting around on the internet for other ideas, and eventually struck on the idea of mounting the TinyCore's filesystem remotely from my trusted subnet and running the check from there with Ubuntu's version of AIDE. As far as I can tell, all the file permissions are replicated faithfully through the remote mount as well, so all the checks I really care about can be carried out.
Performance isn't really an issue for me because it's a small filesystem and I'm running the checks overnight anyway. The server's CPU doesn't have to worry about calculating checksums of the files, or reading/checking against the database. However, it does have to encrypt and shovel all the data over the network.
The process of setting up the check did involve some tinkering. The below steps assume you already have certificate-based root login via SSH on the server. And I've omitted the extra complexities like checking the error codes of each command to debug the damned thing, but for now I believe it actually works!
Thankfully, aide.conf allows you to define macros.
and then on each line specifying a path to check, you prepend @@{BASEDIR}. For example:
Not as simple as I would've liked - umount is only useful for the root user! However, a quick internet search came up with the below:
I've used AIDE (the intrusion detection program, not the Android IDE) for years now to improve my confidence that nobody is poking around on the home machines I have open to the internet.
I have my internet-visible machines on their own separate subnet under a dedicated router. I call it a DMZ, even though I'm not 100% sure that's technically accurate in my case.
Anyway, my normal trusted subnet sits under a different router, so I can be fairly confident nothing can get in from the DMZ to my trusted subnet. However, to run the intruder detection checks, I have a machine on the trusted subnet ssh in to each of the DMZ machines in turn (copying the static-linked binary and database over each time before running the check).
Ubuntu and OpenBSD have AIDE packages, which made the process fairly painless. However, problems arose when I tried to set up the same system on a TinyCore server.
I absolutely LOVE TinyCore. It is indeed tiny, and runs in RAM on some seriously old low-end hardware. The recommended minimum specs are a Pentium 2, 64MB RAM, plus some swap space. I'm actually running a chat server on an old thin client I got for a tenner off ebay.
The problem arises because, as far as I am aware, TinyCore does not have a supported AIDE package. My only option seemed to be to compile AIDE from source on another TinyCore machine/VM and copy it across. Bleh. EFFORT.
So I started casting around on the internet for other ideas, and eventually struck on the idea of mounting the TinyCore's filesystem remotely from my trusted subnet and running the check from there with Ubuntu's version of AIDE. As far as I can tell, all the file permissions are replicated faithfully through the remote mount as well, so all the checks I really care about can be carried out.
Performance isn't really an issue for me because it's a small filesystem and I'm running the checks overnight anyway. The server's CPU doesn't have to worry about calculating checksums of the files, or reading/checking against the database. However, it does have to encrypt and shovel all the data over the network.
The process of setting up the check did involve some tinkering. The below steps assume you already have certificate-based root login via SSH on the server. And I've omitted the extra complexities like checking the error codes of each command to debug the damned thing, but for now I believe it actually works!
Step 1: mounting the drive over SSHFS.
sshfs root@[server ip address]:/ ./mnt/
This will mount the root of the remote filesystem in the local mnt directory.
This can (should?) be done as a non-root user on the local machine doing the check.
Step 2: aide.conf
This took some tinkering because the directory you're checking through is not actually the root of the local filesystem. I couldn't get this to work with relative paths, so I had to put the absolute path into the config.
Thankfully, aide.conf allows you to define macros.
@@define BASEDIR [absolute path to your local mnt directory]
and then on each line specifying a path to check, you prepend @@{BASEDIR}. For example:
@@{BASEDIR}/bin NORMAL
Step 3: running aide - the simplest bit!
aide -c aide.conf
Step 4: unmounting the remote filesystem
Not as simple as I would've liked - umount is only useful for the root user! However, a quick internet search came up with the below:
fusermount -u ./mnt/
Comments
Post a Comment