[Tfug] Automated security checks pupyve6a

[John Gruenenfelder]

On Sat, Feb 01, 2014 at 12:30:22PM -0700, Bexley Hall wrote:
>Hi John,
>
>>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".

Okay, another email thread I neglected for far too long before replying.  :)

What I was intending by "automated" was a utility that requires
not-too-extensive configuration while still providing some useful feedback.
This would most likely mean a distribution provided package as the maintainer
would have done a lot of the leg work to make it work semi-seamlessly on
target distro X.

In my case, I have several machines configured in a number of different ways
so, for the Net accessible ones anyway, I don't want to a package to require
hours of configuration work to get it to function properly without multitudes
of false positives.

In particular, I have my "closet server" which nominally runs Debian/testing.
My main work/development machine (I'm the admin, but it has a small number of
other users) also nominally runs Debian/testing.  Both of these machines
occasionally pull from Debian/unstable in case the machine, myself, or a user,
needs some software that's too new for Debian/stable/testing.  Finally, I have
another seldom (few other tasks than sitting on the Net and serving the random
file) that runs Debian/stable.  If you know much about the Debian archive, you
can see that each machine can (and is likely) organized rather differently or,
at least, contains vastly different software versions.

I guess, in a nutshell, I'm looking for a tool that will periodically scan my
system for questionable security issues *and* make sure I haven't made some
stupid mistake that could have a real-world security implication.  The tool
"rkhunter" fits this bill fairly well, I think.  See below for my impressions
on it.

>>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".

I can see this potentially working, but I think the needed training set would
be far larger than the logs I have available on these systems.  Unlike mass
spam, log entries are just going to be too different, even for valid entries:
timestamps, hostnames, path names, differing config entries, etc.

Despite the workload, I do think the extensive regex method is probably
better, though it has the big disadvantages of requiring a lot of assistance
from *other* package maintainers along with the need to be frequently
monitored/updated.

At the very least, this is a lot more work that I'm looking into puttint into
this (presently, anyway).


>>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!)

I'm not sure I follow.  The tool tracks IP addresses and it blocks users for
either a) too many failed login attempts, or b) too many connection attempts
in too short a time.  How might somebody use this against a valid user?  If
they knew of a username that was valid on the target host they could
conceivably block access to that user FROM that IP, but how could they deny
access for that user who will likely be connecting from a different IP?  In my
experience, Denyhosts did its job very well and I only ever had to manually
purge one entry from the DB when a valid user accidentally failed too many
times (caps lock key mistake, I think).

>>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?

I eventually decided to go with libpam-shield.  So far, I found it to be
extremely easy to configure and easy to use since PAM config on Debian is so
easy.  By occasionally monitoring the logfiles, it appears to be operating as
it should.

The documentation could be a bit better, though.  For example, as I mentioned
above, Denyhosts would block when, from a given IP, a valid user account login
failed too many times *or* if that IP made too many connections in a given
time span (say, 10 connections in five minutes).  From the logs, I know that
pam-shield will block based on the second type of attack, but I don't know if
it also blocks based on the first.

At any rate, I'm happy enough with its performance.  Also, this type of attack
seems to fallen out of favor in recent times.  When I first installed
denyhosts, the machine was literally being hammered all the time by script
kiddies trying this stupid (and unlikely to every actually work) method.
Today, it doesn't seem to happen nearly as often.


During my investigations, I tried a number of other tools.  In particular, I
gave the intrusion detection system (IDS) "Samhain" a try.  Based on its
apt-provided description, I liked its supported features.  Unfortunately, as I
mentioned above about how my machines are configured, the installed software
simply changes *far* too often for an IDS to work effectively.  For any IDS to
work properly, the software, and therefore the computer hash signatures of
that software, simply can't change too often otherwise the tool will
constantly be detecting changed binaries and complain.

Samhain *does* have the really nice feature of natively supporting the usage
of "prelink" which, if you don't know, pre-links binaries and some libraries
so that there is less work for the linker to do when you initially run a
program.  Of course, this alters the binary and and hash computed over its
contents.  Since I do have one machine running Debian/stable and its software
rarely changes, I may still try using Samhain on that machine and see how it
goes.


Finally, there is my old standby security tool "rkhunter" that I have been
using for quite some time.  As its name implies, its primary focus is to scan
your system for rootkit installations by looking for their telltale
signatures.  That's good.  It also performs a number of other useful security
checks for you.  That's also very good, and, in fact, it's the real reason I
use rkhunter.

So, along with the RK scanning, rkhunter also keeps a properties DB on a small
handful of files (far smaller than a true IDS) so that it can detect changes
in them: things like user/owner changes, suid bits, etc.  In can also check
the hashes of these files, if configured, and also has support for systems
using prelink.  I'm not using it, but rkhunter can also work with certain
package managers to, like an IDS, verify that a file's hash matches what the
package manager thinks it should.  rkhunter is also nice enough to have a
aptitude hook so that its properties database is updated whenever you finish
an install/uninstall action with aptitude.

There are also several whitelist/allowlist directives so you can specify
files/directories that *you* know are okay to have.  This way, rkhunter won't
trip up and emit warnings about those particular items.  It also checks
enabled inetd/xinetd services to warn (again, there's a whitelist for this,
too) about enabled network services of questionable use.  Checks are also done
on user/group/shadow files to alert you to changes.  These warnings are only
emitted once, but it's still nice to know when a user/group has been added to
the system.

rkhunter can also check for hidden processes, ports open to the Net (whitelist
for this, too), and can check some options in the configuration of certain
programs, like SSHD.  For example, it will make sure that rkhunter's setting
for allowing remote-root SSH logins matches what is in the sshd_config file
(this is what I referred to above as having a tool look out for stupid
mistakes).


One of the best features of rkhunter (I'm using ver 1.40, BTW) is that it
performs a *lot* of useful work out-of-the-box without needing to be heavily
configured.  There are sometimes a small number of false positives, such as
Java JREs/JDKs that like to install the hidden /etc/.java directory.  I also
like to enable the by-default disable "hidden process" detection ability.
Still, it's possible to use rkhunter in a useful manner and in a very short
time.  Even though I'm not really that worried about rootkits, because of all
of its other features, rkhunter is one of the tools I invariably install on
any Net-facing machine.


Don, thanks for the DDOS documents.  They were interesting, especially the
DDOS taxonomy list.  I'm glad I don't have to deal with this sort of thing...
:)


-- 
--John Gruenenfelder    Systems Manager, MKS Imaging Technology, LLC.
Try Weasel Reader for PalmOS  --  http://weaselreader.org
"This is the most fun I've had without being drenched in the blood
of my enemies!"
        --Sam of Sam & Max
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://tfug.org/pipermail/tfug_tfug.org/attachments/20140302/199801ea/attachment-0001.bin>