Re: [PLUG] Mining for Cycles

[Rich Freeman <r-plug@thefreemanclan.net>]

On Thu, Jan 24, 2019 at 10:07 AM Victor <plug@osquat.com> wrote:
>
> > > On 1/24/19 8:39 AM, Rich Freeman wrote:
> > WHEN you get hacked, how will you know that it has happened?
>
> So what is the best advice for identifying a compromise? In this case
> the only thing that tipped off OP was high CPU utilization for
> cryptomining which might not be an attacker's end goal.

I'd be interested in what others have to say.  Keep in mind that
rootkits can hide themselves fairly well - maybe even hiding CPU use.

The old gold standard used to be tripwire.  You boot from offline
media, and tripwire would scan your system and record hashes of all
the non-volatile stuff (/usr, etc).  That would get stored to offline
media.  Then periodically you could reboot to offline media and do a
comparison to detect changes.

This has some big flaws:
* System is down during scanning and hash updating.
* Hashes need to be updated anytime an intentional change is made.
That means doing a before check, an update, and then capturing hashes.
* Working with offline media is inconvenient in general.  Can't do it
remotely/etc.

The problem is that any kind of online solution is susceptible to rootkits.

I think the direction Redhat/others may be trying to move is something
more signature-based.  This isn't practical for rolling-release-type
distros, but probably could work for something like RHEL.  That would
use a secure boot paradigm so that the bootloader is checked by the
firmware, and then the kernel is checked by the bootloader, and then
/usr is a squashfs or something that is checked by the kernel as it is
used.  This eliminates the need for offline checking and distributes
all the signature checks so that they don't become a bottleneck.
However, it requires applying signatures in a secure manner which
favors more static releases that are centrally managed.  If you want
to update something locally you obviously can't just sign it locally
using your super-trusted key, since that makes the key at risk of
compromise.  So, it still requires offline/secure work, but not at the
point of the production system.  The production system applies
pre-signed changes and the kernel doesn't run anything without a valid
sig.

I'm not sure if anybody has anything in-between.  If you have 1000
identical servers that PKI-centric approach makes a lot more sense
than for a one-off desktop.  But, if EVERYTHING you run is packaged by
a distro then it could be made to work - simply refuse to run anything
not signed by Ubuntu/etc.  I don't think any of this has really been
completely implemented, but I believe parts have.

-- 
Rich
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug