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.
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.
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:
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.
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.
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.
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.
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.
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.
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 http://www.sans.org/top20/.
CVE (Common Vulnerabilities and Exposures) is a list of standardized names of vulnerabilities. For more information on CVE, see http://cve.mitre.org (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. nist.gov. 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.
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 http://www.sans.org/top20.
Vulnerability Type |
Description |
---|---|
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. |
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.
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.
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.
File Pathname |
Permission |
Description |
---|---|---|
/boot/grub/grub.conf |
600 |
GRUB bootloader configuration file |
/etc/cron.allow |
400 |
List of users permitted to use cron to submit periodic jobs |
/etc/cron.deny |
400 |
List of users who cannot use cron to submit periodic jobs |
/etc/crontab |
644 |
System-wide periodic jobs |
/etc/hosts.allow |
644 |
List of hosts allowed to use Internet services that are started using TCP wrappers |
/etc/hosts.deny |
644 |
List of hosts denied access to Internet services that are started using TCP wrappers |
/etc/logrotate.conf |
644 |
File that controls how log files are rotated |
/etc/pam.d |
755 |
Directory with configuration files for pluggable authentication modules (PAM) |
/etc/passwd |
644 |
Old-style password file with user account information but not the passwords |
/etc/rc.d |
755 |
Directory with system startup scripts |
/etc/securetty |
600 |
TTY interfaces (terminals) from which root can login |
/etc/security |
755 |
Policy files that control system access |
/etc/shadow |
400 |
File with encrypted passwords and password expiry information |
/etc/shutdown.allow |
400 |
Users who can shutdown or reboot by pressing Ctrl-Alt-Delete |
/etc/ssh |
755 |
Directory with configuration files for the Secure Shell (SSH) |
/etc/sysconfig |
755 |
System configuration files |
/etc/sysctl.conf |
644 |
Kernel configuration parameters |
/etc/syslog.conf |
644 |
Configuration file for syslogd server that logs messages |
/etc/vsftpd |
600 |
Configuration file for the very secure FTP server |
/etc/vsftpd.ftpusers |
600 |
List of users who cannot use FTP to transfer files |
/etc/xinetd.conf |
644 |
Configuration file for the xinetd server |
/etc/xinetd.d |
755 |
Directory containing configuration files for specific services that the xinetd server can start |
/var/log |
755 |
Directory with all log files |
/var/log/lastlog |
644 |
Information about all previous logins |
/var/log/messages |
644 |
Main system message log file |
/var/log/secure |
400 |
Security related log file |
/var/log/wtmp |
664 |
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.
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.
File Pathname |
Ownership |
Permission |
---|---|---|
/etc/group |
root.root |
644 |
/etc/passwd |
root.root |
644 |
/etc/shadow |
root.root |
400 |
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.
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.
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.
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).
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.
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 http://www.insecure.org/tools.html. 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.
Type |
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 www.insecure.org/nmap.
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 192.168.0.2-10
Here’s part of a typical output listing from that nmap command:
Starting nmap V. 3.00 ( www.insecure.org/nmap/ ) Interesting ports on dhcppc1 (192.168.0.2): (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 (192.168.0.3): (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:
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*
After you find the sharutils package, install it with the following command:
rpm -ivh sharutils*.rpm
To download and install Nessus, follow these steps:
Read the instructions on http://www.nessus.org/posix.html. Then scroll down on that page, click a link to an appropriate FTP site, and download the files nessus-installer.sh and MD5.
Type the following command to install Nessus (you must have the development tools, including the GIMP Toolkit, installed):
sh nessus-installer.sh
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:
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:
nessus-mkcert
Provide the requested information to complete the certificate generation process.
Create a nessusd account with the following command:
nessus-adduser
When prompted, enter your user name, password, and any rules (press Ctrl-D if you don’t know what rules to enter).
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.
Start the Nessus server with this command:
nessusd -D
Run the Nessus client by typing the following command in a terminal window:
nessus
The Nessus Setup window appears.
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.
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 192.168.0.0, I enter the address as:
192.168.0.0/29
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 http://www.saintcorporation.com/products/download.html 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 (http://www.sans.org/top20.htm).
To try out SARA, download the latest version of SARA from http://www-arc.com/sara/downloads/. After downloading the compressed tar file, build and install the software using these steps:
Unpack tar file with the command:
tar zxvf sara*
To configure SARA, type the following commands:
cd sara* ./configure
To build the software, type:
make
After SARA is built, run it with the following command:
./sara
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.