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.

A typical computer security audit of your organization would focus on two areas:

Independent verification of whether your organization is complying with its existing policies and procedures for computer security. This is the nontechnical part of the security audit.
Independent testing of the effectiveness of your security controls, which refer to any hardware and software security mechanisms you use to secure the system. This is the technical part of the security audit.

You might wonder why you need security audits. You need them for the same reason an organization needs financial audits—mainly to verify that everything is being done the way it is supposed to be done. For public as well as private organizations, management may want independent security audits to assure themselves that their security is adequate. Regardless of your organization’s size, you can always perform security audits on your own, either to prepare for independent security audits or simply to verify that you’re doing everything right.

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:

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.

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

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 http://www.sans.org/top20.

Table 22-4: Some Common Computer Vulnerability Types
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.

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

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	Ownership	Permission
/etc/group	root.root	644
/etc/passwd	root.root	644
/etc/shadow	root.root	400

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.

One aspect of penetration testing is to see what ports are open on your Red Hat Linux system. The port number is simply a number that identifies specific TCP/IP network connections to the system. The attempt to connect to a port succeeds only if a server is running on that port (or put another way, if a server is “listening on that port”). A port is considered to be open if a server responds when a connection request for that port arrives.

The first step in penetration testing is to perform a port scan. The term port scan is used to describe the automated process of trying to connect to each port number and see if a valid response comes back. There are many automated tools available to perform port scanning—Red Hat Linux comes with a popular port scanning tool called nmap (I describe it later in this chapter).

After performing a port scan, you know the potential vulnerabilities that could be exploited. Not all servers have security problems, but many servers have well-known vulnerabilities, and an open port provides a cracker a way to attack your system through one of the servers. In fact, you can use automated tools called vulnerability scanners to identify vulnerabilities that exist in your system. (I describe some vulnerability scanners next.) Whether your Red Hat Linux system is connected to the Internet directly (through DSL or cable modem) or through a firewall, use the port scanning and vulnerability scanning tools to figure out if you have any holes in your defenses. Better you than them!

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

Table 22-7: Some Popular Computer Security Tools
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

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.

Nessus

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

SAINT

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.

SARA

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.