If you're connected to the Internet, keeping your network secure should be a top priority. Patching servers shows that you're mindful of the risks, but testing your network for vulnerabilities is the only way to gain real confidence that you're safe from crackers. Use our hands-on guide to analyze just how safe or assailable you actually are.
Whether you have one machine connected to the Internet or ten thousand, keeping your network secure should be a top priority. You patch your web server and are mindful of your firewall configuration, but is your site really secure? How do you check it?
Sure, you can spend spend many tens of thousands of dollars for a professional audit by a top-shelf security firm such as Foundstone, but in many cases, with a little bit of insight and a set of open source tools, you can find and fix the real trouble spots yourself. Here’s a hands-on introduction to finding security risks on your network.
Do not test, probe, scan, audit, or assess networks that you don’t have permission to access.
It’s remarkably easy to get yourself into real trouble by going where you don’t belong. Network administrators with extensive experience with Internet security — often down to the packet level — can sometimes guess what kinds of probes they can “get away with” on a remote network, flying just under the radar. But others may find themselves the focus of a lot of unwanted attention, first by the scanned target, then by their own ISP’s abuse department, and then perhaps by local or federal authorities. In other words, is running an nmap scan on, say, Citibank really worth losing your cable modem over?
Visibility and Vulnerability
Network security risks can be divided into two broad categories: those caused by visibility and those caused by vulnerability.
- Visibility is a problem when a private network service is inadvertently offered to the public. In these cases, the service isn’t the problem, but its visibility is.
- Vulnerability is a problem when a service is intentionally offered to the outside world, but the service has a flaw that grants an outsider greater access than was intended.
The best example of a visibility issue is NETBIOS, the Windows “Network Neighborhood” protocol. Though NETBIOS is wonderfully useful, it should never be permitted to enter or leave your network. Seeing NETBIOS open when performing a network security audit is a serious error, even if a hacker is unable to leverage it for increased privilege.
A common vulnerability is an unpatched or misconfigured web server that can be fooled into running operating system commands. Exploiting a buffer overflow in sendmail to obtain a root shell is another common vulnerability fault.
The difference between visibility and vulnerability is important, and it’s crucial to remember the distinction. Otherwise, you may waste your time addressing a problem that’s not really problematic, audit your security incorrectly, or overrate (or underrate) the effectiveness of your security measures. For example:
- Firewalls protect against visibility issues, not vulnerability issues. Whether it’s your Netopia router, ZoneAlarm on your PC, or ipchains in your Linux kernel, firewalls selectively block traffic as it enters and leaves your systems. A firewall should block all traffic that you don’t specifically permit. However, if you’ve told your firewall to allow inbound traffic to port 80/tcp — your web server — and it turns out that the web server can be exploited via the HTTP protocol, the firewall will happily pass all traffic, good and bad. A few firewalls (typically very high end ones) can filter some malicious traffic, but one should never rely on a firewall to protect badly run public services.
- Not all systems need a firewall. For example, a system that runs only public services — a web server, email, and ssh for example — does not have any private services for a firewall to protect. Ask yourself, “What additional security would a firewall provide?” If the answer is “none,” then the system might as well run outside of or without a firewall. It’s true that a firewall can provide minor protection in the event of compromise by restricting what the attacker can do to others, but the firewall wouldn’t have prevented the compromise in the first place. On the other hand, putting the machine inside the firewall means that if it is compromised, it can be used to launch attacks on the rest of the network. Every system is visible from the inside
- You have to perform visibility tests from outside the firewall. Though it’s possible to test your network for vulnerability issues from most anywhere, visibility tests can only be done from an outside, untrusted platform. Here, “untrusted” doesn’t mean a sinister system, simply one that is not granted special access. For example, a NETBIOS scan of a Windows network from inside the firewall will show every machine in the building. That’s no surprise: Network Neighborhood wouldn’t work if Windows systems couldn’t talk to each other. However, to discover if Joe Random User can see your machines, you have to perform the visibility test from outside the firewall. By the way, if your corporate firewall permits traffic from your home network, your computer is still “trusted.” You’ll need to do your visibility testing from somewhere else.
It’s also important to realize that not all software vulnerabilities cause vulnerability issues. The recent SQL Slapper worm, which exploited a buffer overflow in SQL Server, is a prime example. Microsoft took a lot of heat for a buggy product, but many in the security community placed the blame on the local system administrators. Security experts asked, “Why did you allow SQL Server traffic to enter your network in the first place?” With a properly configured firewall installed on your network, it doesn’t matter whether your server has a bug or not because the outside world can’t even attempt an exploit.
Likewise, even a perfectly patched and locked-down web server presents a visibility problem if private content is reachable from the outside world (by mistake). The employee phone directory is not always public information.
It’s relatively easy to test for visibility issues: A simple port scanner will do. Testing for vulnerabilities is much more involved. More about that later.
With the two classes of security issues defined, let’s see how to audit your network for both kinds of problems.
First, before doing any scans, it’s important to plan your audit to survey your entire Internet presence. Your network may be as small as a single IP address or up to many class C blocks spanning thousands of machines in multiple locations. Whatever the case, be sure to consider the services you provide and the services you receive from outside contractors (for example, web hosting, email servers, file hosting), though you may be severely limited in how much testing you can do to third-party systems.
For small- to medium-sized networks, some security testers create a spreadsheet with fully enumerated IP addresses in the first column and other findings in subsequent columns. “Hostname,” “Pingable,” “Exposed Services,” and “Notes” are good columns to start with.
The spreadsheet is a working document used throughout your assessment. As you find issues, you’ll fill in items and add others, making special note of trouble areas. The spreadsheet should also live on beyond the audit: Your completed spreadsheet is an excellent starting place for your next assessment, which should be performed every few months. With security there’s always more work to be done.
Tools of the Trade
When assessing a network, one of the first and best tools is actually a book: “Hacking Exposed,” by Scambray, McClure, and Kurtz (McGraw-Hill Osborne Media). It’s been a runaway bestseller in the security community for several years, and it’s now in its fourth edition. There are plenty of great security books on the market, but “Hacking Exposed” looks at security from the attacker’s perspective rather than the defender’s. Many of the “attack” techniques are similar to those used to audit vulnerability and visibility risks, so they overlap nicely for our purposes.
Beyond a book, you’ll need some actual tools. There are some outstanding commercial tools that perform very comprehensive assessments on a nearly point-and-click basis, but they’re also very expensive (and typically require a Windows platform). Some of the best commercial products include Retina from eEye and FoundScan from Foundstone. Instead of using commercial tools, we’ll turn our attention to some of the excellent, free tools that are available.
Security auditing tools fall into several broad classes: port scanners, application-specific scanners, and vulnerability testers.
Port scanners are the simplest of the bunch. Port scanners probe remote systems, attempting to discover whether TCP or UDP ports are open. Open ports suggest open services attached to those ports. (But an open port does not guarantee that a certain service is attached to that port. For example, it’s possible to run a telnet server on port 80/tcp and a web server on port 23/tcp, a reversal of the usual roles for those ports. The only way to really know what’s on a port is to ask it.) The output of a port scanner provides fodder for additional assessments with other tools. Port scanners can usually scan a whole range of TCP or UDP ports and a whole range of IP addresses.
Port scanners are usually part of the initial survey process because they provide lists of services to investigate. However, in no case do they provide any information about vulnerabilities. Port scanners are strictly visibility testers.
Application-specific scanners are ad-hoc tools that combine a port scanner with additional tests designed for a particular service. The capabilities and quality of application-specific scanners vary widely, from simply asking a few questions about an application to attempting full-blown exploits of discovered services.
Vulnerability testers are comprehensive systems that include port scanners and extensive, additional test suites that attempt to discover vulnerabilities attached to discovered ports. Vulnerability testers are much more complicated because they must be kept up-to-date with a myriad of tests, and their maintenance is an ongoing project. Unlike port scanners, which are relatively stable, the currency of vulnerability scanners is at the mercy of security advisories that announce newly-found problems.
Many vulnerability testers are also built with per-protocol modules, each with its own set of tests. For example, every serious vulnerability tester has an HTTP module that can query a web server while attempting to find one of perhaps hundreds of vulnerabilities that have been discovered over the years.
Let’s examine several of these tools in turn. Red Hat Linux 8.0 was used for all of the examples in this article.
nmap, the Granddaddy of Port Scanners
nmap, written by “Fyodor,” is a positively indispensable part of any security analyst’s toolkit. It includes dozens of tests and variations of tests, all at the IP level, and many go far beyond that required by a simple self-audit. nmap is available in many forms at http://www.insecure.org/nmap/nmap_download.html. The instructions on that site should be sufficient to build and install it.
In practice, TCP produces more interesting services than does UDP, so we’ll focus on TCP. Here’s a simple nmap scan against IP address 172.27.217.20:
# nmap -sT -O 172.27.217.20
-sT requests a simple “connect” TCP probe and -O (the capital letter ‘O’) tries to guess what operating system is running on the target host. Here’s the output of the command:
Starting nmap V. 3.00 ( www.insecure.org/nmap/ )
Interesting ports on review.unixwiz.net (172.27.217.20):
(The 1598 ports scanned but not shown below are in state: closed)
Port State Service
22/tcp open ssh
1241/tcp open msg
6000/tcp open X11
Remote OS guesses: Linux Kernel 2.4.0 – 2.5.20, Linux 2.4.19-pre4 on Alpha
The diagnostic output reports that nmap scanned 1,601 ports. 1,598 of those ports were closed (per the diagnostic message on the third line), and three were open.
Let’s analyze the risks of each open port. ssh is open, but the machine is behind a firewall and ssh is not reachable from the Internet. Similarly, the X11 service is also open, but unreachable. If the X11 service were reachable from the Internet, it would be a serious visibility issue. The service named as msg is in fact a Nessus server, part of our security audit toolkit. Nessus will be described later in this article.
The last line of output shows that nmap thinks the remote operating system is some flavor of Linux. To formulate a guess, nmap sends carefully-crafted packets that exploit gray areas in the IP protocol and then checks the responses for clues. Indeed, nmap is correct this time: The system probed is in fact running the Linux 2.4.18 kernel.
nmap can also perform UDP sweeps and a variety of special-purpose scans that are highly esoteric in nature. nmap can also scan more than one host at a time and it accepts “/##” netbits notation (e.g., 10.1.4.0/24 to scan 256 addresses) as well as an explicit list of targets. nmap is available for nearly every Unix and Linux platform, and it’s been ported to Windows as well. No other port scanner comes close to nmap.
Nessus is one of the more popular open source vulnerability scanners. Supported by an active community of developers, Nessus features a plug-in architecture that allows you to easily write new security tests in C or in the Nessus Attack Scripting Language (NASL). As the magazine goes to press, there are more than 1,200 plug-ins for Nessus and the number grows daily, often in response to new security advisories.
Instructions for fetching and setting up Nessus can be found at http://www.nessus.org/download.html. Nessus includes a client and a server, and nmap is an integral part of the server’s scanning mechanism. The server part of Nessus can run on nearly any Unix or Linux system, but the client is a GUI application that depends on the X Window System. (All of the examples in this article were created with Nessus 2.0.)
Once Nessus is built and installed (libnasl, nessus-libraries, nessus-core, and nessus-plugins), you should configure the daemon and set up one or more users. Nessus is designed to have a single server (which does the actually scanning), and it consults a database of users for a list of per-user restrictions.
For instance, in a college class on computer security, it’s best if the students can’t scan anything outside the test lab, but professors might get wider latitude. In our examples we won’t be imposing any restrictions other than forbidding outsiders from using our Nessus server.
Though the configuration defaults ought to be suitable, you should look at the configuration file to become familiar with options that you might want to use later. It’s usually found in /usr/local/etc/nessus/nessusd.conf.
Communications between the Nessus client and server are protected by SSL, so a server certificate must be created to help the clients authenticate the server. Though there are several options available for creating a certificate, they’re not necessary for early users; -q skips all of the questions:
This creates the proper certificate files and appends some lines to nessusd.conf. Next, create the first user (who will have no restrictions); what you’d type is shown in bold:
Login : root
Authentication (pass/cert) [pass] : pass
Login password : supersecret
Enter the rules for this user, and hit ctrl-D once you are done :
(the user can have an empty rules set)
Login : root
Password : supersecret
Is that ok ? (y/n) [y] y
The information from nessus-adduser populates files usually found in /usr/local/var/nessus/users/root/. Once set up, you can launch the Nessus daemon itself:
The daemon runs in the background and has no user interface (though it does log activity to /usr/local/var/nessus/logs/nessusd. messages or to syslog, depending on the configuration). At this point, the Nessus server is waiting for connections.
Now launch the X GUI client by running nessus from a prompt. (Your screen resolution should be at least 1024×768; 800×600 doesn’t quite work.) nessus first displays a setup dialog box. Click on the “Nessusd Host” tab and fill in the form to point to your server (if it’s running on a different machine than your client). Next, enter your login name and password and click “Login.” This brings up an “SSL Setup” dialog box; click “OK” after approving the server’s certificate. Now the client is open for business.
Using the Nessus Client
|Figure One: Nessus plug-in selection|
With the client and server running, you can try your first scan. The “Plugins” tab shows all of the available scanning modules grouped in broad categories: “Windows,” “Backdoors,” “Gain root remotely,” and so on. A checkmark in the rightmost column indicates that the set of plug-ins is active. Figure One shows shows some of the categories and individual tests available.
The “Prefs” and “Scan Options” tabs present an enormous set of choices that fine-tune the behavior of the Nessus scanner. Be sure to carefully read the nmap and Nessus documentation before you use something new. Our tests used the defaults.
The “Target Selection” tab lets you choose what to scan and this entry box accepts a hostname, an IP address, a list of IP addresses or hostnames, or a whole subnet in slash-netbits notation. For instance, our internal network is a private class C address space and specifying 172.27.217.0/24 scans all hosts from “.0″ to “.254.”
Two cautions about using the Nessus client:
- Do not enable the “Dangerous” plug-ins, because they can bring down the machines or services probed.
- Limit your testing to off-peak times. Even the “Safe” tests crashed an HP JetDirect print server on our network.
Once a scan starts, each host in the target range is pinged and each host that responds is scanned fully. A progress box is displayed for each host. When using Nessus, patience is a virtue: Some scans can take quite a while to complete.
|Figure Two: A Nessus report |
When finished, Nessus displays a final report dialog box with four panes, as shown in Figure Two. Nessus supports scanning of disparate networks, so start by clicking one of the subnets in the list at the top-left. (In the figure 172.27.217, the only subnet in our testing network, is selected.) The “Host” panel displays all the systems found; click on a (IP address) to display the ports found. Click on a service (ssh) to show the result for that port. Click the “Security Warning” entry in “Severity” to see the detailed text of the report.
The report can be saved in a variety of formats, including “NBE,” which can be reloaded into the Nessus client.
Understanding the Report
There’s a tendency among those new to vulnerability scanning to want to obtain the best “score” possible, but assessing a network security risk does not always come down to a right or wrong answer. There are some issues that nearly always warrant attention, but not everything in a report represents a security problem.
When performing a scan inside a network, focus on vulnerability, not visibility. For example, Nessus is nearly apoplectic about the Windows 2000 workstation on our test network: Nessus was able to access nearly everything. But that machine is inside our network, so of course it’s visible. Such reports can usually be disregarded, as can complaints about machines that have no interaction with the Internet (such as a laser printer).
Instead, focus on the vulnerabilities. The Secure Shell report shown in Figure Two is a genuine issue. (In fact, the fault caught us by surprise, and we’ve since edited our sshd_config file to disable the troublesome SSH Version 1 protocol.)
However, when you turn Nessus loose on remote systems (including your own, when resting from a “untrusted host”), pay attention to visibility issues. Services that are perfectly safe when viewed from the inside of a network are disasters waiting to happen if reachable from the outside. Test from an untrusted, outside location that accurately reflects what the Internet at large can see. If your network suffers from visibility issues, take the recommendations much more seriously.
One final caution: nmap and Nessus scans are very “noisy” to the remote target and are likely to catch the attention of anybody who’s watching firewall logs. Scanning random parties without permission is very risky business.
Just as Nessus attempts to be a “full service” tool, other risk assessment tools have a much narrower scope, serving a special purpose. Combined with Nessus, these smaller tools provide a “big picture” of your network and where you’re susceptible to attack.
For example, a tool called nbtscan, [written by the author of this article], searches for NETBIOS name servers, using probes to port 137/udp. It’s similar in function to the nbtstat tool that ships with Windows, but nbtscan runs on any Linux platform and can scan a range of hosts, not just one. nbtscan can be found at http://www.unixwiz.net/tools/nbtscan.html.
The output of nbtscan reveals machines that may be exploitable via Network Neighborhood. Here’s some sample output:
$ nbtscan 10.1.1.0/24
10.1.1.13 LINKDEV\PRINTSRV SHARING U=ADMIN
10.1.1.45 GALILEO\WKSTN_2 SHARING
10.1.1.82 WORKGROUP\SUSAN SHARING U=ADMIN
10.1.1.86 LINKQ\LINKQ-SRV SHARING DC
10.1.1.90 GRAFIX\PROLIANT SHARING DC IIS
10.1.1.94 GLOBAL\SERVER SHARING IIS 10.1.1.98 WORKGROUP\RCPN SHARING
The listing shows the IP address, the DOMAIN\MACHINE name, and a list of attributes about that target as presented by the nameserver. SHARING means that filesharing is enabled; DC represents a domain controller; and IIS suggests that the machine is running Microsoft’s Internet Information Server. The U= tag identifies a logged-in user. Other tags are described in the online documentation.
nbtscan can also identify Linux systems running Samba servers. Though the IP addresses have been modified, the output above shows a scan of a real subnet on the Internet. We don’t know of any specific exploits that operate over the netbios-ns protocol (137/udp), so providing visibility to this service is not strictly a security matter.
But NETBIOS is actually a suite of protocols, and typically, if one part is open, they all are. For example, if a machine opens netbios-ns, it’s likely to have the session-setup service (139/tcp) open as well. This would be an enormous security hole. nbtscan provides strong clues about exploitable systems.
Putting It All Together
The goal of vulnerability analysis is to discover the weak spots in your network before the bad guys do. Vulnerability analysis requires a very careful survey to achieve any level of confidence that you’ve taken the right steps to protect your users and your systems. Conduct your network security audits every few months and never be overconfident. If you ever say, “Nobody will find it,” chances are you’re making a poor bet.
And if you think, “I don’t have anything that others would want anyway,” think again. Your system is what they want. Intruders want nothing more than an anonymous platform from which to attack other more interesting targets.
Remember: Those defending a network have to get everything right all the time. The intruder only has to get lucky once.
Steve Friedl is an independent consultant who has used UNIX for more than 20 years, and he can usually be found working at home in his pajamas. He gets his mail at firstname.lastname@example.org.