Security Tools For Windows NT Networks

It is common practice today that any network connected to the Internet be protected with some sort of firewall. While firewalls are a necessary component in the arsenal of tools for the network administrator, they are no longer sufficient. Firewalls are relatively static devices in that they enforce a particular ruleset. But what happens when valid, legal packets, at least according to the rules, are being used to formulate an attack on your network or execute an attack against one of your servers? Additional tools must be used for additional protection, particularly for the Windows NT environment and TCP/IP protocols.

This article will discuss several security tools that can be implemented on Windows NT systems to spot potential problems before they are exploited by attackers from both the inside and outside, namely port scanners, vulnerability testers, log analyzers, and intrusion detectors.

The Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) identify higher layer services by use of a port number. Port scanners are tools used to determine what TCP/UDP services are available on a particular server. One of the cardinal rules of server security is to disable any service that is not being used. A port scanner can be used by a system administrator to ensure that only the desired TCP/UDP services are running. Any open TCP/UDP service offers an attacker a possible entree into your system. Having any port open that is not absolutely necessary, then, should be avoided, particularly because if there is a service running that you don't know about, then you won't be monitoring it.

The so-called Well Known Ports are of particular interest; these are port numbers between 0 and 1023, and are generally implemented so that these services can only be used by system processes or by programs executed by privileged users. Exploiting a well known port, then, gives an attacker potential control of a server. Some of the well known TCP/UDP ports are listed below; a complete list of assigned port numbers can be obtained from the Internet Assigned Numbers Authority (IANA, http://www.isi.edu/in-notes/iana/assignments/port-numbers):

There are several generic schemes that can be employed to scan ports, although most focus on TCP:

• TCP connect() scanning: The most basic form of TCP scanning, where the 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 not reachable and the service is not available. This scheme is fast and requires no special privileges, but can be easily detected and blocked at the target system.
  
  
• TCP SYN scanning: Establishing a TCP virtual connection requires what is called a three-way handshake: one host sends a TCP segment with the synchronize (SYN) flag set, the other responds with a segment with both the acknowledge valid (ACK) and SYN flags set, and the first host sends a segment with just the ACK flag set. With SYN scanning, the querying host sends a SYN segment to every port; if the server responds with a SYN-ACK segment, then the service is available; if the server responds with a reset (RST) segment, then this service is not available. These probes can typically be logged by the target site.
  
  
• TCP FIN scanning: With this scheme, the querying host skips the three-way handshake entirely and just sends a finish (FIN) segment to all interesting TCP ports (which, under ordinary circumstances, would close an open TCP connection). If the port is open (i.e., listening or active), the FIN is supposed to be ignored (because there is no existing connection); if the port is closed (i.e., not listening or inactive), a RST segment is generated. Thus, lack of a response indicates an active port. This is a clever way around the problems of SYN scanning and very hard to trace. Ironically, this method doesn't work very well on most Windows systems because Microsoft's TCP implementation always sends a RST in response to a FIN.
  
  
• FTP bounce attack: This type of attack uses the FTP PORT command and the upload capability (if present) at an FTP server behind a firewall to allow a client to connect with other systems that would not be otherwise accessible. Consider this scenario: an attacker creates a text file containing the Simple Mail Transfer Protocol (SMTP) dialog of a spoofed e-mail message and uploads it to an FTP server behind a firewall. The attacker could then issue an FTP PORT command to the server, providing the IP address of the intended target system (say, the mail server) and the SMTP port number. The attacker then sends the file to the victim machine where the e-mail is sent and appears to have come from the FTP server. Obviously, other types of Trojan horse programs or viruses could be inserted behind a firewall in this way, and might also allow a querying client to connect 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 that the IP address contained in the PORT command match the original IP address provided on the FTP control channel (TCP port 21). In addition, by default, the PORT command cannot be used to specify any privileged ports (those below 1024) except the FTP data channel (TCP port 20).
  
  
• UDP Internet Control Message Protocol (ICMP) port unreachable scanning: Because UDP is a connectionless protocol, it is harder to perform a port scan than in TCP because ports are not required to respond to probes. Most implementations, though, do generate an ICMP port_unreachable error when a packet is sent to a closed UDP port; as in TCP FIN scanning, then, lack of a response indicates an active port.

Screen 1: TCP/UDP vulnerabilities display from WebTrends Security Analyzer.

There are several tools that perform port scanning and they may use any combination of the methods mentioned above (or other methods); this software can be run from either a Unix system (e.g., SATAN, nmap) or a Windows system (see Table 1). Screen 1 shows the Web-based display after scanning a group of four Windows NT servers for TCP/UDP vulnerabilities using the WebTrends Security Analyzer:

• The Most Vulnerable Services graph and table shows that four services are open on these systems, namely the File Transfer Protocol (FTP, on TCP port 21), the Hypertext Transfer Protocol (HTTP, on TCP port 80), the Post Office Protocol version 3 (POP3, on TCP port 110), and SMTP (TCP port 25). The graph shows that FTP is running on two servers, one having a medium risk vulnerability and one a low risk vulnerability. The web (HTTP) is also running on two servers, one a high risk and one a low risk. Finally, POP3 and SMTP are each running on one server, a low risk vulnerability.
  
  
• The Service Vulnerabilities table describes the risks in more detail. The FTP and HTTP services, for example, are low risk vulnerabilities merely because they are running. The medium-risk vulnerability FTP service is one that has enabled anonymous access; the high-risk HTTP service is so noted because the $DATA hole is NT's Internet Information Server (IIS) can be exploited. This latter vulnerability affects many IIS installations, where an attacker can download the active server page (ASP) source by appending the string "::$DATA" to the URL. This can expose usernames and passwords that are hard coded within scripts; SQL and other administrator passwords, for example, are often placed within scripts in this fashion.

After listing these vulnerabilities, many port scanners will suggest possible fixes, such as shutting down the service or installing a hotfix. Of course, shutting the service off may not be an option, but we should know that there is a possible risk so that we can balance the exposure with the benefit. But this type of scan can also remind sysadmins to turn off any service that they are not actually using, such as Gopher (which comes standard with IIS, and defaulted to enabled in IIS 3).

There are many security vulnerabilities that are operating system specific. Vulnerability testing is similar to port scanning but whereas port scanning is directed at the TCP/IP communications protocols, vulnerability testing is directed towards specific operating systems. Although another rule of secure management is to avoid advertising the operating system of your servers, attackers already have many clues: .asp file extensions, use of .htm rather than .html, and home pages named default.htm almost always indicate an IIS server. In addition, there are many tools available that allow attackers to determine the operating system of another computer and all the attacker needs to use such a tool is the server's IP address.

Screen 2: Windows NT operating system vulnerabilities display from WebTrends Security Analyzer.

System and network administrators, then, are well-advised to examine their systems for operating system vulnerabilities. Screen 2 shows a sample display from the WebTrends Security Analyzer directed at four servers. As in the port scan report, vulnerabilities are ranked as high, medium, and low risk. This report shows that:

• All of the servers were found to have at least one user account with a blank password and at least one user account with a password that is too short (less than 6 characters); in addition, none had the LSA-2 fix installed.
  
  
• Two of the servers were found to have at least one user account locked out and at least one user account with the password the same as the username; in addition, two of the servers use the File Allocation Table (FAT) disk file system instead of the NT File System (NTFS).
  
  
• One of the servers is vulnerable to the $DATA hole exploit.

This screen also lists about a dozen medium-risk vulnerabilities, followed by low-risk vulnerabilities. But knowing about the vulnerabilities is only half the battle. Most vulnerability testers will also tell you where you can get more information and suggest corrective measures, such as pointers to Microsoft knowledge base articles, links to hotfixes and service packs, instructions for updating the Registry, or other guidelines. Screen 3, in particular, shows a portion of the WebTrends Security Analyzer display listing the suggested fixes for the vulnerabilities listed in the previous screen.

Screen 3: Suggested fixes to Windows NT operating system vulnerabilities displayed from WebTrends Security Analyzer.

New operating system vulnerabilities, particularly with NT, are appearing all the time. Just like antivirus software, then, the database of operating system vulnerabilities has to be updated periodically. You can't just run a vulnerability test once, fix the problems, and walk away; this is a tool that has to be used frequently with the most up-to-date information.

It is important to note that many versions of tools such as port scanners and vulnerability testers can be used across a network. Therefore, they can be used by network administrators to test their own network as well as by attackers to probe someone else's network for weaknesses. Isaac Asimov fans are certainly familiar with the adage:

A third rule of security management is to maintain system logs, particularly for your servers and routers. And many sites do diligently maintain logs and turn on auditing at the servers. But does anyone read the logs? Log files are typically quite large and it is difficult to read a multi-megabyte text file and see any serious trends. Log analyzers are programs that read the log files (most audit tools, including those with Windows NT, use one of a few standard log formats) and prepare a graphical or tabular representation of the data. In the NT environment, in particular, some log analyzer products run as stand-alone software while others run in conjunction with the operating systems own management capabilities.

Different log analyzers report different types of information, of course, but the kinds of events to look for include:

• Bandwidth utilization patterns
• Top users by bandwidth utilization
• Incoming and outgoing protocol/service usage (e.g., FTP, Web, Telnet)
• Critical events and host addresses
• Errors and warnings, and the host addresses
• VPN usage statistics and external host address
• Login attempts and failures (and host address is via remote access)
• Top e-mail senders' and recipients' host addresses (internal and external)
• Top FTP download (and upload) host address
• Top Telnet host address
• Unsuccessful TCP connection setup requests
• Packets/addresses blocked at firewall/router

Screen 4: Web traffic log display from SessionWall-3.

Screen 4 shows sample output from the SessionWall-3 product, available from Platinum Technology (formerly Memco, formerly AbirNet ). This output is a simple graphic representation of the outgoing web traffic log, displaying users, type of site visited, and number of visits. Screen 5 shows a display from Centrax Log Analyst (this product is now available from CyberSafe). This display shows information from the error log, indicating failed login and virus/Trojan horse events. All of this information, of course, is available in the log files that should be enabled anyway. But it may be hard to find a few "bad" events interspersed in a large log file and people tend to be able to spot trends better in a graphical format than in a list.

Screen 5: Error log information display from Centrax Log Analyst.

It is a general truism that you shouldn't log events that you don't care about and you shouldn't turn logging on if you're not going to read the logs. These aren't merely tongue-in-cheek quips; whether you read the information or not, there is data in them there log files and you are, therefore, responsible (and possibly legally liable) for the information they contain whether you are looking at the data or not. Log analyzers, then, are important tools because they allow administrators to quickly make sense of trends and patterns of the network traffic, server operations, and internal and external users. They also make the logs relevant! Too many sites maintain NT auditing and never look at the files.

Firewalls, proxy servers, port scanners, vulnerability testers, and log analyzers are wonderful for blocking unauthorized access, indicating the presence of a potential problem, or determining if an attack might have already occurred. Only intrusion detectors, however, tell you in real time when unusual or suspicious activity is occurring.

There are a number of common threats that can be aimed at your systems and detected in real time, as listed below. Additional information on all of the "attacks" mentioned below can be found at Microsoft's Security Bulletin page (http://www.microsoft.com/security), CERT/CC (http://www.cert.org), or at vendors' Web sites of these products):

