Security tools that find holes before intruders attack
To secure an Internet-connected network, firewalls are a necessary component in your arsenal of tools. However, firewalls alone are no longer sufficient protection, because they're static devices that enforce a particular ruleset. This setup means that intruders can use valid, legal packets to formulate an attack on your network and compromise your security. You must use additional tools for complete protection, especially for Windows NT and the TCP/IP protocol. To spot potential problems before intruders exploit them from inside or outside your network, you can implement several security tools, such as port scanners, vulnerability tests, log analyzers, and intrusion detectors.
Port Scanners
TCP and UDP use port numbers to identify higher-layer services. Systems administrators use port scanners to determine what TCP/UDP services are available on a server. A cardinal rule of server security is to disable any service that the system isn't using because any open TCP/UDP service offers intruders a possible entry into your system. Thus, you can use a port scanner to ensure that only the desired TCP/UDP services are running.
Port numbers 0 through 1023 are well-known ports that systems administrators usually use for only system processes or for programs that privileged users are running. If attackers exploit a well-known port, they can potentially gain control of a server.
To compromise your network, attackers use several generic schemes to scan ports. The following examples focus on TCP scanning:
- TCP connect() scanning is the most basic form of TCP scanning. An attacker's host issues a connect() system call to every interesting port on the target machine. If the port is listening, connect() will succeed; otherwise, the port is unreachable and the service is unavailable. This attack scheme is fast and doesn't require any special privileges; however, port scanners can easily detect and block this attack at the target system.
- TCP SYN scanning attempts to set up a TCP virtual connection. Establishing a TCP virtual connection requires a three-way handshake, in which one host sends a TCP segment with the synchronize (SYN) flag set, the other host responds with a segment that has the acknowledge valid (ACK) and SYN flags set, and the first host responds with a segment that has only the ACK flag set. In SYN scanning, a querying host sends a SYN segment to every port. If the server responds with a SYN-ACK segment, the service is available; if the server responds with a reset (RST) segment, the service is unavailable. Port scanners can usually log these attempts at the target site.
- TCP FIN scanning entails the attacker's querying host skipping the three-way handshake and sending a finish (FIN) segment to all interested TCP ports. In ordinary circumstances, sending a FIN segment closes an open TCP connection. However, if the port is open (i.e., listening or active), the system is supposed to ignore the FIN because there is no existing connection; if the port is closed (i.e., not listening or inactive), the system generates an RST segment. Thus, lack of a response identifies an active port to an attacker. This attack is a clever way around the problems of SYN scanning, and it's very hard to trace. Ironically, this method doesn't work well on most Windows systems because Microsoft's TCP implementation always sends a RST in response to a FIN.
- FTP bounce attacks use the FTP PORT command and the upload capability at an FTP server behind the firewall. This attack lets a client connect with other systems that otherwise wouldn't be accessible. For example, an attacker creates a text file that contains the SMTP dialog of a spoofed email message and uploads the file to an FTP server behind a firewall. The attacker then issues an FTP PORT command to the server and provides the intended target system's IP address and the SMTP port number. Next, the attacker sends the file to the victim machine, so the file appears to come from the FTP server. Intruders can use this method to insert Trojan horse programs or viruses behind a firewall and might gain access to an FTP server and scan services behind a firewall. Microsoft's FTP server implementation is reportedly immune from this type of attack because it requires the IP address contained in the PORT command to match the original IP address provided on the FTP control channel (TCP port 21). In addition, by default, you can't use the PORT command to specify any privileged ports (i.e., port numbers less than 1024) except the FTP data channel (TCP port 20).
- UDP Internet Control Message Protocol (ICMP) port unreachable scanning is one of the few UDP scans. UDP is a connectionless protocol, so it's harder to scan than TCP because UDP ports aren't required to respond to probes. Most implementations generate an ICMP port_unreachable error when a user (or intruder) sends a packet to a closed UDP port. Thus, a lack of a response indicates an active port.
You can perform port scans by using several tools that employ a combination of methods to detect attacks. You can run port scanning software from UNIX (e.g., System Administrator Tool for Analyzing Networks—SATAN, nmap) or NT systems. (Table 1, page 62, lists popular NT security monitoring tools.)
For example, I used WebTrends Security Analyzer to scan a group of four NT servers for TCP/UDP vulnerabilities. The Most Vulnerable Services Graph, which Screen 1 shows, reveals that four services are open to attack.
The Service Vulnerabilities table describes each risk in detail. For example, the FTP and HTTP services are vulnerabilities merely because they're running. The medium-risk vulnerability FTP service is susceptible because it has anonymous access enabled, and the HTTP service is high risk because attackers can exploit the $DATA hole in Microsoft's Internet Information Server (IIS). This vulnerability affects many IIS installations because an attacker can download the Active Server Pages (ASP) source by appending a ::$DATA string to the URL. This action can expose usernames and passwords that systems administrators have hard-coded within scripts (e.g., SQL and other administrator passwords).
After listing these vulnerabilities, many port scanners suggest possible fixes, such as shutting down the service or installing a hotfix. Although shutting off the service might not be an option, knowing that a vulnerability exists helps you balance the risk exposure with the benefit. Port scanners also remind systems administrators to turn off any service that they're not using.
Vulnerability Tests
Vulnerability testing is similar to port scanning, but you use vulnerability testing for specific OSs rather than TCP/IP communications protocols. Many security vulnerabilities are OS specific, so a good rule of secure management is to avoid advertising your servers' OSs. However, clues such as .asp file extensions, use of .htm rather than .html, and home pages named default.htm usually identify an IIS server to an attacker. In addition, many tools help attackers determine a system's OS, and to use these tools attackers need only the server's IP address.
Systems administrators are well advised to use software to examine their systems for OS vulnerabilities. For example, I used WebTrends Security Analyzer to scan four servers for OS vulnerabilities. The software generated a report that ranked the systems' weaknesses as high, medium, or low risk, as Screen 2 shows. Security Analyzer found that all the servers have vulnerabilities.
Knowing about these vulnerabilities is only half the battle. Most vulnerability testers will also tell you where you can get more information, such as pointers to Microsoft articles and links to hotfixes and service packs, and suggest corrective measures, such as instructions for updating the Registry to secure your systems. For example, Screen 3 shows a portion of the WebTrends Security Analyzer report that lists the suggested fixes for my systems' vulnerabilities.
New OS vulnerabilities, particularly NT weaknesses, appear all the time. So you can't run a vulnerability test once, fix the problems, and have a secure system. You need to use this tool frequently with an up-to-date database of OS vulnerabilities. In addition, many versions of port scanners and vulnerability testers can scan across a network—you can use them to test your network, and attackers can use them to probe your network for weaknesses.
Previous
