[lug] File Signature Monitoring and Encrypted File Systems

[Bear Giles]

P.S., if you want to go hardcore I believe linux NFS now supports Kerberos
authentication (and encryption). That's a little more effort - you have to
set up a KDC somewhere - but it should give you a lot better security than
standard NFS.

(I'm going to ignore suggestions to forward the NFS port over SSH.)

Bear

On Wed, Aug 23, 2017 at 11:53 AM, Bear Giles <bgiles at coyotesong.com> wrote:

> 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/b659a381/attachment.html>