The Unix Auditor's Practical Handbook


This handbook is meant to be a practical guide to auditing Unix. It will be kept as up-to-date as possible. The commands and filenames given here are applicable to a Sun Solaris system. However, there are cross-command references for AIX and Linux. Another point we wish to make is that it does not religiously follow any specific standards such as COBIT or BS7799. It is more about how we practically do a security audit more than anything else. In case, you find that the following document misses the mark as far as any of these standards are concerned, please do let us know and we will incorporate the necessary changes. Also some of the sections tend to be for Unix novices. The more experienced Unix gurus may skip those sections. All copyrights belong to Network Intelligence India Pvt. Ltd. This document is authored by K. K. Mookhey. Please send all feedback to or 

Preliminary Steps:

Before you actually start working on the server, there are some steps that you must take. You will need to ask some questions to the technical or the administrative contact within the organization. Prepare these in the form of a questionnaire and ask them on a one-to-one basis. Do not let them write down their answers and submit them to you. You might not be able to ask other related questions. Remember to always ask open-ended questions as far as possible.

About the Audit

Establish preliminary information about the audit itself:

  • Who or what is the prime reason for conducting this audit?
  • Have similar audits been conducted in the past?
  • Who will be the intended recipients of the report of this audit?
  • Does this audit or other security initiatives involve the management?
  • Do you (the local administrators) perceive any threats? If yes, from what sources?
  • Have any security incidents taken place earlier? What was their nature? How were they dealt with?


Documentation you should obtain before beginning the audit:
  1. Copies of previous audit reports or baselines
  2. Hardware and software configuration of the server
  3. The topology diagram
  4. The IS or Security Policy, if available
  5. The Contingency or Disaster Recovery Plan, if available
  6. List of personnel responsible for management, administration, servicing, and support of the systems
  7. List of the vendors of the equipment being audited and the period, scope and terms of the contract signed between the client and the vendors.
  8. The vendor manuals related to the system being audited. Ensure that these are available to you at all times. It is not unusual for even the most technically adept auditors to need to refer to manuals occasionally to enter the correct command. Always rely on the Unix man command if you have the slightest doubt.

Other Considerations:

Some of these points may sound pedantic. But we like to keep them in mind while doing the audit.
  1. Read the documentation well before you begin. Keep all documentation with you throughout the period of the audit. Make extra copies of these if necessary.
  2. Ensure that you obtain a proper working area with at least one machine dedicated for your use. It is preferable to carry your own laptops but the client may not want his data residing on an outside machine. Ensure that you have easy access to printer facilities. Keep the administrators and management informed that other requirements may come up during the course of your audit
  3. It is extremely vital that you carry out the audit under a specially created user account, say auditor. This user must be an ordinary non-root user. Ask the administrator to create one for you. A lot of the information is available as non-root, although some critical information is available only as root. Sometimes a server may be malfunctioning in a non-obvious manner. So be sure that as an auditor, you maintain full accountability for your actions. If possible, it is preferable to have one of the local administrators sit right next to you as you issue the commands to gather the data. 
  4. As you carry out more audits, you will narrow down on those commands, which require root access. Carry out these commands at one go, after you have finished the rest of the data gathering. Ask the administrator for the root password, and use the su command to gain superuser privileges. Then execute each command in his presence. In this handbook, those commands that are only executable as root have the # prompt, while ordinary commands are written on the $ prompt.
  5. Keep a normal and cordial, but business-like approach with the local administrators. You must be unbiased at all times.
  6. Most importantly, document everything. Every observation must be immediately documented. If necessary, have an assistant auditor carry out the documentation. Type out all your observations, and methods onto a single document in chronological order. Even though this is a tedious process it is best not to avoid it, as it enables you to look at your notes and gather information that you could have missed out. 
  7. Also note down the positive points about the systems and the administrative practices. Keep your report balanced, focusing on both the good and the bad.
  8. Determine what is the main purpose/functionality of this server. Is it a proxy, mail server, web server, database server, etc.? Does it have a dual role - i.e. is it a database server, as well as a web server? You will have to ensure that the system configuration is adequate for its role. 

Physical Security

General Checks:

Check where the server is located - in an open cubicle or in a closed server room. Ensure that a casual outside user must not be able to glance and see the entire setup of the server room. Ensure that the monitor is well-hidden from 'open view'
Is there a physical access control mechanism such as a key, swipe card, infrared card, biometric system, etc. for the server room? What is the normal position of the door of the room? In a lot of cases, we have seen the most elaborate physical authorization methods, with the door being kept open most of the time anyway. Recommend that the door be kept closed regardless of whether there are personnel inside the room or not.
If it is a server room, which personnel keep the access key/card to the room? Note down their names and designations.
Does the server’s CPU unit have any security to prevent unauthorized users from resetting it or even switching it off? Is there a prevention mechanism for preventing booting from alternate media? See File System Security
Which of the personnel are allowed physical access to the room? Make a list of these and verify the responsibilities and roles of each. Document this in your report.
Under what circumstances would unauthorized (non-administrative) personnel be required to enter the room? What procedure is adopted for such a situation? There must exist a well-documented and strictly followed procedure whenever an unauthorized user needs to enter the room. This includes vendor representatives, and auditors of course.
Is a record maintained (in a Register) of who has entered the room, when, and for what purpose? This Entry Register must contain at a minimum the following fields: Who is being allowed, Which organization or department does he belong to, Who among the list of authorized personnel defined earlier is accompanying him, What is the purpose of this person, and Time of Entry.
Is there adequate cooling in the room? What does the ambient temperature feel like? If required, measure it and consult the system manuals to determine if it is adequate or not.
Is there adequate protection from water and fire hazards, or other Acts of God. Check if there is a fire extinguisher, water detectors, smoke alarm, fire alarm, etc.

The Server Itself:

Note down all the information that appears on the CPU of the server - its vendor, its make, the serial number, etc.

Ensure there are no Post-it notes with any critical information written on them. This is unlikely, but we are just being thorough.

When you approach the screen, note if it is locked out or not? In case of Unix GUI (Open Windows, or CDE) an automatic lock-out option can be set which will require the user to login again after a pre-determined amount of time. See the section on GUI Security.
In case of a non-GUI console, identify the Login Screen and note the message. Does it give some sort of warning? Does it unnecessarily exhibit the Name and Version of the Operating System, such as “IBM AIX 4.0”? Recommend changing the welcome message on the server to something a little more stringent, and without revealing the Operating System or its version. The message should include a warning to the effect that, “This is the property of XYZ Ltd., and all actions are being logged. If you are not authorized explicitly to login, we strongly advise you not to attempt logging into this server. If the monitoring information shows that there has been a violation of the Security Policy or of the IT Law, strictest action will be taken.” See the section on Banners in Network Security below.

Login as the specially created ‘auditor’ account name, which must not have root-level access.

As soon as you login, the first command you need to type is to alias the rm command which is used to delete files. Most administrators have their favorite horror stories of having deleted entire partitions. On Sun especially, the rm command executes without a confirmation from the user. Use the following command to ensure that the rm command always asks you for a confirmation before deleting any file:
Solaris# alias rm 'rm -i'
Better still, just don't use the rm command at all.

Create a special directory for your own use.

Solaris$ mkdir /auditor
Solaris$ cd /auditor
Change the permissions on this directory so that only you are allowed 
to have access to this directory and the files within it.
Solaris$ chmod 0700 /auditor
Store output of all commands in that directory, and also copies of critical system files
Store the output of all commands by redirecting them to an appropriate file. 
For instance, if you want to store the output of the
ls -al command issue,
Solaris$ ls -al > /auditor/lsal.txt
And if required copy log files, system configuration files, and other important files to this directory
Solaris$ cp /etc/inetd.conf /auditor/

EEPROM Security

Check the eeprom parameters by typing the command
Solaris# eeprom
Ensure that the security mode is set to 'full', and that an adequate EEPROM password is chosen. This ensures that even if a malicious attacker is able to gain physical access to the system, he will be unable to reboot the system without knowing the EEPROM password. However, this is only a small hurdle for the determined hacker. Ensure that the EEPROM password is not the same as the root password, as the former can be retrieved in clear text. Caveat: Do not recommend this on a system that may be required to boot quickly without user intervention. 

Check if any bad logins have been made at the EEPROM with the command:

Solaris# eeprom security-#badlogins which will show the number of bad logins made.

Ensure that the primary boot device is the disk.

Solaris# eeprom boot-device

GUI Security

Ensure that the xhost command is disabled, unless it is very specifically required by some application. This can be checked by using the
ls -al command to see that
the permissions on the /usr/openwin/bin/xhost and /usr/X/bin/xhost
files are set to 744.

If CDE (Common Desktop Environment) is installed ensure that XDCMP connection access is disabled. For this ensure that the file

 /etc/dt/config/Xaccess exists with the following line in it:

which will deny all users access. Ensure that permissions on this file are set to 444. Else, recommend that this be done.

For CDE, ensure automatic lockout of the screen is enabled and the values are set appropriately. To do so
go to the Application Manager | Style Manager | Screen, and check that the timer sliders for the Screen Saver are set to 3 minutes, and that of the Screen Lock to 5 minutes.

For OpenWindows, the same can be done by starting the Workspace menu by right-clicking in the window background | Properties | Miscellaneous | Screen Saver. Check if it is set to Auto and the number of minutes is between 3-5.

Operating System

Identify what system you are working on. Issue the command:
Solaris$ uname -a
On a Sun Solaris system, the following command yields a better output
Solaris$ uname -X
Determine the meaning of the output of ‘uname -a’. Each Unix system has its own version of the uname command. Issue a ‘man uname’ command to study the manual entry associated with the uname command. For Sun Solaris the output of the uname -a command is in the format: System (SunOS), node name, the main version number, Kernel ID, Machine, Processor Type, Model Type. Save the output.