• Denial of Service (DoS) attacks are intended to block access between a victim's network and the general Internet, generally by overloading critical system resources or usurping all available bandwidth. Examples of DoS attacks include WinNuke (Windows Out of Band), TCP SYN Flooding, Ping Flooding, Ping of Death, ICMP Bombing, Smurf, TearDrop, and Land.
  
  
• Unauthorized access to restricted files and/or commands, as the name implies, are attempts by an attacker to read, write, or modify files and/or execute commands for which he/she does not have permission. These types of attacks may use domain name system (DNS), finger, POP, and sendmail buffer overflow; FTP hijacking; HTTP, IIS, and/or Internet Explorer vulnerabilities; and password attacks on the root (Unix), administrator (Windows NT), or supervisor (NetWare) account.
  
  
• A pre-attack probe is an attempt by an attacker to gain basic information about users, servers, or a network that can be used in subsequent break-in attempts. Examples of pre-attack probes include use of tools such as SATAN or nmap, DNS zone transfers, excessive use of traceroute (Unix) or tracert (Windows), or use of SMTP EXPN (name expansion) and VRFY (verify) commands.
  
  
• Suspicious activity can be any network traffic that is outside of the expected, normal traffic patterns; while often due to error, these aberrant behaviors can also indicate undesired activity on the network. Examples of suspicious activity include use of IP source routing, IP unknown protocol events, excessive FTP uploads, Trivial File Transfer Protocol (TFTP) traffic, Windows NT connections between unrelated systems, access to server Registry files, excessive unsuccessful login attempts to one or more account names, or attempts to delete, modify, deactivate, or flood log/audit files.
  
  
• Hostile code insertion includes the spectrum of programs that can alter the behavior of the system or network, including virus, Trojan horse, and back-door programs, malicious applets, and packet sniffers.
  
  
• Infrastructure attacks are those that target the very systems and facilities that comprise the operational network. Examples of these threats are firewall modifications, router modifications, user account additions/modification, file permission/access control list (ACL) modification, and DNS modification.

