Unix Insider –
Consider your to-do list, based on your security plan. It should include one or more of the following steps:
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.
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."
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
<font face="Courier">COPS</font>, 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'
<font face="Courier">ftp</font>to grab Tiger.)
<font face="Courier">tiger</font>(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:
<font face="Courier"># ./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'. </font>
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).
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.
There are two ways to approach this problem. One is to install a program like
<font face="Courier">npasswd</font>(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.
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.
<font face="Courier">ps</font>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
<font face="Courier">t</font>should appear in the permissions string reported by
<font face="Courier">ls</font>). If it is not set, the system is vulnerable. To temporarily fix the problem:
<font face="Courier">chimay# /usr/bin/chmod 1777 /tmp chimay# /usr/bin/chown sys /tmp chimay# /usr/bin/chgrp sys /tmp </font>
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 firstname.lastname@example.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 (email@example.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.
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.