Overview
Beware of Greeks bearing gifts. Cassandra (allegedly)
It has been said that lieutenants and captains study tactics, majors and colonels study strategy, but generals study logistics. To an extent, that is so because of the relationships among them; tactics are employed in support of a strategy, but without the proper logistics, the strategy will fail. It also reflects the capabilities for understanding of the officers involved. Younger, less experienced officers study the smaller pieces; middle−aged (in military terms) officers pull those together, tempered by their own tactical experiences; mature leaders create the operating environment in which the others can succeed.
This is a chapter about the tactics your attackers will use. As with the building blocks of military thought, once we understand the tactics, we can address strategy by looking at how and when the enemy is likely to use certain tactics; we can then position ourselves to best counter the enemy. This does not—repeat not—mean that you can position yourself never to be attacked. The only network that will not be attacked is the completely bounded one, whose power switches are collectively in the "off" position, and that no human can physically access. And even those conditions can be gotten around if the attacker has the right incentive.
Because you will be attacked (actually, you have almost certainly already been attacked, whether you realize it or not), it helps to recognize the tactics being run against you. Further, I do not recommend counterattacking and attempting to destroy your attacker. For one thing, the attacker is not necessarily who you think he or she is. For another, as early as Sun Tzu, over 2,500 years ago, strategists have counseled to leave the enemy a path to retreat in order to encourage him to do just that (rather than fight to the death and take more of your people with him). In defending your network, by all means do everything you need, but do no more. This is not a game, and it has no fixed endpoint after which we all shake hands and go home. You must be able to outlast your attacker, and that takes logistics.
You may expect a variety of attacks, ranging from not directly damaging to devastating. The least damaging attacks are the probes—reconnaissance, to continue the military analogy. Any of the remaining broad types can severely degrade your network's performance or even take it down completely. They are viruses and worms (similar in principle but different in completeness as well as execution), denial of service and distributed denial of service attacks, and Trojan horses.
Before we can explain what those tactics do, you may need a refresher (or a primer) on how packets move through a network. If you work with IP packets routinely, this is old hat; skim or skip to the next section as desired. If you haven't worked with IP for a while or have used IP networks but never needed to know how the information moved around in them, this will introduce the principles on which that movement is based. These pieces are what attackers use against you.
TCP/IP
TCP/IP (Transmission Control Protocol/Internet Protocol) was developed for the U.S. Department of Defense in the early 1970s. The goal was to have a flexible, survivable means of routing electronic
information. Computer networks were, if not in their infancy, mere toddlers at that point; networks in general and TCP/IP as a networking protocol suite have evolved over the intervening three decades (three decades, of course, is multiple generations in Internet time).
TCP/IP focuses its attention on the interface between the local host (a particular machine, such as a client, server, network printer, or router) and the network to which it speaks. You may hear reference to a "layer" by a number; that refers to a generic networking model (the OSI Reference Model) that postdates TCP/IP by several years. The layers and their names are shown in Figure 3.1. Application Layer OSI Layers 5, 6, 7 Host−to−Host Layer OSI Layer 4 (Transport Layer) Internetwork Layer OSI Layer 3 (Network Layer)
Network Interface Layer OSI Layers 1, 2
(Physical Layer)
Figure 3.1: The TCP/IP protocol stack.
Everything in the Application Layer is either specific to this host (such as a FreeCell game) or involves a logical relationship across the network between your host and another (such as your email program, where your host is a client for a server out there somewhere). The Network Interface Layer (often called the Physical Layer) governs how this host communicates with the network. Between the two is where TCP/IP really works—in the Internetwork Layer (usually called the Network Layer, or Layer 3 due to the popularity of the OSI Model's naming and numbering scheme) and in the Host−to−Host Layer (again, usually called the Transport Layer, or Layer 4).
We can review what happens to a chunk of information you need to send across the network from your host to another. You work with some sort of application, which creates a stream of information and sends it through the Application Layer, where a logical relationship between your host and the other is established. As with a telephone conversation or message exchange, you aren't directly connected to each other; you are communicating through intermediates, which are transparent to you. This is the same kind of logical relationship, or session, that is conducted between hosts. By the time this stream of data arrives at the Transport Layer, it is in a standard format and where it needs to go has been established.
The Transport Layer breaks the information into segments and multiplexes the information from several applications together. It keeps track of which information belongs to which application by designating a port for that application (in fact, most ports are already assigned—something very important to network security). Each segment gets a header to separate this segment from all the
others and to carry information about the segment's content. Many people think of the header as a sort of envelope for the data.
Two protocols operate at this layer: TCP (Transport Control Protocol) and UDP (User Datagram Protocol). TCP is more complex because it operates with some quality control; UDP assumes another program is handling that and so does not waste effort on it. Both approaches have their uses.
The TCP header, seen in Figure 3.2, is always shown in this format, due to some internal architectural issues that are not important here. I have emphasized the first two fields of the header, the Source and Destination ports, along with the Flags field. Certain ports have been designated by IANA, the Internet Assigned Numbers Authority, for certain protocols or functions. Numbers in these fields range from 0 to 65,535; the first block (0−1023) was assigned to the most fundamental protocols and functions with regard to networking. These ports are where many attacks are targeted.
Figure 3.2: TCP header.
To see which ports are open on your computer (we assume you have a Windows−based computer), open a command line or DOS window (click on Start, Run and type in "command" with no quotes, click OK) and enter the command "netstat −a" (again, no quotes). You will see all active connections, many of which (if you are on a network) may have a status of "listening." It is not important for you to know what each of these is at the moment; what is important to realize is that
each open port represents a conversation your computer is having with the network. Each is also a potential entry into your computer.
The flags are a set of independent settings that signal a message type. TCP requires that there be a coordinated session between the two hosts that are communicating; no session, no data exchange. The session is coordinated by a three−part handshake. The first machine sends a SYN (synchronization) message; the second replies with an ACK/SYN (acknowledgment and some synchronization parameters). The first then replies with an ACK, agreeing to the parameters. Among the Flags fields is one to indicate a SYN, one for an ACK (both turned on makes an ACK/SYN), and a RST (reset) flag. The latter flag orders the recipient to reset the TCP session (abort it, and then it can try to reinitialize it). Attackers abuse these three flags, as we shall see.
PROCESSES AND PRIVILEGES
Computers perform one action at a time, but their division of time is so tiny that it seems to humans that they are doing many things at the same time. Each thing is a separate process. Processes are not necessarily limited to activity on one computer. Multiple computers simultaneously working on the same problem via the same process are said to be sharing a session. To keep track of the session, a specific TCP or UDP port is used at each host. It does not have to be the same port on each host, though it often is.
As an example, some network workstations are designed (in hardware) to not know who they are until they have talked to a server−but how does the server know who's asking for its attention? A protocol called BOOTP handles this. The workstation is powered up and sends out an identification request from a BOOTP client, via UDP port 68; the BOOTP server replies with identification via UDP port 67. The TCP/IP protocol stack that comes up when the workstation is powered on knows these ports and what they mean.
These are examples of well−known ports. The well−known ports are the lowest−numbered ports, from 0 to 1023. As mentioned earlier, they are used for the most fundamental processes on a host and in host−to−host communications. They are the site of many network attacks because most of these fundamental processes require special privileges to access. If you can access the process, you can gain those special privileges, and those privileges may now allow you to manipulate other key processes in a cascade.
Different network operating systems use different names for these privileged accounts. The goal of an attacker against a UNIX system is to gain root privileges. Root is, essentially, the network god of a UNIX system. Other, lesser gods exist, such as superusers and admins, but root is superior to all. Root is allowed to change the most fundamental processes on a UNIX system. Root is normally a well−protected account because of the damage it can do to a UNIX system as a result of making a mistake in this arena. Among the processes root can modify is what activities the accounting function tracks—and that is one reason why root is a target of an attacker: It allows the attacker to erase any record that he or she was there. As a fundamental security measure, the root account should never be left named as root, much less use root as its password (for a login of root, password of root; you may hear this called "root−root").
In Windows NT and its follow−on, Windows 2000, the default godlike account is the Administrator. If the server is a master server on the network (a domain server), the account has Domain Administrator privileges. The Windows environment uses a more granular approach to the actions that a set of privileges grants, but if an attacker gains access to the Domain Admin account, he or she basically has all privileges on all processes, everywhere. When an attacker finds themself in a Windows−based network, the Admin account is the first target, for the same reasons root is the
target in a UNIX system.
The UDP header, seen in Figure 3.3, is much less complex because it does not perform all the quality−control processes that TCP does. But it also uses ports for the same purposes. To the maximum extent possible, IANA has assigned the same port numbers to UDP that it did to TCP.
Figure 3.3: UDP header.
When TCP or UDP has finished segmenting the stream of data and placing a header on each segment, it passes the segments to the Network Layer. Here, segments may be further broken into pieces, depending on how big a piece can be handled by the network en route to the destination (and that can vary for performance optimization reasons). The pieces are now called packets, and each packet receives another header, the IP header, as seen in Figure 3.4.
Figure 3.4: IP header.
The IP header has several fields that are not important to this discussion and three that are. The Service Type field is where Differential Services, or DiffServ, marking is applied. The Source and Destination Address fields are where the location on the network of your host and your traffic's destination is specified. Addresses used here are the familiar ones you see in the format A.B.C.D, like 192.168.1.105—and you can check your IP address by using Start, Run and typing in "command" with no quotes, clicking OK, then entering "ipconfig" with no quotes.
If you send a packet to another computer, the IP address you see here should be the address in the Source Address field (this can be altered, or spoofed). As a diagnostic check, you can find out if you can reach another host by sending it a ping (or pinging it—ping originally stood for packet internet groper); enter the command "ping hostname", using whatever the host's name on the network may be. A server called the Domain Name Server will translate the name into an IP address (if it can), and then it will test the connection to that host. "Request timed out" is a possible reply; this could mean a way could not be found to get there from here or back here from there—the reply is independent, or it could mean that the destination has been configured not to send a reply. You may also see a series of four replies because four requests are normally sent, and each will have an elapsed time in milliseconds. The replies name the destination's IP address.
Another message that originally began as a means to diagnose network problems is traceroute (the DOS and Windows command is tracert). This is a series of slightly modified pings, which returns the path taken by a packet from here to there. (Note: The path from there to here might be quite
different; there is no requirement that the two be related other than at the endpoints.) Both ping and traceroute are a part of the Internet Control Message Protocol, or ICMP. They use a message called the ICMP ECHO_REQUEST and ICMP ECHO_REPLY. Because ping and traceroute are abused by hackers (see Denial of Service/Distributed DoS, later in this chapter), many sites have turned off any response to them, as noted previously.
Back to the Service Type, or DiffServ, field. While every packet has a source and a destination address, not all will have a DiffServ Code Point (DSCP) set. A total of 64 different codes may be placed in this field; 32 have been proposed as standard, 16 are reserved for future expansion of the standard (if needed), and 16 have been reserved for local or experimental use. These codes can be used to prioritize traffic on a network and to specify forwarding treatments. Their implementation on networks is relatively new, but they can be used to prevent abuse (from internal users as well as internal or external attackers) as well as ensure minimal transport times for special traffic (like Voice over IP).
The Network Layer has wrapped the packet in another header and now sends it down the stack to the Physical Layer, where it is encoded for transmission and placed onto the physical transport (copper wire or glass fiber). At the destination, the process is reversed, all the way up to the Application Layer. There is one more piece to understand about how your traffic gets there from here (and how the reply from there gets back to here).
It is virtually guaranteed that your packet will not get to its destination (and any reply from the destination will not get back to you) in only one step, even a giant step. At each step, or hop, along the way, the packet is passed from the Physical Layer to the Network Layer for a little change. This process is fundamental to how data travels through networks. Each interface on a network has an address, called a physical address (you can see yours with the command "ipconfig /all"). When traffic comes over the wire (or fiber), the interface examines the physical address; if it belongs to this host, even as a hop along the way to a different ultimate destination, the packet is accepted and passed on to the Network Layer, which places the physical address of the next hop on the packet and sends it back to the Physical Layer for placement on the wire. If not, the packet is discarded (like junk mail addressed to "Resident"). To get to the ultimate destination, your packet must be received and processed by many hops, each with a different physical address, each of which must be known.
A protocol called the Address Resolution Protocol, or ARP (which can also be abused by attackers) manages this. It builds a table, called the ARP cache, which contains mappings of logical interface addresses (IP addresses) with physical addresses. Based on that table, your packet is given the physical address of its next hop and sent along the way. The whole process is very much an automated assembly line for information: Pieces are added, and the bigger piece is sent to the next station, where it is processed. Meanwhile, this station does the same thing to the next packet, and the next.
Probes
In order for the attacker to get in and do something useful, he or she must have found the unlocked door or open window. To do that, the attacker has rattled doorknobs and tugged at sashes until he or she found one that gave. Just like a house burglar, why force a hard door when just down the way is an easy door no one locked?
Probes can be as simple as an automated ping. It is not hard to write a script, in any of a number of user−friendly languages. An automated ping script can be generated that simply modifies the IP
address to interrogate by 1, then asks (essentially) if anyone is home at this address. After receiving a reply or a no response, the script adds 1 to create the next address and tries again.
In this way, an attacker can find the address of interfaces on your network that can be reached from the outside. That is why some interfaces have the reply to a ping turned off. (I have turned it off on my personal firewall.) An attacker may not want me to be able to trace back and find out who he or she is, so the attacker may keep my address in mind and keep exploring. Attackers often keep