Check what processes are running on the system. Issue the ps command.

Solaris$ ps -ef
This will give you the details on each process, process ID, CPU usage, time since it is running, and complete path of the executable. On an IBM AIX, or Sun Solaris system use ps -ef, but on a Linux system use ps -aux to get the same results. Note down all processes that seem reasonably unnecessary. Also note down those processes that are taking up inordinately large amounts of processing and memory. Recommend that the administrator configure the system to execute these programs with the nice utility, or to not run them at all if possible. However, be careful of the recommendations you make here. 

Obtain the hardware inventory on the system. List all hardware devices by issuing the command:
Solaris$ /usr/platform/`uname -i`/sbin/prtdiag -v
This would be necessary only if you were making an inventory or it was explicitly required by the deliverables.

Get a list of software installed on the system. Issue the command
Solaris$ pkginfo to gather the details of the installed software.
On the Red Hat Linux system, software is usually installed in the form of RPMs (Red Hat Packet Managers). Issue an rpm -q -a at the command prompt to get a list of RPMs installed on the system. This command will give you extensive details on each package, so redirect the output to another file and study it thoroughly.
Recommend removal of unnecessary packages as they consume resources. If this is a production server, and you have determined its actual purpose you will be in a better position to recommend the removal of unnecessary packages. Especially, to be considered are Compilers and those Sun packages that have been prone to critical vulnerabilities such as SNMP, X Windows, CDE, Sendmail (unless they require it, in which case see the section on Sendmail), ToolTalk, etc.
Interview the administrator to find out what is the procedure when installing new software and who is authorized to install new software. Document this in your report.

Recommend that the installation of new software be carried out by logging in as an ordinary user and not as root. Most software does not need root privileges in order to install correctly. It is best practice to carry out as many tasks as possible by using a non-root username. And using the su command whenever root privileges are required.

Security patches:
It is of prime importance that all vendor-recommended patches be applied on the system as soon as they are released. To get the latest list of vendor-recommended patches, you must visit the vendor’s website. Sun provides patch information at

Check for the list of patches by issuing the command:

Solaris$ showrev -p
Check this list against that given at the Sun website for the particular version of the Sun OS that you are auditing. It must match with the list given by Sun under the name Recommended and Critical patches. Alternatively, you can use the excellent CheckPatches script that is available here:[TAR KIT]
More information on its usage is available here:
This script automatically checks the installed list of patches against the Sun Recommended and Critical patches for your version of the Sun OS and shows the ones that are missing. Alternatively, you can also use the patchdiag tool provided by Sun. But for this, the client must have a Sun Support Contract. Which is something you ought to recommend in any case. See Vendor Support below.

Cron and At
The cron and at utilities are used to execute certain tasks at predefined times, akin to the Windows Task Scheduler mechanism. They are a favorite place for hackers to insert their own processes. Administrators also include periodic tasks here. Most of the entries are to do with periodic system maintenance tasks such as cleaning up log files or making backups, etc.
The entries that are executed as part of the cron utility can be viewed using the command
Solaris# crontab -l
The format of the cron file is tab-separated list of fields: minutes, hours, day, month, day of week, complete path of file to be executed.

The at jobs are located in the /var/adm/atjobs directory and are executed using cron.
The main difference in the commands listed in at and those in cron is that, at commands are to be executed only once at a fixed time, while cron commands are to be executed over and over again at the specified time.

The security of who is allowed to execute tasks via the cron utility is stored in the /var/adm/cron/cron.allow and /var/adm/cron/cron.deny file. Similarly the access for at jobs is specified in the at.allow and at.deny files located in the same folder. Check the existence of these files and their content. Recommend the following:

To allow anyone to use it:
- touch  cron.deny,  if it does not exist.
To explicitly allow a user and no one else except root:
- touch  cron.allow
- put userid in it
To explicitly deny a user:
- touch  cron.deny
- put userid in it
Under most circumstances, you would want to ensure that only root is allowed access to cron. For this ensure that:
1. The CRONLOG=YES line exists in the file /etc/default/cron
2. All files except root are removed from  /var/spool/cron/crontabs


Check if the syslogd (Syslog Daemon) is in the list of processes:

Solaris# ps -ef | grep syslogd

Copy the file /etc/syslog.conf to your /audit folder.Note down the configuration of the syslog.conf file carefully. It determines what gets logged and what does not. The # sign represents a line that is commented out. Most importantly, you must note down all filenames that appear in the syslog.conf file. These are the log files of the system and maybe located anywhere. The default location of log files differs depending on which flavor of Unix we are auditing. On Linux the log files are in the /var/log folder. In Sun Solaris you can find the log files in the /var/adm/logs and /var/adm/messages folders. On IBM AIX system, log files are in the /var/adm, /usr/adm, and /etc/security folders. Copy all these log files onto your folder. Study them thoroughly. The more log files you study the easier it will be to spot system malfunctions or security incidents.

