Network Defense by Rik Farrow and Richard Power Network reconnaisance The prelude to any well-planned attack involves scoping out the target's defenses. For ground-based military forces, the recon is done by sending out some groups of soldiers, patrols, to pinpoint the edges of the target's defenses, looking for both strongpoints and weaknesses. The strongpoints will be avoided (or perhaps distracted with a feint), and the weak points will become the focus for the attack. In network attacks, much the same can happen--although the foot soldiers will instead be network packets. An attacker can send various packets to probe a target's defenses, looking mainly for weaknesses: services with weak or non-existent authentication or known to be buggy/exploitable. The attacker is also working out the disposition of the defender's servers and other systems, looking for heavily trafficked networks, and other potentially interesting bits of data which might aid in the attack. Not all attacks procede so methodically. Lightweight attackers, the so-called script-babies, will try exploit scripts against any system they discover. This method for attacking is somewhat like driving through neighborhoods with an ordinary garage door opener in hand, activating its radio signal, and watching for garage doors to open. The targets may not have garage door openers, work on a different radio frequency, or are expecting a different binary key. The script-baby doesn't care. With enough time, some door will open. The more serious attacker will take the time for reconnaisance. Probing the defense will likely turn up potential weak points that may be exploitable--even using the same attacks the script-babies use, but with much more finesse. The truly serious attacker, the professional or member of an espionage team, well, that's another story. For now, let's look at some of the means available for scanning networks, how detectable these scan are, and how they work. Network Sonar The Brittish are credited with discovering that they could detect submarines by emitting a loud underwater sound and listening for echoes. On networks, we use the ping command to perform a similar task, although in a more directed fashion. Ping uses ICMP (Internet Control Message Protocol) packets to determine if a particular IP address has a working TCP/IP stack. When a ICMP Echo Request packet arrives, correctly functioning IP stacks automatically respond by sending back an ICMP Echo Reply. Sometimes, even crashed systems will respond to ICMP Echo Requests, as that part of the operating system is still functioning. What you need to know is that a system with an IP stack will (almost) always reply to ping packets. You can use the ping command itself but there are better tools that make ICMP probing faster. The fping command, from Stanford University, sends Echo Requests in parallel, greatly speeding up the process. SATAN incorporates fping. The nmap tool also parallelizes Echo Requests, which can speed up the probing process many times. Clever defenders will be on the alert for ICMP probes. Many firewalls block all ICMP packets with their default configuration. You might not want your firewall to do this, however, because there are beneficial uses for other types of ICMP packets, for example Destination Unreachable and Source Quench ICMP packets. True application gateway firewalls correctly recognize and respond to beneficial ICMP packets without passing them through the firewall. If you are using packet filtering, you will want to permit the various Unreachable ICMP packets through the firewall--but for the outside in only. Higher Layers ICMP reacts at layer three, the Internet layer. Layer four, the Transport layer, can also be used while probing. Each of the two protocols, TCP and UDP, at layer four react to packets received at one of the 131070 port addresses. Each protocol has its own set of ports, and its own behaviour when being probed. You may remember that the TCP protocol is connection oriented, and you may have heard of the three-way handshake used to set up a TCP connection (Figure 1). When a client opens a connection to a server, the client first sends an opening request, a SYN (short for Synchronize) packet. If the server has passively opened the destination port, the transport layer sends back a response, the SYN/ACK (where ack is Acknowledgement). The client sends an acknowledgement when it receives the SYN/ACK, and the three-way handshake is complete, and the connection is considered open. An attacker can probe for open TCP server ports in several ways. The easiest, and most common method, is to simply attempt to connect to each port in turn. If the connection request fails, the server returns a RST (reset) packet to break off the connection. If the connection succeeds, the probe tool logs this fact, then closes the connection. Tools like strobe and nmap use non-blocking opens, permitting them to parallelize the probes, vastly speeding up the process. Connection scanning, while reliable, is easily detectable, and also easy to block, even with packet filters. IDS products, and scan detectors, such as Gabriel, Courtney, and scan_detector, will all notice sequential port scanning (where the port addresses are scanned one after the other). Some tools, like nmap or netcat, randomize the ports scanned, making detection more difficult. Of course, all is fair in war (and love), so why play be the rules? Some TCP scanning techniques break the rules by setting different TCP flags, resetting connections, and/or fragmenting packets. Nmap, for example, can send SYN packets, then break off the connection with a RST whenever a SYN/ACK is received from an open server port. "Half-open" scanning won't fool IDS systems, but will prevent applications from logging suspiciously closed connections. And scan_detector and tcp_wrappers won't ever be invoked, and so will miss this form of probing (see Figure 2). Another method for probing involves sending a TCP header with the FIN (for finish) flag set--to a port the prober has never opened. The standard behaviour for TCP/IP stacks is to send RSTs for ports that are not open, and drop packets sent to ports that are open (but recognize the FIN packet as not belonging to an existing connection). FIN scanning can sometimes pass through firewalls, won't be logged by application-based tools, and can even be used to detect Microsoft systems. Microsoft's TCP/IP stacks always send back RSTs, so can easily be distinguished. Fragmentation scanning requires the tool to split the already small IP packets into smaller piece--the fragments. This approach has the advantage of often passing through packet filters, not being detected by IDS systems, while still successfully determining if TCP ports are open. Nmap can fragment its TCP scans. Another Color Scanning for UDP-based servers involves a somewhat different technique. UDP, sometimes called Unreliable Datagram Protocol, is not connection-oriented. So, unlike TCP, a probing tool may send packets to UDP ports, but cannot rely on getting a response back because there is no three-way handshake--there's nothing. Well, almost nothing. Standard IP stacks will respond with a ICMP Port Unreachable message when a UDP port is _not_ open. If a firewall exists, and is blocking these packets, the prober sees nothing to indicate that a particular port is closed. If these packets are permitted out of the firewall, the scanner might see these packets. Both ICMP and UDP are unreliable, which means that the probe UDP packet, and the negative ICMP response, might be silently dropped--the scanner has no way of knowing. Tools like the port scanner included with SATAN, netcat, and nmap, all take the unreliable nature of UDP into account by retransmitting UDP packets. You might think that this would make UDP a better choice for some application, but don't be fooled. Not only is UDP unreliable, its connectionless nature also makes it simple to spoof, making applications based on UDP easier to attack than TCP-based ones. Service Scanning ICMP scans detect hosts, while TCP and UDP scans uncover services. It turns out that services themselves can be used to discover information about a target network. In some cases, this unfortunate result is based upon the very standards used to define the services. Take FTP, for example. RFC 959 describes the capabilities of FTP servers, including the ability to proxy-serve connections. The intent of this feature was certainly benign, as the Internet was a friendly and safe place was FTP was created. But the use of this feature today, called FTP bouncing, is rather hostile. To understand the FTP bounce attack, you need to know something about how FTP works. FTP, and several other applications, use more than a single network connection in their normal operation. FTP clients initiate a TCP control connection with the FTP server. The client sends commands to the FTP server, which sends back the results of those commands along the same control channel. When the client wants to transfer data, be it a directory listing or a file, the client first sends a request, the PORT command, to the server. The PORT command informs the server which IP and port address for opening a TCP connection to for sending data. Normally, the FTP client sets the IP address to its own host address, and the port address to a port where the client listens for the data. In the bounce attack, the probe engine uses the PORT command to set a connection to some port on another host. The FTP server, if it is obedient to RFC 959, opens a TCP connection to the designated IP address and port, and at least attempts to send data through this connection. If the FTP server has a writeable directory, the probe tool can actually control the data being sent, and this data itself then becomes part of the attack or probe. Regardless, the FTP server sends back result codes to the client, which indicate if the PORT command was successful or not. A successful PORT command means that a service is listening at that IP and port address, accomplishing the same probe as other TCP scanners, albeit much more slowly. The nmap tool exploits this capability to probe using vulnerable FTP servers. Some firewalls may permit this use of the PORT command; many actually check that the IP address within the PORT command belongs to the client, and block the request otherwise. Most FTP server support proxy serving, although Microsoft's FTP server does not. Patrols The tools and techniques described make network scanning simple, and in many cases, difficult to detect. The attacker gains information about the target, and the target may not even be warned, if the prober is careful and tricky enough. We advise security practictioners to try scanning their own networks. You can do this with a UNIX system and an Internet account. Linux or BSD makes a fine scanning platform, runs on PCs, and can be aquired for nothing, or on CD for little more than the cost of shipping and handling. The software mentioned here costs nothing more than the time and skill required to download, compile, and use it. Other versions of UNIX will work as well, but most most of these tools (except for netcat) have not been ported to Windows 95 or NT. Commercial tools can also be used for scanning. While you can learn a lot from commercial tools, what you won't learn is how a potential attacker views your network, the records left in logfiles by scanners, and the alerts generated by firewalls and IDS products when a particular scanner is used against you. After all, you don't expect hackers to shell out tens of thousands of dollars for the latest product, do you? Resources: Scanners-- http://www.insecure.org/nmap/index.html NMAP ftp://ftp.win.tue.nl/pub/security/satan-1.1.1.tar.Z SATAN ftp://ftp.avian.org/src/nc110.tgz Netcat http://www.l0pht.com/~weld/netcat/ Netcat for Win32 ftp://ftp.suburbia.net/pub/strobe.tgz Strobe ftp://slapshot.stanford.edu/pub/ fping (also with SATAN) Detectors-- Gabriel http://www.lat.com or ftp://ftp.best.com/pub/ Courtney http://ciac.llnl.gov.ciac/ToolsUnixNetMon/html scan_detector ftp://coast.cs.purdue.edu/pub/tools/unix/scan-detector.tar.Z