Auditing Your Environment

The most effective method of validating your security policies and posture is through the use of audits . Your audit process should include not only an examination of your policies to ensure that they are accurate and well written, it should verify that technical controls are in place that enforce them. It should also contain an active test of your systems and applications to test not only compliance with the security policies but also vulnerabilities to threats. The active testing of security controls and vulnerabilities is commonly known as penetration testing or vulnerability assessment . These guidelines cause a good security audit to be composed of three distinct components :

• A checklist of items composed from your policy and from industry best practices This checklist is used to verify and validate that everything contained in your policy is indeed occurring in your environment and that you are adhering to industry best practices. For example, if your security policy states that certain ports should be blocked at your external firewall, the audit would verify that those ports are indeed blocked.

• A vulnerability assessment (VA) A VA comprises testing your systems for common vulnerabilities to determine what potential exposure an organization might have. For example, a VA might test your Cisco routers to see if they are vulnerable to various denial of service attacks.

• A penetration test A penetration test is similar to a VA test with one major difference. Whereas a VA seeks to identify vulnerabilities, a penetration test seeks to exploit those vulnerabilities in an attempt to bypass your defenses and gain access to your systems. For example, a penetration test might attempt to brute-force guess what a VPN pre-shared key is, allowing the attacker to establish a VPN connection to your network.

One thing to understand about an audit is that just because someone claims they have performed a security audit doesn t mean that is what they actually did. What they might have done is performed a security review, which is a little different. The term security audit has a very distinct meaning, and it is becoming more important for a company to understand that meaning as a result of laws being enacted to ensure the security of critical information. A security audit should only be performed by someone who is a certified auditor . What constitutes a certified auditor often depends on the laws and regulations that govern your business; however, you can find some general references about certified security auditors at the following websites :

