Computer Security Audits and Vulnerability Testing Types - Security - Linux All-in-One For Dummies, 5th Edition (2014)

Linux All-in-One For Dummies, 5th Edition (2014)

Book VI. Security

Chapter 3. Computer Security Audits and Vulnerability Testing Types

In This Chapter

arrow Understanding computer security audits

arrow Learning a security test methodology

arrow Reviewing host and network security

arrow Appreciating vulnerability testing

arrow Exploring different security testing tools

When you see the term audit, the odds are good you think of the kind involving taxes. In actuality, many types of audits exist, and one of them is a computer security audit. The purpose of a computer security audit, in its simplest form, is to test your system and network security. For larger organizations, an independent auditor (much like with the auditing of financial statements) can do the security audit. If you have only a few Linux systems or a small network, you can do the security audit as a self-assessment, just to figure out if you’re doing everything okay.

This chapter explains how to perform computer security audits and shows you a number of free tools and resources to help you test your system’s security.

Understanding Security Audits

An audit is simply an independent assessment of whatever it is you’re auditing. So a computer security audit is an independent assessment of computer security. If someone conducts a computer security audit of your organization, he or she focuses typically on two areas:

· Independent verification of whether your organization complies with its existing policies and procedures for computer security. This part is the nontechnical aspect of the security audit.

· Independent testing of how effective your security controls (any hardware and software mechanisms you use to secure the system) are. This part is the technical aspect of the security audit.

Why do you need security audits? For the same reason you need financial audits — mainly to verify that everything is being done the way it’s supposed to be done. For public as well as private organizations, management may want to have independent security audits done so as to assure themselves that their security is A-OK. Irrespective of your organization’s size, you can always perform security audits on your own, either to prepare for independent security audits or simply to know that you’re doing everything correctly.

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 the case of self-assessments, preparation for any annual independent security testing that your organization might have to face

Nontechnical aspects of security audits

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. Here’s a list of some items to be verified:

· Risks are periodically assessed.

· An entity-wide security program plan is in place.

· A security program-management structure is 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 involve reviewing documents and interviewing appropriate individuals to find out how the organization manages computer security. For a small organization or a home PC, expecting plans and procedures in documents is ridiculous. In those cases, simply make sure that you have some technical controls in place to secure your system and your network connection.

Technical aspects of security audits

The technical side of computer security audits focuses 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, for individual hosts and for the entire network.

Implementing a Security Test Methodology

A key element of a computer security audit is a 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 Internet connection.

2. If there are many hosts and network connections, determine which are the important hosts and network devices that need to be tested. The importance of a host depends on the kinds of applications it runs. For example, a host that runs the corporate database would be more important than the hosts that serve as desktop systems.

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

4. Test the network. This step is usually performed by attempting to break through the network defenses from another system on the Internet. If there’s 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 vulnerabilities and risks.

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

· Prevention: Includes the mechanisms (nontechnical and technical) that help prevent attacks on the system and the network.

· Detection: 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: Includes the steps for tasks such as reporting an incident to authorities and restoring important files from backup after a computer security incident occurs.

For host and network security, each of these areas has some overlaps. For example, prevention mechanisms for host security (such as good passwords or file permissions) can also provide network security. Nevertheless, thinking in terms of the three areas — prevention, detection, and response — does help.

Some common computer vulnerabilities

Before you can think of prevention, however, you have to know the types of problems you’re trying to prevent — the common security vulnerabilities. The prevention and detection steps typically depend on the specific vulnerabilities. Basically, the idea is to check whether a host or a network has the vulnerabilities that crackers exploit.

Online resources on computer vulnerabilities

Several online resources identify and categorize computer security vulnerabilities:

· SANS Institute publishes a list of the top 20 most critical Internet security vulnerabilities — the Top Cyber Security Risks index — at 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. Using the CVE name to describe vulnerabilities is common practice.

· National Vulnerability Database (NVD) is a searchable index of information on computer vulnerabilities, published by the National Institute of Standards and Technology (NIST), a United States government agency. NVD is online athttp://nvd.nist.gov.

Typical computer vulnerabilities

The SANS Internet security vulnerabilities list includes several types of vulnerabilities, such as Windows, cross-platform, and Unix. Of these, Unix and cross-platform vulnerabilities are relevant to Linux.

lxo-102.eps Table 3-1 summarizes some common Unix and cross-platform vulnerabilities that apply to Linux.

Table 3-1 Some Common Vulnerabilities to Unix Systems

Vulnerability Type

Description

BIND DNS

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.

Apache Web Server

