Performing Security Audits

Performing Security Audits

The purpose of a computer security audit is to basically test your system and network security. For larger organizations, the security audit may be done by an independent auditor (much like the auditing of financial statements). If you have only a few Red Hat Linux systems or a small network, you can do the security audit as a self-assessment, just to figure out if you are doing everything okay or not.

The following sections explain how to perform computer security audits and show you a number of free tools and resources to help you test your system’s security.

Understanding Computer Security Audits

An audit is simply an independent assessment of whatever it is you are auditing. So a computer security audit is an independent assessment of computer security.

No matter whether you have independent security audits or a self-assessment, here are some of the benefits you get from security audits:

  • Periodic risk assessments that consider internal and external threats to systems and data

  • Periodic testing of the effectiveness of security policies, security controls, and techniques

  • Identification of any significant deficiencies in your system’s security (so you know what to fix)

  • In case of self-assessments, preparation for any annual independent security testing that your organization might have to face

The nontechnical side of computer security audits focuses on your organization-wide security framework. The audit examines how well the organization has set up and implemented the policies, plans, and procedures for computer security. Some of the items to be verified include

  • Risks are periodically assessed.

  • There is an entity-wide security program plan.

  • A security program management structure is put in place.

  • Computer security responsibilities are clearly assigned.

  • Effective security-related personnel policies are in place.

  • The security program’s effectiveness is monitored and changes are made when needed.

As you may expect, the nontechnical aspects of the security audit involves reviewing documents and interviewing appropriate individuals to learn how the organization manages computer security. Of course, for a small organization or a home PC, it’s ridiculous to expect plans and procedures to be captured in documents. In those cases, all you need to do is make sure is that you have some technical controls in place to secure your system and your network connection.

The technical side of computer security audits focus on testing the technical controls that secure your hosts and network. The testing involves determining:

  • How well the host is secured. Are all operating system patches applied? Are the file permissions set correctly? Are user accounts protected? Are file changes monitored? Are log files monitored? And so on.

  • How well the network is secured. Are unnecessary Internet services turned off? Is a firewall installed? Are remote logins secured with tools such as SSH? Are TCP wrapper access controls used? And so on.

Typically security experts use automated tools to perform these two security reviews—host and network.

Learning a Security Test Methodology

A key element of computer security audit is the security test that checks the technical mechanisms used to secure a host and the network. The security test methodology follows these high-level steps:

  1. Take stock of the organization’s networks, hosts, network devices (routers, switches, firewalls, and so on), and how the network is connected to the Internet.

  2. If there are many hosts and network connections, determine what are the important hosts and network devices that should be tested. The importance of a host depends on the kind of applications it runs.

  3. Test the hosts individually. Typically, this involves logging in as a system administrator and then performing checking various aspects of host security from passwords to system log files.

  4. Test the network. This is usually done by attempting to break through the network defenses from another system on the Internet. If there is a firewall, the testing checks that the firewall is indeed configured correctly.

  5. Analyze the test results of both host and network tests to determine the vulnerabilities and risks.

Each of the two types of testing—host and network—focuses on three areas that comprise overall computer security:

  • Prevention—This includes the mechanisms (nontechnical and technical) that help prevent attacks on the system and the network

  • Detection—This refers to techniques such as monitoring log files, checking file integrity, and using intrusion detection systems that can detect when someone is about to break into, or has already broken into, your system

  • Response—This includes the steps, such as reporting an incident to authorities and restoring important files from backup, that you perform when a computer security incident has occurred.

These host and network security areas have some overlaps. For example, prevention mechanisms for host security, such as good passwords or file permissions, can also provide network security. Nevertheless, it helps to think in terms of the three areas—prevention, detection, and response.

Before you can think of prevention, however, you need to know the types of problems that you are trying to prevent. In other words, what are the common security vulnerabilities? The prevention and detection steps typically depend on what these vulnerabilities are.

Understanding Common Computer Vulnerabilities

The specific tests of the host and network security depend on the common vulnerabilities. Basically, the idea is to check if a host or a network has the vulnerabilities that crackers are most likely to exploit.

Online Resources on Computer Vulnerabilities

There are several online resources that identify and categorize computer security vulnerabilities:

  • SANS Institute publishes a list of Top 20 most critical Internet security vulnerabilities at

  • CVE (Common Vulnerabilities and Exposures) is a list of standardized names of vulnerabilities. For more information on CVE, see (the list has over 2,200 names of vulnerabilities). It’s common practice to use the CVE name to describe vulnerabilities.

  • The ICAT Metabase is a searchable index of information on computer vulnerabilities, published by National Institute of Standards and Technology (NIST), a United States government agency. The ICAT vulnerability index is online at http://icat. ICAT has nearly 5,400 vulnerabilities and it provides links to vulnerability advisory and patch information for each vulnerability. ICAT also a Top Ten List that lists the vulnerabilities that were most queried during the past year.

Typical Top 20 Computer Vulnerabilities

The SANS Top 20 vulnerabilities list includes three types of vulnerabilities—general ones that affect all systems, Windows vulnerabilities, and UNIX vulnerabilities. Of these, the general and UNIX vulnerabilities are relevant to Red Hat Linux. Table 22-4 summarizes the general and UNIX vulnerabilities that apply to Red Hat Linux. The information in the table is based on past SANS Top 20 lists. You can read the complete details about these vulnerabilities at

Table 22-4: Some Common Computer Vulnerability Types

Vulnerability Type


General Vulnerabilities


Default install options

These are the vulnerabilities introduced by the default installation options that often install unneeded software or configure software with insufficient security

Weak or no password

Many user accounts have weak passwords that can be easily cracked by password-cracking programs. Also, some software packages may add user accounts with no password or a standard password that everyone knows.

Incomplete or no backups

If a security incident occurs, the files may have to be restored from backups. However, it’s a common mistake to either not do backups regularly or not test the backups for completeness.

Large number of open ports

The open ports refer to Internet services that are enabled on a system. Sometimes there are many unnecessary Internet services running on a system.

Incorrect or no filtering of packets

An IP address-based packet filter can cut back on attacks, but many systems do not have any packet filtering enabled. With iptables, it’s easy to turn on packet filtering in Red Hat Linux.

Incomplete or no logging

The system logs are the only way to figure out the sequence of events that led to someone breaking into your system. Unfortunately, sometimes the logging is not set up correctly.

Vulnerable CGI programs

This vulnerability refers to the common gateway interface (CGI) that’s used on Web servers to process interactive Web pages (for example, forms that request input from users). A CGI program with vulnerability (such as buffer flow) can provide attackers a way to do bad things to your system.

UNIX Vulnerabilities


RPC buffer overflows (NFS, NIS)

Services such as Network File System (NFS) and Network Information System (NIS) use remote procedure calls (RPC), and there are some known vulnerabilities in RPC.

Sendmail vulnerabilities

Sendmail is a complex program used to transport mail messages from one system to another, and some versions of Sendmail have vulnerabilities.

BIND (DNS) weaknesses

Berkeley Internet Name Domain (BIND) is a package that implements Domain Name System (DNS), the Internet’s name service that translates a name to an IP address. Some versions of BIND have vulnerabilities.

r command (rlogin, rsh, rcp) vulnerabilities

The so-called r commands allow an attacker to easily access any system that has an implicit trust relationship with others (the r commands assume a trust relationship).

LPD (remote printing) vulnerabilities

LPD is the print server process and it listens on port 515 for remote printing requests. Unfortunately, the remote printing capability has a buffer overflow vulnerability.

Default SNMP strings

Simple Network Management Protocol (SNMP) is used to remotely monitor and administer various network-connected systems ranging from routers to computers. SNMP lacks good access control, so, if SNMP is running on your system, an attacker may be able to reconfigure or shut down your system.

