Root Logins (Sco Unix)

[Bill Campbell]

On Sat, Jun 02, 2007, Fairlight wrote:
>>From inside the gravity well of a singularity, Bill Campbell shouted:
>> 
>> One can further tighten this by using secure shell with tcp wrappers
>> support (e.g. libwrap), restricting the IPs, networks, and/or domains that
>> are permitted to access the system.
>
>Something I do for my own machine, but which is not always viable for a
>customer site.  I have a client that cannot employ IP blocking for ssh
>because some of his customers are on dynamic IP.  Likewise, I've had
>customers that have -employees- that are on dynamic IP.  Actually, a fellow
>consultant is on a semi-dynamic IP, but it changes infrequently enough that
>we just change the allow address when it changes every so many months.

We use tcp_wrappers hacked with RBL support so that we can use a DNSRBL to
ALLOW connections as well as DENY things.  We maintain a ``white list'' RBL
which lists sites here and at our customers which are used by tcp_wrappers
as well as for things like allowing sites to use other services.

Most of our client's machines ``check in'' to one of our support machines
every fifteen minutes which is partly a check to insure that they're still
alive and well, and also checks thr IP they connect with to the DNS for
their host name.  When a dynamic IP changes, it generates an e-mail message
saying that the dynamic IP has changed, and if we're authoritative for
their domain, we update the DNS for them.  It also updates a mysql table
that's used by postfix to allow relays from that IP address, which is
critical as many of our customers on broadband connections can't send out
e-mail on port 25 so we have them sending through our servers on a
different port.

>There really are things to be said for static IP.  It's a bity ARIN is so
>miserly about it.

Often one can get static IP addresses at fairly reasonable prices from
broadband providers.  I think QWest has a single static IP and a minimum
block of 8 addresses for under $20/month.  Their single static IP is of
limited use as AOL and some other ISPs consider this to be dynamic
residential, and won't allow direct access to their mail servers from these
static IPs.

>> Jun 01 10:34:28 beta3 <info> sshd[16941]: Failed password for root from
>> 192.168.254.225 port 280
>
>I wrote something for a client that counts failures in that vein from every
>address.  On the 10th password failure from one address, it adds an entry
>to hosts.deny for the host.  No more happy cracking for them.

This is built in to swatch.  I have it running on some heavy load openldap
servers that sometimes get into a ``too many open files'' state, and I have
swatch watch the openldap logs for three of these messages in a 10 second
period, then it runs a script that restarts the openldap server which
generally clears the problem for a while.

>> As a general rule, if a machine has been cracked, one should reinstall from
>> scratch.  If one is running good intrustion detection software that can
>> identify changes in critical files, detect new files, and deleted files, it
>> is possible to clean up a cracked system, but this requires creating the
>> database for comparison before exposing the system to the world, and
>> constantly monitoring for changes.
>
>Something like The Coroner's Toolkit, from what Bill Vermillion has
>mentioned repeatedly, is something to be checked out in this regard.

I've written a program to do this that uses the tripwire configuration
files.  We used tripwire for many years in spite of it's problems with
whitespace in file names, and I had been meaning to do a rewrite for
several years.  I finally got around to it when I couldn't get tripwire to
work on 64 bit machines so spent an afternoon writing my python scanner.

IHMO one of the most important things in an intrustion detection system is
that it produce minimalist output so that it's easy to detect changes (e.g.
they're not lost in the middle of huge reports), and that keeping the
database of attributes for all critical files and directories up to date.

>Personally, I find it's actually better to just bite the bullet and do a
>reinstall.  It goes faster than forensic analysis in most cases, for one.
>And even if you do the analysis and believe you got it all, if you miss
>anything important you can end up doing the same dance again in a day to
>a week.  There's more peace of mind in -knowing- you got the situation
>entirely cleaned up and sealed.
>
>I saw someone get hit with a worm at one point on a linux system, and
>of course there's -no- forensic anything on the system.  I recommended
>a complete reinstall but was shot down for financial reasons.  They
>insisted I just do my best to clean it.  I make -very- sure they realise
>the risks and take full responsibility if they pass on doing the right
>thing like that.  I'm good, but nobody's 100% good, 100% of the time.  I
>don't like that doubt hanging there.  You -think- you got it all, but
>unless you literally go through the whole system file by file, you may
>be missing something critical.  I've seen parts of rootkits stored in
>/usr/share/locale at least twice on systems I was brought in to diagnose.
>That's a pretty obscure hiding place--and actually very smart, since there
>are a cartload of files and most people probably wouldn't look there.

If I'm being pedantic, I'll agree with that, particularly if there was no
prior planning to detect changes.

On the other hand, the daily scanning routines I've written do look through
the whole system file by file with particular attention to setuid files,
and critical directories (/bin, /sbin, /etc, ...).  They use a Berkeley
btree file to keep track of all the file attributes returned by the stat()
command, as well as MD5 and SHA1 digests of critical files allowing them to
detect any changed files.

It also is useful to check for compiled executable programs in the /tmp,
/dev, and /var/tmp directories as these are frequent hiding places for the
crackers tools.  On systems that support it, one can mount things like
backup directories with the ``noexec'' option which keeps crackers from
hiding useful tools on them.

If it's a Linux system using RPM, then ``rpm -V'' is quite useful to detect
changed system files.  So far I haven't encountered crackers who have
managed to fiddle the RPM database.

I have seen fairly frequent exploits via webmin and usermin, some of which
have exploited the ``chfn'' command to gain root access to SuSE Linux
systems.  The default configuration for usermin permits root and other
administrative logins, and it requires reading the install setup scripts to
figure this out as the installed configuration files contain no comments or
commented out options.

As a general rule, we give users the shell, /bin/false, unless they
explicitly need shell access.  One could give them a ``shell'' that invokes
FilePro only, exiting to login without permitting shell access (other than
through FilePro or developer installed back doors).  We had one instance at
an ISP customer where /bin/false had been replaced by /bin/bash (before we
installed our security scanning stuff).

Bill
--
INTERNET:   bill at Celestial.COM  Bill Campbell; Celestial Software LLC
URL: http://www.celestial.com/  PO Box 820; 6641 E. Mercer Way
FAX:            (206) 232-9186  Mercer Island, WA 98040-0820; (206) 236-1676

``People from East Germany have found the West so confusing. It's so much
easier when you have only one party.'' -- Linus Torvalde, Linux Expo Canada
when asked about confusion over many Linux distributions.