3.2 Protocols


3.2 Protocols

No serious study of network security can be accomplished without a solid understanding of the operation of the protocols used by network devices to communicate with other network devices. While there are a number of protocols used in networks around the world, when discussing a global network, the only set of protocols that is common to all networks is the TCP/IP protocol suite. On the local area network, other protocols such as AppleTalk, SNA, NetBEUI, and IPX may be encountered with decreasing frequency as the world continues to converge on TCP/IP as the networking protocols of choice.

Like the OSI Model, the TCP/IP suite is a collection of protocol layers that define the requirements of each layer of protocol communications. It is similar to the OSI Model with the exception that the top four layers of the OSI Model are represented as a single "application layer" in the TCP/IP suite. A graphic with the layers of the TCP/IP suite and associated protocols is shown in Exhibit 5. The network interface layer is roughly equivalent to the physical and data-link layers of the OSI Model. The network interface of the TCP/IP suite can be virtually anything that creates ones and zeros and has successfully (although jokingly) demonstrated to work using homing pigeons. All common data-link layer protocols are represented here, such as the various flavors and speeds of Ethernet, 802.11, PPP, HDLC, ATM, Frame Relay, X.25, and Token Ring. The major point of the network interface layer is that IP, which is responsible for getting transport layer information from point A to point B, does not care what the underlying network is created from. This transparency and adaptability is part of the enormous success of the TCP/IP suite.

Exhibit 5: The TCP/IP Suite and Common Protocols

start example

click to expand

end example

3.2.1 Internet Protocol (IP)

The Internet layer of the TCP/IP suite is dominated by a discussion of a single protocol — the Internet Protocol commonly known as IP. IP is a connectionless, datagram-orientated protocol. An individual IP datagram is known as a "packet" and contains all the addressing information that the packet needs to get between points on a network. Datagram simply implies that big messages, like encyclopedias, are broken up into smaller messages for transport. By using datagrams, many packets carrying different pieces of information can share the network interface by weaving many conversations together as packets are put onto the network. Datagrams also make it much easier to recover from network errors, in that only the damaged data need be present and not the entire sequence.

There are currently two versions of IP in common use: IPv4 and IPv6. [4] Of the two, IPv4 is by far the most common protocol in use on production networks in the United States. In some European countries and Pacific Rim nations, IPv6 is growing in popularity. In our discussion here, unless IPv6 is specifically mentioned, "IP" means IPv4.

For those interested, IPv6 offers several significant advantages over IPv4. Most often cited is the increase in IP addresses. While IPv4 allows a total of just over 4.2 billion addresses, the number of IPv6 addresses is on the order of 2128. [5] It has been pointed out that there are more IPv6 addresses available than grains of sand in the world. IPv6 also offers improvements in routing efficiency, address allocation, and for purposes of this text — security. Most IPSec protocols discussed in this text are a "retrofitting" of security options built into IPv6.

"Connectionless" means that the IP layer does not keep any "state" about what packets it has sent. While the upper layers in a host, such as the transport layer or application layer in certain applications, go through a lot of effort to count packets and make sure they are reassembled in the correct order, IP sends a packet and forgets about it. When a router in a network routes an IP packet, it forgets about the individual packet. [6]

The design decision to make IP connectionless has a couple of important implications that apply to the performance and security of our networks. First, the performance. While many textbooks and vendor certifications make much to-do about the process of subnetting and configuring routing protocols, the operation of IP itself is fairly straightforward. This lends itself to a simpler network core. Instead of worrying about the sequencing of data and the path that the data takes, network devices such as routers can simply concentrate on getting data from one interface to another as quickly as possible. By simplifying the protocol as much as possible, the performance of the network is increased and the cost is decreased.

Other protocols commonly associated with IP include ARP, ICMP, and IGMP. There are others of course, but these are the most common. Each will be discussed briefly in turn.

The IP header, the data that routers and hosts use to address upper layer data, is shown in Exhibit 6. It is a common reaction, when faced with a diagram such as that in Exhibit 6, to roll your eyes up into your head and check your appointment book for important meetings discussing the value of life insurance. Regardless, understanding the header information in the TCP/IP suite is one of the most important steps in understanding the nature of network-based threats in your environment. I do not recommend memorizing the header structure unless you are forced to work in an environment that only examines packets in hexadecimal code. Instead, it is better to familiarize yourself with the fields of the header so that when examining suspicious traffic or reviewing network-based threats, you understand their operation.

Exhibit 6: The Internet Protocol Header

start example

click to expand

end example

As mentioned, the version number for an IP packet is currently 4. An IPv6 packet has an entirely different structure — essentially only the version field remains unchanged so that a host machine that supports both protocols will know how to read the remainder of the header after examining the first 4 bits.

The Internet header length (IHL) is the number of 32-bit words that then tell the host how long the IP header itself is. A 32-bit "word" is nothing more than a grouping of four octets of data. This format was standardized to facilitate the construction of efficient buffer space for protocol headers. TCP and UDP both follow the same format. The IHL allows the host to know when to expect the next header, be it TCP, UDP, ICMP, etc. Note that the minimum that should be here is a value of 5 because the default header is a total of five 32-bit words. If the IHL has a value greater than 5, then you would expect to see a number of options added onto the IP packet header.

The type of service (TOS) field is commonly referred to as the "Quality of Service" (QoS) field. The first 3 bits of this field are used to indicate the priority of the packet and are known as the precedence bits. The next 3 bits are used to determine which type of network the packet should be routed over, if there is a choice. The options are to optimize the packet for minimal delay, maximize the throughput, or take the network path that is the most reliable.

It is a common mistaken assumption about IP that you cannot provide quality of service with it. You can provide QoS signaling in the protocol header; it is just that we generally do not act upon this QoS information in our networks. The lack of QoS is a result of a lack of agreement on how to provision the QoS mechanisms to provide scalable, end-to-end assurance that your data will meet a certain service level agreement. This is especially troublesome when routing packets over networks under diverse administrative control. The other problem facing QoS implementation is the interpretation of the precedence bits. It is difficult to get everyone to agree on what "best-effort" traffic should be and what "critical" traffic should be. Clearly, if everyone had the ability to set these values on his or her own, all traffic on the Internet would be marked as critical.

The TOS field is also not commonly utilized because to implement it in routers that could route a packet based on the delay, throughput, or reliability bits in the packet header would require the creation of multiple routing tables that is, one table for lowest delay, one for highest throughput, and one for most reliable. Furthermore, what would happen if a packet had the bits indicating low delay and high reliability set, yet the routing tables indicated that these two criteria were best met via separate paths? In the end, the complexity of the implementation doomed this effort from the start.

While the TOS field is not formally utilized as intended, it does have a number of uses for Internet traffic. There have been a number of efforts to standardize the contents of this field and define what type of traffic meets which criteria. Diffserv is the most widely deployed of these efforts. Diffserv is a specification that defines up to 64 "code-points" that define the treatment that a packet receives at each hop during its transmission. Some networks also use the original precedence bits for local traffic, but you cannot trust another network to implement these bits in the same way.

Because there is wide variation on the implementation of these bits, there are any number of combinations that can be observed in network traffic. This makes it difficult to determine if the information in this field is legitimate or not, and thus an ideal field for use as a covert channel.

Following the TOS field, 16 bits of the IP header are used to describe the overall length of the packet in octets. With 16 bits, the maximum size of an IP packet is 65,535 octets. Clearly, this is much larger than the most common maximum transmission units (MTUs) of most data-link segments. To facilitate the breaking of the IP packet into frames of the proper size for the data-link layer, IP supports the ability to be fragmented. The next 32-bit word in the IP header contains information critical to the fragmentation of the packet.

The first of the fields related to fragmentation is the identification (ID) field. Each packet that the host sends is uniquely labeled with a value from 1 to 65,535. If a packet needs to be fragmented, the ID of the original packet will be used to help the receiving host reassemble the datagram.