Ensure that the following line exists in the /etc/syslog.conf file to log important authentication messages:

auth.notice    ifdef (`LOGHOST', /var/log/authlog, @loghost)

In most Unix systems, auditing of logins is maintained separately, and it records unsuccessful attempts for all users, and successful attempts only for the root user. For Sun Solaris these logs are located in the /var/adm/loginlog and the /var/adm/sulog file. You must copy all the files in the particular log folder and study them carefully. The user login information is stored in the /var/adm/wtmpx file. 

To see the recent logins issue the command:

Solaris# last

To check for failed logins ensure that the /var/adm/loginlog file is created with owner as root, group as sys and permissions of 600. This file does not exist by default, so you must recommend its creation where necessary.

To see the recent error log messages issue the following command:

Solaris$ dmesg
Note down any serious vulnerabilities or performance issues coming up in the log files. Recommend that the administrator study the log files on a weekly basis at least. Also recommend the inclusion of an additional cron job that emails the output of the dmesg command to the administrator on a weekly basis.

In the log directory, issue an ls -al command to see the size of the log files. If it is too large, you must strongly recommend that the administrator recycle the files on a regular basis (using cron), by saving a backup on another system and deleting this file. If the log files grow too large they can overwhelm the system and even cause the server to halt by filling up the hard drive partition. See the section on checking disk space.

Ensure the log file permissions are 600 allowing only root to read and write them.

Network Security

First determine the network interfaces connected to the machine:
Solaris# ifconfig -a
The output gives details of the interface name, IP address, MAC Address, Subnet mask, Broadcast address, MTU, and other network parameters associated with all the network devices attached to the server. Save the output of this command.

Check out open network connections:
Solaris# netstat -an
The netstat command shows the open connections. You must study its output carefully. The 'a' is used to show All open network connections, and the 'n' gives the output in terms of IP addresses and port numbers, rather than host and service names. Try to note down any network connections that seem out of the ordinary. All unnecessary network connections represent network security risks. All users that are needlessly connected to the system are also potential threats. The last column lists the state of the TCP/IP connection. These states are LISTENING, ESTABLISHED, TIME_WAIT, FIN_WAIT. The last two states represent a connection that is about to close down. The first state implies a process, which is listening for incoming connections. Pay maximum attention to this and try to locate the process, which has opened up this connection (See lsof). The second state implies that this machine has established a connection with another machine. See what IP address or machine name the other end of the connection has and which ports are in use. You may wish to spend a lot of time here - for each connection investigate the ports, processes and connected hosts. See also the section on Nmap, to cross check the results of netstat with the view from the outside.

To view the routing table use:
Solaris# netstat -r

Open the /etc/inetd.conf file and make a note of all entries that do not begin with the # sign. The # sign before a line implies that it is commented out and will not be used. The other entries are network services that are configured to run after system startup. These are ftp, telnet, pop3, imap, and a whole host of others, most of which are unnecessary. Save a copy of this file. Recommend the closure of unnecessary services. For Sun Solaris the following services are recommended to be removed:

telnet chargen rpc.ttdbserverd
ftp daytime rpc.cmsd
finger netstat xaudio
talk rquotad sprayd
tftp ufsd uucp
login printer echo
shell walld time
echo sysstat pop3
discard exec comsat
rusersd rexd kerbd

Check the /etc/pam.conf file and recommend commenting out entries for the r* services (rlogin, rexec, etc.) in addition to commenting them out in /etc/inetd.conf. This ensures that even when using these services the users will still have to supply a password.

Check that the inetd service is started with Connection Tracing (the -t option) enabled. This ensures that all incoming connections to TCP services started through the inetd will be logged to syslog with severity level of notice. To do this, check that the file /etc/initd.d/inetsvc has the following line:

/usr/sbin/inetd -s -t &
Check the files within the folders /etc/rc.d, /etc/rc{0,1,2,3,4,5,6} and /etc/init.d. These files represent processes that will execute when the system boots up. Note down only those files that begin with an S or a K and not with anything else. The files beginning with a letter other than an S or a K are changed to not execute during system boot. Files beginning with S are those that will be executed during system startup and those beginning with a K will be executed during system shutdown. For any files found to begin with an S or a K, make sure that they are absolutely necessary, otherwise recommend renaming them to begin with an X. It is preferable to rename these files rather than to delete them. This saves the linking information associated with these files.

Ensure that the following are running:

S21perf S01MOUNTFSYS S74xntpd S05RMTMPFILES S75cron S20sysetup S75savecore S69inet S80PRESERVE S70uucp S88utmpd S71rpc [CDE] * S90volmgt
S42coreadm S71sysid.sys S99audit
S50devfsadm S72inetsvc S99dtlogin [CDE] S74syslog  

* [Removing RPC is strongly recommended but a large number of measures need to be taken and a few services such as CDE will have to be disabled. Other measures outlined in this document greatly reduce the risks from RPC. Though the jury is still out on this one. Eventually, it comes down to a Risk Assessment exercise - how far do we need to go, for the kind of threats we face. If it is a critical server or one that is exposed to the Internet, you simply must recommend closure of RPC along with its dependent applications such as CDE.]

Recommend that the following are removed by renaming them to begin with X:

rcS.d/ [NFS] rc2.d/S71sysid.sys rc2.d/S75flashprom
rcS.d/S41cachefs.root [NFS] rc2.d/S72autoinstall rc2.d/S76nscd 
rcS.d/S42ncakmod [NCA] rc2.d/S73cachefs.daemon [NFS] rc2.d/S80lp
rc2.d/S47asppp  rc2.d/S73nfs.client [NFS] rc2.d/S80spc
rc2.d/S71ldap.client  S74autofs [Required by NFS] *rc2.d/S88sendmail
rc2.d/S90wbem rc2.d/S93cachefs.finish rc2.d/S94ncalogd [NCA]
rc3.d/S15nfs.server [NFS] rc3.d/S50apache [Unless it is a Web Server] rc3.d/S76snmpdx [SNMP services - very buggy]
rc3.d/S77dmi [Solstice DMI]    

*[Unless it is a Mail Server. Even so recommend PostFix or others. See the section on Sendmail Security]

Save copies of the files /etc/hosts/, /etc/hosts.equiv, /etc/hosts.lpd. These are important configuration files.
The /etc/hosts file lists mappings of hostnames to IP addresses.
The /etc/hosts.equiv file lists which users from which hosts are allowed to connect to the server without supplying a password.
The /etc/hosts.lpd lists the hosts that are allowed to print through this server, again without supplying a password.

For these files the auditor must ensure that:
If the /etc/hosts.equiv contains any uncommented entries, ensure they are absolutely essential, otherwise very strongly recommend removing them.
None of these files contains entries with the + sign in them.
If these files are not being used, then ensure they are empty with permissions of 000. But if they are required (although there is no solid reason why), ensure that the permissions on these files are rw- --- ---, i.e. only root can read and write these files.
You must strongly recommend that the contents of these files be checked at regular intervals and these files not be used at all for allowing other hosts to connect to this server.

Ensure that there are no .rhosts or .netrc files anywhere in the server. These files give unlimited access to the users listed in them, i.e. hosts or users listed in these files do not need to supply a password when connecting to services such as telnet, rlogin, rsh, etc.:

Solaris# find / -name '.rhosts' -print
Solaris# find / -name '.netrc' -print
Ensure that if these files are not being used, then they are created empty and the permissions are set to 000. This will prevent any exploits or rootkits based on modifying these files.

Unless absolutely required, NFS must be disabled on most servers. To do this, ensure that the following files are renamed:

Also, recommend that the file /etc/dfs/dfstab is removed.

Ensure that the inetsvc is configured at a minimum. Ensure that the /etc/init.d/inetsvc file contains as few lines as possible. The following services must be commented out:

  • DHCP Support
  • named startup support
  • multicast support

Ensure that customized banners are displayed for login screens, telnet, ftp, etc. Check if the message of the day is appropriate in the file /etc/motd.

Check if a login banner with the appropriate content exists in the file /etc/issue. This file does not exist by default. Recommend that this file be created with a message giving the name of the organization, and warning that all access is monitored and any unauthorized access will be punishable as per the Company's Security Policy as well as the law of the land pertaining to Information Systems.

Similar banners must be created for Telnet in /etc/default/telnetd and for FTP in /etc/default/ftpd with the BANNER= configuration lines. Recommend disabling telnet or using SSH instead. If neither is possible, do recommend using TCPWrappers for much enhanced security.

FTP Security:
If FTP is configured in /etc/inetd.conf to run, and is absolutely necessary on the system, then ensure that the /etc/ftpusers file exists and contains entries of root and other system created users who will then be disallowed from ftp access to the server. Recommend that FTP be replaced with SSH or that TCPWrappers be used for enhanced security.
TCPWrappers is written by security guru Wietse Venema and is available at
Sendmail Security:
If Sendmail is required, recommend using an alternative such as PostFix or Qmail. Sendmail (in)security is such a vast topic that it cannot be fully covered here. 

However, do ensure that the version of Sendmail being used is the latest. To check this, telnet to the host on port 25 and view the banner. For instance, you may issue the following command from the server itself

Solaris$ telnet localhost 25
This will display the banner. Check the version in it, and ensure it is the latest (8.12 as of this writing).

Also ensure that the server is not acting as an open relay. An Open Relay is a Mail Server that will accept mails from users that do not belong to its domain and have recipients that also do not belong to its domain. So it will be relaying mails for users that have nothing to do with the organization. These emails are usually spam or junk emails being sent through this Mail Server. This has two consequences: One, it overloads the server to the extent that it fails to do its normal tasks properly. Second, the server will sooner or later get blacklisted as an Open Relay server, and other servers around the world will stop accepting any emails originating from this server, thus rendering it useless even for genuine users. To check if the server is an Open Relay or not, issue the following commands after the telnet.

Check what is the server response. Ideally, it should issue an error saying Relaying Denied. If instead, it say 'Enter the message and end with a CRLF [.] CRLF on the last line', or something similar, then recommend reconfiguring the server to prevent it acting as an Open Relay. Of course, this assumes your client does not have a domain called or

Also recommend that the sendmail banner is changed by commenting out the following line in 

O SmtpGreetingMessage=$j Sendmail $v/$Z; $b and replacing it with:
O SmtpGreetingMessage=Mail Server Ready
TCP/IP Security:
A lot of low-level network parameters can be set using the ndd command for ARP, IP, TCP, etc. 

Ensure that the file /etc/default/inetinit contains the following line TCP_STRONG_ISS=2 to generate more unique and more random ISNs in IP packets.

Ensure that packet forwarding is turned off, unless it is explicitly stated that this server is acting as a router. To do this, issue the command:

Solaris# ndd -get /dev/ip ip_forwarding
Recommend that this value be set to to 0 by issuing the following command:
Solaris# ndd -set /dev/ip ip_forwarding 0.
This may also be added at the end of /etc/init.d/inetinit

If the Solaris system is acting as a router you may also wish to recommend that the following parameters be set:

Ignore Redirects:ndd -set /dev/ip ip_ignore_redirects 1
Send Redirects:ndd -set /dev/ip ip_send_redirects 0
Forward Directed Broadcasts: ndd -set /dev/ip ip_forward_directed_broadcasts 0
Source Routing: ndd -set /dev/ip ip_forward_src_routed 0

Users and Groups

What is the procedure followed when adding new users? Ensure that there exists a well-documented procedure for adding new uses. Or recommend one for the client.
Who is allowed to add a new user to the system? Include the names and designation of these personnel in your report.
Do users have to fill in a form, or sign their acceptance of an agreement before being given a username and a password? If a Security Policy exists, determine if users are made to sign their agreement and acceptance of it.
Determine what password restrictions are imposed on the user. Does the organization have a well-defined Password Policy?
Determine the procedure followed when an employee leaves the organization. Is her username removed, are her files deleted, etc.? Are new employees assigned userids of ex-employees?
Get a list of users. Copy the file /etc/passwd to your directory. Open the file with a text editor. Understand the value of each of the 7 fields. The format of the /etc/passwd file is: User Name, Password, User ID, Group ID, User Description, Home Directory, Shell. Each field is separated by the ':' character. If shadow passwords are in use then the password (the second) field will contain an asterisk or an exclamation mark. On most Unix system the encrypted passwords can be found in the /etc/shadow file. But on an IBM AIX system, this file is called /etc/security/passwd. The shadow file contains the actual passwords in the second field and not placeholders such as ‘!’ or ‘*’.

The auditor must study the passwd and shadow files carefully, and ensure that:

  • No default user accounts or guest accounts present
  • No unused accounts of users who have already left the organization are present
  • No entries should contain the + sign, in either the /etc/passwd or the /etc/shadow files
  • Only one line contains 0 in the third field: i.e. there is only one root user on the system
  • There are no entries with :: after the username
  • All system (non-user) accounts have ':*:' after the user ID and have '/dev/false' as their login shell.
  • No '+' appears in any line in /etc/passwd
  • No line like this: '+:*:0:0:::' appears in /etc/passwd.
  • Password shadowing is implemented or is not available for this operating system.
  • The administrator periodically audits the /etc/passwd and /etc/shadow files for additions, alterations, and removals.
  • The administrator periodically verifies that each user with an identity in the password file corresponds to a currently authorized user.
  • There are no unauthorized users listed in the password files as of now.
  • Ensure that all system user IDs are locked out by putting "NP" in the password field. This must be done for 'daemon', 'bin', 'adm', 'lp', 'nobody', ,'nobody4', 'noaccess', 'sys', 'uucp', 'nuucp', 'listen', 'smtp', etc.

Audit the users’ passwords using the Crack program from Alec Muffet. You can know more about Crack and where to download it, from here: You will need to compile it on your laptop and copy the /etc/shadow file from the target server. Go through the README files very carefully whenever installing or compiling software on Unix machines. The Crack program runs in the background and its output can be viewed at any point of time using the Reporter command. If you need to shutdown your machine, you can restart Crack and it will carry on from where it left off. Read the documentation for more information.
If this is too much work, or not possible under the circumstances you may simply ask the local administrators staff to hand over the user passwords that they know of. Judge password complexity from this sample.

Password parameters can be checked in /etc/default/password. Note them down. Recommend the following password parameters:
1. PASSLENGTH= 8 [Minimum length of password]
2. MAXWEEKS=6 [Maximum time for usage of same password]
3. MINWEEKS=2 [Minimum duration for which password is valid]
The default profile exists in the file /etc/default/profile. Ensure that the current directory [.] does not exist in the PATH variables. Ensure that the [.] current directory does not exist in the PATH= and SUPATH= lines in /etc/default/login or in .profile, .login, or .cshrc files for root.

In /etc/default/login ensure that the PASSREQ=YES line is present and uncommented. This ensures that all users must have a password.

Issue the following command to check for users who are allowed to login without a password:

Solaris# logins -p

Also ensure that the file /etc/default/login is modified to change the UMASK value to a safer 022.

Ensure that the SYSLOG=YES line is present and uncommented in /etc/default/login to enable logging of all root login attempts and all failed root login attempts as Critical. See the section on Logging for more details on logging of ordinary users.

Ensure that the CONSOLE= line in /etc/default/login is uncommented to prevent root logins from remote terminals.

On Unix, users can be grouped together to make system administration easier by assigning rights to the entire group based on functionality required. The group information is available in the file /etc/group.

Check if this file contains the group wheel. If it does, then the list of users for this group must not be null. This group represents the users who are allowed to su to root. All others, even if they supply the correct password will be prevented from obtaining super-user privileges.

User Quotas:
In Unix, each user can be limited to the access he has to system resources, and not just to particular files or directories. For instance, users can be limited to the number of files that they can keep open at any point of time, the total CPU usage they can utilize, the total memory usage they are allowed, the total disk space they can use up, etc. For Sun, check if any users have quotas by searching for a file called quotas in the root filesystem. If users share the hard drive space then recommend that soft disk space and hard disk space limits are set. When a user exceeds a soft limit, a message box warning him is displayed. If he exceeds a hard limit, the user will not be able to create any files. Quotas are activated with the quotaon command. A quota report can be viewed with the repquota command.

File System Security

Find out the file systems that are present on the system
View the /etc/vfstab file to see the partitions that have been created and the parameters with which they have been mounted. For those partitions that hardly change recommend setting the ro [read-only] mount  parameter and for sensitive partitions the nosuid [No SUID files will be executed] parameter is set.
You may recommend that the partitions be set with the following parameters:
/var               nosuid 
/usr               ro 
/opt               nosuid, ro
The Sun OE contains a Volume Management system that automates the task of mounting removable media such as CD-ROMs and Floppies. This creates the additional security risk that anyone could insert a UFS (Unix File System) floppy and execute a SUID file to gain super-user privileges. To prevent this, ensure that the following lines are added to the end of the /etc/rmmount.conf file
mount hsfs -o nosuid
mount ufs -o nosuid
This will ensure that the SUID bit is ignored on file systems mounted by the VM system.

Sometimes not all open files are visible through the ps command. If there are any Trojans or hacker-processes they will be hidden well and we need to be thorough in our search. You may wish to use lsof, and it can be downloaded from: , and compile it on that system. In case compilation is not possible, binaries of lsof are also available for you version of Solaris at  The output of the lsof command is quite extensive and it requires a bit of detailed study before you can begin to make out the unnecessary files or those that are possible Trojans. The most important part about lsof is not just the processes that are running, but also the list of files being kept open by those processes. Another important output from this command is that all open ports are mapped to the processes. This enables you to further investigate any suspicious or unnecessary processes that are keeping ports open.

You can view disk usage by issuing the command:

Solaris# df -k
which shows the partitions and the number of blocks used up, blocks free, and percentage of free partition. This is necessary to determine if the partitioning has been done correctly and if adequate free space is available for partitions that are likely to grow such as /opt, /var, or /usr.
If this is a Mail Server, ensure that /var/mail exists as a separate partition as this is likely to grow with time.

Find all files that have the SUID or SGID bit set. These are files that can be created and possibly modified by anyone, but when executed they will execute with the permissions of the owner - usually root. Some of these are system files and are necessary for the proper functioning of the system, but any unexplained ones are potentially Trojans and should be noted down immediately and brought to the attention of the Administrator. Recommend that the Administrator must regularly issue the commands given below and compare them with the output you have given him. He must immediately recognize any suspicious new entries.

Solaris# find / -perm -1000 -print
Solaris# find / -perm -2000 -print

Find out all files that are no longer owned by any user:

Solaris# find / -nouser -print
Check the umask value for root.
Solaris# umask
This should ideally be 022. The umask value specifies the permissions with which any new file is created. Each user has his own umask value and can change it by altering the parameters in the .profile file in his home directory.

Note on permissions in Unix
In Unix, the most important thing to keep in mind is that everything is a file. Even the hardware devices are files. The monitor/terminal is the file /dev/console. The printer is the file /dev/lpt, serial devices are /dev/ttyS0, etc.

The auditor must ensure that:

  • System directories should have permission 755 minimum. Do an ls -ald from the / directory and note down the permissions listed in the first column for the directories /bin, /etc, and /sbin
  • System directories used by root for programs should be owned by root.
  • Ensure that the sticky bit is set on /tmp, /usr/tmp. This will appear as the letter ‘t’ in the first column of the permissions field when you do an ls -ald
  • Ensure that the following permissions are set on critical files:
    /etc/default/passwd         r-- r-- r--
    /etc/passwd                 rw- r-- r--
    /etc/security/audit_user    rw- r-- r--
    /etc/security/shadow        r-- --- ---
  • Device file perms are set as follows:
    disk, storage, tape, network device files: 600, owned by root.
    tty device files: 622, owned by root.
    /dev/null: 777
  • User HOME directories should be mode 710. Mode 711 allows others to inspect subdirectories with permission.
  • .profile, .login files should be mode 600 or 640.

Ensure that there is only one copy of system commands and these should be in the system dir. Do a find / -name [filename] -print, where filename should be replaced by login, su, passwd, ls, etc.

Sun Built-in Auditing

We do not go very much into the details of the built-in auditing available on Sun OE. More information on this subject is available from the online documents at

To check if auditing is enabled on the server or not, issue the following command:
Solaris# ps -ef | grep audit
Auditing is configured in the files: audit_control, audit_class, and audit_event which are present in the /etc/security directory.

The audit trail files are stored in a directory specified in /etc/security/audit_control. The auditor must ensure that the permissions on this directory are such that only root can access them. Also the permissions on the files within the /etc/security folder must be such that only root can read-write.

If auditing has been turned on, you must ensure that there is adequate disk space especially for the partition that holds the audit trail files.
See the section on determining disk space.

Backup and Emergency Procedures

Check if there is there adequate power supply

Is there a UPS in place, and is it adequate for the task? (You must note down the technical specifications of the UPS - Hours, Time for Charging, KV, etc.)

What backup procedures are in place for the servers? Ask the administrator what backup procedure he follows and whether it is documented

Which files are included in the backup (databases, system configuration files, user files, emails, log files, complete hard disk)?

Determine the locations where the backups are stored

If backups are stored at an offsite location determine who transports them to and from the offsite location and in what manner

Check if a full/partial system recovery has been attempted from the backups?

Check what contingency procedures are in place in case of an emergency

Is vendor support found to be reasonably adequate and quick? Go through the vendor support agreements, and enquire as to past vendor response in terms of speed and expertise.

What is the normal procedure when a system fault occurs? Check if the list of persons, and their contact numbers well documented and evidently displayed.

Does the organization maintain a Faults Register? If the server is critical, recommend that such a register be maintained and it should contain at least the following fields: Date and Time of Fault, Symptoms of the Fault (any error messages on console, or system halts, etc.), Action taken, Final Solution to Fault, Person Recording the entry.

Check what Sun Support Plan the server is covered under. There are four SunSpectrum support plans available: Bronze, Silver, Gold and Platinum. Depending on the criticality of the server, it must be covered under the appropriate plan. Roughly speaking:

Platinum -> Mission-critical, no downtime allowed
Gold -> Critical, some downtime allowed
Silver -> Important Server, but downtime of 24-48 hours is allowed
Bronze -> Secondary or backup server. Can do with a downtime of upto 7 days.

For a more accurate description of each support plan go to Another factor that determines the plan is the in-house expertise of the client.

Automated Vulnerability Testing:

The tools listed here are most commonly used by auditors as well as hackers to find documented vulnerabilities in systems. As auditors, we must never rely completely on these tools. They must only act as supplementary aids to the actual auditing process of data gathering, analysis, and recommendations. We suggest that the reports obtained from these tools be attached to the Appendix and if necessary the more critical vulnerabilities discovered by these tools can be included in the main report.

Nmap is one of the most widely utilized auditing tools used. The latest version can be downloaded from Its main purpose is to find out all the ports that are opened up on a target machine. It comes with a wide variety of options. The main options we will be using are
laptop# nmap -O -P -sS.
-O identify the Operating System of the target
-P Ping the host
-sS Use SYN scanning, i.e. do not close the TCP connection
The output of nmap gives us the ports open on the server, and a probably guess at the Operating System of the server. This is its unique capability to be able to pinpoint the Vendor and Version of the Operating System with astounding accuracy.
You can ask nmap to be more verbose in its output by adding the -v or -vv switch to the above command.

Nessus is one of the premier vulnerability scanning tools available freely. It can be downloaded from After downloading it, unzip the package
laptop# tar -zxvf nessus.tar.gz
Then run the built-in installer script
laptop# ./nessus-installer
(Choose the default options, and create a user and give it a password of your choice)
Once nessus has been successfully compiled and installed, go through the documentation to get a better grip on how the software functions. It has two parts - the server and the client. The server part accepts connections from the client, wherein it receives the details on the target to be scanned, and the options chosen by the client. The server then runs a battery of tests against the target, as chosen by the client and presents the final report to the client. To begin the server part of nessus:
laptop# nessusd -D
Now connect the client to it from another terminal window:
laptop# nessus
Enter the password and choose the target. There are a number of options available. Choose as you see fit.
Every now and then update the tests that Nessus executes:
laptop# nessus-update-plugins


Vendor Sites:
Sun Online Documentation:


Other websites: 
SANS Institute:

Solaris Security, by Peter H. Gregory


Mailing Lists:
Sun Security Bulletin: