Print
Close Window
From: www.itworld.com
Re-tooling?
October 17, 2001 —
Consider your to-do list, based on your
security plan. It should include one or more of the following steps:
- Scan the system for known OS holes and fix them
- Check for generic Unix problems and fix them
- Check directory structure for proper permissions
- Check for network-attack vulnerabilities
- Check for bad user (and root) passwords
- Determine who has the root password and if it isn't
needed, take it away from them
- Install tools to monitor the system and generate
alerts when the system file is altered
- Log all network connections
- Limit access to network daemons
- Prevent users from choosing easy-to-guess passwords
We'll address the first half of that list this month, and the rest next
month.
Scan the system for known OS holes and fix them
There are some holes that the available tools do not check for. These
include recent problems, under-publicized problems, and problems
specific to your site. For these, you need to keep alert to current
problems. Methods include the bug list in this
column, CERT advisories, and mailing lists like
"sneakers."
Check for generic Unix problems and fix them;
Check directory structure for proper permissions
The second and third step can be accomplished by two worthy and free
tools.
The tools are Tiger
and COPS.
Tiger is more up-to-date and more inclusive than COPS, so
it's the one I recommend.
(Note: the TAMU ftp server does not seem to respond well to WWW browser
HTML links, so you may need to step back in time and use ol'
ftp to grab Tiger.)
Running tiger (the executable for the Tiger package)
produces an extensive system scan. Depending on the size and speed of
the system, the check can take from 15 minutes to several hours. Also
note that it is CPU and disk intensive. Here is a snippet from the
beginning of its report:
# ./tiger Configuring... Will try to check using config for 'sun4m' running SunOS 5.3... --CONFIG-- [con004c] Using configuration files for SunOS 5.3. Tiger security scripts *** 2.2.3, 1994.0309.2038 *** 12:20> Beginning security report for tanis. 12:20> Starting file systems scans in background... 12:20> Checking password files... 12:20> Checking group files... 12:20> Checking user accounts... 12:20> Checking .rhosts files... 12:20> Checking .netrc files... 12:20> Checking PATH settings... 12:23> Checking anonymous ftp setup... 12:23> Checking mail aliases... 12:23> Checking cron entries... 12:24> Checking 'inetd' configuration... ./scripts/sub/check_devs: bad substitution 12:25> Checking NFS export entries... 12:25> Checking permissions and ownership of system files... 12:26> Checking for altered or out of date binaries... 12:27> Checking for indications of breakin... 12:27> Performing system specific checks... 12:27> Performing check of embedded pathnames... 12:44> Waiting for filesystems scans to complete... 12:44> Filesystems scans completed... 12:44> Security report completed for tanis. Security report is in `./security.report.tanis.950907-12:20'.
One problem with Tiger is that in some ways it is too
complete. The output from the above run, on a standard-installation
SPARCstation 5, was 782 KB. The output can be even more voluminous if
you install the appropriate signatures for your system. These
are secure checksums of system files based on the original release
of the operating system. Tiger compares the signatures to the current
checksums of your system files, and reports any differences. Files
that are different from the standard release may have been
trojan-horsed by miscreants or somehow changed for ill intent. Tiger
includes a limited, built-in list. You can
get an expanded list from the Tiger ftp site
(again, the TAMU server may not permit browser-initiated ftp requests).
Check for network attack vulnerability
SATAN: ftp://ciac.llnl.gov/pub/ciac/sectools/unix/satan/.
Well, this column is four months old, and I've finally had to
break down and talk about SATAN. Alas, the other shoe must now drop.
SATAN is a good tool with a flashy interface. It is designed to be run
on a system other than the one you're testing. SATAN attempts to find
known security holes in a system that would allow it to be compromised
via its network interfaces. SATAN requires Perl 5 to run, which has
definitely limited its appeal. It produces output in HTML format,
so you need a web browser to use it. As you are reading this column
with a browser, that should not be a hindrance.
Unfortunately, some unfriendly types use SATAN to gather information
that can be used to break into system.
Courtney,
distributed as shareware,
can help you tell if SATAN is being used against your systems.
SATAN itself is based on an important security paper:
"Improving the Security of your Site by Breaking Into It"
by Dan Farmer and Wietse Venema. This paper helps you think like a
cracker, exploring your system, looking for chinks in its network
armor, and explaining how any holes could be exploited.
Check for bad user (and root) passwords
There are two ways to approach this problem. One is to install a
program like npasswd (described next month), which
disallows "bad" passwords, and forces users to regularly change their
passwords.
The second way is to find a lot of compute cycles and run
Crack.
Crack uses a set of dictionaries, manipulated by a set of rules, to
try to break each entry in your password file. Each of these attempts
takes time, and the dictionary word must be encrypted and compared to
the password stored in /etc/passwd or /etc/shadow
file. Each rule transforms every dictionary entry in some way. For
instance, by adding the digits 0 through 9 to the end of each word.
Further rules might add those digits between each letter in each word.
You can use the standard set of rules and dictionaries, or add custom
flavors to suit your particular needs.
Improve the security
of your site by
breaking into it.
As you may have guessed, Crack can take a while to run (cracking a
600-entry password file can be done overnight if you have 60 or so
SPARC-class workstations at your disposal). Generally, 10% of
passwords are breakable with this attack.
Determine who has the root password and
if it isn't needed, take it away from them
If you don't know who has the root passwords on your systems, you've
found the first step you need to take toward securing your systems.
Consider a disgruntled employee or contractor who gets dismissed by
your company. You may get notified to remove their account, but if you
don't know they have the root password, how do you know to change it?
According to the Computer Security Institute, 9 percent of security problems
are caused by disgruntled employees. Don't let them go postal on your
systems! If you want to avoid these sorts of attacks, it's probably
worth fighting the political battles to gain control of the root
password.
An important
CERT advisory
was released last month. The bug affects Solaris 2.x systems. It
describes a problem with /tmp directory permissions.
ps is a setuid-root program that creates a temporary file in
/tmp. If /tmp has permissions set incorrectly, a
hacker can use this temporary file to gain root access for the system.
Note that this is not a theoretical problem: An "exploit program" that
can use this vulnerability has already been published.
To correct the problem, check the permissions on the /tmp
directory and determine if the sticky bit is set (a t
should appear in the permissions string reported by ls).
If it is not set, the system is vulnerable. To temporarily fix the
problem:
chimay# /usr/bin/chmod 1777 /tmp chimay# /usr/bin/chown sys /tmp chimay# /usr/bin/chgrp sys /tmp
This fix will go away after a reboot if you are carving /tmp
out of swap space by using tmpfs. Included in the full CERT advisory
are directions on making the fix permanent.
To receive CERT advisories, you can subscribe to the
comp.security.announce
newsgroup or request direct mailings by e-mailing to
cert-advisory-request@cert.org.
CERT advisories are a good way to keep up with known security problems.
Unfortunately, there is usually a delay between when a problem is
discovered and when CERT makes an announcement.
Donald Nichols (dnichols@d-and-d.com) writes in with some good observations:
While overall the information in the page was good advice, it did not mention
either ethernet sniffing, or the two reasonable protections against
that problem.
One-time password schemes are one answer to that problem, fully
encrypted sessions are another. While I realize that Sun does not (yet?)
offer either a one-time password system or fully encrypted sessions,
(the latter would, of course, entail serious limitations on the exportability
of the product), they should be at least mentioned, along with a pointer
into the comp.unix.security newsgroup.
Also, a caveat that no matter how well protected your system may seem,
it is never a safe bet to say that nobody can break in, or otherwise
commit damage. Your page, in neglecting to mention these, could lead
to a false sense of security in your readers.
However, all publication of security practices is to be considered a
good thing, in that it encourages people to think of the possibility
of a breakin, and what can be done to reduce the chances, and to recover
if one does occur.
Nichols makes a good point that systems people should keep in mind.
Establishing secure network connections will be covered in an upcoming
column.
My compatriot Morrow Long at Yale University
has built a low-traffic but high-quality mailing list about firewall
and security evaluation and testing. Check out
sneakers.
A very interesting book about computer crime has just been published:
Computer Crime
by David Icove, Karl Seger, and William VorStorch
(O'Reilly and Associates, 1995). This
book started out as the FBI handbook on computer and crime, but has
been expanded to be a general-purpose and generally useful work.
System managers can detect computer break-ins, and sometimes determine
who the culprit is. The problem is, how do we know if the cracker
broke the law? How can we help ensure the cracker will be punished?
This book explains the law, explains the crimes, and provides a guide
to gathering the information needed to successfully prosecute fiends.
If Computer Crime interests you, you'll be interested in the
Unix and the Law conference sponsored by The Sun
User Group. This second annual conference will be held in Tampa, FL in
November. It features keynotes by key players from the legal side of
computing. I'll be there teaching a tutorial on Introduction to Unix
Security, and holding a workshop on security tools. Hope to see you there.
USENIX also
presents several security-related conferences every year.
Closely related are the Network Security '95 conference and TeleSANS -- a
training program for SunOS security. Sorry I don't have more
information on these. I'll update this page when I hear more.
Next Month, on "As Pete's Wicked World Turns"
Next month we'll delve into the toolchest again to look at packages
that help you restrict access to your computers, as well as detect
when the system is under attack.
Unix Insider