The next two fields of note in the IP packet are the DF (don't fragment) and the MF (more fragments) bits. As the names of these bits suggest, they relate to the process of fragmenting and reassembling datagrams.

There may be instances when an IP packet should not be fragmented. In this case, the DF bit is set. When a router or other network device determines to pass over the data-link layer on the way to the next hop, the packet must be fragmented and the DF bit is set to 1. The router does not attempt fragmentation and, instead, returns an ICMP "fragmentation needed and DF bit set" error message to the originating host. This technique is commonly used to determine the minimum MTU across multiple data links. When trying to discover the MTU across a series of dissimilar links, the sending host will send out a large packet with the "do not fragment" bit set. When the packet hits a link that has a smaller MTU than the packet, an error message is sent back to the originating host from the router, representing the link with the small MTU. The sending host then sends a smaller packet with the "do not fragment" bit set and tries again. The process is repeated with increasingly smaller packets until the packet is successfully transmitted across the network. While this adds overhead and delay to the initial transmission process, it decreases the amount of fragmentation taking place in the network.

When the MF bit is set to 1, this tells the receiving host that the packet is fragmented and the host should expect more fragmented packets sharing the same ID value to be reassembled before passing them up to the transport layer. When the router receives a packet that has the MF bit set to 0, it assumes that the last fragment has been received for the packet and attempts to reassemble the data.

To help the receiving host determine where in the packet the fragmented data should be placed, the fragment offset field indicates where in the original packet this particular fragment should be placed.

Fragmentation can be a complex process that significantly slows down the devices that must fragment and reassemble the packets. Furthermore, creating illogical packets that cannot be reassembled is a common network attack that is used to disable a remote host. In addition, this technique can sometimes be used to circumvent some firewalls.

Fragmentation slows down the routing process because of where it occurs. Consider the illustration in Exhibit 7. Host A is sending a packet that is 1500 octets to Host B. While this MTU is fine for the Ethernet segments to which the hosts are connected, the PPP connection between the two routers only supports an MTU of 576. The first router in the path that is able to transmit the packet over the PPP segment must then fragment this packet. Routers have recently begun to offer very high forwarding rates and can now operate at what is known as "line-speed" in many circumstances. This means that as fast as you can send packets to a router, it can forward them. Previously, this feat was the province of layer 2 switches only because the forwarding logic on a router required software processing of the packet. Routers will now cache next-hop information on an interface and greatly increase their performance. This increase, however, only applies to standard IP packets. Packets that require special treatment such as fragmentation must be processed by the software functions on the router. The performance of the router decreases when it needs to fragment a great many packets.

Exhibit 7: Fragmentation Example

start example

click to expand

end example

Historically, IP stacks were written with the idea that the information that they were going to receive was going to be sane. If a host received fragmentation information that was not sane, then it might panic and crash. There are a number of ways to create troublesome packet fragments. The simplest way is to simply never send the last packet in the fragment. If the receiving host never receives that MF = 0, indicating that it was the last packet, it consumes resources waiting. Another way to confuse reassembly would be to construct packets so that the fragmentation offsets over-lapped when the receiving host tried to reassemble them. Instead of fitting together like pieces of a puzzle, the overlapping fragment offsets would be equivalent to an operating system trying to put a round peg in a square hole. Finally, one could arrange the fragments so that when they were put together, the packet size was greater than the maximum IP size of 65,535 octets of data.

Most of the attacks described above have been well documented and fixed in most operating system protocol stacks. It does, however, show the danger of using fragmented packets. Instead, attackers have now moved to using fragmented packets in different ways.

When an IP packet is fragmented, only the first fragment contains the original IP header and upper layer information. For example, if a TCP segment is fragmented into five smaller packets, only the first fragment will contain the port information and control bits. Using a packet filtering firewall presents a particular problem because it is this very information that the firewall uses to make filtering decisions. When a firewall sees the separate fragments without the transport layer information included and the fragmentation bit set, it must either assume that the packet is part of a series of fragments and allow it through, or deny the fragments altogether. The first option creates vulnerability in the firewall that an attacker can utilize by just making all the traffic look like fragments. The second option could create problems for users who are using applications located on remote networks that genuinely have a need for fragmentation.

Due to the number of problems with fragmentation, its use is discouraged. The transport layer protocol TCP (Transmission Control Protocol) has a mechanism as an option known as MTU path discovery. This allows the sending host to use the DF bit in traffic to try to estimate the maximum MTU of remote networks and send packets with that MTU, thereby avoiding fragmentation. IPv6, while not forbidding fragmentation, has put the responsibility for creating properly sized packets onto the sending host, again to avoid the need for fragmentation. Because not all hosts are configured with the MTU discovery options and for a great many in the world IPv6 is still a few years off, fragmentation is an issue that needs to be under-stood and dealt with today.

The time to live (TTL) field of an IP packet is normally used as a hop count. It is used to remove packets from the network that do not seem like they are ever going to reach their destinations. Without this field, packets could circle the network indefinitely. The original concept of the TTL was that each possible value in the field from 0 to 255 would represent one second. Upon implementation, however, it became clear that it was tougher than expected to estimate how much time a packet was spending in a router or in transit. If there were delay or congestion in the router, how would that be accounted for as well? The only way to do this would be to record the time the packet entered the router and the time that it left — for each packet! This clearly is too much to handle when routers process millions of packets per second. Instead, a simpler use for the TTL was devised. Each time a router forwarded an IP packet, it would decrement the TTL by a value of one (1). When the TTL reached 0 and the packet had not reached its final destination, an ICMP "time to live exceeded in transit" message would be sent back to the originating host.

Due to the current implementations of the TTL field, in IPv6, the TTL is renamed to the more accurate "Hop Count."

The popular application Traceroute (see Exhibit 8) uses decrementing TTL fields to be able to map out a network. The first packet sent by Traceroute will have a TTL of one (1). This means that when it hits the first router, the first router will decrement the TTL to 0 and return an ICMP error message to the sending host. The next packet is then sent with a TTL of 2. This second packet makes it to the second router, which then sends back an ICMP error message. Because each ICMP message has a source IP address of the originating router, this allows a listing of each router in the network path to be recorded. This is an incredibly useful tool when troubleshooting network connectivity issues. It is also an incredibly useful tool to map network devices and paths. To prevent this from occurring, some network administrators will configure firewalls and routers not to return any information when a TTL of 0 is created on their device. This lack of information, however, can be just as useful to an attacker. If I create a Traceroute to your Web server and notice that the last two hops before the server itself do not return ICMP replies, then I have a clue as to what your internal network structure is.

Exhibit 8: Sample Traceroute

start example

click to expand

end example

The 8 bits of the protocol field in the IP header describe what the header that follows the IP header is going to be. Combined with the Internet header length field, the receiving host now knows how many total bits are included in the IP header and when those bits end, and what the next group of bits should be interpreted as. There are 95 defined protocol values that can be found here; the most common are listed in Exhibit 9. While the list in Exhibit 9 is by no means all-inclusive, it does represent the most common values that would be found in a secure environment, especially one that is using IPSec. If you should happen to see protocol values that include anything different, then it would be worth your time to investigate what is creating them and where they are going. If you have a requirement for a more complete listing, the most recent port assignments can always be found at http://www.iana.org.

Exhibit 9: Common IP Packet Types

start example

Protocol

Decimal Value

Hex Value

ICMP

1

0x01

IGMP

2

0x02

TCP

6

0x06

UDP

17

0x11

RSVP (end-to-end QoS reservations)

46

0x2E

GRE (tunneling protocol commonly used with VPNs)

47

0x2F

ESP (IPSec encrypted packets)

50

0x32

AH (IPSec authentication header)

51

0x33

IGRP (routing)

88

0x58

OSPF (routing)

89

0x59

end example

The checksum field of the IP header is simply a mechanism used to ensure that data in the IP header itself is not corrupted in transit. Because certain fields in the IP header such as the TTL need to be changed at each hop, the checksum likewise needs to be calculated at each hop. The normal behavior for a host that determines that the checksum is corrupt is to discard the packet. It would be very difficult to manipulate this field into an effective attack.

The final two fields in the IP header are fairly self-explanatory. They contain the values of the source and destination of the packet. One thing that is not often clear and is worth pointing out is that most routers will only act upon the destination of the packet. The source of the packet is irrelevant until it comes time to return the packet to the sender. It is therefore a simple matter to send IP packets with spoofed source addresses. The routers along the path generally do not pay attention to the source. This also means that technologies such as network address translation (NAT), discussed Chapter 8, are not required to send packets over the Internet. NAT just makes sure that the packet has a valid source so that the data can be returned.

Finally, the last field of the IP packet header is the options field. This field is appended to the IP packet header in 32-byte increments if additional options are added to the IP packet. While there are a number of options available, we will only discuss the one that deals most directly with security — source routing — and then explain why IP options are rarely used.

Of the 25 or so defined IP options, from a security perspective, the most interesting options are those that define source routing. Source routing comes in two flavors: loose and strict. Both options include IP addresses that the sender of the packet wishes to send the IP packet through, as it is en route to its final destination. As the name suggests, loose source routing defines a single hop. This option in effect says to routers along the path, "I don't care which path you take to get me to my final destination, but make sure you send me through the network node with this IP address in it." Strict source routing, instead of offering a single hop, defines the entire path along which the packet should be sent. Strict source routing says to routers, "When sending me to the final destination, make sure that you send me through each node in this list of IP addresses."

Source routing used to be a popular and effective tool for network troubleshooting. It allowed network administrators to remotely test various parts and paths of a network, regardless of how the routing protocols preferred to route data. Unfortunately, this functionality is rarely used anymore because this same technique can also be used by attackers to route packets through networks of their choosing. This is an effective way to get packets onto private networks, for example. Attackers on the Internet may wish to send a packet to a server located at a private address on a target LAN. Normally, they could never send a packet directly to this server; but using source routing, they can define the path right up to the company access routers and manage to inject the packet onto the otherwise unreachable private address space. Thus, most routers now filter source routing to reduce the risk of this option.

IP options, in general, are rarely used. The reason is that IP options tend to negatively affect router performance. IP-based routers, in order to forward packets at very high speeds, perform the forwarding logic in hardware. The registers that hold the IP header information are very specific and work well when the fields are very well defined, such as a standard IP header. IP options, however, can be any number of values. Like fragmentation, this means that the forwarding for the packets must be popped out of the hardware logic and processed by software — a process that is considerably slower than hardware forwarding.

3.2.2 Address Resolution Protocol (ARP)

IP routing needs the assistance of other protocols to be fully functional. ARP (Address Resolution Protocol) is just one of those protocols. While the TCP/IP suite finds other computers using a globally unique IP address, the actual data transmission has to occur over some type of data-link layer. This is commonly known as layer 2 forwarding in deference to the OSI Model.

Multi-access data-link layers such as Ethernet or Token Ring on the other hand may have hundreds of hosts on any network segment. There needs to be a way to uniquely identify these hosts for the transmissions of frames at the data link. The address used by these protocols is known as a MAC address (i.e., Media Access Control address). Every network interface card sold for Ethernet networks, whether they are used in routers, workstations, or firewalls, come with a factory-set MAC address that is globally unique.

When a local host has a packet to send, it will encapsulate that IP information in a data-link frame and that frame will contain the MAC address of the sending host in the data-link frame. To obtain the MAC address of the destination of the packet, the sending host will first use the ARP process to query the local network. A broadcast LAN frame is sent out saying, "Any host out there on the network with the IP address 200.20.15.5 please respond to this broadcast with your MAC address!" (Of course, substitute the IP address given above with whichever one is being queried.)

Each data-link layer has its own method of addressing. Some protocols such as Frame Relay use a data-link connection identifier (DLCI) that takes a value from 15 to 1024; and others such as as PPP or HDLC have nominal addressing because they are only used on point-to-point links. In the case of point-to-point connections, if a host receives a frame, it is not difficult to figure out where it came from; and more importantly, there is not a lot of thinking that needs to occur when attempting to send the packet.

The results of the ARP queries let hosts know where to find each other at the IP layer. For example, Host A will learn that the IP address of Host B can be reached by sending frames with a destination MAC address of 00-40-05-DF-20-9C [7] and that the IP address of Host C can be reached by sending a frame with the destination MAC address of 00-10-A4-0A-4C-4F. As far as Host A is concerned, the MAC address in its database is the identity of the remote host.

This has interesting implications from a security point of view. An attacker can quickly masquerade as any given IP address by simply listening to the network and responding to ARP requests. At the very least, the location of active hosts can be ascertained, because an ARP request is broadcast and forwarded by all switches.

Switches listen to ARP broadcasts, responses, and data frames to learn the network topology. As each ARP request passes through the switch's interfaces, it records the MAC address source of the frame containing the ARP and associates that MAC address with a port on the switch. When future frames are sent, the switch knows to forward a frame appropriately out a given port and thus create the appearance of a private circuit between two communicating hosts and improving overall network performance and privacy.

As previously discussed, one advantage to employing a switch was that it became more difficult to sniff passwords and other sensitive information off the network because the switch would only forward traffic between the two hosts involved. By understanding the operation of ARP, this privacy can be circumvented. By occasionally responding to ARPs for important network resources, the attacker can make it appear to the switch that the location of the network resource has changed ports for a time. The switch, believing the new information to be correct, will forward frames to the port of the attacker, allowing them to observe information for some period of time. If it happens to be the period of time that a user is sending their login information, then the effort may be worth it for the attacker.

3.2.3 Internet Control Messaging Protocol (ICMP)

The second major protocol that is generally considered part of the Internet layer is the Internet Control Messaging Protocol (ICMP). To understand the utility of ICMP, consider this: most of the time IP itself is either passing incoming data up to the TCP/UDP transport layer, or passing outgoing data down to the network interface layer. What if there was an important message to deliver to the Internet layer itself? Examples might be messages such as: "The host (IP address) you are sending packets to does not exist," or "The time to live of the packet that you sent has expired and it was discarded en route to its destination." To deliver messages such as these and others, the ICMP is used. One of the most useful applications for network troubleshooting is the Ping application. Ping generally uses a special ICMP packet that sends an echo-request that asks, "Are you there?", to which the remote host (assuming it is there) replies with an echo-response saying, "I am here."

There are a total of 11 ICMP message types, each of which applies to Internet-layer-to-Internet-layer communications. Some ICMP messages such as "source quench" are rarely used, due to a lack of need. Source quench was designed to have one host tell another to slow down the transmission rate of information that is being sent. For the most part, that applications that require such service have built in their own flow control algorithms. Even if a receiving host sends a source quench, there is no assurance that the sender is going to slow down anyway.

Other ICMP message types are used with caution as they can be used to cause Denial of Service attacks. This option refers to the "redirect" ICMP message (see Exhibit 10). Commonly, ICMP redirect messages are used on network segments with multiple gateways. Each host is configured with a default gateway, but if the gateway itself receives a packet and determines that another locally attached gateway would better serve in the routing of that packet, a redirect will be sent to the original sending host of the packet telling it to forward packets directly to the secondary gateway in the future. This application of the redirect function makes the gateways operate more efficiently and improves performance for the sending host. The ICMP redirects can also be used to denial of service a network as well. By sending redirect packets to a host that look like they came from a gateway, the host will then begin to forward packets to a nonexistent gateway.

Exhibit 10: ICMP Redirect Example

start example

click to expand

end example

ICMP, like IP itself, is a connectionless protocol. This means that packets are sent and there is no means of keeping track of what has been sent, what order they have been sent in, or flow control. The ICMP packet itself does contain an identifier field that may or may not be used on a per-packet basis. Its use is determined by the type of ICMP packet being sent, as described below.

The "spray and pray" connectionless nature of ICMP makes it an excellent tool for flooding a network with packets in DoS attacks. It is also a commonly used transport for fragmentation-based attacks such as the Ping of Death and other variants.

ICMP presents a particular problem when configuring stateful packet filters and receiving ICMP packets. Consider the following example. Host A wants to ensure that Host B is "alive," so it sends echo request packets using ICMP. Because ICMP is connectionless, the Internet layer itself makes no effort to associate outbound packets with any type of state information. When Host B receives a number of ICMP packets and returns the echo reply, how does Host A know which reply was in response to which packet it sent out? Or, what if Host A was simply trying to connect to a Web page and was sending a TCP SYN packet to a remote host? At this point, Host A is expecting a TCP SYN ACK in reply; but if the remote host is not available, Host A may receive an ICMP "host unreachable" message from an intervening router. In this second case, Host A is not even expecting an ICMP packet and between the connection attempt and the response may have sent out dozens of packets. How does it know to associate the host unreachable packet with that single failed TCP connection?

To provide information to the receiver of the ICMP packet, ICMP responses include the first 64 octets of data from the packet that generated the error condition. In the case of echoes, this allows the ICMP echorequest information and the identification field of the echo-request field to be included. In the case of the failed TCP connection, the data returned is the IP header and the TCP header, which would include source address and port information. In each case, by providing extra information, the sender of the first packet is able to piece together what has occurred. If multiple echo requests have been sent, the sender is able to associate each response with a request. If dozens of TCP connection requests have been made, the originator of the requests is able to determine which request has failed due to the ICMP information returned in the error message.

This behavior by ICMP makes it particularly suitable for use in covert channels. A covert channel is a communications pathway that is not clearly a communications path. By manipulating the value of bits in unused or seldom used fields, information can be relayed. It may not be very high bandwidth, but the information can be hidden and passed through a firewall. Because ICMP has a comparatively large number of bits in the identification field that are only used rarely, this field is ideal for hiding information.

Here is an example using ICMP as a covert channel for controlling a remote application. You have somehow managed to convince someone internal to the network that you wanted to attack, to install a Trojan program on a host. Perhaps you e-mailed it to them or got them to download it from a Web site. To control the Trojan, you need to communicate with it, so you have it configured to send ICMP echo-request packets to a remote site when the host is turned on. Because most firewall policies allow echo-request through for troubleshooting purposes, this packet makes it to your remote command center. To communicate your intentions back to the Trojan, you simply send back an echo-reply. Inside the ICMP header, encoded in just a few bits, are your instructions for the Trojan. The popular denial-of service-tools based on Tribe Flood Network (TFN) operate in this very manner.

ICMP can be a double-edged sword in the world of network protocols. On the one hand, it is incredibly useful when trying to troubleshoot a remote network or otherwise deal with connectivity issues. Any network troubleshooter of any skill will first start with the PING application to quickly zero in on the problem. Either the remote host is not working properly or the network is not working properly. PING and ICMP allow a troubleshooter to quickly establish where to concentrate their efforts.

The information available from ICMP, while valuable for troubleshooting and reporting, is also dangerous when used against your network. An attacker can determine the approximate layout of your network in a matter of seconds using ICMP and PING sweepers — programs that send out a number of PING packets to a range of IP addresses rather quickly. Firewalls and other network access controls need to be carefully configured to allow only the proper ICMP message through.

Commonly, packet filters will be used to deny all ICMP traffic inbound to the network except ICMP echo-reply packets. The theory is that if someone on the inside of the network sent an ICMP echo-request packet as part of the PING application, the only legitimate response should be an echo-reply. Other solutions include configuring a single server with full ICMP access. When troubleshooting through the firewall, network technicians will source traffic from this single host.

3.2.4 IP Options

IP also supports the inclusion of multiple options. The most commonly encountered options are those related to source routing. For reasons of security and performance, options at the IP layer are commonly disabled, not used, or not allowed on certain networks.

As previously discussed, source routing is the ability to define in an IP packet the path that the IP packet should take en route to its final destination. Due to the potential for abuse, both options are typically disallowed on routers and through firewalls. Imagine the scenario where an attacker instructs two hosts to communicate with each other yet routes the packets through his or her remote network.

As discussed with fragmentation, the use of options also degrades the overall performance of routers. Because the options can take many different values, they must be individually examined by the software routing process instead of letting the much more efficient caching of routes forward the packets.

3.2.5 IP-Related Issues

Along with the construction of the IP header, there are numerous other technologies that security-conscious professionals need to be aware of. This section discusses the operation and security implications of technologies such as Dynamic Host Configuration Protocol (DHCP), private addresses, network address translation (NAT), and the various routing protocols that can be used on a network and how to employ them in a secure manner.

3.2.5.1 Dynamic Host Configuration Protocol.

The first topic of discussion is the DHCP. Odds are that you may have changed the IP address on your computer at one point in time. The process of changing an IP address, for any given computer, takes anywhere from one to five minutes. This of course does not include the time it takes to walk to the computer, talk to the user for a couple of minutes, get them to save their work, etc. For any single device, the process is not that onerous. Multiply that by 100 or 500 and IP address management becomes a job that most network administrators dread. It should come as no surprise that we enlisted the help of computers to make this process easier on us. After all, that is why we use them so much, is it not? Instead of managing IP addresses on single computers, we create a small server that has a pool of IP addresses. When a computer powers up first thing in the morning, the first thing it does, network-wise, is to send out a broadcast packet requesting an IP address from any local DHCP server. The DHCP server will then select an IP address from its pool of available addresses and loan it to the requesting client.

From a security point of view, this should be the first concern. Because the computer that is booting does not yet have an IP address to use, or any type of IP configuration for that matter, it cannot send a request to a specific DHCP server. Instead, it broadcasts the packet, and the first DHCP server that answers the broadcast is the one that the booting host accepts. A rogue DHCP server could potentially provide configuration parameters to requesting clients a good portion of the time if it were able to respond to client requests before the valid DHCP server were to.

To examine the level of vulnerability to false DHCP configuration requests, let us first examine what else that DHCP can be used for. The primary purpose — the assigning of an IP address — we have already covered. An IP address, however, is not all that a computer needs to be able to utilize network resources. At a minimum, any IP address requires a subnet mask to be relevant. This is not a book on subnetting, but to put it briefly, a subnet mask is a way of letting a computer know how the IP network has been broken up. Instead of having one big network with 500 computers in it, each using a single IP address, you can have two (or more) smaller networks, each with only 250 hosts in it. A host computer understands the way you have broken up the network based upon the information in the subnet mask.

With an IP address and a subnet mask, a computer has everything that it needs to be able to communicate, using IP, with other computers on its directly attached network. This means that if all the computers are attached to the same hub or switch, they can communicate. For modern networks, which we expect to communicate with networks all over the world, we do not have enough information yet. We also need to tell the computer where to send packets that are destined for other networks. Because we cannot reasonably assume that each desktop, laptop, or server on a network knows the location of every single other of the 500 million hosts attached to the Internet, we simply give our hosts a single instruction: "When you have a packet destined for somewhere not on your network, send it to the default gateway and let the gateway figure out what to do with the packet." All we need to do on the host to make this process work is tell it the location of the default gateway. Default gateways are also known as default routers in some applications, so do not be concerned if you see different terminology. The "default" is the clue that will explain the function.

You would think that we have everything we need by this point — and we do. We have everything that we need on the host to get it to forward IP packets properly. All you need to know now is the IP address of the remote resource and the protocols take care of the rest. If I were to give you a quick quiz and asked you the IP address of your company's Web server, unless you were the administrator of the e-mail server on your network, you would either have to think for a moment or just plain look it up. Imagine if I were to ask you to browse to the fark.com Web site. Quick! What is the IP address?

Of course we poor humans cannot remember such details for all the possible network resources we want to use, so we use the domain name system (DNS) to do this lookup for us. For a host computer to be able to perform such a lookup, it needs to be configured with the IP address of one or more DNS servers. This is another common element that DHCP will configure for our hosts.

IP address, subnet mask, default gateway, and DNS servers — these are the four minimal configuration options for Internet connectivity. There are others types of servers and information that DHCP can provide for hosts but they are specific to the operating environment. From these four alone, however, three risks immediately present themselves.

3.2.5.2 DHCP Security Concerns.

A rogue DHCP server assigning either a bad IP address or subnet mask would effectively create a denial-of-service (DoS) for the network host. Likewise, assigning incorrect DNS servers or default gateways would do the same. Incorrect information in any one of these fields would prevent hosts from accessing network resources, as many network administrators have discovered from their own legitimate DHCP configurations. While an annoyance, such attacks are easily discovered. Because something was not working, the first thing a network administrator would typically do is examine the IP-related information that was assigned to that host. Even a casual examination would show that incorrect information has been assigned and the hunt would be on for the cause. A double-check of the legitimate DHCP server would show it to be working and, in short order, the rogue DHCP server would be discovered. Imagine, however, an attack that is much more insidious and shows no outward indications of breaking anything. If, for example, an incorrect default gateway is assigned, all traffic leaving the network could be sent to a particular host and then back out onto the network. The user notices nothing, but all the while the host acting as the default gateway is able to examine each packet as it is sent. This form of packet sniffing would defeat even a switch. Because most users do not habitually check their IP address information obtained through DHCP (if they even understand what they are looking at), this attack can go undetected for some time.

Another attack along those same lines is simply to change the location of the DNS servers. Instead of using the company DNS server, name/address resolution requests could be sent to a DNS server with custom entries for certain sites such as the company's mail server, Web pages, and SQL server. The location of the rogue DNS server and modified network resources are irrelevant as the helpful network ensures that packets are being forwarded correctly. With a bit of doctoring, each of these fake resources could be made to appear as the actual resource. This is especially effective when log-ins are required. At some point, the process would break down, but by then a great deal of damage could have already been done.

Lest you believe such events to be unlikely on your network, consider that custom mini PCs with built-in networking cards are easily created, built from scratch, or built from game consoles (Sony Playstations, for example) that can contain the DHCP server, sniffer, DNS server, and false server resources all at once. These devices are then configured to periodically "phone home" to deposit any information that they have learned. Inconspicuously dropped into a vacant network port and kicked under a desk, these devices can be very difficult to find and require only a moment of physical access to the network and in most cases are small enough to fit in a briefcase or knapsack.

While a rogue DHCP server can be difficult to find, the effects of one can be greatly minimized by following sound security principles. Restrict physical access to the network to only those who require it. Encrypt traffic in transit so that it cannot be sniffed. Use server authentication in the form of public keys to prevent other devices from masquerading as important resources. Each of these options for reducing these threats will be discussed in the following sections and chapters.

3.2.5.3 Private IP Addresses.

IPv4 addresses are rumored to be in short supply. Around the mid-1990s, there was such a worry that the growing Internet would utilize all 4.2 billion available IP addresses that a flurry of activity was undertaken to find solutions to this problem. In addition to utilization, there were a number of other problems with IP addresses related to the scalability of our current addressing plans. One of the most clear-cut solutions to all of the problems of IP addressing was IP version 6 (IPv6). This increases the number of available IP addresses into the trillions and at the same time solves a number of other scalability problems, including security. The security solution introduced with IPv6 is the IPSec suite of protocols that we now use to secure our networks. As far as the rest of the IPv6 protocol, it became clear that the work required to migrate a global Internet to a new network layer protocol would take years, if not decades, to accomplish. In the short term, a number of other solutions were introduced at the same time as IPv6. These solutions include variable-length subnet masking (VLSM) and classless interdomain routing (CIDR). These two solutions together are used to solve many of the scaling problems of IPv4. They do not, however, directly affect the number of available IP addresses that we can use with IPv4. The value of these solutions is that they allow us to more efficiently utilize our existing IPv4 addresses.

The primary shortage of IP addresses and IPv4 is a result of the requirement that each Internet host use a unique address. Each IP address and each IP network number can only be used once. This means that the network number your ISP has assigned you for your network can never be used on another network without causing confusion on Internet routing tables. To many, this seemed inefficient. What we needed was some way to reuse the same network numbers.

To help overcome this shortage, the IETF (Internet Engineering Task Force) combined an existing address allocation scheme known as private addressing with a new technology, network address translation (NAT). For some time, there had been the requirement that private IP networks not connected to the Internet have a reserved address space. The goal of this was to avoid any confusion should a network ever connect to the Internet and to spare companies without Internet access the task of applying for IP address blocks from the IETF. The IETF took a look at the current IP address allocations (circa mid-1990s) and found large chunks of the old class A, B, and C address space that were unallocated. The IETF then decreed that these network spaces would be able to be reused by anyone on their private networks. There was, of course, one caveat. If you were going to connect to the Internet, you could not advertise these private addresses to the rest of the world. That is, they could only be used to get information from point A to point B inside your own network, not across the Internet.

The addresses designated as private appear below:

  • 10.0.0.0/8 (255.0.0.0) — 16,777,216 addresses

  • 172.16.0.0/12 (255.248.0.0) — 1,048,576 addresses

  • 192.168.0.0/16 (255.255.0.0) — 65,536 addresses

Clearly, such large address spaces are meant to be subnetted into smaller networks, allowing companies quite a bit of flexibility with complicated internal network topologies.

When working with customers and training, I commonly hear the association that "private addresses are not routable." This is not accurate. Private addresses are just as routable and functional as normal public IP addresses. Any one of the private network numbers can be used to create private routed networks that are quite large, all with no special network configuration required. Private networks and packets destined to private addresses are not exchanged over the Internet because ISPs will filter private networks from their routing tables. This is important to remember when considering network security. Unless configured otherwise, a router or other network host will treat a private address just like any other address. We revisit this concept when discussing router security and route filtering.

3.2.5.4 Network Address Translation.

The ability to reuse the same network space by separate unconnected organizations through private addressing was a great boon to the temporary shortage of IPv4 addresses. Clearly, however, at some point network administrators with private addresses would want to connect to the Internet. If this is going to happen, there needs to be some way to translate the private reusable addresses into something unique. This is the role of network address translation (NAT) and it is the second technology that has allowed us to conserve the IP address space by allowing network administrators to connect privately addressed networks to the Internet. NAT is a service that resides on a gateway device, be it a firewall or a router. The best way to understand the operation of NAT is with a quick tutorial. In Exhibit 11, Host A is sending a packet to Host B on the Internet. When Host A sends the packet, the source of the packet is Host A's private IP address and the destination is Host B's public IP address. When the packet passes through the firewall, the firewall changes the source of Host A's packet to make it look like the source is a public IP address that is part of a pool [8] of public addresses reserved on the firewall. In this specific example, the public address pool is the same as the address assigned to the firewall public interface. At the same time the address is changed, other options in the IP and TCP header are changed as well to reflect the new source address. When Host B receives the packet and returns its own packet, the source of the packet is now Host B's public IP address, and the destination is the public IP address that the firewall inserted into the packet. When the firewall receives the packet, it consults its NAT table, which is simply a table that indicates that it changed the source of a packet from Host A to Host B. When the return packet is seen, the firewall performs a reverse translation and changes the destination IP address of the packet from the public address to the private IP address of Host A. Internal to the private network, the packet is routed to Host A, which receives the packet none the wiser that any translation has occurred.

Exhibit 11: NAT Example

start example

click to expand

end example

It is a common misconception that NAT is needed to send packets onto the Internet. From the example above, we see that Host A sends a packet that is entirely able to make it to Host B as the destination of the packet is correct. Without NAT, however, when Host B tries to return the packet to Host A, the routing of the packet will fail because now there will be a private address in the destination. Because backbone routers and most access routers are specifically configured to filter packets to private addresses, the return of the packet to Host A will fail.

To perform a translation, the NAT device needs to be configured with at least one public IP address to use in translations. In the early days of NAT, this led to a NAT device only being able to concurrently translate addresses on a one public:one private basis. For example, if a NAT device were configured with six public addresses, then at most, six devices internal to the network could access the Internet at a time. This was the only way that the NAT device could keep packets straight in its NAT table. If you had a network of 200 users and could expect concurrent Internet sessions from all of them, you would need 200 public addresses for the NAT device. This is hardly an address saving technique!

Allowing more internal hosts configured with private addresses to share public IP addresses requires additional information to allow the NAT device to properly associate return traffic from the Internet with the proper internal host. In addition to IP addresses, transport layer and other protocol headers provide enough unique information to allow return traffic to multiple internal hosts to be reverse translated from a single IP address. By expanding the NAT translation tables to include both IP addresses and transport layer ports, network address translation expanded to include port address translation (PAT). Today, PAT is so common that when NAT is mentioned, it is commonly assumed to include PAT.

For some time, NAT has been touted as a network firewalling technique. It is commonly employed as part of a firewall, but should never be considered a stand-alone security solution for your company. We now discuss the relative security offered by NAT. First, the pro-firewall logic will be examined.

"NAT protects your internal network because unless there is a currently active connection, someone scanning your network from the outside cannot reach your internal hosts. This makes it more difficult for people to map your network and make connections to internal hosts."

This is true. The way that NAT works is that the NAT table creates a temporary entry when dynamic NAT is used. Dynamic NAT simply means that every time a client passes through the NAT device, there is no assurance that it will receive the same translation as it did the last time. In the case of a large NAT pool, Host A will appear to the Internet to be a different IP address each time it connects to Internet resources. When the connection has completed, the old entry in the NAT table is removed, allowing other hosts to use the address/port combination for outbound traffic.

NAT fails as a stand-alone security technique in several respects. The first is that dynamic NAT is not the only way to employ NAT. Let us assume that internal to your private network you have some resources that you want remote sites to be able to access, such as SMTP and POP3 servers. Because internal to your network they are configured with private addresses, you will need to translate packets sent from them or to them at the NAT gateway. To ensure reachability from outside the firewall, you will have to make sure that the NAT is the same IP address and port all the time. That is, you will have to create static NAT entries. From the point of view of someone on the Internet, some of your most interesting resources (servers) look like they have public IP addresses. That NAT is being transparently employed between you and the attacker has no effect on the attack. Packets sent from the attacker are translated with the same facility that legitimate packets are sent. Thus, no protection is provided for Internet resources through the use of NAT.

When attacking other internal hosts, there are many easier ways to attack a network host other than actively scanning a NAT device and guessing at active translations. Perhaps the easiest way to attack a computer on a privately addressed network is to simply convince the user to connect to you or otherwise download your attack to their computer themselves. This is true regardless of the presence or absence of NAT. For example, you could send them an e-mail with a suggestive subject line and a plausible-looking attachment. Despite this being one of the most common transmission methods for viruses and worms, it still works. Once a program is installed on a computer with private addressing, it can connect or "phone home" right through the NAT device just as any other application on the computer would. There are a number of attack vectors that are not related to scanning that NAT does nothing to protect against.

What does NAT do for us? It allows the use of private addresses internal to our network to ensure that traffic sent from our network can return properly. Does it provide some security? Yes, but NAT alone should never be considered adequate protection from network attacks. If you go through the process of creating a security policy and properly evaluating threats and vulnerabilities, you would find that only defense in depth will ever protect your network properly.

3.2.6 Routing Protocols

This section discusses the operation of common routing protocols, how they affect the security of your network, and the steps that can be taken to help the routing protocols operate in a more secure manner.

3.2.6.1 LAN Routing Protocols.

A router forwards packets. A router forwards packets according to the information in its routing table. It is the cardinal rule of routing that if there is not an entry in the routing table instructing the router what to do with the packet, then the packet is dropped. Clearly, the routing tables are important to the overall functioning of our networks. The question is, how does network information get into the routing tables to begin with? There are basically two ways to accomplish this. As a network administrator, you could sit down with a diagram of your network, log on to each router, and specifically tell it where to send packets to reach all parts of your network. This manual entry of routing information is known as static routing. While you create a very complex network using nothing but static routing, only the most masochistic network administrator would attempt such a thing. When static routing is used, the routers will use the information entered by the administrator, regardless of the state of the network. Thus, if there were a failure or addition to the network, the only way to ensure reachability to all portions of the network would be to log back into all of your routers and update the static routes. In the meantime, your network users are in the parking lot racing office chairs because no network-based work can occur.

Indeed, instead of relying on static routes, we looked for some way to have each router inform all other routers in the network of what networks it is attached to. This process of automatic communication between the routers is known as a routing protocol. As with most things in technology, there are multiple ways and opinions as to the best way to do things and routing protocols are no exception. There are a number of routing protocols that can be used on your own network and all enable each router to learn the relative position of each network to itself.

Production routing protocols come in two major flavors known as distance vector and link state. Simply put, a distance vector routing protocol exchanges routing information directly with its neighbor. As Exhibit 12 shows, Router A learns about Network 10 from Router B. Router C tells Router B, and Router B then tells Router A. There are three distance vector routing protocols in common use and they go by the names of Routing Information Protocol versions 1 (RIP) and 2 (RIPv2), Interior Gateway Routing Protocol (IGRP), and the Enhanced Interior Gateway Routing Protocol (EIGRP). [9] The other major family of routing protocols likely to be found on internal networks is the family of link state routing protocols. Using multicast packets, link state routers communicate with all other routers in the network. Thus, in Exhibit 12, Router A hears about Network C through a multicast packet sent directly from C. Link state routers use this information to create something known as a link state database. This link state database is essentially a snapshot of the network. From the link state database, the routing tables are created. The most common link state routing protocol found in commercial environments today is the Open Shortest Path First (OSPF) protocol. The Intermediate System to Intermediate System (IS-IS) protocol is also used, although with less frequency and typically on larger, older ISP backbones. Functionally, the two protocols are similar; and if one is employed, there are few compelling reasons to change to the other.

Exhibit 12: Distance Vector Routing

start example

end example

3.2.6.2 The Border Gateway Protocol.

All the routing protocols mentioned thus far are known collectively as Interior Gateway Protocols (IGPs). This means that they are all meant to be used internally to an autonomous system (AS). An autonomous system is nothing other than a routing domain that is under the administrative control of a single entity. Therefore, the largest enterprise network is a single AS and my test network within my office is a single AS. Size is not important with regard to the definition of an AS, but who controls the network is. By this definition, we can see that when most people talk about their network or their company LAN/WAN, they are technically speaking of their AS. Inside your AS, the IGP that you use is totally up to you. You will make a decision about which routing protocol to use based on the size of your network, the amount of changes and growth you expect your network to have, the amount of control you want over your network traffic, and, of course, the security required for your routing protocols. You can use either link state or distance vector routing protocols. While many networks converge on a single routing protocol, it is not unusual to find link state and distance vector protocols coexisting on the same network. When you send traffic to another network, you will typically have one of two choices: either static routes or the exterior gateway protocol known as the Border Gateway Protocol version 4 (BGPv4 or just BGP).

BGP is known as a path vector routing protocol, so it is not quite a distance vector routing protocol and it is most certainly not a link state routing protocol. Rather, it is in a class of its own. BGP is the routing protocol that allows the packets on your LAN to reach a Web server on the other side of the world, and its use is mandatory if you wish to be a major network presence on the Internet. As a routing protocol, BGP simply creates a routing table such as RIP or OSPF; but because it needs to control enormous numbers of routes from networks around the world, it is quite a bit more powerful, flexible, and configurable. As such, we will see that the security considerations of routers running this protocol need to be taken into consideration because anyone able to control BGP is able to inflict serious damage not only to your network but also the Internet as a whole.

With that cursory introduction to routing protocols out of the way, let us examine how the choice of routing protocols can affect the security of your network. In the above discussion, we saw that routing protocols can roughly be divided into two categories: (1)those that are used inside your network, the interior gateway protocols (IGPs), and (2) those that are used between your network and someone else's, the exterior gateway protocols (EGPs). Of the EGP family, there is only one routing protocol that is used, the Border Gateway Protocol version 4 (BGP). There is also a special type of routing table entry, the static route that can be used inside and between networks. Each of these will be addressed in turn.

IGPs control where the traffic inside your network is sent. The vast majority of small office/corporate office networks only have one or two routers at most. In this case there will not be much redundancy in the network and, as such, the routing protocols will be sharing limited information. In the rest of corporate or ISP networks that have quite a few routers and are large networks, there may be hundreds of routers sharing a common routing protocol and building local routing tables on each router. It is these routing tables that allow all areas internal to your network to be reached and direct traffic off your network as appropriate. The manipulation of these routing protocols can have disastrous effects on your company. A brief example illustrates this.

The operation of the routing protocol RIP is to broadcast packets to any host that will listen to the state of that particular router's routing table. Other RIP routers listen for those packets and then update their own routing tables according to what they hear. The ability to capture a routing table, while not the type of information you would normally want available, pales in comparison to what else someone with malicious intent could do while taking advantage of RIP operation. Because RIP is configured to listen to any packet that looks like a RIP packet, it is a simple procedure to create a fake RIP packet with routing information that suits the attacker's goals. This can have several effects. One effect would be to funnel all routed packets through a particular machine for reading. Because the routing tables can be manipulated on a per-subnet basis, this can also affect traffic destined to only a particular subnet — such as the server farm. Less sophisticated manipulation can simply route all packets to incorrect subnets, effectively creating a denial-of-service situation.

This type of problem is caused because routing protocols, by default, do not perform any authentication of the information they receive. Whether it is RIP, EIGRP, or OSPF, packets that look right are assumed to be valid. The solution to this problem is to configure authentication as part of the routing protocols. A password/key for each router interface can be assigned as part of the routing protocol configuration. The key is hashed [10] using MD5 or SHA-1 and then sent as part of the routing protocol updates in each packet. Routers that receive the updates will hash their own password/key and compare the result to that included in the packet. If they are the same, the routing update is considered to be from a valid source. Replay attacks are prevented through the use of incrementing sequence numbers that are also protected by hashing.

There are a couple of things to be aware of with this solution. The first is that not all routing protocols support authentication. RIP is a notable example of a routing protocol that does not allow authentication and is very commonly implemented. If authentication is required, then RIPv2 should be used instead. It should be noted, however, that the IETF considers RIP itself a historical protocol and advocates the use of OSPF in future installations. The second major consideration regarding authentication is that none of these routing protocols support the actual encryption. Anyone with the ability to capture data would still be able to read your routing tables. That said, there are other ways to figure out a network topology without reading the routing tables, but it certainly does make things easier for a would-be attacker.

The final consideration of authentication is that someone on your network can easily end up inadvertently negatively affecting network reachability. If you change or otherwise carelessly modify the authentication key on one interface, that router will immediately stop accepting updates from its neighbors, effectively cutting itself off from the rest of the network. This creates an additional amount of maintenance, administration, and configuration overhead that must be considered when determining if the authentication scheme should be used.

For routing between ASs, such as your network and that of a business partner or an upstream ISP, either static routes or BGP will be used. Typically, if a network is only single-homed — that is, it has only one data connection to another network — static routes will be used. If a network is multi-homed, having more than one data link to one or more remote networks, BGP will most commonly be the routing protocol in use although it is not unheard of to use static routes in this instance as well.

BGP is unique among routing protocols in that it is designed with flexibility and control at the forefront. Other routing protocols can be manipulated to control what routing information they accept, but that is really a secondary function for them. BGP, on the other hand, must be configured with this control to work. It is easy to demonstrate the reason. When you control the routing information, you control where information is sent and what information is sent to you. By controlling what you send other networks, you affect who is able to reach your network. By controlling what you receive from other networks, you control your ability to reach Internet destinations. From a security and routing efficiency point of view, these are things that we would expect from any protocol that allows you to directly peer with another network.

The configuration of BGP requires that you manually configure your peer relationships. This means that between you and your service provider, you will enter a command in the BGP configuration that says, "Only accept network updates from this particular peer router." Because your upstream connection is typically a point-to-point serial link of some sort, the ability of someone to interject false information between you and your service provider is limited. Inside your own network, you will also create BGP peering sessions with other routers. To preserve the integrity of routing information exchanged via BGP peer routers, BGP allows the configuration of authentication much like the IGPs allow.

The far greater risk associated with BGP, however, is the insertion of inconsistent or bogus routing information from networks that you do not peer with. Remember that the entire Internet is simply a bunch of networks connected at various points and share routing information via BGP. So, the entire networking world is a mesh of BGP peers sharing routing information. Neither you nor your neighbor may be originating bad information, but someone in another country could be sending bad information, which could eventually find its way back to you. If this is the case, your network would be only one of thousands that would suffer from a wide-scale threat. To prevent this, ISPs and other responsible organizations will configure their own BGP to double-check the information they are sending and, more importantly, receiving from others. You will need to ensure that your BGP configuration does the same.

The actual process of configuring BGP is complicated and is best left to those who specialize in configuring BGP. Therefore, I will not offer specific advice in this text on the configuration of the protocol. Entire texts have been written only for this purpose. Importantly, however, there is a difference between configuring BGP for optimal routing and configuring BGP in a secure manner. In practice, optimal routing and security can be achieved. This discussion provides information you need to work with your routing expert to ensure that BGP is being applied in a secure manner. It should be noted that most service providers, recognizing the importance of BGP to the overall health of the Internet, apply the same general rules to their own BGP configurations.

Filtering routes with BGP is very specific to the vendor you are using, yet a few rules can be generalized. First, the Internet routing tables, when summarized, account for 108,000 to 120,000 routes. From time to time as someone else misconfigures their BGP, the number of routes may jump by 50,000 to 60,000 routes. This spike will adversely affect the performance of your router. Most BGP implementations allow you to limit the total number of BGP routes being accepted from your peers. Placing a conservative number of 125,000 routes should be acceptable for legitimate routes and still protect against leaks in the routing table.

Every time a route is added or removed from the BGP tables, that update must be propagated through the Internet. On the scale of over a 100,000 routes, these changes alone create quite a bit of traffic and consume processing as each router readjusts its own routing tables to reflect the new change. By purposely causing a number of routes to go up and down (such as pulling the connector on the access-link), instability can ripple across the Internet. To help protect against this, a technique known as route flap dampening can be applied to the BGP process. Route flap dampening simply means that if the state of a route changes a configurable number of times within a certain time frame, then the route will be suppressed (removed) from the routing table. Typically, the dampening period will be three times in 15 minutes with a suppression of 45 minutes. Even with route flap dampening configured, the number of changes on the Internet routing tables is on the order of one to two updates per second.

When possible, BGP should be configured to accept and send only those routes that you specifically want the rest of the world to gain access to. For example, assume that you have two major network numbers in your internal network. These networks are each divided into ten subnets. One of the networks is an internal network that you do not want to be advertised. If you do not advertise it out over your Internet connection, nobody will ever be able to send packets to that network. You have taken several other precautions, such as firewalling and packet filtering traffic from that network, but the extra layer of information to consider is ensuring that the private network is not advertised at all using BGP. Control routing tables and you control traffic. Do not tell anyone about the private network and no traffic will be sent to it.

Likewise, there is no need to advertise the ten separate subnets of your public network to the rest of the world. Most ISPs will not accept all of the subnet entries because it would cause their routing tables to grow too quickly. To ensure the efficiency of the Internet routing tables and shield specific information about your network as much as possible, you should only advertise the network block summarized as a single network and not the specific subnets.

The other common method of configuring routing, especially to upstream peers, is through the use of static routes. Due to the amount of processing power required to process BGP information and the fact that if you have only one access link to the rest of the Internet, a simple static default route saying, "Send any traffic not part of my network upstream," is sufficient. After all, knowing 100,000 routes only makes sense if you have a choice as to which way to send packets, hence the application of BGP to multi-homed networks.

From a security perspective, static routes have advantages. Because they are configured on each router and do not depend on information from another source, they are difficult to change or influence without access to the router itself. On the other hand, they can be an administrative night-mare because they do not reflect changing network conditions. For a simple single-homed network, however, static routes are preferred. Indeed, unless you are multi-homed, many ISPs will insist that you use static routes when peering with them.

3.2.7 Transmission Control Protocol (TCP)

3.2.7.1 Transmission Control Protocol Basics.

Of the most common protocol headers, the Transmission Control Protocol (TCP) header (see Exhibit 13) contains the most detail and is the most complicated. While the combination of fields and options may seem overwhelming, understanding this protocol is critical to the understanding of network-based security.

Exhibit 13: Transmission Control Protocol Header Format

start example

click to expand

end example

The first two fields — source and destination ports — apply to the software addresses used by the transport layer processes to pass data to application layer processes. It is the information in the port fields that allows a computer to run multiple client and server applications at once. If a server is acting as a Web server, mail server, and DNS server, when it receives a packet to its single IP address, how does the TCP/IP stack know which application the packet is ultimately destined for? When initialized, each server process listed above will begin to listen for information on a port listed in its configuration file. Each client process will use a random source port for its communication to the server.

In a simplified example, Host A wishes to view a Web page at Host B. Host A sends a TCP packet with a destination port of 80, which is the standard port for an HTTP server. The source port of that packet will be a random port, [11] generally higher than 1023. For this example, assume that it uses port 5440. When the Web server at Host B receives the request, it reverses the source and destination ports and sends the reply to port 5440 with a source of 80.

A port can be any number between 0 and 65535. With such a range, the Internet community has come to the consensus that certain popular services, such as relaying e-mail, Web servers, file servers, and the like, will be run on certain "well-known" port numbers. This ensures that a user in Europe can connect to a Web server in the United States without having to first call the company she is interested in to learn of the port that the TCP connection should be initiated to.

A complete list of the well-known ports and a number of other ports commonly used for services can be found online at http://www.iana.org. Note that this list is considered the standard and obsoletes an older RFC 1700 that defined the well-known ports.

Other than the well-known port numbers, which are ports in the range of 0 to 1023, there is also a range of "Registered" ports. These ports can be used for application servers that do not fall into the traditional well-known range. The Registered ports are in the range of 1024 to 49151. Above that range, the ports are considered "private" and can be used freely within an organization.

Just because a certain port is listed as a certain service does not mean that if you notice that port 80 is running on a host device that it is necessarily running a Web server. Ports are easily configurable within an application. To try to confuse would-be attackers, some network administrators run their network services on non-standard ports. This technique does not work for long because port scanning will show that something is listening on an open port. It is generally just a matter of connecting to the port once you notice it is listening to determine the service running.

Running services on non-standard ports is also a way to circumvent firewall rules. "Legitimate" Internet services such as the World Wide Web are often found on port 80. Chat servers or media streaming servers are configured to listen on port 80 with the assumption that most firewalls allow users to surf Web pages. This knowledge can also be used by attackers and is commonly how spyware operates. If an attacker manages to install a Trojan on a host computer, that host computer can generally be assured Internet access through port 80 on the firewall. Spyware, which monitors user's Internet activities for sale to marketing services, will also phone home on port 80 with the assumption that traffic through the firewall is generally allowed.

The combination of TCP port information and the IP addresses used in the connection is known as a "socket" and is used to uniquely identify connections between TCP hosts. The common representation of a socket is [IP address]:[local port]. As an example, an HTTP connection between a client and a server would be represented as 200.1.1.1:2053 as the socket for the client and 200.1.1.100:80 as the socket for the server.

The next field in the TCP header is that of the sequence numbers. This 32-bit number is how TCP processes on hosts keep track of what has been sent and received. When initiating a connection, the TCP stack sends an initial sequence number to the remote host. This number essentially tells the host, "When I send you data, I'm going to start counting at 1,657,145,002." Each octet of data that the sending host then sends will increment the sequence number by a value of one.

Because it would be very wasteful of network bandwidth to send a single octet (8 bits) of data per packet, TCP sends a group of packets all at once.

The receiving TCP host acknowledges what it has received from the sender by using the Acknowledgement field. This 32-bit field is where the receiver indicates that "The next sequence number I expect from you is: 1,768,145,953." Upon receiving the acknowledgement number, the sender will then determine if the receiver has received everything that has been sent. If there is a discrepancy between the sequence number that the sender has counted to and the acknowledgement number that the receiver has, then the sender will know exactly what data is missing and resend it.

The data offset field in the TCP header serves the same function that the Internet header length (IHL) field in an IP packet. It describes to the receiving host how many 32-bit words are in the TCP header. At a minimum, this value will be 5; but because options are more commonly used in TCP than in IP, it can greater than 5.

There are 6 bits reserved in the TCP header. According to the official specifications, these reserved bits need to be zeros. They can, however, be used for covert data channels although this use is more commonly found using an ICMP packet along with popular Trojans.

There are six control bits in the TCP header. Using these bits, the TCP connection is created, controlled, and torn down at the end of a transmission or due to errors. Understanding these bits is critical to the proper implementation of a packet filter firewall. In order, the bits are named URG (urgent), ACK (acknowledgement), PSH (push), RST (reset), SYN (synchronize), and FIN (finish). A short discussion of the significance of each follows.

The URG bit indicates to a receiving TCP process that some of the data in the data field is considered "urgent" and demands immediate attention. What qualifies as urgent is up to the application developer. To tell the TCP receiver where the urgent data is, another field in the TCP header known as the Urgent Pointer indicates where in the bitstream the urgent data starts.

The ACK bit is set every time a packet acknowledges the receipt of data from a remote sender. TCP is a protocol that operates in full duplex. That is to say, that while Host A is sending data to Host B over a virtual connection, Host B can send data to Host A over the same connection. There is no need to establish a separate channel for return data. It also means that at the same time Host B sends data to Host A, it acknowledges what it has received from Host A up to that point. Under normal circumstances, for established connections, the ACK bit can be set in every packet. This is so typical that to determine the difference between a previously established connection and a new connection, a packet filtering firewall looks for the presence of an ACK bit alone or in conjunction with a SYN bit in TCP traffic to determine if it should filter the packet.

Under normal circumstances, a receiving TCP host will buffer a certain amount of data and reassemble it into application layer data before passing up to the application layer itself for use. This introduces a small amount of delay that might be noticeable in interactive applications. When the PSH bit is set, this informs the receiver to pass the information up to the application layer without first buffering it. The most common applications of the PSH bit are in the use of HTTP applications. Imagine that an entire Web page is 150K in size. As the receiving host, my Web browser could buffer the entire 150K until the transmission is complete and then display the page in its entirety. The alternative is to display the data as it arrives. From the point of view of the network, it takes the same amount of time to transmit the data in either case. From the point of view of the user, however, the second option seems to be the more responsive Web site because visual feedback is provided as the page loads on the Web browser.

If there is an error in the communications that one host cannot recover from, a packet is sent with the RST bit set. This is a notification that the connection is going to terminate — immediately. Attackers trying to determine the presence of a host, even if ICMP is disabled, can use this behavior to their advantage. By sending a packet with the ACK bit set to make it look like part of an established connection, a remote host will send an RST packet in response. From the point of view of the host sending the RST, the original packet that was part of a scan was just a packet "out of the blue." Assuming that there must be some sort of error in the connection, the host helpfully responds with the RST in hopes of alerting the scanning machine of the error condition.

Because TCP sequence numbers do not start from zero, at the initiation of every TCP connection, the sequence numbers must be synchronized. This is an indication that a new connection is being requested and the synchronization of sequence numbers occurring is signified through the SYN bit in a TCP header. Under normal circumstances, this bit will only be set twice in a TCP communication. The first SYN is set in the initial connection request packet along with the initial sequence number. The second SYN seen in the transaction is sent in reply to the first packet. This indicates that the second host is willing to accept the connection request and synchronize its own sequence numbers with the initiator.

If TCP sequence numbers started at zero, then the synchronization process would not be necessary. There is a design reason for not starting the sequence numbers at zero. Assume that Host A connects to Host B and starts transmitting data. For the sake of this example, the sequence numbers have started at zero. At some point in the connection, the socket between Host A and Host B is broken. Host A reconnects and creates a new virtual circuit to continue the data transmission and starts the sequence numbers at zero again. From some other point in the network, a few packets from the first connection show up at Host B. Because the sequence number space for the two connections overlaps, Host B has no way of knowing if the packets are from the first connection or the second connection. No matter the decision that Host B makes about the packets — to keep them or discard them — there is a significant chance of the second connection becoming corrupted.

For this reason, the sequence numbers must increment periodically to make sure that in the event of new connections, the sequence numbers between the two connections are unique. This also translates into a security mechanism. If the sequence numbers would be easy to predict, which they would be if the session started from zero, an attacker would be able to guess what window the remote host were accepting and insert packets into the stream, hijack the connection altogether, or replay previous packets in an attempt to disrupt the integrity of the transmitted data.

For the proper synchronization of sequence numbers at the start of a TCP connection, three packets are required. Host A sends a packet with the initial sequence number (ISN) and the SYN bit set, indicating that it would like the remote host to acknowledge the ISN and synchronize its own sequence numbers. The remote host, Host B, responds with a SYN of its own and its ISN. To acknowledge to Host A that its sequence numbers were properly received, Host B also sets the ACK bit. At this point, both sides now know the sequence numbers that the remote is going to use when the transfer of user data begins. One more packet is required, however. Host A sends back an ACK of its own to indicate to Host B that it has received the SYN from Host B. This TCP connection setup process is known as the "three-way handshake."

The final control bit, aptly named the FIN bit, is used by hosts to indicate that they are ready to take down an established TCP connection. While a three-way handshake is used to set up TCP connections, two, two-packet exchanges are used to take down the connection. Host A will send Host B a packet with the FIN bit set, indicating that it is ready to tear down the connection. Host B will respond with an ACK of the FIN. Because TCP is a full-duplex connection, Host B may still have data to transmit. To indicate that Host B is finished sending data, Host B will send its own FIN packet and receive the ACK packet from Host A to finally tear down the connection.

3.2.7.2 TCP Operation.

We examine a typical TCP connection below; but after our discussion of the control bits of the TCP header, you might start to get the idea that, under normal circumstances, there are only certain combinations of controls bits that should ever be set at any point in time. For example, it really only makes sense for the SYN bit to be seen either alone or with the ACK bit as part of a TCP connection setup. It would be atypical to see the SYN and FIN bit together, however. The earlier programmers of TCP/IP applications took logical control bit combinations into account. Often, the TCP process was programmed only to understand what to do when the obvious logical combinations were presented to it. Attackers took advantage of this type of programming to create a number of threats that exploit the TCP stack. By creating packets that contained control bit combinations that do not make sense, attackers soon realized that a number of TCP stacks on various operating systems could be crashed. Two of the most well-known variations are the "Christmas tree" packet and the null-packet. In the Christmas tree packet, all the control bits are set at the same time. This would typically end up crashing the host recipient of such a packet, as it simply does not have a place in normal TCP communications. The null-packet, on the other hand, has none of the control bits set. This is just as surprising to a receiving host as careful examination of the data exchange process shows that, at the very least, either the SYN or ACK bit is normally set.

All of these combinations have been tried, crashed a lot of systems, and then patched. While we hope that current protocol programmers will account for non-valid data as much as they do valid data, it is helpful to know that a crucial element of overall network security is the secure development of applications. Sadly, constant examples of new attacks using malformed packets show that the overall network community is still learning that all data must be checked before being processed.

To control the amount of data sent between hosts at any given time, the window field is used. This is a 16-bit field that indicates how many octets the sender of the packet is willing to accept. Through this mechanism, a slower TCP host can establish some sort of flow control with a faster TCP host. The size of the window is related to the buffer space that the receiver of the TCP segments has available. With each ACK that a host transmits during a connection, the window size will be set in a packet that indicates how much buffer space in octets of data is available. The host that is transmitting data, upon receipt of the information in the window field, then knows how much to send before it expects an ACK for the information. This amount of information may represent a single packet's worth of data or multiple packets of data.

The proper behavior of the TCP, based on the information in the window field, is crucial to the scaling and performance of TCP on the Internet and in your own networks. Because TCP is connection oriented, when data is lost, it must be retransmitted. Data in a TCP connection can be lost in one of two places: it is lost in the network, or the receiver has run out of sufficient buffer space to hold the packets. Either case will result in resending the TCP data that was lost. If the sending host does not honor the window size information, then packets may be continually dropped as the remote host constantly fills up its buffers and is forced to discard packets. These packets end up being retransmitted and contribute to further congestion in the network.

The window field is also used to slow down a TCP host when packets are successfully transmitted and make sure that packets transmitted are not dropped. If packets are lost in the network, the sending host will assume that the network was congested and reduce the window size, effectively reducing the amount of information that is sent at one time.

The relationship between the window size and TCP behavior during network congestion has a couple of interesting ramifications. The first is that certain programmers have created TCP stacks that behave just the opposite of normal TCP when congestion (packet loss) occurs. Because these programmers know that if there is network congestion, everyone else's TCP connections will automatically slow down, they create their stack to speed up, thus taking advantage of the newly freed up bandwidth (to the detriment of all other network users). While an interesting application of TCP behavior, other ways of exploiting normal TCP behavior are more damaging to your network.

The flow control that TCP exerts on its own connections makes it a well-behaved protocol. Other protocols, such as UDP (User Datagram Protocol) and ICMP, have no concept of flow control. If packets are lost in a UDP stream, there is not even a mechanism for either the sending or the receiving host to notice the loss. Well-behaved traffic like TCP can be muscled off a network by protocols such as UDP. As the network traffic increases, the TCP application slows down and UDP will fill in the remaining bandwidth. This is one reason that UDP and ICMP are popular protocols to utilize in network bandwidth-based denial-of-service attacks. The only real way to prevent this from occurring is to artificially flow control UDP and other connectionless traffic through the use of network QoS (quality-of-service) mechanisms. In this case, proper network design and quality of service become effective countermeasures for the risk of denial-of-service.

Similar to IP, TCP makes use of a one's complement checksum algorithm. Unlike IP, the TCP checksum is based on the information in the TCP header itself and the "pseudo header." The pseudo header includes the source and destination IP address from the IP field, the protocol type field, and the TCP header and data length. The inclusion of the pseudo header in the checksum helps prevent the inclusion of misrouted segments as part of a valid TCP connection.

TCP has the ability to include options. Unlike IP, TCP options are more commonly used. Some of the most common options are discussed below.

The most often seen TCP option is the selective-acknowledgement. It would be an inefficient use of network resources if a receiving host sent back an ACK packet for every single TCP packet it received. It would be inefficient from the sending hosts perspective because for each packet that was sent, it would have to wait for the packet to get to the remote host and for an ACK to be sent back. On a network that operated at high speeds or one with latency due to the distances involved — or both, this wasted time would add up to a considerable decrease in the overall transmission of data. Instead, the sending host will send a number of TCP segments up to the advertised window size and then wait for an ACK for the last packet that was sent. Remember that the receiver of these segments is counting the octets of data that it receives and only needs to send an ACK for the next sequence number that it expects, implicitly acknowledging the receipt of all data up to that point.

In the event of a network error, one or more packets of the series that was sent to the host may be lost. Normal operation of TCP is to resend all segments starting with the last one the receiver acknowledges receiving. If the third out of eight packets is the only one to be lost, this would mean that the third, fourth, fifth, sixth, seventh, and eighth packets would be resent. Clearly, this is a waste of network resources. The selective-acknowledgment (SACK) option allows the two hosts to specifically communicate which segments were lost and only resend those segments.

The maximum segment size (MSS) is used to indicate to the remote host what the MTU for the data should be. This is determined through the use of IP don't fragment bits in the initial packets to the remote host. Preventing the fragmentation of packets by sending data that is properly sized to the data-link layer improves overall network performance and security of the network, as discussed in Chapter 3.2.1.

TCP was a protocol developed for fairly low-speed networks with high delays. The overall performance of TCP is not based simply upon the bandwidth of the link. Because TCP is connection oriented and expects acknowledgment of the data that has been sent, the performance of TCP is related to both the bandwidth of the network, the end-to-end delay of the network, and the number of packets lost during a TCP transmission. Impacting any one of these will affect the overall performance of the TCP session. To understand this, remember that the maximum window size of a TCP segment is only 64 KB. This means that the most data that can be sent at any time is only 64 KB before an ACK is required.

Modern networks can be high-bandwidth in the case of fiber-optic and gigabit networks, and high-delay as in the case of satellite network connections. In the case of a high-bandwidth cross-country link with 30 ms of delay, 64 KB of data can be sent in multiple packets in much less than 30 ms. For the remainder of the 30 ms for the sent data to arrive and the 30 ms required for the ACK to return, the sender is idle. From the point of view of the user, the expensive high-speed link they are paying for is not operating at full capacity.

Instead of trashing TCP however, two options appeared that allow TCP to take advantage of higher-speed networks. The first of these options is the window scale option. This allows the window size to be increased beyond 64 KB by indicating in the options field a "multiplier" of the header window field that can be used to communicate the true window size.

The second option is the use of the Timestamp option. Normally, TCP will wait around for as much as 120 s before determining that a packet it is expecting to arrive has been lost in the network. This is because during the early years of TCP, there was not a mechanism available that could be used to accurately compute the mean round-trip time of a packet. The round-trip time is the average time that it would take a packet to travel to a remote host and the response to find its way back to the original sender. On high-speed networks, 120 s is far too much time, yet TCP still has a need to estimate how long it should wait before declaring an expected packet missing in action. The inclusion of a timestamp in the TCP options field allows for communicating TCP hosts to accurately estimate how long the average round-trip time for their particular connection is and thus timeout and retransmit missing packets more rapidly.

3.2.7.3 TCP Vulnerabilities.

The preceding discussion was a brief introduction into the operation of TCP, yet there is much more to know. From the security point of view, the major points have been hit. Next, we examine the operation of the protocol in its entirety. This will provide a complete context in which to place the earlier TCP discussion. Once again, our hypothetical Host A and Host B will create a TCP connection, share a small amount of data, and then tear down the connection. Exhibit 14 shows this transaction in process. The previous discussion and illustration suggest one more way to take advantage of normal TCP behavior to exploit remote systems. If we assume that Host A is a client and Host B is a server, we see that the server commits some of its resources to maintain its side of the connection before the connection itself is fully established. Imagine now that the remote client sends a dozen connection requests and the server responds to each of these connection requests with a SYN ACK and a small commitment of resources while the server waits for the final ACK from the client. If the server does not receive the final ACK from the client immediately, there is no way for the server to know if the ACK packet from the client has been lost or delayed in transit or if the client is simply not going to respond. With no way to know, the server is committed to wait a standard time out period for the packet. At this point, the server TCP connections are said to be in a "half-open" state.

Exhibit 14: TCP Three-Way Handshake

start example

click to expand

end example

For a dozen connections, the effects on the server are insignificant. If the client or a group of clients coordinating an attack were to increase the number of connections requests to hundreds or thousands per minute, then the server could conceivably use up all of its resources on half-open connections. This is the trademark characteristic of a SYN attack, a form of denial-of-service attack.

Unless the attacks are coming from a single source, it is generally not possible to simply filter SYN packets as this would prevent legitimate traffic from connection — in effect causing the same behavior as the denial-of-service we were trying to avoid. In this case, the vulnerability is that the normal behavior of TCP is to wait a certain period of time for the final connection request. To solve this, the behavior of TCP needs to be altered. While it is possible to do this on a per-server basis, it is generally much more efficient to do this on a firewall. Typically known as SYN filtering, TCP intercept, or some similar sounding term, a firewall will intercept incoming TCP connections and reply to the connection on behalf of the servers. When the final client ACK arrives back at the firewall, the firewall will then forward the connection request to the appropriate server.

The advantage to this approach is that the TCP timeouts can be greatly reduced. Therefore, bogus connection requests are detected and dropped at a faster rate. This same firewall functionality can also dynamically adjust the TCP timeout period based on the number of incoming connection requests. This means that during normal circumstances, the TCP connection timeouts are quite generous. As the traffic increases, for example during a SYN attack, the connection wait period will decrease to compensate for the increased traffic. Another advantage to performing SYN filtering on a single device such as a router is that network administrators can avoid needing to adjust TCP variables on individual hosts.

3.2.7.4 TCP Sliding Windows.

TCP is a complicated layer of the networking model. It needs to provide flow control and error checking over links of an unpredictable nature between parties of unknown capabilities. To do this, TCP employs a number of congestion avoidance and flow control algorithms. One mechanism that is particularly noteworthy in terms of security is that of the sliding window. While the sliding window is primarily a flow control technique, understanding it will also make security discussions clearer. Between two TCP hosts, information is sent within the packet that indicates the allowable window size. At the same time, acknowledgments are sent indicating the highest octet of data that has been received. If Host A sends a window of 1000 octets to Host B and acknowledges sequence number 100,000, then it stands to reason that any data that Host B sends back to Host A should be in the range of 100,001 to 101,000. If Host A should receive anything outside this window, then there has either been a problem on the network, the sending host, or someone is trying to send information to Host A, making it look like it came from Host B but they guessed wrong.

3.2.8 The User Datagram Protocol (UDP)

Compared to the TCP header, the User Datagram Protocol (UDP) is much more straightforward. As can be seen from the protocol header itself (Exhibit 15), UDP provides only the basics required by a remote host to associate a packet with a connection. The source and destination port of UDP operate in exactly the same fashion as the TCP. When reviewing the assigned numbers, you will notice that for many of the well-known TCP ports, there is a corresponding UDP port.

Exhibit 15: User Datagram Protocol Header Format

start example

click to expand

end example

The one small exception to the UDP port fields is that because UDP is connectionless, there may not be a reply expected to a stream of data. The standards themselves allow the setting of the source port in UDP to be zero. In practice, UDP commonly expects some sort of reply to the packets that it sends and so the source port is set to facilitate return traffic.

The length field is simply an indicator of the overall length of the user datagram, including the UDP header, and is used in the same manner as the TCP length field. Likewise, the checksum is the same as the TCP header in that covers the pseudo header of the IP field, the UDP header itself, and the data.

What stands out the most about the UDP header is what it does not contain. There are no control fields, sequence numbers, acknowledgements, or windowing. UDP does not have the ability to keep track of the data that has been sent or received. If this function is important to the data that UDP is transporting, then the application layer itself must make provisions for the accounting of data. Furthermore, UDP has no concept of flow control. Because senders and receivers do not know when data has been lost, it continues to transmit at a given rate regardless of the network conditions. As with the accounting for data, if flow control is required as it commonly is in VPN or VoIP connections, the application layer must establish a method of providing this for the data.

3.2.8.1 UDP Security Concerns.

The lack of a built-in flow control mechanism in a UDP stream means that it is also an effective denial of service tool capable of easily using up all the available network bandwidth. In the design of networks or access-links, it would not be uncommon to restrict the amount of UDP data that can utilize network bandwidth to prevent just this use of UDP. These types of attacks can be reduced in severity through the use of bandwidth throttling. This technique is also known as creating a committed access rate. Essentially, a router or other firewall device is configured to only allow a certain amount of a particular traffic type through over a period of time. For example, a 1.544-Mbps T-1 line could be configured to never allow more than 128 Kbps of ICMP traffic and 512 Kbps of UDP traffic.

The type of bandwidth flooding that UDP packets are capable of is most likely to affect the fairly low bandwidth WAN links. Unfortunately, the most accessible place for most companies to configure this type of filtering is on the ingress interface of the router that connects to their upstream ISP. This means that the traffic leaving the ISP router interface is congesting the ISP router WAN interface to the customer. Filtering this traffic overload on the customer router does little to alleviate the denial-of-service. To be effective, committed access rates must be configured on the ISP routers before the traffic is sent down the low-bandwidth WAN link to the customer site. How likely this is to happen is solely a factor of how easy it is to work with your ISP. Will the ISP configure these for you prior to activating the link to protect you from the beginning? If you decide to apply this filtering during an attack, how easy is it for you to get in touch with the engineers who can actually apply these filters? If these bandwidth starvation attacks are a consideration for your company during the risk analysis phase, it is essential to determine the answer to these questions prior to implementing the security policy.

[4]IPv5 was never released as a production protocol. It was developed for a real-time stream protocol that was never widely adopted.

[5]That is 3.4 followed by 68 zeros.

[6]To improve performance, many routers will cache routes or use some sort of "express forwarding" mechanism that allows packets to bypass the normal software-based routing table and use an interface-based forwarding table. This is not the same as keeping count of individual packets, however.

[7]While IP addresses are represented in decimal for human consumption, MAC addresses are traditionally represented in hexadecimal. Thus, each character of a MAC address represents four binary bits.

[8]In NAT terms, a pool can be a range of public IP addresses, or a single IP address.

[9]While Cisco sometimes markets EIGRP as a routing protocol with link state characteristics, it is fundamentally a distance vector routing protocol. For those still skeptical, I offer the following exercise: create a small test network using EIGRP and OSPF. Attempt to filter outbound route updates within your autonomous system (EIGRP) or area (OSPF) as appropriate. Note your findings.

[10]We will discuss hashing in a bit. For now, consider it a form of one-way encryption.

[11]In theory, the ports are random. In practice, some vendors increment the sequence numbers by one for each new connection. So the first source port for packets will be 1024, the second 1025, etc.




Network Perimeter Security. Building Defense In-Depth
Network Perimeter Security: Building Defense In-Depth
ISBN: 0849316286
EAN: 2147483647
Year: 2004
Pages: 119
Authors: Cliff Riggs

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net