Some Apache Web Server modules (such as mod_ssl) have known vulnerabilities. Any vulnerability in Common Gateway Interface (CGI) programs used with web servers to process interactive web pages can provide attackers a way to gain access to a system.

Authentication

User accounts often have no passwords or have weak passwords that are easily cracked by password-cracking programs.

CVS, Subversion

Concurrent Versions System (CVS) is a popular source-code control system used in Linux systems. Subversion is another version control system for Linux that is becoming popular. These version control systems have vulnerabilities that can enable an attacker to execute arbitrary code on the system.

sendmail

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

SNMP

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 an attacker may be able to reconfigure or shut down your system if it is running SNMP.

Open Secure Sockets Layer (OpenSSL)

Many applications, such as Apache Web Server, use OpenSSL to provide cryptographic security for a network connection. Unfortunately, some versions of OpenSSL have known vulnerabilities that could be exploited.

Network File System (NFS) and Network Information Service (NIS)

Both NFS and NIS have many security problems (for example, buffer overflow, potential for denial-of-service attacks, and weak authentication). Also, NFS and NIS are often misconfigured, which could allow local and remote users to exploit the security holes.

Databases

Databases such as MySQL and PostgreSQL are complex applications and can be difficult to correctly configure and secure. These databases have many features that can be misused or exploited to compromise the confidentiality, availability, and integrity of data.

Linux kernel

The Linux kernel is susceptible to many vulnerabilities, such as denial of service, execution of arbitrary code, and root-level access to the system.

Host-security review

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 a password for a boot loader, and use encryption.

· Detection: Capture log messages and check file integrity with Tripwire (a tool that can detect changes to system files).

· Response: Make routine backups and develop incident response procedures.

The following sections review a few of these host-security mechanisms.

Operating system updates

Linux distributions release updates soon. When security vulnerabilities are found, Linux distributions release an update to fix the problem. Many distributions offer online updates that you can enable and use to keep your system up to date. The details of updating the operating system depend on the distribution. (See Book V, Chapter 4 for information on how to update Linux online.)

File permissions

Protect important system files with appropriate file ownerships and file permissions. The key procedures in assigning file-system ownerships and permissions are as follows:

· 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 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 to access the files.

Table 3-2 lists some important system files in Linux, showing the typical numeric permission setting for each file (this may differ slightly, depending on the distribution). See Chapter 2 of this minibook for more on numeric permission settings.

Table 3-2 Important System Files and Their Permissions

File Pathname

Permission

Description

/boot/grub/menu.lst

600

GRUB boot loader menu file

/etc/cron.allow

400

List of users permitted to use cron to submit periodic jobs

/etc/cron.deny

400

List of users who can’t 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 rotate

/etc/pam.d

755

Directory with configuration files for pluggable authentication modules (PAMs)

/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 log in

/etc/security

755

Policy files that control system access

/etc/shadow

400

File with encrypted passwords and password expiration information

/etc/shutdown.allow

400

Users who can shut down 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 the syslogd server that logs messages

/etc/udev/udev.conf

644

Configuration file for udev — the program that provides the capability to dynamically name hot-pluggable devices and create the device files in the /dev directory

/etc/vsftpd

600

Configuration file for the Very Secure FTP server

/etc/vsftpd.ftpusers

600

List of users who are not allowed to 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/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 is owned by root, the program runs with root privileges, no matter who actually 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 is unusual.

Password security

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

Table 3-3 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 policy that answers the question of what to do if something unusual does happen to the system. The policy tells you how to proceed if someone breaks into your system.

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, remember these key points:

· 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

A network-security review focuses on assessing the security mechanisms in each of the following areas:

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

· Detection: Use network intrusion detection and capture system logs.

· Response: Develop incident response procedures.

Some key steps in assessing the network security are described in the following three subsections.

Services started by inetd or xinetd

