[lug] File Signature Monitoring and Encrypted File Systems

Bear Giles bgiles at coyotesong.com
Wed Aug 23 11:53:26 MDT 2017


There's always NFS-exporting the filesystem read-only on an internal NIC
(or properly configured vlan). You run the checks on a second system that's
otherwise isolated.

This has the benefit that nobody on the system being monitored is aware of
the monitoring.

Bear

On Wed, Aug 23, 2017 at 11:49 AM, <stimits at comcast.net> wrote:

> 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.us
> Sent: 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 9585 <(303)%20438-9585>
> http://www.connectdaily.com
>
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: irc.hackingsociety.org port=6667 channel=#hackingsociety
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20170823/28e6a63b/attachment.html>


More information about the LUG mailing list