[lug] File Signature Monitoring and Encrypted File Systems

[stimits at comcast.net]

The following is for the question on protecting the files you use to check other files.
 
I've not heard of anyone doing this, but if your tools for verifying were in a loopback mounted ISO9660 formatted file, then the driver itself would not know how to write to the image. If the image is small enough, then it could also be burned to CD or DVD for verifying the loopback image. An ISO9660 file could probably be much larger than any DVD, though I don't know what that limit might be.
 
With a normal journal protected file system you get possible metadata changes (e.g., stats on mount count) even when no actual content changed, so doing a checksum on the file being mounted under loopback for ext4 might show a false positive for change. With ISO9660 there is no metadata for mount counts, and if the file is unchanged, then the checksum of the file being loopback mounted will always be constant (and you can checksum any backup CD or DVD as well to see if the loopback file still matches reference media...yet still have hard drive access speeds). An unchanged checksum on the ISO image file itself would guarantee no content had changed.
 
The ISO9660 loopback file used for loopback mount could have a custom selinux role added, and change or mount requiring a specific user. You could do a custom selinux setup without a loopback mounted file, but it seems easier to just protect a single file than compared to the effort to protect an entire set of tools/directories/files simultaneously.
 
----- Original Message -----From: George S. <georges at mhsoftware.com>To: lug at lug.boulder.co.usSent: Tue, 22 Aug 2017 23:14:41 -0000 (UTC)Subject: [lug] File Signature Monitoring and Encrypted File Systems

I'm going through my PCI DSS compliance checklist and one of the things I need to do is setup some file monitoring. Even though this is a "checklist" requirement, I really do want to come up with the best and most robust solution. Last summer we had an incident where someone tried some cute things to compromise one of our cloud customers. We really took a hard look at a lot of things then, and we're really interested in coming up with the best solution.
Anyhow, I'm thinking I'll set it up file signature monitoring using Aide, and be pretty limited about what I'm checking. With any signature verification system, the rub becomes how do you protect your binaries that you're using to check your signature. I'm thinking that I would setup an encrypted file system and put the binaries and signatures on the encrypted file system. Unless I'm actively doing updates, I'll keep the encrypted fs mounted read-only.
Ideally, I'd like to have two keys for the encrypted file system. One that can mount it read-only, and one that can mount it read-write. I'd like the partition to be mounted read-only at boot time so that periodic signature checks can happen. When I need to update the signatures, I'll re-mount the partition read-write. I know that a deeply compromised system can get around these constraints. My experience has been that intruders usually aren't real subtle and that if I can monitor things that are sensitive, I stand a pretty good shot of finding out something is happening before it goes to far.
I've been reviewing the docs for LUKS and cryptsetup. I see that I can have up to 8 keys for a device, but I'm not seeing anything that lets me say the access level for this key is read-only. Is this possible?
Is there some magically better thing that I could do that would be better than what I'm suggesting? One idea that came to mind was doing the file signature checks from a remote system that's dedicated and (theoretically) secured. I'm thinking perhaps using sshfs or something like that.
I would be interested in hearing what everyone's thoughts are.
-- 

George S.MH Software, Inc.

Voice: 303 438 9585http://www.connectdaily.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20170823/989d69be/attachment.html>