Token Substitution in the BreakingPoint Storm CTM
by Mike Hamiltonby Mike Hamilton
When I was a kid growing up, Putt Putt was the place to be. Miniature golf, bumper boats, go-carts, and arcade games could all be had at one location. In order to play the arcade games, though, you had to have special tokens. Regular coins simply didn’t work. Well, today I want to write about a specific type of token in the BreakingPoint CTM product line and how to use it to achieve a very specific goal.
First, a little background on what we call ‘token substitution.’ In an effort to provide our customers with every available avenue to achieve the most realistic simulations possible, we began adding what we call tokens to our device starting with firmware release 1.4. These tokens are special identifiers that may be placed in Super Flows, where they get replaced by very specific data patterns in real time during a simulation run. Each of these tokens is subject to various types of random seeding, which allows for either completely randomized data, or pseudo-random data.
This functionality is great because it's so straightforward to implement, yet highly useful for various tasks including Hypertext Transfer Protocol (HTTP) URL filtering, Domain Name System (DNS) resolution validation, and keyword identification. The token that I’ll be focusing on in this post is the ‘flow_dict’ token, which is substituted with data from a dictionary of words that a user can upload to the BreakingPoint Storm CTM.
The Problem
Let me set the stage with the problem that a customer recently asked me about. What this particular customer was trying to do was send multiple HTTP GET requests via our Application Simulator component. This is easy to do in a generic way with any BreakingPoint CTM, but our customer wanted a very specific pattern within the Uniform Resource Identifier (URI) fields. For his purposes, the URI had to be the same between two different HTTP GET actions within each application transaction. To put it another way, what he was really looking for was multiple URIs with an incrementing pattern like this:
Index.php?iterator=1 and MyPage.php?iterator=1
Index.php?iterator=2 and MyPage.php?iterator=2
Index.php?iterator=3 and MyPage.php?iterator=3
There were a couple of other requirements. He needed 2500 unique pairs of URIs, and they needed to cycle through regardless of how many transactions were happening simultaneously.
Index.php?iterator=1 and MyPage.php?iterator=1
Index.php?iterator=2 and MyPage.php?iterator=2
Index.php?iterator=3 and MyPage.php?iterator=3
. . .
. . .
. . .
Index.php?iterator=2499 and MyPage.php?iterator=2499
Index.php?iterator=2500 and MyPage.php?iterator=2500
Index.php?iterator=1 and MyPage.php?iterator=1
I realized that our token substitution functionality would be a perfect fit for doing this. Even better, I wanted to go above and beyond and not necessarily restrict him to using only numbers. Perhaps he even wanted to progress through the alphabet. Thus, I decided to use our new dictionary functionality, which we provided to all of our existing customers in our recent 2.1 firmware release.
Implementation
The first step in executing this is to decide what pattern I want to use. For this example, I’ll still use incrementing numbers for the sake of simplicity. My next step is to create a “Flow Dictionary,” which is a fancy way of saying “a simple text file.” Here is what my version looks like.
You’ll see that I’ve created a simple iterator that counts from 1 to 16. (This could easily be expanded to many more than 16.) Once I’ve created my iterator list, I must define my flow dictionary within my Super Flow. In the screenshot below, you’ll notice that my dictionary ID is set to ‘0’. This is important because you can have multiple flow dictionaries per Super Flow. You’ll see this value again in a few minutes.
The delimiter is set to a new line, which matches the text file shown previously. You could also choose to use a custom delimiter, which can be specified from this screen. The last configuration parameter is the flow dictionary, which you can upload from this screen as well. I’ve selected my iterator.txt file.
Now that I’ve defined my flow dictionary, I can create my HTTP GET requests using the pattern I showed earlier. Here’s what that looks like:
You’ll notice a few things from this screenshot. I’m using the dict_flow token, which takes a handful of different parameters. The first parameter is what we call the seed. In this case, “seed_sequential_superflow” means that, within this Super Flow, the same value will be used, but will iterate through the flow dictionary sequentially. This is what we want based on the customer’s request. The second parameter is the flow dictionary, in this case ‘0’. This was the same number that we specified in our “Add Flow Dictionary” action. So now our first HTTP GET action is configured with the appropriate URI.
After we configure that initial HTTP GET, we configure the subsequent HTTP GET actions that we want, as shown in this image:
Here’s one more screenshot of the actual token after scrolling over in the text box, which shows you the ‘0’ parameter is entered:
Now that we have created our Super Flow, we can simply use it as we run a simulation. In order to verify that our pattern works, let’s take a look at the packet capture (PCAP) that this particular Super Flow generated:
You can see from the Wireshark PCAP that our two URLs within each flow use the same iterator number, while incrementally iterating through the flow dictionary that we built in our text file. Success! (If I were back at Putt Putt, this would be the moment when I won the big stuffed bear.)
As I mentioned previously, this functionality has many different applications including URL filtering, DNS resolution validation, and even keyword identification. For example, to use this for DNS resolution, you would simply create a library of hostnames that you would want to validate against. Using the ##flow_dict## token within the DNS query action, you could point our device at a live DNS server to verify correct functionality. For URL filtering, you could simply load in a list of URLs that you want to query, then use some basic configurations to validate URL filtering devices or even HTTP servers.
This new incremental iterator seed, seed_sequential_superflow is available in the 2.1 Technical Release 3 firmware, which is available to our customers via the BreakingPoint StrikeCenter. If you have questions or comments about this feature, please share them in the comments field.
