The Arctic Region Supercomputing Center (ARSC) is part of the High Performance Computing and Modernization Program (HPCMP). This requires developing a defined, testable security profile. Over the last three years, we have developed a security profile based primarily on host hardening.
Host hardening is the process of configuring a host as securely as possible. The focus is on securing each individual host, not the network. Securing every host reduces the vulnerabilities that affect the overall network. Host-hardening is a collection of individual techniques that combined increase the security of the host. Actively reconfiguring system files, regular log review, and installing software for security are examples of host-hardening techniques.
Host hardening has given ARSC the foundation for improved network security and has helped us to develop a more efficient procedure for connecting new or upgraded systems to the network. Host-hardening improves a networked host's ability to thwart attacks from the network, from internal threats, and avoid general system problems. As more computers are networked together, individually trustworthy systems improve overall network security.
In the last two years, we have formalized our system installation procedures and our upgrade procedures. A Cray T3E has replaced an earlier T3D system, a J90 has replaced a YMP, and we have begun upgrading all of our Silicon Graphics Workstations to Irix 6.5. Using an initial host hardening procedure, we can connect a system to the network without compromising our overall security profile before all of the third party security software is installed. We can be confident that we have added the system without violating our security standards and the standards of the HPCMP. This also helps us to become familiar with new systems and begin working them into other system administration procedures.
This paper is not intended to be a comprehensive host hardening guide. The following steps should be the first of many that a system administrator performs to implement good security practices. At the end of the paper is a listing of references (web sites and books) that help to further establish a defined, trustworthy security profile.
The ten steps are:
These are the "first" ten steps is because no third party software is required for implementation. Also, the steps can be implemented while in single user mode, or in multi-user mode on a standalone system and no network connection is needed.
The best time to implement the steps is when a machine is first received and before adding it to the network. However, it is easy to retrofit these steps to machines already connected to a network. At ARSC, we did so starting two years ago in response to regular security reviews, called Security Test and Evaluations (ST&Es). By further developing the steps as an installation methodology, we have become more confident in our security profile and simplified the process of adding a new machine to our network without losing confidence in our security posture.
We have implemented these steps on each UNIX host at least once. When we upgrade an operating system, we carry over locally rewritten configuration files and step through the list. When we add new hardware or hosts, we use this list, saving the original and reconfigured system files on a server created only for system administration. On our Crays and SGI workstations, we have automated regular reviews of system files to ensure that changes are not introduced without our knowledge. We have also tried to implement all ten steps on our network hardware (routers and printers).
1. Configure the /etc/passwd and /etc/shadow files
A host's primary defense is the password file. Many security administrators believe
that if a cracker can get on the system, then they have penetrated too far. Thus,
every account in the password file is a system entry point that needs to be controlled.
Accounts can be divided into user accounts, system accounts and application accounts. User accounts are created to provide authorized users system access. Generally, no special privileges are assigned to user accounts. System accounts are created for managing the system. They have many special privileges and should be carefully managed by the system administrators. If possible, system accounts should not provide external access to the system. Application accounts are system accounts with limited privileges or system access. They are used in the execution of a specific application (or service) and can provide limited system access.
Immediately after an operating system is installed, the system administrator should review the password file containing the base accounts set. The initial vendor delivered account settings are often intended to get the system set up and running as quickly as possible. Security is lessened in favor of ease of use.
A secure password file is characterized by the following properties: every account can be traced to an authorized user; every account has a good password or is locked; and every account has an authorized shell and a valid home directory .
The first property is a user accounts policy and management issue. At ARSC it is our policy to create accounts on all of our systems at one time and only active accounts are allowed to remain on the systems. We define an "active" account as one that has been logged into in the last 180 days. We inactivate accounts after that point on a platform by platform basis. If a user has been inactive on all platforms for more than 180 days, we remove the account from all systems leaving only placeholders so we can reuse the id if the user desires to reactivate their account. System administrators are responsible for system accounts, applications accounts and any placeholders.
Password selection is an art of its own. See Garfinkel and Spafford's "Practical UNIX & Internet Security" [1] for guidelines on selecting good passwords and what makes a bad password. The key point is to make sure that no account is left open for unauthorized persons to use. If an account will not be logged into, it should be locked.
Authorized shells should be listed by the system administrator in /etc/shells. If the account will be accessed externally or has to execute commands, then a standard shell such as csh(1) is required. Otherwise, an approved invalid shell should be used. Commonly /bin/false(1) is used, but at ARSC we use a simple C program that is just an exit call. All home directories should exist and be owned by the account, or by root. Set the permissions depending on how the account is used, but avoid world-write.
When Irix is first installed, no user accounts exist. The initial password file contains system and application accounts. Figure 1 is the initial password file after installing a base Irix 6.5.2 system on a blank disk. There are problems with this password file that, if left uncorrected when the system is put on the network, create serious security problems.
root::0:0:Super-User:/:/bin/csh sysadm:*:0:0:System V Administration:/usr/admin:/bin/sh cmwlogin:*:0:994:CMW Login UserID:/usr/CMW:/sbin/csh diag:*:0:996:Hardware Diagnostics:/usr/diags:/bin/csh daemon:*:1:1:daemons:/:/dev/null bin:*:2:2:System Tools Owner:/bin:/dev/null uucp:*:3:5:UUCP Owner:/usr/lib/uucp:/bin/csh sys:*:4:0:System Activity Owner:/var/adm:/bin/sh adm:*:5:3:Accounting Files Owner:/var/adm:/bin/sh lp::9:9:Print Spooler Owner:/var/spool/lp:/bin/sh nuucp::10:10:Remote UUCP User:/var/spool/uucppublic:/usr/lib/uucp/uucico auditor:*:11:0:Audit Activity Owner:/auditor:/bin/sh dbadmin:*:12:0:Security Database Owner:/dbadmin:/bin/sh sgiweb:*:13:60001:SGI Web Applications:/var/www/htdocs:/bin/csh rfindd:*:66:1:Rfind Daemon and Fsdump:/var/rfindd:/bin/sh EZsetup::992:998:System Setup:/var/sysadmdesktop/EZsetup:/bin/csh demos::993:997:Demonstration User:/usr/demos:/bin/csh OutOfBox::995:997:Out of Box Experience:/usr/people/OutOfBox:/bin/csh guest::998:998:Guest Account:/usr/people/guest:/bin/csh 4Dgifts:*:999:998:4Dgifts Account:/usr/people/4Dgifts:/bin/csh nobody:*:60001:60001:SVR4 nobody uid:/dev/null:/dev/null noaccess:*:60002:60002:uid no access:/dev/null:/dev/null nobody:*:-2:-2:original nobody uid:/dev/null:/dev/null --- Figure 1. Initial Irix 6.5 password file
The seven highlighted accounts have blank passwords, including the root account. At no point during the installation process is the administrator prompted to create passwords. (After the installation, the administrator can use the setup program which does prompt for a root password if the administrator chooses to secure the system.) In the last year, crackers have begun searching out Irix systems and testing whether the administrator has assigned passwords to these seven accounts. Too many times they have not.
At ARSC, most of our Irix systems have no root password. The account is locked with an asterix. On one trusted server, we created a root password from a random string generator. It was written down and locked in a safe. For a while we used su(1) but now we use sudo, a freely available utility for controlled root access with better logging and individual passwords. This trusted machine has root level access to all the other Irix machines, but the opposite is not true. This way we do not worry about attempts to brute force the root passwords or the root login because we have no root passwords to crack.
After running the setup program, EZsetup(1M), four of the accounts, including root, have been assigned passwords. However there are still accounts without passwords that crackers can use to access the system. The system administrator should lock those accounts before putting the workstation on the network.
Figure 2 is the base password file after reconfiguration. Any accounts which we did not want to be externally accessible were given an asterix for a password, assigned an inaccessible home directory and assigned our null login shell.
root:x:0:0:root-sgi I6.5:/:/bin/csh sysadm:x:0:0:System V Administration:/usr/local/homefree:/usr/local/bin/nullogin cmwlogin:x:0:994:CMW Login UserID:/usr/local/homefree:/usr/local/bin/nullogin diag:x:0:996:Hardware Diagnostics:/usr/local/homefree:/usr/local/bin/nullogin daemon:x:1:1:daemons:/usr/local/homefree:/usr/local/bin/nullogin bin:x:2:2:System Tools Owner:/usr/local/homefree:/usr/local/bin/nullogin uucp:x:3:5:UUCP Owner:/usr/local/homefree:/usr/local/bin/nullogin sys:x:4:0:sys-sgi:/usr/local/homefree:/usr/local/bin/nullogin adm:x:5:3:adm-sgi:/var/adm:/bin/sh lp:x:9:9:Print Spooler Owner:/var/spool/lp:/bin/sh nuucp:x:10:10:Remote UUCP User:/usr/local/homefree:/usr/local/bin/nullogin auditor:x:11:0:Audit Activity Owner:/usr/local/homefree:/usr/local/bin/nullogin dbadmin:x:12:0:Security Database:/usr/local/homefree:/usr/local/bin/nullogin sgiweb:x:13:60001:SGI Web Applications:/usr/local/homefree:/usr/local/bin/nullogin rfindd:x:66:1:Rfind Daemon and Fsdump:/usr/local/homefree:/usr/local/bin/nullogin EZsetup:x:992:998:System Setup:/usr/local/homefree:/usr/local/bin/nullogin demos:x:993:997:Demonstration User:/usr/local/homefree:/usr/local/bin/nullogin OutOfBox:x:995:997:Out of Box Experience:/usr/local/homefree:/usr/local/bin/nullogin guest:x:998:998:Guest Account:/usr/people/guest:/bin/csh 4Dgifts:x:999:998:4Dgifts Account:/usr/local/homefree:/usr/local/bin/nullogin nobody:x:60001:60001:SVR4 nobody uid:/usr/local/homefree:/usr/local/bin/nullogin noaccess:x:60002:60002:uid no access:/usr/local/homefree:/usr/local/bin/nullogin nobody:x:60001:60001:original nobody id:/usr/local/homefree:/usr/local/bin/nullogin -- Figure 2. ARSC initial Irix password file.
In Figure 2, all of the password fields have an "x". This is because we use a shadow password file on this system as well. However, we have also locked all of these accounts since we do not allow external access to these accounts. Whenever possible, use a shadow password file. A shadow password file protects the encrypted password strings by removing general access to the strings. This reduces temptation for authorized users to try hacking and provides more security if an initial penetration is successful.
We did not remove the unused accounts from the password file. At one point we removed the accounts from the password file. After an upgrade, the accounts were reintroduced but the userid had been assigned to real users by then. Suddenly, user's files were owned by system accounts, or users owned a lot of files in strange parts of the system. For record keeping, we assigned the users new userids and we leave the unused default accounts in the password file as placeholders.
Unicos and Unicos/mk has a user database (UDB) file to manage accounts and account properties. This has the advantages of being a nonstandard authorization mechanism which is more difficult to crack and provides default password shadowing. The default database is created by a script which is run before the system is delivered. Figure 3 is an /etc/passwd representation of the initial UDB.
root:hv^s0yui4/ase:0:0:UNICOS Root:/:/bin/sh sync::1:1:sync:/:/bin/sync bin:*:2:2:System Binaries:/: sys:*:3:3::/: adm:*:4:4:Accounting:/usr/adm: cron:*:5:0:Chronological Manager:/: nqs:*:6:0:Network Queueing System:/usr/spool/nqs: daemon:*:7:0:System:/: operator:*:9:9:Operator:/:/bin/sh ce:*:10:5:CE:/ce: Idle:*:11:0:System Idle:/: unknown:*:12:0:Default for Fair-Share:/: nobody:*:32:32766:Non-privileged network applications:/dev/null: --Figure 3. Initial Unicos password file.
The sync account is an exception to both the password and authorized shell properties of a secure password file. The account was created to run a single command when at login. Anyone was supposed to be able to login as the sync userid to force the command to execute in emergency situations.
Ten of the accounts have no valid shell. This is not secure as the default on many operating systems is to use sh(1) anyway. At ARSC, we assigned sh(1) to accounts that execute commands. A null-login shell was assigned to the rest.
The root account has a default password (I have substituted a different string in this listing) provided by SGI/Cray. Using a default password is marginally more secure than a blank password. However it is not difficult for the password to become publicly known. Recently, the default diagnostic passwords installed by router manufacturers became the source of security problems at many Internet sites. It is up to the system administrator to make sure that the root password is changed immediately.
2. Configure the /etc/group file
The group file cannot be used to access the system like the password file, but it
does protect access to files on the system. Most often, groups control which users
can access files. If a user is in the proper groups (and file permissions are properly
set) then they can access the files of other users or in restricted parts of the
system.
Groups can also control which programs can be executed. By using groups and the set-group-id (SGID) bit, the privileges of many set-user-id (SUID) programs can be reduced. Because of this, it is important to correctly configure the /etc/group file.
There are several ways of configuring the group file, depending on how the site wishes to use it. One approach, called the "user private group" configuration, assigns every user their own private group as their primary group. The user is then added to any other groups which own files that user wishes to access. The primary benefit of the user private group configuration is that by setting the SGID on shared directories, the administrator guarantees files created in those directories have the correct group. It also ensures that users will not gain accidental access to other user's files in private home directories. For more information on the user private group scheme, see the Red Hat Linux Installation Guide[2].
At ARSC, we use the traditional configuration, basing groups on projects or workgroups and assigning users a primary project. We use the groups to control access to software packages and to grant privileges to groups of users. For example, we have a group of users who have the ability to start and stop a specific daemon on one of our visualization servers. We do not use the password feature of groups, and we rely on users switching effective groups (using newgrp(1)) if they wish to work on projects other than their primary project.
In the last year we have worked to remove user accounts from system groups. On the Crays especially we found that we were adding staff members to groups such as sys and bin just to be able to access files efficiently. This added too many privileges to staff accounts. We created administrative groups and reassigned file ownerships in non-system directory trees.
The initial Irix file leaves the group's password field blank. We inserted an asterix in all of those fields. This was done to resolve a finding from one of our early ST&E visits, and also for better accounting. We decided that users should generate their files and then use chgrp(1) to assign them to other groups. This creates traceable accounting records. On the Crays, the password field is ignored, but an asterix is assigned for backwards compatibility.
3. Configure the /etc/inetd.conf file
The inetd.conf file controls what services are available through the inetd(8) daemon.
This file represents the majority of possible doorways through which a cracker can
enter the system. Unfortunately, as delivered, systems tend to have more swinging
doors than necessary. It is critical to review this file before connecting a system
to the network. Once connected, all of the services are immediately available for
access and penetration.
The general vendor sentiment appears to be to turn on as many services as possible so that if the user wants to use them, they are available without needing administrator intervention. Unfortunately for new system or security administrators, this means many services are available which administrators may not be aware of. At ARSC, we review the inetd.conf file and disable any services that we are not using. Figure 4 lists all of the default services that we disabled after installing Irix 6.5.
http stream tcp nowait nobody ?/var/www/server/httpd httpd wn-http stream tcp nowait nobody ?/var/www/server/wn-httpd -f /var/www/conf/httpd.conf bootp dgram udp wait root /usr/etc/dhcp_bootp dhcp_bootp -o /etc/config/dhcp_bootp.options tftp dgram udp wait guest /usr/etc/tftpd tftpd -s /usr/local/boot /usr/etc/boot ntalk dgram udp wait root /usr/etc/talkd talkd tcpmux stream tcp nowait root internal echo stream tcp nowait root internal discard stream tcp nowait root internal chargen stream tcp nowait root internal daytime stream tcp nowait root internal rstatd/1-3 dgram rpc/udp wait root /usr/etc/rpc.rstatd rstatd walld/1 dgram rpc/udp wait root /usr/etc/rpc.rwalld rwalld rusersd/1 dgram rpc/udp wait root /usr/etc/rpc.rusersd rusersd rquotad/1 dgram rpc/udp wait root /usr/etc/rpc.rquotad rquotad sprayd/1 dgram rpc/udp wait root /usr/etc/rpc.sprayd sprayd sgi_snoopd/1 stream rpc/tcp wait root ?/usr/etc/rpc.snoopd snoopd sgi_pod/1 stream rpc/tcp wait root ?/usr/etc/podd podd ttdbserverd/1 stream rpc/tcp wait root ?/usr/etc/rpc.ttdbserverd rpc.ttdbserverd tcpmux/sgi_scanner stream tcp nowait root ?/usr/lib/scan/net/scannerd scannerd tcpmux/sgi_printer stream tcp nowait root ?/usr/lib/print/printerd printerd --Figure 4. Services disabled in /etc/inetd.conf
We disable even more services such as telnetd(8C) and ftpd(8C) on the machine used for system administration. If we can not identify a need for a specific service, we disable it. This was done in accordance with the security policy of disallowing all but necessary services (the "less is more" approach). If a request for a specific service is made, we evaluate turning it back on. For example, only on our print servers are we running the tcpmux/sgi_printer(8) service.
Disabling services also reduces a host's "Internet fingerprint." Active services can be discovered using port scanning. Which ports are active indicates what services a host is executing. Generally, any information which can be discovered about a host without actually logging in is considered a host's Internet fingerprint.
Controlling this information improves the host's security by reducing the amount of knowledge a cracker has about the host. Several months ago, crackers were scanning for the tcpmux/sgi_printer(8) service. This service is unique to Irix workstations. Once an Irix workstation is identified, crackers would look for accounts with no passwords. If a host is not a print server, it does not need the sgi_printer(8) service.
4. Configure the /etc/rc or /etc/init.d files
The system boot scripts also initiate network services, such as sendmail(1M), as
well as local services, such as the file alteration monitor (fam(1M)). These services
provide external access as well as internal access to system activity, so it is important
to review whatever daemons are started at boot time and configure them properly for
the same reasons that the inetd.conf file is reviewed.
Irix uses a SYSV startup file system. The scripts reside in /etc/init.d. The scripts are invoked when init(1M) executes files in /etc/rc[023].d (via /etc/rc0, /etc/rc2, and /etc/rc3). Those files are links to the actual scripts. Links starting with an "S" are startup scripts and links starting with a "K" are shutdown (or kill) scripts. A number follows the "S" or "K" in the file name. The lower the number, the sooner that link executes. Irix also uses the chkconfig(1M) command to set flags (stored in /etc/config) used by the system scripts to decide whether or not to invoke a daemon.
Because init(1M) and the rc scripts execute as root, many of the daemons started at boot also execute as root and never stop executing. If not properly written, these running services can provide possible exploitable avenues to access the system, or access the root account.
The best defense is to disable any services/daemons not being used. If the daemon is not running, it generally cannot be exploited. At ARSC, we have disabled autofs, bsdlpr, ipaliases, lp, ntp, pcnfsd, sendmail, sharity, and snetd since installing Irix 6.5. We have also enabled the verbose flag and added set -x to /etc/rc2 so we will see the commands executed during the boot sequence. Sendmail is enabled on our mail server and backup mail server but nowhere else. By disabling the services, we do not worry that our machines will be accessed via the ports opened by listening daemons.
Of the remaining daemons which presumably have to be running, try to run secure replacements or install the latest version of that deamon. For example, we have installed our own printing software (LPRng by Patrick Powell) to replace the default software. Using a more secure replacement, or at least using the most up to date version of a daemon reduces the possibility that a known vulnerability exists which affects that daemon.
If a daemon is being used, then try executing it as a userid other than root. Using su(1M) -c, the startup script can execute a daemon as a user such as guest. At ARSC, we run our license server as guest. As long as the log file is writable by guest, and the license data files are readable by guest, we do not worry about unauthorized persons trying to use the license port as a access point. The daemon listening on that port has no privileges on the system in general.
The Crays use their own startup system. The brc, bcheckrc, rc, rc.mid, rc.pre, and rc.pst(8) scripts in /etc execute the startup scripts. By adding a daemon invocation to one of the rc scripts, that service is added to Unicos startup. A Cray administrator should be very familiar with these scripts and how to modify them safely. Most of the modifications on ARSC's Crays are made in rc.pst(8) and only with the approval of the Cray security administrator.
Any entries in the rc scripts should have comments indicating their purpose and when they were enabled. This provides a history and a change management scheme that helps troubleshoot future problems.
5. Review all set-user-id programs
Exploiting set-user-id (SUID) programs is the most common method of increasing one's
privilege. SUID programs, grant a user privilege by assuming an alternate effective
userid during execution. The most common alternate id is root. This allows a user
to access system level privileges long enough to perform proscribed actions. Due
to many programming errors, SUID programs are also a major security hole. For more
information on the programming errors, and how to fix them, see the paper "Secure
Programming in the UNIX Environment"[3].
To manage SUID programs, the first step is to find and record them. The simplest way is to issue the following command as root: find / -perm -4000 -exec ls -ld {} \; This generates a long listing of every SUID program, no matter what the userid. This list should be stored where only the administrator has access. At ARSC we use this information to monitor a system's SUID programs and make sure no new programs appear without our knowledge. We use checksums (md5 or sum(1)) to ensure he known programs do not change. (A file integrity checker such as tripwire does the same thing.)
Next review each SUID program and decide whether to a) keep the privileges, b) downgrade the privileges, or c) remove the privileges. Using these three categories, we have created a file listing all of our SUID binaries, their permissions before and after modification, the file owner before and after modification, as well as the size of the program. Using this list, we can monitor the SUID programs to make sure they do not change without our knowledge.
Many programs, such as system administration utilities, have SUID privileges as a convenience, not as a necessity. The SUID bit on those programs should be removed. If it is necessary to execute the program as root, then the administrator should become root to do so. Su(1) or sudo are two common utilities for executing programs as root.
If a program only uses SUID privileges for file access, for example passwd(1), the administrator should create a new group, assign that group to the file(s) being accessed and the SUID program, and then downgrade the SUID privilege to set-group-id (SGID) privilege. By adding users to the new group, the administrator permits them to perform the privileged file access. This adds accountability and security to previously unrestricted privileged operations.
After removing, or downgrading, as many SUID privileges as possible, the remaining programs should be wrapped to control the inputs. By doing so, the administrator reduces the possibility that the program can be exploited. Most SUID exploits require inserting malicious code in the program's input. This code is executed by exploiting poor memory management (referred to as "exploiting a buffer overrun").
Irix 6.5 contains 70 to 75 SUID programs, most of which are root owned. At ARSC, we have permanently wrapped six because we consider them too prone to exploitable errors. Those six programs are lp(1), xterm(1), iwsh(1G), xwsh(1G), mail(1) and mailx(1).
Unicos 10.0.0.1 contains almost 150 SUID root programs. We have not completed a full investigation of these programs, mostly because of the number of them, but also because in our experience, exploits of Cray SUID programs are not common. However, it is a current project to finish such a review in time.
Another goal at ARSC is to implement the new capabilities function available with 6.5. Capabilities allow the administrator to limit a privileged program to very specific actions. However, even after applying capabilities, we will still use wrappers for logging and intrusion detection.
6. Review all set-group-id programs
Set-group-id (SGID) programs also provide users increased privileges. Generally,
a program is SGID so that it can read or write a file or directory. That is why SGID
permissions are perfect for downgrading SUID programs that only use privilege to
read and write files. The administrator must protect the rest of the system from
this privilege though. SGID programs are commonly exploited as one step in taking
control of a system. Thus they should be handled like SUID programs.
SGID programs should be documented and reviewed like SUID programs. Again, start by listing out all the SGID programs on the system. As root, execute the command: find / -perms -2000 -print. The permissions should be removed from any programs users will not use and the remaining programs should be wrapped.
As mentioned before, SGID programs can be created to reduce the privileges of SUID programs. They can also be used to protect files owned by groups like root, bin, and sys. For example, programs that access the /dev/kmem(7) filesystem under Irix. gr_osview(1), xload(1), w(1), arp(1M), netstat(1), sadc(1M), top(1), ipcs(1), gr_top(1), osview(1), dkstat(1), and fuser(1M), all access core memory which is a privileged operation. If the program can be exploited, then the memory space of any user's process can be accessed. Since most the programs are installed SGID root, if they can be exploited, it could be possible to affect files in any directory owned by the root group.
To avoid the second problem, we created a new group named "kmem". The kmem device file was assigned this group and the world access permissions were removed. All of the above programs were assigned the kmem group. In the case of gr_osview(1), the root SUID permissions were also removed. These actions protect the system from 12 SGID programs without affecting the functionality of those programs.
7. Review all world-writable files
As much as possible, world writable files should be removed from the system. On their
own, world writable files are not security problems. However, world writable system
files (specifically directories) provide opportunities for privileged programs to
be exploited. World writable user files mean that user's data can be accessed and
altered by anyone.
World writable directories create the possibility that a malicious user can interfere with other user's work or with system activities. Symlink exploits, tmp races[3] and accessible private files are problems created by the existence of world writable directories. By removing the world write permission, these problems are negated.
Upon installing the system, the administrator should record the world writable files, just like SUID and SGID files using: find / -perm -0002 -print. This list should be reviewed periodically to check if new files appear. Tools such as tiger or tripwire are helpful to maintain file integrity. A perl script comparing the stat() output of a live binary against a recorded image does the same thing.
Temporary work directories, such as /tmp or /scratch, are useful for users as extra work space outside their home directories. To avoid users deleting each others files, the "sticky bit" should be set on the directory. Creating individual user subdirectories without world access provides an extra layer of protection since only the user or their group can access the subdirectory. These directories should be created and removed as part of managing user accounts, just like the home directory. Users only need to set their TMPDIR environment variable and well behaved programs will respect this system modification.
8. Install wrapper programs to mediate any remaining problems
Wrapping a program is simple, but requires a little preparation and research into
the operation of the program being wrapped. The administrator should identify all
the required environment variables and input characters that the program uses. Then
the wrapper is programmed to filter out all but those variables and input characters.
Every variable and command-line input is also limited to a specified number of characters.
The original program is renamed "program.real" and all special privileges
are removed. The wrapper program replaces the original program and assumes its privileges.
The wrapper executes the original program after screening the command-line and environment
variables. The wrapper program we use at ARSC is available via the web at ftp://ftp.arsc.edu/private/lforbes/sct/wrapper.c.
The basic structure of the wrapper is simple, but the administrator can compile in additional checks when compiling it. Figure 5 is an outline of the wrapper used at ARSC.
Initialize string constants such as the full path to the real program, maximum string lengths, the allowed character mask, and the allowed environment variable list Check that an environment exists (used by interactive programs) Check that USER & uid can be found in /etc/passwd (paranoid option) For i=1 to argc rewrite each character using a character mask if string length > predetermined value, error out For i=1 to length of envp drop any variable not in predetermined list rewrite each character using a character mask if string length > predetermined value, error out if variable is suppose to be the user name but isn't, error out (paranoid option) Create the new environment variable array Execve real program with new environment and safe argument strings --Figure 5. Outline of ARSC security wrapper
When compiling the wrapper, statically link the resulting binary and then strip out the symbol table using the strip(1) command. Statically linking the binary helps protect the program from someone trying to substitute their own libraries for standard system libraries. Stripping the binary helps to conserve disk space.
9. Install all vendor [security] patches
One of the difficult tasks of any system administrator's job is keeping up with vendor
patches. Making sure that the latest patches are installed, and work, requires time
and effort. The more systems a site has, the more time and effort is required.
Many vendors now distribute their patches via the web, including SGI. Security patches for the Irix operating system can be downloaded from http://www.sgi.com/Support/security/security.html. These patches are free for the taking. Sometimes patches take a while to become available. In the meantime, using wrappers and monitoring privileged programs helps to maintain system security.
As a general rule, we try to install any security patches as soon as they are available. Sometimes this is not possible, or a patch is not available when a problem is discovered. In those situations, we take steps to make sure that our systems are not vulnerable. If a privileged binary is involved, we remove the privileges. If a writable file is involved, we remove the write permissions. This may affect users, but generally it is possible to find or create a usable workaround until a vendor patch is available.
Unicos is a slightly more difficult system to patch. Source patches are not available to the majority of customers. Nor is there a systematic approach to binary patches. Security fixes are rolled into operating system upgrades. Unfortunately, this is not a practical solution to fixing security holes as soon as they are found. In between upgrades, local modification of permissions and programs is required to maintain a secure system.
For both Irix and Unicos, a regular patch/upgrade schedule should be established. During each iteration, the available security patches should be reviewed and installed if applicable. By having a regular schedule and procedure, the workload can be reduced as well as spread out among multiple administrators. A regular schedule also helps to ensure that the latest security patches will be installed. At ARSC we try to maintain a quarterly schedule of patches or upgrades.
SGI has a new product, called RoboInst, for automatic upgrades and system patches. This software uses a central server to distribute the upgrade or patch to specified Irix systems. We have not had time to test RoboInst, but the system administrators at SGI have been using it for several months and report that it works very well.
10. Turn on and configure the system auditing software
Both Irix and Unicos have builtin auditing features that can be used to monitor security.
Under Unicos, this is part of the Multi-Level Security (MLS) software. Auditing allows
the administrator to monitor use of privilege, files accessed, files deleted, as
well as device usage such as network ports and hardware devices.
It is important not to audit too much information though. Usually auditing software requires a minimum disk space or it will reset the system to single user state to make sure no actions occur that are not audited. Auditing too much information can overflow the filesystem and stop general execution until more space is made available.
At ARSC, we have enabled the auditing system on our Crays. Figure 6 lists events from the config tool that we are auditing to monitor the use of privilege. Our main goal is to be able to track and recreate the use of privilege without overflowing the filesystem.
Log discretionary access changes? ON Log discretionary access violations? ON Log all directory make (mkdir) violations? ON Log all directory remove (rmdir) violations? ON Log all link (ln) violations? ON Log all remove violations? ON Track all path names on accesses? ON Log all su attempts? ON Log all setuid requests? ON Log name and password on login password fail?ON Log use of privilege? ON Log operator actions? ON --Figure 6. Auditing options to enable
We have had to turn off a few options which would indicate the use of privilege because of a lack of space. Some auditing options generated more records than we expected, so until we are more prepared to manage large audit logs, we disabled logging "mandatory access violations," "trusted process activity," and "security system calls."
Continued monitoring of logs, and file integrity, is necessary to keep the system secure. Everyday we check that privileged files and configuration files have not changed unless our technical services group knows who made the change and why. We are continuously updating and combining our log reduction scripts to efficiently review the system and audit logs from all of our workstations and high performance systems on a regular basis. Log review generally falls to the "oncall" person. That person is backed up by the entire technical staff on a regular basis with several administrators follow the logs at their own workstation by tailing the SYSLOGs.
Using host hardening techniques, it is possible to better protect the entire network. There are fewer possible entry points and those that remain are better controlled. The ten steps described above are the techniques that we have employed at ARSC to successfully pass two ST&E's. Since running these ten steps on our networked UNIX hosts, we have had no problems with unauthorized access or system usage.
Conclusion
It is important to match the effort of securing a system to the importance of the
system. All ten steps are not necessary on systems that never connect to the network.
Nor are all ten steps necessary for machines that sit in front of a firewall. Analyze
the risks that each system will be exposed to and determine how secure the system
needs to be. Once the analysis is finished, it should be written down and put in
an accessible library (on an intranet for example). The documentation and storage
of security procedures is not fun, but it is necessary for a strong, maintainable
security posture.
We encourage anyone who works with UNIX systems and computer security to regularly employ these ten steps. After every upgrade, we redo the above ten steps. After any system modification, we redo many of the steps. We believe that these steps can be the basis of a strong, host based security posture.
Works Cited
Further Security References