Depending on your distribution, the inetd or xinetd server may be configured to start some Internet services such as TELNET and FTP. The decision to turn on some of these services depends on such factors as how the system connects to the Internet and how the system is being used. You can usually turn off most inetd and xinetd services by commenting out the line — just place a pound sign (#) at the beginning of the line.

If you are using xinetd, it is possible to see which services are turned off by checking the configuration files in the /etc/xinetd.d directory for all the configuration files that have a disable = yes line. (The line doesn’t count if it’s commented out, which is indicated by a #character at the beginning of the line.) You can add a disable = yes line to the configuration file of any service that you want to turn off.

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

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

· /etc/hosts.deny lists hosts denied access to services.

Standalone services

Many services, such as apache or httpd (web server) and sendmail (mail server), start automatically at boot time, assuming they’re configured to start that way.

In some distributions, you can use the chkconfig command to check which of these standalone servers are set to start at various run levels. (See Book V, Chapter 1 for more about run levels.) Typically, most systems start 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 chkconfig --list | more. When you do a self-assessment of your network security and find that some servers shouldn’t be running, you can turn them off for run levels 3 and 5 by typingchkconfig --level 35 servicename off, where servicename is the name of the service you want to turn off.

In some distributions, you can use a GUI tool to see which services are enabled and running at any run level. With YaST, for example, click System on the left side of the window, and then click Runlevel Editor on the right side of the window.

When you audit network security, make a note of all the servers that are turned on — and then try to determine whether they should really be on, according to what you know about the system. The decision to turn on a particular service depends on how your system is used (for example, as a web server or as a desktop system) and how it’s connected to the Internet (say, through a firewall or directly).

Penetration test

A penetration test is the best way to tell what services are really running on a 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 break in or, at minimum, get access to services running on your Linux system.

One aspect of penetration testing is to see what ports are open on your Linux system. The port number is simply a number that identifies TCP/IP network connections to the system. The attempt to connect to a port succeeds only if a server is running, or “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 describes the automated process of trying to connect to each port number to see whether a valid response comes back. Many available automated tools can perform port scanning — you can install and use a popular port-scanning tool called nmap (described later in this chapter).

After performing a port scan, you know which ports are open and could be exploited. Not all servers have security problems, but many servers have well-known vulnerabilities. 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 (some vulnerability scanners are described in the following sections). Whether your 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 whether you have any holes in your defenses.

Vulnerability Testing Types

The number-one purpose of penetration testing is to identify vulnerabilities. When viewing such a test from this angle, it is important to understand that there are three ways of approaching it: black, white, or gray. These three approaches differ in the amount of information you assume you have in the beginning; you can use the color with almost any other word: black box versus white box if it is a piece of software doing the testing; black hat versus white hat if is an individual doing the testing; and so on. The following discussion focuses on the individual and uses boxas the preferred noun.

· With black-box testing, the tests assume no knowledge of the network and look for vulnerabilities that an outsider might stumble across, such as open ports and weak passwords.

Imagine that a bored miscreant came across your network at random and decided to bring it to its knees.

· With white-box testing, the test assumes that the attacker is a knowledgeable insider who’s trying to break the system.

Imagine that you just fired a system administrator and they want to get back at you by crashing your network.

· Between these two extremes rests the realm of gray-box testing. Here the assumption is that an insider is behind the problem.

Imagine someone from shipping is angry about not getting the raise he or she thought was deserved, and so wants to make the company pay. The attacker doesn’t have the knowledge an administrator would, but still knows more about the systems than a complete outsider would.

Exploring Security Testing Tools

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

You can browse a list of the top 100 security tools (based on an informal poll of nmap users) at http://sectools.org. Table 3-4 lists a number of these tools by category. A few of the freely available vulnerability scanners are described in the next few sections.

Table 3-4 Some Popular Computer-Security Testing 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, ngrep, AirSnort (802.11 WEP encryption-cracking tool)

Host-security tools

Tripwire, lsof

Packet sniffers

tcpdump, Ethereal, dsniff, sniffit

Intrusion detection

Snort, Abacus portsentry, scanlogd, NFR, LIDSSystems (IDSs)

Password-checking tools

John the Ripper, LC4

Log analysis and monitoring tools

logcolorise, tcpdstats, nlog, logcheck, LogWatch, 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 offer, what operating system (and the operating system version) they run, what type of packet filters or firewalls they use, and dozens of other characteristics. You can read more about nmap at http://nmap.org.

If nmap is not already installed, you can easily install it on your distribution either with the command apt-get install nmap or through the software search facility of YaST (find nmap) or any distribution-specific interface you may have.

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

nmap -O -sS 192.168.0.4-8

Here’s a typical output listing from that command:

Starting nmap 6.40 ( http://www.insecure.org/nmap/ ) at 2013-08-28 16:20 EDT
Interesting ports on 192.168.0.4:
(The 1659 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
111/tcp open rpcbind
631/tcp open ipp
MAC Address: 00:C0:49:63:78:3A (U.S. Robotics)
Device type: general purpose
Running: Linux 3.9.X|3.9.X|3.9.X
OS details: Linux 2.4.18 - 2.6.7
Uptime 9.919 days (since Thu Aug 18 18:18:15 2013)
. . . Lines deleted . . .
Nmap finished: 5 IP addresses (5 hosts up) scanned in 30.846 seconds

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

For a very quick scan of your own machine, you can use the IP address of 127.0.0.1 (as shown in Figure 3-1); hopefully the scan will verify that the ports are closed.

Figure 3-1: You can view any open ports with nmap.