[Tfug] Automated security checks pupyve6a

[Bexley Hall]

Hi John,

On 2/1/2014 4:59 AM, John Gruenenfelder wrote:
> Greetings TFUG,
>
> Recently, while digging around some of the new packages to find their way into
> the Debian archive, I came across a handful of harden-* packages.  These
> are metapackages designed to offer suggestions for *helping* you to secure a
> system.

I think you need to first define the type of system you are trying to
secure (i.e., how it *hopes* to be used and how you *fear* it can be
ABused).  E.g., a box that (just) accumulates PR's has a different
attack surface than one that has to be a "general timesharing system".

> Here is some of what I've found on my own:
>
> The "logcheck" package, at first look, seems like a great idea.  It scans your
> syslog for suspicious messages and emails you a report.  It performs this by
> having a big database of regex of messages to ignore.  Unfortunately, this
> appears to be a dead project upstream and as a result the database is horribly
> out of date for a current Debian system, and essentially useless if you are
> tracking Debian/testing or unstable.  The email reports are bursting with
> warnings about harmless syslog messages.
>
> After a little more checking, I found that logcheck is actually maintained by
> the "Debian logcheck Team" and that there is some effort underway to resurrect
> and update the package and database.  The webpage they have set up is rather
> sparse and I didn't see any information about when they might put out a new
> useful version.

You can probably hack together a comparable system using something like
spamassasin (or any other trainable SPAM system) and a bit of your time
"feeding it" good/bad log file entries.  This seems more effective
(in the long term) than trying to analyze *all* potential log sources
and building regex's for each type of message (and, having to repeat the
exercise each time you change/upgrade some bit of software)

You could conceivably use such a system to process reports from other
"security" packages.  Sort of an "intelligent agent".

> The "checksecurity" package appears to be broken out of the box.  I was going
> to investigate fixing it, but I found that it was also quite old, limited, and
> very like superceded by newer programs.

Welcome to the FOSS world!  ;-)

> On a somewhat related note, I've been using "denyhosts" for quite some time on
> a few different systems.  Denyhosts is an answer to the problem of idiot
> crackers trying to get into your system by flooding your box with countless
> SSH connection attempts.  They are not trying to exploit flaws in SSH
> implementations, rather they appear to have some database of common account
> IDs and common poor passwords and operate on the idea that eventually one of
> them will work somewhere on the Net.  Denyhosts is a fairly simple
> countermeasure which monitors your login attempt logfile and keeps track of
> the number of failed attempts from each IP address.  It then adds entries to
> the hosts.deny file to keep these people away.

Here there be dragons.  Someone can potentially trick a system like
this into denying *you* access (by masquerading as your machine and
trying to do things that it *knows* you wouldn't like being done;
once these things are detected, a rule is dutifully added that locks
*you* out!)

> There are other viable solutions, of course, such as those that use iptables
> instead of hosts.deny, but I found denyhosts very easy to use and it also has
> a nice feature where users can submit the IPs they block to a central service
> and receive from that service lists of IPs that others have blocked (given
> some useful threshold so you aren't fed bad data).
>
> Just recently, however, I have found that denyhosts is no longer part of the
> Debian archive.  From the bug report leading to its removal it seems that the
> project is dead upstream and has some outstanding security bugs filed against
> it.  The same report recommends the "fail2ban" package as a replacement, and,
> from its description, it appears to offer more features and work with more
> services.  I don't know about the user-data-sharing capability, but that's
> hardly a deal breaker.  The descriptions also says that fail2ban can use
> either firewall chains or hosts.deny.  Is anybody here using either of these
> packages?  What have your experiences been?
>
> A new package to appear in the archive is "libpam-shield".  Its description is
> quite short, but it does indicate that it is used to lock out remote attackers
> trying to brute-force their way in with password guessing and does so using
> iptables.  Since it is a PAM module it won't cover as many services as
> fail2ban appears to.  I have not yet enabled it, but having looked at its
> config file it hits all the important points such as a persistent database of
> IPs and automatic timed expiration of entries.  It also supports blocking by
> null-routing, using iptables, or by using iptables via the ufw firewall
> package.  Has anybody used libpam-shield before?

Same issue as above.

I've taken a more draconian approach with my automation system.  Nothing
can ("physically") talk to anything else without that traffic being
expressly previously enabled (these permissions change dynamically
over time as functionality migrates).  Worst case, a single point attack
can take a single node offline (but, you can't prevent that with *any*
solution!).  And, because the system itself knows who should be doing
what, the rest of the system implicitly knows of such an attack by
the absence of traffic from the afflicted node.

But, this sort of approach won't work for any "general purpose" system
as the communications therein can't be defined a priori...

I'll be interested to see what you come up with!  I've got some (short)
summaries of attack mechanisms that I'll try to locate and forward to
you in PM.  But, they may be at too low of a level for you to
effectively implement without hacking your network stack, etc.

--don