Reviewing Host Security

When reviewing host security, focus on assessing the security mechanisms in each of the following areas:

  • Prevention. Install operating system updates, secure passwords, improve file permissions, set up password for boot loader, and use encryption.

  • Detection. Capture log messages and check file integrity with Tripwire.

  • Response. Make routine backups and develop incident response procedures.

I describe how to review a few of these host security mechanisms.

Operating System Updates

Red Hat issues Red Hat Linux updates as soon they learn of any security vulnerabilities, but it’s up to you or a system administrator to download and install the updates. One way to keep up with the Red Hat Linux security patches is to sign up for the Red Hat Network service (it’s free for a single machine, but costs for a subscription for other machines).

You can install them using the rpm command. If you place all current updates in a single directory, you can use the following command to install them:

rpm -F *.rpm

On larger organizations, an authorized system administrator should install the operating system updates.

To assess whether the operating system updates are current, an auditor gets a current list of updates for key Red Hat Linux components and then uses the rpm command to check if they are installed. For example, if a list shows that glibc version 2.2.5 is what the system should have, the auditor types the following rpm command to view the current glibc version number:

rpm -q glibc

If the version number is less than 2.2.5, the conclusion is that operating system updates are not being installed.

File Permissions

Key system files should be protected with appropriate file ownerships and file permissions. The key steps in assigning file system ownerships and permissions are to:

  • Figure out which files contain sensitive information and why. Some files may contain sensitive data related to your work or business, whereas many other files are sensitive because they control the Red Hat Linux system configuration.

  • Maintain a current list of authorized users and what they are authorized to do on the system.

  • Set up passwords, groups, file ownerships, and file permissions to allow only authorized users access the files.

Table 22-5 lists some of the important system files in Red Hat Linux. The table also shows the numeric permission setting for each file.

Table 22-5: Important System Files and Their Permissions

File Pathname





GRUB bootloader configuration file



List of users permitted to use cron to submit periodic jobs



List of users who cannot use cron to submit periodic jobs



System-wide periodic jobs



List of hosts allowed to use Internet services that are started using TCP wrappers



List of hosts denied access to Internet services that are started using TCP wrappers



File that controls how log files are rotated



Directory with configuration files for pluggable authentication modules (PAM)



Old-style password file with user account information but not the passwords



Directory with system startup scripts



TTY interfaces (terminals) from which root can login



Policy files that control system access



File with encrypted passwords and password expiry information



Users who can shutdown or reboot by pressing Ctrl-Alt-Delete



Directory with configuration files for the Secure Shell (SSH)



System configuration files



Kernel configuration parameters



Configuration file for syslogd server that logs messages



Configuration file for the very secure FTP server



List of users who cannot use FTP to transfer files



Configuration file for the xinetd server



Directory containing configuration files for specific services that the xinetd server can start



Directory with all log files



Information about all previous logins



Main system message log file



Security related log file



Information about current logins

Another important check is to look for executable program files that have the setuid permission. If a program has setuid permission and it’s owned by root, then the program runs with root privileges, no matter who runs the program. You can find all setuid programs with the following find command:

find / -perm +4000 -print

You may want to save the output in a file (just append > filename to the command) and then examine the file for any unusual setuid programs. For example, a setuid program in a user’s home directory would be unusual.

Password Security

Verify that the password, group, and shadow password files are protected. In particular, the shadow password file should be write-protected and readable only by root. The filenames and their recommended permissions are shown in Table 22-6.

Table 22-6: Ownership and Permission of Password Files

File Pathname












Incident Response

Incident response is the answer to the question of what to do if something does happen. In other words, if someone has broken into your system, what you need to do.

Your response to an incident depends on how you use your system and how important it is to you or your business. For a comprehensive incident response, here are some key points to remember:

  • Figure out how critical and important your computer and network are and identify who or what resources can help you protect your system.

  • Take steps to prevent and minimize potential damage and interruption.

  • Develop and document a comprehensive contingency plan.

  • Periodically test the contingency plan and revise the procedures as appropriate.

Reviewing Network Security

Network security review focuses on assessing the security mechanisms in each of the following areas:

  • Prevention. Set up firewall, enable packet filtering, disable unnecessary xinetd services, turn off unneeded Internet services, use TCP wrappers access control, and use SSH for secure remote logins.

  • Detection. Use network intrusion detection and capture system logs.

  • Response. Develop incident response procedures.

I briefly describe some key steps in assessing the network security.

Services Started by xinetd

Many Internet services such as Telnet and POP3 are started by the xinetd server. The decision to turn on some of these services depends on factors such as how the system is connected to the Internet and how the system is being used. You can usually turn off most xinetd services.

Check which xinetd services are turned on by using one of the following ways:

  • Check the configuration files in the /etc/xinetd.d directory for all the services that xinetd can start. If a service is turned off, the configuration file has a line like this:

    disable = yes

    Remember that the disable = yes line doesn’t count if it’s commented out by placing a # at the beginning of the line.

  • Type the following command:

    chkconfig --list | more

    In the output, look for the lines that follow:

    xinetd based services:

    These lines list all the services that xinetd can start and whether they are on or off. For example, here are a few lines showing status of xinetd services on a system:

            chargen-udp:    off
            rsync:  off
            chargen:        off
            daytime-udp:    off
            daytime:        off
            echo-udp:       off
            echo:   off
            services:       off
            servers:        off
            time-udp:       off
            time:   off
            cups-lpd:       off
            sgi_fam:        on
            kotalk: off
            ktalk:  off
            imap:   off
            imaps:  off
            ipop2:  off
            ipop3:  off
        ... lines deleted ...

    In this case, the sgi_fam (a server that reports changes to any file) service is on, but everything else is off.

Also check the following files for any access controls used with the xinetd services:

  • /etc/hosts.allow lists hosts allowed to access specific services.

  • /etc/hosts.deny lists hosts that should be denied access to services.

Standalone Services

Many services such as the httpd (Web server) and sendmail (mail server) start automatically at boot time, assuming that they are configured to start that way. You can use the chkconfig command to check which standalone servers are set to start at various run

levels. Typically, your Red Hat Linux system starts up at run level 3 (for text login) or 5 (for graphical login). Therefore, what matters is the setting for the servers in levels 3 and 5. To view the list of servers, type the following command:

chkconfig --list | more

Here’s a partial listing of what you might see:

snmpd           0:off   1:off   2:off   3:off   4:off   5:off   6:off
snmptrapd       0:off   1:off   2:off   3:off   4:off   5:off   6:off
iptables        0:off   1:off   2:on    3:on    4:on    5:on    6:off
gpm             0:off   1:off   2:on    3:on    4:on    5:on    6:off
kudzu           0:off   1:off   2:off   3:on    4:on    5:on    6:off
winbind         0:off   1:off   2:off   3:off   4:off   5:off   6:off
ntpd            0:off   1:off   2:off   3:off   4:off   5:off   6:off
syslog          0:off   1:off   2:on    3:on    4:on    5:on    6:off
atd             0:off   1:off   2:off   3:on    4:on    5:on    6:off
netfs           0:off   1:off   2:off   3:on    4:on    5:on    6:off
network         0:off   1:off   2:on    3:on    4:on    5:on    6:off
random          0:off   1:off   2:on    3:on    4:on    5:on    6:off
rawdevices      0:off   1:off   2:off   3:on    4:on    5:on    6:off
saslauthd       0:off   1:off   2:off   3:off   4:off   5:off   6:off
xinetd          0:off   1:off   2:off   3:on    4:on    5:on    6:off
...lines deleted...

