Detecting a network attack

BACKGROUND

[0001] Communicating over a network involves a wide variety of tasks. Typically, these tasks are grouped into different layers of network operations. Briefly, the lowest layer, known as the physical layer, handles, among other things, tasks involved in the reception of signals over a connection and the translation of these signals into digital bits (e.g., 1-s and 0-s). Above the physical layer, the “link layer” can group the bits into a logical organization known as a frame. A frame often includes flags (e.g., start and end of frame flags), a frame checksum that enables a receiver to determine whether transmission errors occurred, and so forth

[0002] A frame may also store one or more packets. By analogy, a packet is much like a mailed letter. That is, the letter being mailed is like a packet's payload while the mailing and return addresses are like source and destination addresses stored in a packet's header. The “network layer” can use data in a packet's header to find a route through a network that connects a sender and receiver. Since a message may be spread across many different packets that independently travel across a network, the “transport layer” can reorder and reassemble transmitted data into its original form.

[0003] Together, the different layers form a “protocol stack”. A device may select from a wide variety of protocols operating in the different stack layers. For example, many computers on the Internet use a stack known as the Transport Control Protocol/Internet Protocol (TCP/IP) protocol stack that features TCP as the transport layer protocol and IP as the network layer protocol.

[0004] To connect to a network, devices often use a network adapter. A network adapter often includes physical layer and link layer components. In many systems, network operations are divided between the adapter and host. For example, in many systems, when the adapter identifies a received packet, the adapter transfers the packet to a host (e.g., memory of a personal computer) and alerts the host to the packet's arrival. The host often includes software to continue processing the packet in accordance with network and transport layer protocols.

BRIEF DESCRIPTION OF THE DRAWINGS

[0005]FIG. 1 is a diagram of a device to detect denial of service attacks.

[0006] FIGS. <b>2</b>-<b>4</b> are flowcharts of processes for detecting denial of service attacks.

[0007] FIGS. <b>5</b>-<b>6</b> are diagrams illustrating operation of a remote server notified of attacks.

[0008]FIG. 7 is a flowchart illustrating operation of the remote server.

[0009]FIG. 8 is a diagram of a network adapter including logic for detecting denial of service attacks.

DETAILED DESCRIPTION

[0010] Network devices may be subjected to a variety of attacks that attempt to disrupt normal network operation. For example, denial of service (DoS) attacks attempt to reduce a network's ability to process valid network traffic by introducing “forged” network traffic. These forged packets have a variety of different tell-tale characteristics. For example, some attacks include erroneous source addresses chosen to cause predictable, though unfortunate, responses by a receiver. FIG. 1 depicts a system <b>100</b> that can detect and, potentially, thwart such attacks. The system <b>100</b> may be, for example, a configured personal computer (PC), laptop computer, network switch or router, wireless device, or network appliance. The system <b>100</b> shown connects to a network via a network adapter <b>102</b> (e.g., a network interface card (NIC)) that includes logic <b>104</b> to detect and, potentially, react to network attacks. In addition to detecting attacks, the adapter <b>102</b> can potentially conserve host resources <b>106</b>, <b>108</b> by halting processing of the packet before the packet is processed by the network and/or transport layers of the protocol stack.

[0011] To illustrate examples of logic <b>104</b> operation, FIGS. <b>2</b>-<b>4</b> depict techniques for detecting a variety of denial of service attacks based on characteristics of packets involved in such attacks.

[0012]FIG. 2 illustrates logic that the network adapter <b>102</b> can use to detect a LAND denial of service attack. Briefly, a LAND attack involves sending a packet to a destination with a “spoofed” source IP address that is set to the destination's IP address instead of the address of the actual packet source (i.e., the attacker's node). By analogy, this is much like sending a letter having the same return address as the addressee. The packet is also constructed to elicit a response from the receiver. For example, a LAND attack may take the form of a TCP/IP SYN packet. In TCP, when a receiver receives a SYN packet the receiver typically acknowledges its receipt. However, in the receiver's attempt to acknowledge the spoofed packet, the receiver attempts to send a message to itself. This may cause the receiver to loop indefinitely, flood itself with messages consuming memory and/or processor cycles and/or other resources, and/or otherwise crash.

[0013] To prevent a packet of a LAND attack from reaching the network (e.g., IPv4 or IPv6) and/or transport layers (e.g., TCP, User Datagram Protocol (UDP), Real-Time Transport Protocol (RTP)) of a protocol stack, the logic can parse <b>120</b> data within the packet and determine whether the packet has a source address that matches the address of the device. For example, the process can compare <b>122</b> the source and destination IP or Ethernet addresses of the packet. If equal, the packet may be dropped <b>126</b> and/or result in other responses by the logic <b>104</b> (e.g., incrementing an on-board attack counter, cause entry in a log, notification of the attack to a remote server (see FIGS. <b>5</b>-<b>7</b>), and so forth). Packets not having this characteristic of a LAND attack may be forwarded <b>124</b> for further processing, for example, by network and transport layer protocols of the protocol stack (e.g., ACK generation and traversal of a TCP finite state machine).

[0014] As another example, as shown in FIG. 3, the logic <b>104</b> may also attempt to identify “SMURF” denial of service attacks. Briefly, a SMURF attack typically involves three entities: an attacker, one or more intermediaries, and a victim. The attacker sends the intermediaries a message with a forged source address of the victim. The message is chosen to elicit a response from the intermediate receivers. For example, a SMURF attack packet may include an Internet Control Message Protocol (ICMP) echo request such as a Packet Internet Groper (PING) command. Such a message causes the intermediaries to respond by sending replies to the victim instead of the actual packet source (the attacker). The victim can quickly become overwhelmed with traffic sent by the unsuspecting intermediaries. To aggregate a large number of intermediaries, a SMURF attacker can send a packet using a broadcast destination address (e.g., an IP address of a sub-net followed by 1-s). This can cause a copy of the packet to be sent to each device on a sub-net. Thus, a single message from the attacker can cause a message to be sent to the victim from each device on a sub-net, amplifying the attack. To generate a very large number of messages, the attacker may continually send such broadcast packets to the sub-net.

[0015] To, at least partially, undermine a SMURF attack, the logic <b>104</b> may implement the process shown in FIG. 3. As shown, after parsing <b>130</b> a packet, the process determines <b>132</b> if the packet has a broadcast destination address. If so, the process can drop <b>136</b> the packet to avoid participation in a SMURF attack as an intermediate. Again, such a process may perform other operations in response to detecting this characteristic of a SMURF attack. For packets not having this characteristic, the process can forward <b>134</b> the packet for further processing, for example, by the network and/or transport layers.

[0016] Unfortunately, in addition to SMURF attacks, the process shown in FIG. 3 may also filter out legitimate broadcast packets. To increase the likelihood the logic <b>104</b> is responding to an attack instead of legitimate traffic, FIG. 4 depicts a process that permits acceptance of broadcast packets provided a limited number of such packets are received within a window of time. For example, as shown, after a timer <b>140</b> and a count <b>142</b> of the number of received broadcast packets are reset, the process increments the count <b>148</b> for each broadcast packet received <b>146</b>. If the count of broadcast packets exceeds <b>150</b> a threshold, the process can halt acceptance <b>152</b> of further broadcast packets for some period of time or until an external agent lifts the broadcast packet restriction.

[0017] The timer and threshold setting may be pre-configured or may be dynamically determined. For example, the process may decrease the threshold and/or timer setting based on a frequency of detected attacks. If the timer expires <b>154</b> before the broadcast packet count exceeds the threshold, the timer and count are again reset <b>140</b>, <b>142</b>.

[0018] While FIGS. <b>2</b> to <b>4</b> illustrate logic to combat LAND and SMURF attacks, similar techniques can detect other attacks. For example, other denial of service attacks feature broadcast source addresses. Additionally, while the example attacks described above were described in conjunction with Internet Protocol addresses, similar techniques may be used to detect attacks within other protocols such as Ethernet and a variety of multicasting protocols.

[0019] As described above, the network adapter logic <b>104</b> may detect a variety of network attacks. In addition, or as an alternative, to merely dropping the packets forming the suspected attack, the adapter may take additional or alternative counter-measures. For example, FIG. 5 depicts a remote server <b>160</b> that can receive notification <b>164</b> of attacks detected by different network adapters. The remote server <b>160</b> can, potentially, coordinate a response to the attacks. For example, after receiving notification of a SMURF attack detected in one sub-net, the server can preemptively set network adapters in other server <b>160</b> managed sub-nets to handle broadcast packets more restrictively (e.g., using the logic of FIG. 3 instead of the logic of FIG. 4). As shown in FIG. 6, the server <b>160</b> can subsequently instruct a device to restore normal packet processing.

[0020] In greater detail, as shown in FIG. 5, a device <b>162</b><i>a </i>can notify a server <b>160</b> of a detected attack. For example, the device <b>162</b><i>a </i>may send the server <b>160</b> a Remote Management Control Protocol (RMCP) formatted message used by Alert Standard Forum (ASF) enabled devices (see, e.g., Alert Standard Forum Specification, version 1.0, Jan. 17, 2001). Briefly, ASF enabled devices send RMCP messages to notify servers of a variety of system events and/or status (e.g., overheating, cover removed, and so forth). The ASF specification includes different handshake mechanisms to ensure reliable server/client communication. Additionally, the ASF scheme permits extensions to its basic set of messages. Thus, to report network attacks, a RMCP message class may be defined for network attacks with various message types defined for different types of network attacks.

[0021]FIG. 7 illustrates an example of interaction between the remote server and a device detecting an attack. As shown, after detecting <b>172</b> an attack, the device notifies <b>174</b> the remote server of the attack. Potentially, the device may re-transmit such a message if the device does not receive acknowledgement of the message within some period of time. If so configured, the device may alter <b>176</b> its operation in response to the attack. For example, the device may drop all subsequently received packets other than RMCP messages sent by the server.

[0022] After receiving <b>178</b> notification of the attack, the server can acknowledge the notification (not shown). The server may respond to the message in a variety of ways. For example, when one device detects a LAND attack, the server can anticipate attacks on other devices and remotely reconfigure devices not yet attacked. At a later time, the server can send <b>180</b> a message to the device to restore <b>182</b> operation.

[0023]FIG. 8 is a diagram of a network adapter <b>200</b> including attack detection logic <b>204</b>. As shown, the network adapter <b>200</b> includes a link layer component (e.g., an Ethernet medium access controller (MAC) or Synchronous Optical Network (SONET) framer) <b>202</b>. The adapter <b>200</b> may also include a physical layer (PHY) component to handle data transmission/reception over a physical medium (e.g., copper wire, twisted wire pair cabling, coaxial cabling, fiber optic cabling, or wireless medium). The adapter <b>200</b> shown also includes a bus interface <b>206</b>. The interface <b>206</b> can transfer packet data to host memory, for example, using direct memory access (DMA) and generate an interrupt to the host processor when packet transfer is complete. The bus interface <b>206</b>, for example, can interface to a Peripheral Component Interconnect (PCI) bus (e.g., PCI express), Universal Serial Bus (USB), or InfiniBand bus, among others.

[0024] As shown, the adapter <b>200</b> also features memory <b>208</b> to store packets as they arrive via the PHY/link layer components <b>202</b>. The attack detection logic <b>204</b> can operate on the packets as they arrive in memory. By detecting attacking packets, the adapter <b>200</b> can not only prevent behavior sought by the attack, but can also potentially conserve host memory and processing resources by stopping packet processing before transfer of the packet to the host.

[0025] The logic <b>204</b> may be implemented in a wide variety of ways. For example, the logic <b>204</b> may be implemented as hardware (e.g., an integrated circuit chip, Programmable Gate Array (PGA), Application Specific Integrated Circuit (ASIC), or a micro-controller). The logic <b>204</b> may also be implemented as software instructions for execution by an adapter <b>200</b> processor. Such instructions may be disposed on a computer readable medium such as a magnetic (e.g., hard disk, floppy disk, tape) or optical storage medium (e.g., CD ROM, DVD ROM) or other volatile or non-volatile memory device(s) (e.g., EEPROM, ROM, PROM, RAM, DRAM, SRAM, flash, firmware, etc.).

[0026] The adapter <b>200</b> may include other components. For example, the adapter may include other packet filters and/or a TCP Offload Engine (TOE) that performs TCP protocol operations on packets after their examination by the attack detection logic <b>204</b>. A TOE can further reduce the burden of network operations on a host processor. Additionally, the attacks detected and the adapter's responses may be configured, for example, by setting dip switches, jumpers, via EEPROM, host software, or other mechanisms.

[0027] Other implementations are within the scope of the following claims. For example, while discussed in terms of a TCP/IP protocol stack, the detection logic may be used in other environments (e.g., a Asynchronous Transfer Mode (ATM) protocol stack that features an ATM network layer and an ATM Adaptation Layer (AAL) transport layer. In addition to a network interface card, the network adapter may be included within other hardware (e.g., a chipset, motherboard, or PCI slot).