• International Register of Certificated Auditors (http://www.irca.org/index.html)

• Information Systems Audit and Control Association (http://www.isaca.org/)

There are two primary methods of auditing your environment. The first is an internal audit, where either your internal audit team or you and your staff will audit your policies and test your infrastructure. The second is an external audit, where you have an external company come in and perform an audit of your policies and environment.

Performing an Internal Audit

The primary benefit of an internal audit is that it is a relatively low-cost endeavor because you will be using local resources. Many companies organizational charts maintain a separate audit staff from the IT or security staff. This is the best method of performing an internal audit because you have a clear separation of audit and technical resources, thus alleviating any appearance of impropriety. In addition, a dedicated audit staff is generally more trained and specialized in performing the kinds of testing required for an effective audit than your normal IT or security staff.

There are a couple of drawbacks, however, that you need to consider when performing internal audits. First, if the audit is being performed by the people involved in hardening your network infrastructure, they are susceptible to overlooking issues. This is not an intentional issue in most cases. However, because they know what should be occurring, they are vulnerable to assuming certain things occur. It s kind of like that Internet brain teaser where you are given a sentence to read and asked how many times a certain word occurs. Upon rereading it, however, you find that the word was never used, but because you are so used to reading that word in the phrase, your mind assumed it was there. Your internal auditors who are also members of the IT or security team may do the same thing, assuming that certain procedures are being followed because they are expecting that to be the case. The second drawback is that if you don t have dedicated internal auditors, they may lack the expertise of knowing exactly what and how to test for issues. This is not a condemnation of your internal personnel s, yours, or my skills, but the reality is that most of us are not hackers. We do not have the time to be hackers. Instead, we have to spend the vast majority of our time working on issues that facilitate the corporate goals and objectives as part of the daily IT or security grind. You simply need to be aware of the limitations that exist in undertaking an internal audit.

Common Auditing Tools and Documentation

Here s a list of some tools and documentation available for those of us who aren t hackers that can assist us in auditing our environments for most of the basic threats and vulnerabilities:

• The Open Source Security Testing Methodology Manual ( OSSTMM ) This manual, by Pete Herzog (http://www.isecom.org/projects/osstmm.shtml), is an excellent reference for providing a security testing methodology for the following six security areas: information security, process security, Internet technology security, communications security, wireless security, and physical security.

• Insecure .org This site maintains a list of the top-75 security tools, based on a poll of the subscribers of the nmap-hackers mailing list (http://seclists.org/#nmap-hackers), at http://www.insecure.org/tools.html. I will point out a couple of tools of particular value in auditing your environment.

• Port scanners These tools try to connect to a system on many different ports in an attempt to identify the ports on which a system will respond. This can assist a hacker in determining what the target system is or what types of exploits to attempt against a target. A number of commercial and open-source port scanners are available on the market:

  • Nmap 3.48 and Nmapwin 1.3.1 These are both simple port scanners that can be used to determine the open network ports on which a device is responding. Nmap works on Unix/Linux systems, whereas Nmapwin is designed for Microsoft Windows systems. Both are free products that can be obtained from http://www.insecure.org/nmap/index.html. I highly recommend either version of Nmap.

  • GFI LANguard Network Security Scanner (N.S.S) This is a commercial hybrid port scanner and rudimentary vulnerability-assessment tool. It can be obtained at http://www.gfi.com/lannetscan/.

  • netcat This tool has been described as a TCP/IP Swiss army knife . Although technically not a port scanner, netcat is an excellent tool when used in conjunction with a port scanner to connect to the open ports in an attempt to determine exactly what program is actually running on the port. netcat for Windows and Unix can be obtained at http://www.atstake.com/research/tools/network_utilities/.

• Vulnerability analyzers (VA) and assessment tools These products use a database of signatures or scripts to detect whether a system is vulnerable to a certain exploit. By running a VA program against a device or network, you can determine what vulnerabilities your infrastructure equipment is susceptible to. Be advised, however, that VA programs are not a vulnerability-assessment panacea. Many provide false positives ”and, more important false negatives ”that can give you an inaccurate picture in regard to your security posture. Here are the five main VA tools on the market today:

  • Nessus 2.0 This is an open-source vulnerability-assessment tool provided for free on Unix/Linux systems. Also, a retail version is available for Windows. One of the benefits of Nessus is that its scripts are constantly being updated by members of the open-source community, which generally results in a quicker ability to detect new vulnerabilities. You can obtain Nessus at http://www.nessus.org. I highly recommend Nessus.

  • Internet Security Systems (ISS) Internet Scanner 7.0 This retail product can be obtained at http://www.iss.net.

  • eEye Digital Security s Retina 4.9.145 This retail product can be obtained at http://www.eeye.com/html.

  • Symantec s NetRecon 3.6 This retail product can be obtained at http://enterprisesecurity.symantec.com/products/products.cfm?ProductID=46.

  • SAINT s SAINT 5.0 This retail product that can be obtained at http://www.saintcorporation.com/.

Heads Up

Because many VA tools are actively attempting to exploit systems, you should use extreme caution in running them against production equipment. For example, if a particular vulnerability will render a device unusable due to a denial of service attack, running the VA program could well have the same effect. Nessus is particularly notable for its ability to crash systems, in some cases to the degree of requiring a complete rebuild to recover.

 

• Packet sniffers These are simply invaluable in performing a security audit, as well as for daily network administration tasks . The reason for this is simple: Only with a packet sniffer can you directly observe exactly how systems are communicating with each other. You can decode and translate the conversations occurring on your network, giving you insight into precisely what your network devices are doing. For example, we all know what a TCP three-way handshake is. Document after document explains that it is used by two devices to negotiate a TCP conversation. This simple expression is great from an esoteric theory perspective, but it doesn t tell us how it works. It is only by decoding and viewing the establishment of a TCP three-way handshake that we can truly understand what is occurring and precisely how network communications work. For example, Figure 13-3 shows the TCP three-way handshake and session negotiation (packets 21, 22, and 23) occurring before an SSH connection is established between two systems.

  
  Figure 13-3: TCP three-way handshake

  • Microsoft Network Monitor 2.0 This retail product is a component of Microsoft System Management Server. A free version ships as a component of Microsoft s Server class operating systems; however, it will only monitor traffic that is sourced or destined for the server. Microsoft Network Monitor 2.0 only runs on Windows platforms, though the full version can capture any packets on the network. I highly recommend Microsoft Network Monitor. You can obtain it by purchasing Microsoft SMS at http://www.microsoft.com/.

  • Ethereal 0.10.0 This freeware product runs on Unix/Linux and Windows platforms. Although I like the interface in Network Monitor 2.0 better than Ethereal s, Ethereal is a very robust packet sniffer with the particularly useful feature of replaying TCP conversations, which allows you to see the output of a conversation on your screen, as opposed to having to manually piece it together from the packet decodes. You can obtain Ethereal at http://www.ethereal.com. I highly recommend Ethereal.

• Figure 13-4 demonstrates why packet sniffers are so valuable and dangerous. Although I sanitized the image by removing any addresses and names , this was a capture I ran while chatting with the tech editor for this book. Notice how easy it is to view the entire conversation. Indeed, clear-text communication is not really that top secret if you have a sniffer that can capture and decode the conversation.

  
  Figure 13-4: Ethereal capture

  • Network Associates Sniffer Distributed and Netasyst Network Analyzer These retail products run on Microsoft Windows platforms only. Sniffer Distributed is a two-component solution consisting of the actual sniffer probe that you capture traffic with and a separate management console that you decode and view the captured traffic with. Netasyst is the replacement product for Sniffer basic, which is designed to run on a local system and capture traffic like Ethereal or Microsoft Network Monitor. You can obtain either product at  http://www.nai.com.

The Value of a Sniffer

I once had a customer that was experiencing connectivity problems between their web server in a DMZ and their SQL server on their internal network. The systems could not communicate with each other when the firewall was in place, but they worked fine when the firewall wasn't in place. This was a particularly troubling issue, and no logging on the firewall gave any indication of the problem. It was not until we put a sniffer on the network and monitored the conversation that we realized the programmers were causing the web server to initiate a TCP three-way handshake on one port and then switch to another port for the data conversation to occur. Normally, a stateful firewall has an entry in its state table that keeps track of incoming and outgoing communications, so the firewall can determine which responses should be automatically allowed to pass. Switching the port numbers in use had the effect of causing the firewall to drop the data conversation because it did not have an entry in its state table for the conversation, which in turn caused a nonstop cycle of initiating a three-way handshake and attempting to send data, resulting in the initiation of another three-way handshake, and so on. In addition, the system was making a name resolution call that would fail when the firewall was in place but generated no errors. Without using a packet sniffer to see exactly how the systems were communicating, we would have found it much more difficult to diagnose the problem. The solution in this case required the programmers to change the SQL configurations and the network team to configure the firewall to permit the DNS request.

 

Heads Up

All of these tools, and especially a packet sniffer, are a real gift if a hacker can find them installed on your network, ready to be used. As a result, you should not install packet sniffers, or any of the other tools, on your servers and desktops in general. Like all applications, only install them when and where you need them, and remove them when you are done.

 

Using Nmap and Nessus to Perform a Basic Security Review

Two tools you should have in your security toolkit are Nmap and Nessus. Although both originated as Linux/Unix only utilities, Nmap now runs native on Windows as well, and Nessus has a Windows client that you can run against the Nessus server on Linux/Unix. For someone who does not have a Linux/Unix background, these tools may seem like they are more of a hassle than they are worth, but nothing could be further from the truth. In fact, it was my desire to run both of these tools that caused me to decide to learn Linux a number of years ago.

A note of caution needs to be mentioned before we start, because I do not want to give you the impression that running these two tools will give you an accurate security audit, vulnerability assessment, or penetration test of your systems. They will not do this. However, if you have never run any kind of tests against your systems, running these two tools will give you a good starting point on things to look at and tasks to perform before you invest the money in a formal security audit. Likewise, these two tools can help you identify any issues involved if you are looking for a quick-and-dirty answer to the question, Is there anything blatant I have overlooked? It is far more efficient and cost effective to become proficient in these tools and clear up the easy stuff yourself and leave the high-dollar penetration testers to find the hard stuff. We will start by looking at Nmap and what it can do; then we will look at Nessus and what it can do.

Port Scanning with Nmap

Nmap is a basic port scanner. It works by trying to connect to a remote host using TCP or UDP ports in an attempt to determine what applications and services might be responding on the system. Although this does not provide a guarantee that a certain service is running, it is usually a safe bet that it is. For example, if someone were to decide to run an SMTP server on TCP port 80, which is normally reserved for HTTP servers, a port scanner will simply state that port 80 is open. The safe assumption is that it means that an HTTP server is running on that port. However, only by performing a vulnerability assessment or penetration test will you know for sure. The value in a port scanner is the ability to identify whether ports are open that you did not intend to be open. For example, if you have configured your firewall to only allow TCP ports 25 (SMTP), 80 (HTTP), and 110 (POP3) to be open, when you run your port scan, you should not see any other open ports. If you do, this is an indication that something might be running that you did not plan to have running.

Nmap has two interfaces: a command-line interface and a GUI. The command-line interface generally provides more options for running Nmap in different configurations than the GUI does, though the GUI really just runs the command-line Nmap executable in the background. The two primary types of scans are TCP scans and UDP scans . As the names imply, a TCP scan is used to detect open TCP ports, and a UDP scan is used to detect open UDP ports.

A UDP scan is a relatively straightforward process, although it can provide inconsistent results. This is due to the nature of how UDP works. Because UDP is a connectionless protocol, there isn t a good way to know whether a UDP is closed. Nmap functions by sending a 0-byte UDP packet to each port on the target system. If an ICMP port unreachable message is received, the port is closed. In all other cases, the port is assumed open. The problem with this is that there are many systems that will not respond with an ICMP port unreachable message because they are trying to mask the fact that anything exists on the target IP address. This is commonly known as operating in stealth mode, because you can t really tell if something does or doesn t exist on that IP address. Consequently, you need to take your UDP port scan results with a grain of salt. If Nmap is reporting that virtually all UDP ports are open, the system you are scanning is probably operating in stealth mode.

Running a UDP scan is pretty easy using the GUI. Simply start Nmapwin from your Start menu, and you will be presented with the main Nmap screen. Leaving everything else as their defaults, enter the name or IP address of the host or the range of IP addresses you want to scan in the Host field and then select UDP Scan in the Scan Mode section. When you are ready to initiate the scan, simply click Scan. Nmap will begin scanning the target, as shown here:

Notice how the actual nmap command to run the exact same scan is shown at the bottom of the screen:

 nmap -sU -PT -PI -O -T 3 urnst 

If you wanted to run Nmap at the command line, that is what you would type. Once the scan has completed, you will be presented with output, as shown here:

Looking at the results, it is probably a safe bet that the system scanned was a Microsoft Windows “based system. It is responding on most Microsoft NetBIOS “based port numbers, but we can see that it is also responding on NTP and SNMP ports. If you have a policy that SNMP should not be run on the target system, running a port scan is a quick way to determine whether the machine is in compliance.

Running TCP scans is a little more difficult than running a UDP scan because of the options available for TCP. Unlike UDP, which really only has one scanning option, there are five primary TCP port scanning methods:

• Connect scan This is the most basic form of TCP scanning, and it uses the connect() system call provided by the operating system to open a connection to every port specified. This is essentially the normal three-way handshake. If a connection can be established, the port is open. If it can t, the port is closed. This type of scan has the advantage of requiring no special privileges in order to run, but it s generally very easy to detect in target host logs.

• SYN stealth This is the most common scanning method and is often referred to as half-open scanning because Nmap will send a SYN packet as if it were trying to establish a session and wait for a response. If it receives a SYNACK response, the port is open. If it receives an RST response, the port is considered closed. If a SYNACK is received, Nmap will immediately send an RST to tear down the connection. The advantage of this type of scan is that fewer systems will log this type of connection, but the drawback is that it requires root privileges on the scanning system (not the target) to build this type of custom SYN packet.

• FIN stealth, Xmas tree, and Null scan These scanning methods are all designed to be as clandestine as possible when compared to a SYN stealth or connect scan. Because more firewalls have been designed to watch for open SYN connections, these advanced scanning methods can sometimes pass unnoticed by a firewall. The concept behind these scans is that closed ports are required to reply to a connection attempt with an RST response, whereas open ports are supposed to ignore the packets in question. A FIN scan uses a FIN packet to surprise the target because there is no corresponding SYNACK that preceded it. An Xmas tree scan will turn on the FIN, URG, and PUSH flags, whereas a Null scan turns off all flags. The drawback of this type of scan is that many systems, including Microsoft, Cisco, BSDI, HP/UX, MVS, and IRIX, do not respond appropriately to a FIN probe against an open port. They all respond with an RST when they should, according to RFC (RFC 793), simply drop the packet. As a result, you may only use these types of scans in special circumstances.

In most cases, you will only need to use a connect or SYN stealth scan for your testing. Personally, I tend to run SYN stealth scans because they are faster than a connect scan. Performing a connect scan is as simple as selecting Connect in the Scan Mode section and clicking Scan. Shown next is the result of a connect scan.

One Step Further

In order to understand what type of TCP port-scanning method to use, we have to first review how TCP communications occur and define some terms. Two hosts communicate over TCP by first establishing the manner in which the conversation is going to occur. This is known as a TCP three-way handshake . During the handshake, the systems negotiate the sequencing and windowing of the data. The initial connection request is known as a synchronization (SYN) request . The responding host then responds with a SYN and an acknowledgement (ACK) segment to acknowledge the original synchronization request. The originating host then responds with a final ACK that signifies that a session has been established (EST). TCP supports some other commonly used control bits, each having a distinct meaning:

• FIN Short for finished, the FIN control bit is used to tell the hosts to clear the connection because there is no more data to be sent.

• RST Short for reset, the RST control bit is used to tell the hosts to reset the connection, typically due to errors in the sequence numbers. For example, if a host expected to receive sequence 301 and actually received sequence 589, it would issue an RST to force another three-way handshake so that the sequencing could be renegotiated properly.

 

Shown next is the result of a SYN stealth scan. Notice that although the exact same number of ports were detected , it took only 3.085 seconds, compared to 418.991 seconds (almost 7 minutes) for the connect scan.

Although plenty of other options are available for running Nmap in a more advanced scanning configuration, these are the basic tasks you ll use for 99 percent of your port-scanning needs. Nmapwin ships with a really nice help file that contains very detailed information about all the options, how they work, and how to configure them.

Performing a Basic Vulnerability Assessment with Nessus

Whereas Nmap is a fairly straightforward port-scanning tool, Nessus is a little bit more complex to initially set up and configure. This is due to a combination of factors. First, it is much more robust and complex compared to Nmap. Second, the Nessus server component can only be installed on a Linux/Unix system.

Installing Nessus is fairly straightforward. First, you need to be logged in as root. You will need to install and configure the following components to support Nessus if you do not already have them:

• GTK The Gimp Toolkit version 1.2. You can obtain GTK from ftp://ftp.gimp.org/pub/gtk/v1.2.

• OpenSSL Although not required, OpenSSL is recommended because it is used for remote client connections to the Nessus server. You can obtain OpenSSL from http://www.openssl.org.

I recommend downloading and installing the nessus-installer.sh standalone installation package for the simplest installation routine. This eliminates the need to compile the binaries and the related tasks that make Linux not so user friendly. You can begin the installation by typing the following:

 [root@keoland nessus]# sh nessus-installer.sh 

The installer will begin and prompt you to press ENTER to continue:

 NESSUS INSTALLATION SCRIPT Welcome to the Nessus Installation Script ! This script will install Nessus 2.0.9 (STABLE) on your system. Please note that you will need root privileges at some point so that the installation can complete. Nessus is released under the version 2 of the GNU General Public License (see http://www.gnu.org/licences/gpl.html for details). To get the latest version of Nessus, visit http://www.nessus.org Press ENTER to continue 

Once you press ENTER , the nessus-installer will prompt you for where to install the files. Accept the defaults:

 ----------------------------------------------------------------------------  Nessus installation : installation location ---------------------------------------------------------------------------- Where do you want the whole Nessus package to be installed ? [/usr/local] <  enter  > ----------------------------------------------------------------------------  Nessus installation : Ready to install ---------------------------------------------------------------------------- Nessus is now ready to be installed on this host. The installation process will first compile it then install it Press ENTER to continue 

Once you press ENTER , the nessus-installer will begin installing and configuring Nessus on the system. When it is finished, you will be presented with the Nessus Installation: Finished screen:

 ----------------------------------------------------------------------------  Nessus installation : Finished ---------------------------------------------------------------------------- Congratulations ! Nessus is now installed on this host . Create a nessusd certificate using /usr/local/sbin/nessus-mkcert . Add a nessusd user use /usr/local/sbin/nessus-adduser . Start the Nessus daemon (nessusd) use /usr/local/sbin/nessusd -D . Start the Nessus client (nessus) use /usr/local/bin/nessus . To uninstall Nessus, use /usr/local/sbin/uninstall-nessus . Remember to invoke 'nessus-update-plugins' periodically to update your  list of plugins . A step by step demo of Nessus is available at :  http://www.nessus.org/demo/ Press ENTER to quit 

Once you have pressed ENTER , it is time to run the post-installation configuration steps. The first step is to generate a certificate for Nessus to use. This is done by changing to the /usr/local/sbin directory and running the nessus-mkcert program.

A wizard will walk you through the creation of the SSL certificate:

 [root@keoland nessus]# cd /usr/local/sbin [root@keoland sbin]# nessus-mkcert /usr/local/var/nessus/CA created ----------------------------------------------------------------------------  Creation of the Nessus SSL Certificate ---------------------------------------------------------------------------- This script will now ask you the relevant information to create the SSL certificate of Nessus. Note that this information will *NOT* be sent to anybody (everything stays local), but anyone with the ability to connect to your Nessus daemon will be able to retrieve this information. CA certificate life time in days [1460]: <  enter  > Server certificate life time in days [365]: <  enter  > Your country (two letter code) [FR]:  US  Your state or province name [none]:  TX  Your location (e.g. town) [Paris]:  Houston  Your organization [Nessus Users United]: <  enter  > ----------------------------------------------------------------------------  Creation of the Nessus SSL Certificate ---------------------------------------------------------------------------- Congratulations. Your server certificate was properly created. /usr/local/etc/nessus/nessusd.conf updated The following files were created : . Certification authority :  Certificate = /usr/local/com/nessus/CA/cacert.pem  Private key = /usr/local/var/nessus/CA/cakey.pem . Nessus Server :  Certificate = /usr/local/com/nessus/CA/servercert.pem  Private key = /usr/local/var/nessus/CA/serverkey.pem Press [ENTER] to exit 

The next step is to add a user to Nessus who is allowed to run the program. This can be done by running the nessus-adduser program from the /usr/locl/sbin directory. A wizard will walk you through the user-creation process:

 [root@keoland sbin]# nessus-adduser Using /var/tmp as a temporary file holder Add a new nessusd user ---------------------- Login :  wnoonan  Authentication (pass/cert) [pass] :  pass  Login password : <  password  > User rules ---------- nessusd has a rules system which allows you to restrict the hosts that wnoonan has the right to test. For instance, you may want him to be able to scan his own host only. Please see the nessus-adduser(8) man page for the rules syntax Enter the rules for this user, and hit ctrl-D once you are done : (the user can have an empty rules set) <  CTRL+D  > Login : wnoonan Password : password DN : Rules : Is that ok ? (y/n) [y]  y  user added. 

The next step is to run the nessus-update-plugins command to update to the latest version of the plug-ins. The plug-ins contain the information that Nessus uses to test for vulnerabilities. As new vulnerabilities are written, new Nessus plug-ins are written to test for those vulnerabilities. You can run the command from the /usr/local/sbin directory as follows :

 [root@keoland sbin]# nessus-update-plugins 

The final step is to start the Nessus server in daemon mode. Nessus is a client/server vulnerability-assessment tool. The Nessus server running on Linux/Unix is where all the testing is performed. The Nessus client is used to connect to the Nessus server and configure it to perform the configured tests. The client and server can be running on the same system, or the client can be running on a remote system (even running Microsoft Windows if the NessusWx client is used) that connects to the Nessus server over the network. The command to start Nessus in daemon mode is

 [root@keoland sbin]# nessusd D 

You can verify that the Nessus server is functioning by running the ps “ef grep nessusd command as follows:

 [root@keoland sbin]# ps -ef  grep nessusd root 29470 1 0 21:46 ? 00:00:00 nessusd: waiting for ncoming connections root 29474 3438 0 22:02 pts/1 00:00:00 grep nessusd 

Now that Nessus is installed and configured and the Nessus server is running, the next step is to run the Nessus client by running nessus at the command line, as follows:

 [root@keoland sbin]# nessus & 

Typing & after the command allows you to return to the command line to run other commands while the GUI client is running. The first step is to log on to Nessus using the user account you specified with the nessus-adduser command, as shown here:

You will be prompted for your SSL setup options. Select the option you prefer and click OK:

Depending on the option you selected, you will be prompted with certificate validation information. Click the appropriate button for your screen to continue. Option 1 will display and remember the certificate without worrying about whether or not the CA is a trusted CA. This is not a secure method of using SSL. Option 2 will only accept the server certificate if it is valid and certified by a trusted CA; however, it will not remember the certificate. This is a more secure and recommended method of configuration. Option 3 is similar to option 2; however, it remembers the server certificate. This will allow you to detect whether the certificate has changed. This is more secure than option 2 because if the certificate changes for some reason, you will be prompted and notified of the change.

Once you have been logged on, you will receive a pop-up message stating that plug-ins that have the ability to crash services have been disabled. Keep in mind that running certain tests can and will crash systems you are testing against. Enable them with caution.

Once you have been logged on to Nessus, you will be presented with the Plugins tab. There are literally hundreds of Nessus plug-ins you can choose to run (or not to run). However, if you want to run the most thorough test possible, you should select to enable all plug-ins:

Caution  

Enabling all plug-ins could cause the target host that is being tested to crash or have other unexpected results. For example, when I run a Nessus scan against my HP LaserJet 4050N printer, it causes the printer to start printing nonstop garbage pages and eventually causes an EIO error that requires me to physically reboot the printer. In my small lab, that is no big deal, but if you were to do this to hundreds of printers in your enterprise, I would bet that you would have a lot of unhappy people. Be very careful about enabling all your plug-ins to make sure that no critical business systems will be affected if you test a system with all plug-ins enabled. You can mitigate this to some degree by specifying the hosts that you want to scan, ensuring that your critical systems are not scanned until the risk associated with the scan is acceptable (for example, scanning during nonbusiness hours). Unfortunately, if you don t test with all plug-ins enabled, you will not get a complete and accurate vulnerability assessment.

Next, you will need to configure the Nessus preferences from the Prefs tab. Nessus uses Nmap to perform port scans, and this screen allows you to define what Nmap options to use. In addition, you can configure the following preferences:

• Timing Policy This defines how fast you want Nessus to run its tests. This is useful if you are trying to scan a system but want to take your time so as to not generate a bunch of log entries that would cause an administrator to discover that something is trying to exploit the system. Something to be aware of in setting the timing policy is that it can be used to try to scan a system without generating alerts that might notify an admin that something potentially harmful is occurring on the network. In some cases, you are going to want to scan systems in this manner, trying to avoid detection. You should only do this with the appropriate authorization, however. A benefit of slowing down the scanning rate is that if it does happen to start crashing systems, at least it is not doing it at breakneck pace, and hopefully it would give someone time to respond and shut down the scan before affecting too many systems.

• Ping the Remote Host This defines how and whether to attempt to ping the remote host. Many firewalls will no longer respond to an ICMP echo request, so turning this function off can allow Nessus to run under the assumption that the host is online without attempting to ping it.

• Libwhisker Options Libwhisker is used for HTTP server security testing, and these options allow you to configure how libwhisker should function under Nessus. Libwhisker is written and maintained by Rain.Forest.Puppy, a fairly well-known hacker and security consultant. You can find more information about libwhisker at http://www.wiretrip.net/rfp/lw.asp.

• SMB Use Domain SID to Enumerate Users This allows you to define Microsoft domain SID options to use in testing.

• Misc Information on News Server This section allows you to define news server connection settings for testing Network News Transport Protocol (NNTP) servers.

• Services This section allows you to define various Nessus service connection settings.

• HTTP NIDS Evasion This section allows you to configure settings for evading detection by a network intrusion-detection system (NIDS) while you are testing HTTP servers and services.

• Web Mirroring This section allows you to define how many web pages Nessus should mirror if it finds a web server running on the target host.

• FTP Writable Directories This section allows you to define how to test for FTP writable directories.

• Brute Force Login ( Hydra ) This section allows you to define how hydra should be configured for performing brute-force password cracking. Hydra is a tool developed by The Hackers Choice at http://www.thc.org/.

• SMTP Settings This section allows you to configure SMTP testing options.

• NIDS Evasion This section allows you to configure different techniques to evade detection by an NIDS.

• HTTP Login Page This section allows you to configure settings for HTTP login.

• SMB Scope This section configures Nessus to attempt to gain information about your Windows domain.

• SMB Use Host SID to Enumerate Local Users This allows you to define Microsoft host SID options to use in testing.

• Login Configuration This section allows you to specify usernames and passwords for various services that may request login authentication.

As you can see, there are a lot of options you can configure that will change how Nessus attempts to test a system. For simplicity, you can leave these settings at their default values until you get more comfortable with them, with the exception of the Nmap settings, which I would configure to use SYN stealth scanning to speed up the scanning process:

The next screen to configure is the Scan Options screen. Like the Prefs screen, it offers a number of options that will define how Nessus performs the scanning. I recommend leaving most settings at their default values until you get more comfortable with them, with the exception of turning off Connect Scanning and turning on Nmap and SYN Scan in the Port Scanner window:

The next screen to configure is the Target Selection screen. This is where you specify the name, IP address, or network range you want to scan against. In general, I recommend only scanning a Class C network range at a time, due to time and performance issues. If you have a larger network that you need to scan, you should scan it in Class C (255 host) size chunks . Once you have specified the target(s), you can begin the scan by clicking Start the Scan.

Nessus will display a scanning progress screen, as shown next. You can stop the scan at any time by clicking the Stop button. Be advised that depending on how many hosts you are trying to scan and how powerful the Nessus server is, it could take hours to complete a single scan. Nessus begins by performing a portscan (if you selected this option) before it begins running attack tests.

Once the scan has completed, you will be presented with a report screen that details the results of the scan. The report screen is separated into five sections:

• Subnet This section shows the subnet or range of hosts that were scanned. If you scanned a single host, it will be listed here as well. Once you select the subnet value, the list of hosts on that subnet will be displayed.

• Host This section is where the individual hosts from the subnet section are listed. This allows you to select a single host to view the vulnerabilities of just that system. Once you select the host to view, the list of open ports on that host will be selected.

• Port This section lists the ports detected as being open. Once you select a port, the list of severity issues will be displayed.

• Severity This section lists the issues discovered for the selected port. Once you select an issue, the details of the issue will be displayed in the Severity Details section.

• Severity Details This section displays information from Nessus regarding what the potential vulnerability is as well as any workarounds that may exist. Be advised that this section does not provide a definitive answer of exactly what is wrong. Often, it simply gives you a list of potential problems to which the target host might be vulnerable. Be aware that sometimes Nessus will report a false positive report here. For example, I commonly see Nessus report Apache vulnerabilities on web servers that I know for a fact are not running Apache.

The following shows a Nessus report screen where I have drilled down to select a security hole for port 161 (SNMP). Notice that the target system responded to the default SNMP community string of public, which is a cardinal sin and a no-no for all systems on the network, because every hacker and script kiddie is automatically going to attempt to connect using default community strings (public, private, security, and monitor).

The CAN number listed in the security details section represents a list of common vulnerabilities and exposures (CVEs) that are maintained at http://cve.mitre.org. For example, CAN-1999-0517 is the CVE candidate that refers to having a default, null, or missing SNMP community string.

If you want to save the report for future viewing, you can click the Save Report button. Although you can save your reports in a number of different file formats, I am particularly fond of HTML with Pies and Graphs, because I can store the reports on a web server in a format that is generally well liked by upper management due to the pretty graphs. This screen shows how you would save the report:

Figures 13-5 through 13-8 provide some examples of what the HTML reports look like. As you can see, the information is presented in a number of different formats, making it easy to cater not only to the technical folks but also to your upper management. When the reports are used for scanning multiple systems, the graphs in particular provide a very good representation of what protocols, services, and systems pose the greatest risk to your environment.

Figure 13-5: Nessus HTML Report Main Screen

Figure 13-6: Nessus HTML Report Statistics

Figure 13-7: Nessus HTML Report Security Risk Proportion

Figure 13-8: Nessus HTML Report Details

Although Nmap and Nessus are not tools that you should solely rely on to gauge your security posture, like a hammer and screwdriver, they are two tools that every security professional should have in their toolbox.

Performing an External Audit

The primary benefit to having an external audit performed is the fact that the audit is (or should be) performed by a company that has expertise in specifically auditing and testing an organization s security policies for compliance, function, and vulnerabilities. They should also be able to provide a certified audit report that you can use to prove that you are meeting whatever legal requirements (such as HIPAA or Sarbanes-Oxley) your organization is governed by. However, a caveat emptor to an external audit is the fact that if the company auditing your environment is simply running the previously mentioned tools, frankly, they aren t really adding any value beyond what you could probably do on your own ”and it is coming at a substantially higher price than what it would cost to perform an internal audit. To address the issue of competence on the part of your external auditing company, you should make sure you select a reputable and known company for testing your systems. You also should define whether the company in question is expected to provide all three components of an audit. For example, an auditing firm may not be able to provide an effective VA or penetration test. Instead, you might need an auditing company to handle strictly the audit side of the house while you use a specialized security firm for providing your VA and penetration testing. Although each component will give you a little bit of information, only by having all three components can you get the full picture as to the validity of your security policy and posture.

Many companies that provide financial auditing services have a dedicated practice that can perform security auditing at the same time. Here s a list of some of the better known companies that can perform a security audit:

• Deloitte Touche Tohmatsu (http://www.deloitte.com)

• PricewaterhouseCoopers (http://www.pwcglobal.com)

• Accenture (http://www.accenture.com)

• Ernst and Young (http://www.ey.com)

In addition, here are some of the better known companies that can perform VA and penetration testing:

• Foundstone (http://www.foundstone.com/)

• Symantec (http://www.symantec.com)

• @stake, formerly L0pht Heavy Industries (http://www.atstake.com/services/)

Perhaps the most important aspect of an external audit, however, is the fact that the information contained in the audit can go a long way toward validating the security direction of your organization as well as provide political capital to lobby for additional resources in achieving your security goals.