The first column shows the names of the servers. Look at the column of entries that begin with 3: and the ones that begin with 5:. These are the ones that show the status of the server for run levels 3 and 5. The ones that appear as on are automatically started when your Red Hat Linux system starts.

If you are doing a self-assessment of your network security and you find that some servers should not be running, you can turn them off for run levels 3 and 5 with the chkconfig command like this:

chkconfig --level 35 servicename off

Replace servicename with the name of the service you want to turn off.

If you are auditing network security, make a note of all the servers that are turned on and then try to determine if they should really be on, based on what you know about the system. The decision to turn on services depends on how a system is used (as a Web server or a desktop system) and how it is connected to the Internet (through a firewall or directly).

Penetration Testing

A penetration test is the best way to tell what services are really running on a Red Hat Linux system. Penetration testing involves trying to get access to your system from an attacker’s perspective. Typically, you perform this test from a system on the Internet and try to see if you can break in or, at a minimum, get access to services running on your Red Hat Linux system.

Exploring Security-Testing Tools

There are many automated tools available to perform security testing. Some tools are meant for finding the open ports on every system in a range of IP addresses. Others are meant to find the vulnerabilities associated with the open ports. Yet other tools can capture (or sniff) and help you analyze them so you can glean useful information about what’s going on in your network.

You can browse a list of top 50 security tools (based on informal poll of nmap users) at Table 22-7 lists a number of tools by category. I describe a few of the freely available vulnerability scanners in the next few sections.

Table 22-7: Some Popular Computer Security Tools


Names of Tools

Port scanners

nmap, Strobe

Vulnerability scanners

Nessus Security Scanner, SAINT, SARA, Whisker (CGI scanner), ISS Internet Scanner, CyberCop Scanner, Vetescan, Retina Network Security Scanner

Network utilities

Netcat, hping2, Firewalk, Cheops, ntop, ping

Host security tools

Tripwire, lsof

Packet sniffers

tcpdump, Ethereal, dsniff, sniffit

Intrusion detection system (IDS)

Snort, Abacus portsentry, scanlogd, NFR, LIDS

Password checking tools

John the Ripper, LC4

Log analysis and monitoring tools

logcolorise, tcpdstats, nlog, logcheck, Swatch


nmap (short for Network Mapper) is a port scanning tool. It can rapidly scan large networks and determine what hosts are available on the network, what services they are offering, what operating system (and the operating system version) they are running, what type of packet filters or firewalls are in use, and dozens of other characteristics. Red Hat Linux comes with nmap. You can read more about nmap at

If you want to try out nmap to scan your local area network, just type a command similar to the following (replace the IP address range with addresses appropriate for your network):

nmap -O -sS

Here’s part of a typical output listing from that nmap command:

Starting nmap V. 3.00 ( )
Interesting ports on dhcppc1 (
(The 1595 ports scanned but not shown below are in state: closed)
Port       State       Service
21/tcp     open        ftp
22/tcp     open        ssh
23/tcp     open        telnet
111/tcp    open        sunrpc
1024/tcp   open        kdm
6000/tcp   open        X11
Remote operating system guess: Linux Kernel 2.4.0 - 2.5.20
Uptime 3.322 days (since Tue Feb  4 14:07:38 2003)

Interesting ports on dhcppc2 (
(The 1600 ports scanned but not shown below are in state: closed)
Port       State       Service
139/tcp    open        netbios-ssn
Remote OS guesses: Turtle Beach AudioTron Firmware 3.0, Windows NT4 or 95/98/98SE
... lines deleted ...

As you can see, nmap displays the names of the open ports and hazards a guess at the operating system name and version number.


The Nessus Security Scanner is a modular security auditing tool that uses plugins written in Nessus scripting language to test for a wide variety of network vulnerabilities. Nessus uses a client-server software architecture with a server called nessusd and a client called nessus.

Insider Insight 

Before you try to install Nessus, you must install the sharutils RPM. That package includes the uudecode utility that the Nessaus installation script needs. For some reason, the sharutils package is no longer installed with any of the standard package groups.

To install sharutils, follow these steps:

  1. Mount the companion CDs one by one and locate the package whose name starts with sharutils. You can try the following sequence commands after mounting the CD on /mnt/cdrom:

    cd /mnt/cdrom/RedHat/RPMS
    ls sharutils*
  2. After you find the sharutils package, install it with the following command:

    rpm -ivh sharutils*.rpm

To download and install Nessus, follow these steps:

  1. Read the instructions on Then scroll down on that page, click a link to an appropriate FTP site, and download the files and MD5.

  2. Type the following command to install Nessus (you must have the development tools, including the GIMP Toolkit, installed):


    This should extract the Nessus files and build all the executables and libraries. I have had some compilation errors sometimes, but I hope the steps complete without any problems when you try it.

After the installation is complete, here are the steps to use Nessus:

  1. Log in as root and type the following command to create the Nessus SSL certificate used for secure communication between the Nessus client and the Nessus server:

  2. Provide the requested information to complete the certificate generation process.

  3. Create a nessusd account with the following command:

  4. When prompted, enter your user name, password, and any rules (press Ctrl-D if you don’t know what rules to enter).

  5. If you want to, you can configure nessusd by editing the configuration file /usr/local/etc/nessus/nessusd.conf. If you want to try out Nessus, you can proceed with the default configuration file.

  6. Start the Nessus server with this command:

    nessusd -D
  7. Run the Nessus client by typing the following command in a terminal window:


    The Nessus Setup window appears.

  8. Type a nessusd user name and password, and then click Log In. Nessus displays the certificate used to establish the secure connection and asks if you accept it. Click Yes. After the client connects to the server, the Log in button changes to Log out, and a Connected label appears at its left.

  9. Click the Target selection tab. Enter a range of IP addresses to scan all hosts in a network. For example, to scan the first eight hosts in a private network, I enter the address as:
  10. Click Start the Scan. Nessus starts scanning the IP addresses and checks for many different vulnerabilities. Progress bars show the status of the scan.

After Nessus completes the vulnerability scan of the hosts, it displays the result in a nice combination of graphical and text formats. The report is interactive—you can click on a host address to view the report on that host, and you can drill down on a specific vulnerability (including the CVE number that identifies the vulnerability).


Security Administrator’s Integrated Network Tool (SAINT) scans hosts for a variety of security vulnerabilities. For the vulnerabilities it finds, SAINT shows the Common Vulnerabilities and Exposures (CVE) identifier. Older versions of SAINT are free, but the latest version is available to only those who purchase SAINTWriter or SAINTexpress.

You can download a crippled (limited to scanning two hosts only) 15-day trial version of SAINT from and see what it can do. You can decide whether to buy the full version or not.

I won’t describe the steps for downloading and installing the trial version. You will find the instructions on the page from which you download the free trial version of SAINT.


Security Auditor’s Research Assistant (SARA) is a vulnerability-scanning tool based on SAINT. SARA scans for known vulnerabilities, including those in the CVE list and the SANS Top 20 List (

To try out SARA, download the latest version of SARA from After downloading the compressed tar file, build and install the software using these steps:

  1. Unpack tar file with the command:

    tar zxvf sara*
  2. To configure SARA, type the following commands:

    cd sara*
  3. To build the software, type:


After SARA is built, run it with the following command:


SARA starts a Web browser and displays its user interface in the Web browser. You can perform various tasks by clicking the links along the left-hand side of the Web browser. For example, to perform a vulnerability scan, click the Target Selection link. SARA brings up a form where you can provide information about hosts and networks to scan. You can also specify the scanning level—anywhere from light to extreme.

After filling in the information, click the Start the Scan button at the bottom of the form. SARA starts to perform the vulnerability scan. During the scan, SARA displays a data collection page that indicates progress of the scan.

After the scan is complete, you can proceed to data analysis and view the vulnerability information.