The Unix Auditor's Practical Handbook

Contents:

Introduction:

All copyrights belong to Network Intelligence India Pvt. Ltd.

This document is authored by K. K. Mookhey. Please send all feedback to unix@niiconsulting.com or cto@niiconsulting.com 

Preliminary Steps:

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:

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:

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:

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.

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. 

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 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

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

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 http://sunsolve.sun.com

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: http://ist.uwaterloo.ca/security/howto/2000-12-04/CheckPatches.html. 
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

Logging
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

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:

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:

* [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.]

*[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:
/etc/rc1.d/K65nfs.server
/etc/rc1.d/K80nfs.client
/etc/rc2.d/S73nfs.client
/etc/rc2.d/K60nfs.server
/etc/rc3.d/S15nfs.server
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

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 ftp://ftp.porcupine.org/pub/security/index.html
 
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.
HELO 
MAIL FROM: someone@here.com
RCPT TO: someone@there.com
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 here.com or there.com

Also recommend that the sendmail banner is changed by commenting out the following line in sendmail.cf: 
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

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: http://www.users.dircon.co.uk/~crypto/download/c50-faq.html. 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.

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.

Groups:
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

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: ftp://ftp.cerias.purdue.edu/pub/tools/unix/sysutils/lsof/ , and compile it on that system. In case compilation is not possible, binaries of lsof are also available for you version of Solaris at ftp://ftp.cerias.purdue.edu/pub/tools/unix/sysutils/lsof/binaries/sun/solaris/.  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 http://www.sun.com/blueprints.tools. 

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

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:

Automated Vulnerability Testing:

References:

Other websites:

Books:
Solaris Security, by Peter H. Gregory

Mailing Lists: