previous  next  Title  Contents  Index        Previous     Next      Top   Detailed TOC  

Securing UNIX: Part 1/2


UNIX was not designed to be a secure operating system. It was designed to be flexible, "open", portable and simple in concept. Now, at 28 years of age, UNIX is one of the major server operating systems and looks likely to remain so in the coming years. However it is causing major security headaches. Most vendors have improved security over the years, with the result that the current systems are better than their precedents, but vendors still don't put nearly enough effort into cleaning the UNIX source code, or can't (for compatibility). Technical innovation seems to be the major selling point for UNIX systems and security is being neglected. It requires significant system administrator know-how to run UNIX systems securely. [The same applies for VMS and NT incidentally]

UNIX has many variations, for example: Next, SGI, AIX, HP-UX, AUX, SunOS, Solaris, SCO, Ultrix, Digital UNIX (OSF/1) and Unixware. The UNIX trademark now belongs to X/Open Ltd. UNIX has two principal flavours: BSD (developed at Berkeley University) and SYSV (System 5 from AT&T, later USL, Novell and now SCO).

SVR4 and OSF are based on both BSD and SYSV with SVR4 being the defacto standard today. Most commercial systems are based on SVR4 or have certain components from SVR4. DEC, IBM and HP systems have lots of OSF features.

BSD: SunOS (Solaris 1.x), BSDI, Ultrix, OSF/1, NeXTstep, HP-UX, OpenBSD, NetBSD, FreeBSD.
SVR4: Solaris 2.x, HP-UX, Unixware and (sort of) IRIX5, HP-UX10
OSF: Digital Unix
Weird: AIX (SVR3+BSD+OSF+IBM). AIX is a mixture between BSD, System V release 3 and major non-standard changes. Hardly any subsystem in AIX is managed in the same way as on BSD or SVR4. Lot's of fun to administer.

In this section SunOS (Solaris 1.x) and Solaris 2.x are mainly considered. AIX, Digital UNIX, IRIX and HP-UX will also be added bit-by-bit. However, most of these systems are similar to either SunOS or Solaris, so this chapter should be useful for non-Sun admins.

A quick guide to securing UNIX



Ref. Document number  Title Date Author
[unix1] ISBN 1-56592-148-8  "Practical UNIX Security", O'Reilly & Associates. 
2nd Edition in April 1996 (much bigger) 
June 1991  Garfinkel / Spafford 
[unix2] Unixworld magazine  Encrypting Shell Scripts  Sept. 1992  R. Schwartz 
[unix3] ISBN 0-201-63357-4  Firewalls and Internet Security  1994 Cheswick / Bellovin 
[unix4] ISBN 0-13-149386-8  Panic! UNIX system crash dump analysis.  1995 Drake / Brown 
[unix5]   Solaris 2.5 Documentation: 
"System Administration Guide, Vol2" 
1995 SunSoft
    Solaris 2.5 Documentation: 
"System Administration Guide, Vol1" 
1995 SunSoft
  ISBN 0-13-151051-7  UNIX System Administration Handbook, 
Prentice Hall 
1995 Nameth /Snyder.... 
  ISBN 1-56592-124-0  "Building Internet Firewalls", O'Reilly & Associates  1995 Chapman / 
    Solaris 2.5 Documentation: 
"SunSHIELD BSM Guide" 
1995 SunSoft
  SunWorld The Solaris Security FAQ (online)
SunWorld security columns
Peter Galvin
P.Galvin/Carole Fennelly


For assurance choose an OS version which has been certified to ITSEC or TCSEC levels. See the "Operating System Overview" chapter. Most UNIX versions are available with C2. 

"C2" for SunOS4

This package should allow a solaris1 machine to conform to C2 level security. Practical experience shows that it is difficult to administer, requires many patches, is complex, provides huge logs and even writes clear text passwords to these logs. It is recommended to upgrade to Solaris 2, rather than use this package. 

Principal dangers / problems


Identification / authorisation


Standard UNIX identifies users through user ids (UID), which are a number attributed to the user's login name. Users are authenticated by use of a password.

Standard UNIX authentication methods (telnet, ftp, "r" commands, NIS) are easy to cheat on a network of UNIX machines, if a user has root access to his own workstation. 

UNIX accounts: General Guidelines

Most of the following guidelines are tested by utilities such as COPS, TAMU Tiger, ESM and SecureMax:

Solaris 2: /etc/default/passwd, /etc/shadow, commands nispasswd, passwd, admintool
Solaris 1: passwd, yppasswd
HP-UX:  In trusted mode, see /tcb/files/auth/..
AIX:       /etc/security/login.cfg
Other PD utilities, proactive: npasswd, passwd+. reactive: COPS, scripts to check for empty or bad passwords (with crack).

The following are not necessarily check by the tools mentioned above:



passwd: compat
passwd_compat: nisplus
group: compat
group _compat: nisplus

Then each user to be allowed login access requires an entry in /etc/passwd and /etc/shadow of the form:
+fred:x:::::: /etc/passwd
+fred::::::: /etc/shadow 

Passwd replacements

Passwd+, npasswd, Obvious are public domain utilities which enhance the choice of passwords chosen by the user. Passwd+ and npasswd were evaluated by the author in 1994, but they had no NIS+ support at the time. Npasswd in particular seemed easy to extend and verify.

Consider one of the above programs to ensure that good passwords are used. 

DES encrypted scripts

Class  systems should not have root or administrator passwords in clear text scripts, even if the scripts are only readable by the owner. However such scripts are often necessary for database management (for example). One solution is to encrypt the entire script and decrypt it during encryption by using a modified shell which decrypts the script on-the-fly.

DNS:  Domain Name Service

Most UNIX variants include both a DNS client (called a resolver) and DNS server. Vendor versions tend to be old and not without problems (e.g. cache corruption problems, domains that return large amounts of data, security etc.).

Domain registration notes:

Audit trail

Monitoring system changes

One needs to know what the filesystem permissions and checksums should be, set these permissions, take snapshot & make these read-only. Regularly remake snapshot and compare with the original for changes. The system should automatically reset permissions.


Auditing is the monitoring of security related events, the writing of these events in an audit trail and the reporting and analysis of these audit events. Auditing should allow the actions of users to be monitored with a view to detecting abuse of the system. Auditing tools are different from system logging tools (which indicate system errors and help in solving system administration problems).

Sun Shield / BSM

Sun deliver a "C2" level auditing system for both SunOS (Sunshield) and Solaris (Sunshield BSM). It is bundled with Solaris 2. The Solaris 2.4 BSM is discussed here. BSM allows the actions of specific users to be recorded and written to an audit file. However, the auditing is at the system call level, meaning huge logs may be generated by simple user actions. Performance is also affected. The standard analysis tools praudit and auditreduce offer no high level analysis of audit trails. Applications may also write to the audit trail.

Reference documentation: "SunSHIELD Basic Security Module Guide" (Standard Solaris 2.x documentation). Man pages: audit(1m), audit_startup(1m), audit_warn(1m), auditconfig(1m), auditreduce(1m), bsmconv(1m).

See also Solaris C2/BSM security notes (sp/Solaris_bsm.html).

Log Files

A system administrator who regularly checks logs will learn a lot about how the system functions, can guarantee less downtime and at the same time should notice when security breaches occur, especially if alerts are used. Monitoring logs should not be regarded as a boring job, but a chance to understand the guts of the system!

On UNIX systems, there are various sources of logging information, most of which are kept in the /var partition. These logs need to be monitored.

General Recommendations:


Syslog is a centralised logging utility used extensively on most UNIX systems providing 8 priorities and 18 facilities. The principal users of Syslog are the kernel, news, uucp, sendmail and login services. The logger utility can be used to send messages to syslog in scripts or to test Syslog. The Syslog daemon is called syslogd.

AIX: Although syslogd is supported on AIX, it is useless since no system utilities report their messages to it!

Security Bug (Jan 1996): The 8lgm security mailing list found serious problems with string handling in syslog. They were discovered in June 1995 and some vendors have yet to produce a corrective patch. This problem was currently being exploited in sendmail. HP has released patches, get the security bulletin HPSBUX9602-029 from the HP patch server (See section on patches "Change/Release management") as have Sun (Solaris 2.5 has this fix integrated).

On most UNIX systems Syslog offers some interesting possibilities:


Process Accounting 

Accounting software is a set of tools that can be used to work out how much users should pay for system usage. It is interesting from a security perspective because it reports who is using the system and what commands are being used.

Solaris Accounting

Commands are in /usr/lib/acct, reports are in /var/adm/acct/fiscal/fiscrptMM (numbers) and /var/adm/acct/sum/rprtMMDD (user summary reports).

ln /etc/init.d/acct /etc/rc2.d/S22acct
ln /etc/init.d/acct /etc/rc0.d/K22acct
sh /etc/rc2.d/S22acct start

crontab -e adm
# Check /var/adm/pacct size:
0 * * * * /usr/lib/acct/ckpacct
# Create weekly report:
0 2 * * 0 /usr/lib/acct/runacct 2> /var/adm/acct/nite/fd2log
# Create monthly accounting summary:
0 7 1 * * /usr/lib/acct/monacct

crontab -e root
0 22 * * 4 /usr/lib/acct/dodisk

vi /etc/acct/holidays [set your local holidays]

Two principal reports are produced, the daily report showing command usage and the monthly report showing the system usage per user. The following is a typical extract from daily command summary:

sh 1082 85.98 0.57 183.20 149.67 0.00 0.00 218296 14
lpstat 886 84.49 0.53 3.08 159.36 0.00 0.17 749192 1
uname 682 39.38 0.38 0.43 103.64 0.00 0.89 3964 4
hostname 194 14.49 0.15 0.30 96.82 0.00 0.49 98552 1
sed 209 14.01 0.17 0.38 84.82 0.00 0.43 407197 0
ssh 71 12.26 0.54 41.66 22.85 0.01 0.01 2539679 87
csh 99 12.10 0.48 1.51 25.15 0.00 0.32 744715 94
sendmail 46 10.30 0.15 0.65 67.25 0.00 0.24 10724864 297

TOTALS 4300 364.04 14.61 12068.92 24.91 0.00 0.00 1626266848 21308

A monthly report looks like:

2 date changes
28 system boot
2 run-level 6
2 run-level 3
1 runacct
1 acctcon

0 root 0 9 16 205 9 133 0 2453 79 0 0
4 adm 0 0 1 0 0 0 0 13 0 0 0
71 lp 0 0 0 1 0 0 0 24 0 0 0
200 ftp 0 0 0 0 3094 5040 0 0 6 0 0
315 boran 2 3 165 15 10298 25740 0 1810 24 0 0
TOTAL 2 12 182 221 13401 30913 0 4300 109 0 0

What would be nice is a report of what commands are being used by what users on a regular basis. This is not available in the standard reports, but the lastcomm command shows what commands were last executed by a particular user since the last accounting update (e.g. weekly or daily). Lastcomm can be used by the Administrator to monitor a user's activities, but also by an attacker to monitor the administrators activities (since any user can execute lastcomm). Therefore:

[11] If passwords are synchronised across machines, the weakest machine determines the security level.
[12] "Avalon Security Research" published details of this hole along with scripts ("slammer") to exploit it on the Internet (Nov.'95).
[13] A utility for automatically generating /etc/.rootkey is available from the author.
[14] A script is required for this, no standard utilities are available.
[15] "Avalon Security Research" published details of this hole along with scripts to exploit it ("slugger") on the Internet (Nov.'95).
[16] Example commands are for Solaris 2.4.

previous  next  Title  Contents  Index    Previous   Next   Top   Detailed TOC  IT Security Cookbook, 14 août, 2002