Screen 6: ISS RealSecure console screen.

Screen 6 shows the Console screen from ISS's RealSecure. Intrusion detectors constantly monitor the activity on the network and protected systems. If a particular usage pattern that matches a known attack signature is found, the intrusion detector software responds by sending a warning to the system manager, either via the software's interface, e-mail, pager, and/or by other means. This interface allows a network administrator to view real time events, categorized as high, medium, and low priority.

Intrusion detection software is coming into more common usage as security incidents themselves become more common and serious. As the attacks become more complex and involve multiple sites, it would be advantageous if different vendors' intrusion detection software could communicate across sites and share data about an ongoing attack. To address this challenge, the Internet Engineering Task Force (IETF) created the Intrusion Detection Exchange Format Working Group (idwg) to define data formats and protocols for sharing information between intrusion detection and response systems, and network management systems with which they may interact. Initial specifications are expected by the end of 1999. More information about this group can be found at http://www.ietf.org/html.charters/idwg-charter.html.

There are several port scanners, vulnerability testers, log analyzers, and intrusion detectors that run on Windows NT systems, as listed in Table 1. These tools, however, are just a part of the network managers' toolkit and they must be employed on a regular basis. Note that although these particular products run on NT systems, there is a plethora of software that can detect and probe Windows NT systems from non-NT platforms, notably Unix.

Internet Security With Windows NT by Mark Joseph Edwards (Duke Press) is a good place to start to learn about securing your NT boxes. Also check out Maximum Security: A Hacker's Guide to Protecting Your Internet Site and Network, 2/e by Anonymous (SAMS) and Internet Security, 2/e by Atkins et al. (New Riders), two excellent books that offer detailed information about security and tools for attacks and defenses. Both books discuss Windows NT within the broad spectrum of the general security problem. Don't limit your thinking to just NT; the bad guys aren't!!

About the Author: Gary C. Kessler is a senior network security/WAN consultant at SymQuest Group (http://www.symquest.com), a network integration consulting company in South Burlington, VT. His e-mail address is kumquat@sover.net.