Network traffic surgery - Or: How to remove bad traffic with fine-grained signatures

One of the problems that many organizations have when being faced with network anomalies, such as DDoS attacks and worm outbreaks, is the fact that it is hard to remove the traffic from their network, while keeping the business running.

It is quite astonishing to me how many vendors of security solutions are touting their products with claims about anomaly detection and filtering capabilities. At the same time, though, their wares are woefully ill equipped to actually provide the kind of insight into the anomaly traffic that is required to really allow for the surgical removal of that traffic. For the most part, any filters those solutions can implement or suggest represent a broad ax when really a fine scalpel is called for.

Let's consider an example: An e-commerce web-site is under a TCP-Syn attack on port 80.  So, what traffic should be removed now? The traffic to the web-site (identified by IP address and/or port)? The service provider may think so, since this would keep their network operational. However, the owner of the attacked site clearly has different priorities.

Should all TCP-Syn packets to that site's IP address and port be filtered out? This would not be ideal either, since any new, legitimate connection to the site would be prevented.

Now, we have to keep in mind that many of the solutions out there in the market, who claim to protect against zero-day anomalies by means of behavioral anomaly detection, only provide such impractically broad filters. Let us examine why this is the case.

Most of the solutions are based on the processing of flow records, such as Cisco's Netflow, for example. There is no doubt that flows are useful for many things. However, one thing they are terribly inadequate for is as a source of information to provide truly fine-grained filter suggestions and signatures for network anomalies.

A flow, we need to remember, is a summary record about a connection (actually only about one direction of a connection) between two hosts. So, it contains information as to when the connection started, when it stopped, which IP addresses where involved, which protocol and port, as well as byte and packet counts. Once the connection is closed, or timed out, the flow-generating device, typically routers, will pack the flow into a packet, along with a couple of other flows, and send it to a registered flow consumer. The flow consumer typically is a server, which receives the flow records and performs some processing on them.

Many network behavioral anomaly detection (NBAD) solutions are based on flows. We can see, though, that the NBAD server is quite far removed from the actual anomalous traffic. It only receives an abstraction, or summary, of what really happened on the wire. It has no insight into the actual traffic. It has no means to collect packet samples. Thus, all it can base it's 'filter' suggestions on is the information contained in the flow records.

Well, and that information only allows for IP addresses, ports and protocols. Sometimes some flag information can be gleaned from the record as well, but as we have seen, that does not help much.

So, assume then that e-commerce site www.mybigbusiness.com has invested in such a flow-based NBAD solution. Now they are under the TCP-Syn attack we have mentioned earlier. They look to their shiny, new security product for help, and what do they see?  They see a recommendation like this:

        You are under TCP-Syn attack.
        Filter all TCP-Syn packets to www.mybigbusiness.com on port 80.

If they were to follow that recommendation, My-Big-Business would be out of business in a hurry.

Clearly, something better is needed.

I contend that flow-based analysis of network anomalies only gets you a part of the solution. Much more insight into the actual traffic is needed. That's why we here at Esphion are big advocates of packet-based NBAD.

In a packet-based approach, you don't rely on third-party summary information, such as flow records, but look at the actual culprit, the actual offending packets, directly and immediately. A packet-based NBAD solution therefore will sit right there where it matters: In the network, listening to the traffic on a spanning port or even via a network tap.

So, what can we see if we do that? We can see any characteristics, which further identifies and differentiates the offending packets from the legitimate packets. Essentially it goes like this:

1. We know that there is an anomaly (we have specialized neural networks that can detect those very nicely).
2. We know how many bad packets we currently see per second.
3. We take a sample of the actual traffic (in the case of the Syn flood, we would take a sample of all TCP Syn packets to www.mybigbusiness.com).
4. We then run those special algorithms over that sample, in order to find a fine-grained signature, which takes into account all the information that is contained in the packets.

I don't need to go into all the details here, but it suffices to say that with that approach, we get signatures which contain much more detail than just the IP addresses, ports and protocols. We may see something like:

        You are under TCP-Syn attack.
        Filter all TCP packets with the following characteristics:
            - TCP-destination port: 80
            - TCP-flags: SYN
            - Destination address: www.mybigbusiness.com
            - Window size: 16000
            - Sequence number: 12345678

We can see here that items such as the window-size and the sequence-number have been identified. In this particular case, the attack tool generated packets which had those things in common. Using modern IPSs and even some firewalls, filtering on such fine-grained information is possible.

This information then allows for the truly surgical removal of offending traffic. If filters based on those recommendations were implemented, the vast majority of legitimate traffic would be able to pass through completely uninhibited.

It should be noted that the usefulness of this is not only limited to DDoS attacks. Worms are particularly interesting as well. For example, the SQL/Slammer worm, which propagated on UDP port 1434. A business who needs this service for operation will not just be able to block all traffic on that port. Our packet-based NBAD solution, however, did not only identify the port and protocol, but also the packet length as a very distinct characteristic of that traffic. Filtering on packet length is possible even with many routers, so this information can be put to practical use immediately by many organizations.

The key is, though, that a flow-based solution will never be able to provide this level of detail and accuracy, only a packet-based NBAD solution can do this.

Juergen Brendel
CTO
www.esphion.com