Detecting and Blocking Network Attacks at Ultra High Speeds
Stateful, in-depth, in-line traffic analysis for intrusion detection and prevention has grown increasingly more difficult as the data rates of modern networks rise. One point in the design space for high-performance network analysis - pursued by a number of commercial products - is the use of sophisticated custom hardware. For very high-speed processing, such systems often cast the entire analysis process in ASICs. This project pursued a different architectural approach, which we term Shunting. Shunting marries a conceptually quite simple hardware device with an Intrusion Prevention System (IPS) running on commodity PC hardware. The overall design goal is was to keep the hardware both cheap and readily scalable to future higher speeds, yet also retain the unparalleled flexibility that running the main IPS analysis in a full general-computing environment provides. The Shunting architecture we developed uses a simple in-line hardware element that maintains several large state tables indexed by packet header fields, including IP/TCP flags, source and destination IP addresses, and connection tuples. The tables yield decision values the element makes on a packet-by-packet basis: forward the packet, drop it, or divert ('shunt') it through the IPS (the default). By manipulating table entries, the IPS can, on a fine-grained basis: (i) specify the traffic it wishes to examine, (ii) directly block malicious traffic, and (iii) 'cut through' traffic streams once it has had an opportunity to 'vet' them, or (iv) skip over large items within a stream before proceeding to further analyze it. For the Shunting architecture to yield benefits, it needs to operate in an environment for which the monitored network traffic has the property that - after proper vetting - much of it can be safely skipped. This property does not universally hold. For example, if a bank needs to examine all Web traffic involving its servers for regulatory compliance, then a monitor in front of one of the bank's server farms cannot safely omit a subset of the traffic from analysis. In this environment, Shunting cannot realize its main performance benefits, and the monitoring task likely calls for using custom hardware instead. However, in many other environments we find Shunting holds promise for delivering major performance gains. This arises due to the the widely documented 'heavy tail' nature of most forms of network traffic, which we might express as 'a few of the connections carry just about all the bytes.' The key additional insight is '... and very often for these few large connections, the very beginning of the connection contains nearly all the information of interest from a security analysis perspective.' We argue that this second claim holds because it is at the beginning of connections that authentication exchanges occur, data or file names and types are specified, request and reply status codes conveyed, and encryption is negotiated. Once these occur, we have seen most of the interesting facets of the dialog. Certainly the remainder of the connection might also yield some grist for analysis, but this is generally less likely, and thus if we want to lower analysis load at as small a loss as possible of information relevant to security analysis, we might best do so by skipping the bulk of large connections. In a different context, the 'Time Machine' work by Kornexl and colleagues likewise shows that in some environments we can realize major reductions in the volume of network traffic processed, by limiting the processing to the first 10-20 KB of each connection. As a concrete example, consider an IPS that monitors SSH traffic. When a new SSH connection arrives and the Shunt fails to find an entry for it in any of its tables (per-address, per-port, per-connection), it executes the default action of diverting the connection through the IPS. The IPS analyzes the beginning of the connection in this fashion. As long as it is satisified with the dialog, it reinjects the packets forwarded to it so that the connection can continue. If the connection successfully negotiates encryption, the IPS can no longer profitably analyze it, so it downloads a per-connection table entry to the Shunt specifying that the action for the connection in the future is 'forward.' For heavy-tailed connections, this means a very large majority of the connection's packets will now pass through the Shunt device without burdening the IPS with any further analysis load. On the other hand, if the IPS is dissatisfied with some element of the initial dialog, it downloads a 'drop' entry to terminate the connection. Note that by providing for reinjection, we can promote an intrusion detection system into an intrusion prevention system, one that does not merely detect attacks but can block them before they complete. Reinjection also allows the IPS to normalize traffic to remove ambiguities that attackers can leverage to evade the IPS.
- Research Organization:
- International Computer Science Institute
- Sponsoring Organization:
- USDOE
- DOE Contract Number:
- FG02-04ER25638
- OSTI ID:
- 993443
- Report Number(s):
- DOE-ER25638- Final Report; TRN: US201110%%270
- Country of Publication:
- United States
- Language:
- English
Similar Records
Bro Intrusion Detection System
Charliecloud