Ixia BreakingPoint and IxLoad-Attack: Two Sides to the Same Story

June 6, 2014 by Ixia Blog Team

After Ixia acquired BreakingPoint Systems in 2012 there was a lot of excitement, especially within Ixia’s security products engineering, since it introduced us to new ways of thinking about application and security testing. But, we also needed to figure out how best to merge together common endeavors such as strikes and application flow development to best serve both the BreakingPoint solutions and the Ixia products we already had.

One of these common endeavors is strike development. We needed to integrate strikes both in the Ixia BreakingPoint Security Engine (BPS) as well as in IxLoad-Attack Published Vulnerability and Malware (PVM).

These two engines, while similar in their end goal of emulating malicious traffic on the network, have two different approaches when it comes down to defining the contents of a strike. The BPS uses the bottom-up approach of manually constructing strike payload using a wide range of available data blocks and arranging them in a tree-like manner. PVM uses an advanced packet replay engine and thus the strike payload is defined by packet captures.

Both ways walk a fine line between flexibility and scalability when it comes down to strike development. While the BPS approach is very flexible and allows us to introduce a lot of randomness and obfuscation into strikes, it generally scales a bit less when it comes down to strike numbers. On the other side, PVM can easily scale with regards to strike numbers since you just need an existing packet capture to define the payload of a strike — but the tradeoff in this case is flexibility since the payloads of a strike are generally fixed.

Porting Strikes Between Engines

Typically, porting strikes from the BPS engine to PVM is somewhat straightforward since you can just generate a packet capture and then add it as a PVM strike definition. Ixia has used this same process since the BreakingPoint acquisition to feed a lot of new strikes into PVM updates.

But what about the other way around? What about porting strikes from PVM to BPS? Well, this gets tricky from an engineering perspective if you want an automatic way of porting them since you need to analyze the packet capture file, extract the payload, and then send it through the BPS engine.

We like tricky problems in engineering so recently added support in the BreakingPoint Security Engine for analyzing packet captures and extracting, modifying, and sending the payloads found within them.

This analysis is done on the transport-level payload so everything below it is regenerated when you run the strike, so it is based on the network neighborhood configuration/network evasions. Based on the type of application traffic, we can also randomize certain parts of the payload (e.g. HTTP headers), but this typically involves a bit of human intervention since we don’t want to mess up the actual malicious part of the payload.

Striking the Right Balance

So why all this fuss around packet replay all of a sudden? Well, as you can probably guess by now, we’ve begun porting strikes from PVM that we didn’t have in BPS. This means that, along with the normal strike feed, there will also be some extra strikes classified as being ported from the Ixia PVM engine. We’ve also created a special strike list called “Ixia Ported Strikes” that customers can use to easily identify these strikes. The pool of strikes we can port is pretty large, so their numbers should increase with each Strikepack we release.

When evaluating IPS/IDS equipment you want it to be able to detect complex attacks with randomized payload, but you also want it to detect a wide range of attacks. Balancing between the two can be difficult from a device vendor perspective because as you add more strike signatures, the performance of the detection engine gradually slows down. The device vendor can alleviate the problem by either adding more processing power to the equipment, thus driving up its price, or simplifying the detection engine, which limits its ability to detect complex strikes. It’s a constant tug-of-war between these factors and finding the right match can be really hard. By leveraging the BPS and PVM technologies, Ixia customers have the ultimate toolset to “strike” the right balance.

Leverage Subscription Service to Stay Ahead of Attacks

The Ixia BreakingPoint Application and Threat Intelligence (ATI) program provides bi-weekly updates of the latest application protocols and attacks for use with Ixia platforms.

Additional Resources:

View Ixia’s Full ATI Protocol List