Topics of Interest
- Application Protocol Fuzzing
- Cloud Computing and Virtualization
- Custom Applications and Attacks
- Cyber Warfare
- Data Center Planning and Consolidation
- DDoS and Botnet Simulation
- Deep Packet Inspection
- IPTV
- IPv4/IPv6
- Layer 2-7
- Network Traffic Generation
- Performance Testing
- Security Updates
- Server Load Testing
- VoIP
- 10/40/100 GigE
Devices
Test Automation: BPS TCL!
If you are a BreakingPoint customer, you probably know that each week we release a StrikePack to update our Security and AppSim components. These updates insure that our security coverage is as up-to-date as possible and give customers quick access to the most recently developed application protocol simulations. This type of rapid release schedule requires testing to happen quickly.
Enter the BreakingPoint TCL API. Since we're building test equipment, it stands to reason that people expect (nyuk-nyuk) the availability of TCL to automate their BreakingPoint appliances (and soon, our chassis the BreakingPoint Elite). BreakingPoint provides a custom TCL shell that provides the API for controlling your devices. This shell is used as the interpreter for TCL scripts, as well as an interactive shell. The interactive mode is a great way to explore and learn the API. Customers can also read chapter 14 of the BreakingPoint UserGuide, which can be downloaded from the BreakingPoint Systems Documentation page on StrikeCenter (authentication required). The examples in this post are intended for use with appliances running the 1.2.3 BreakingPoint software release.
BreakingPoint Interactive TCL Shell
To get started, download the BreakingPoint TCL shell from the system start page. When you run it from the command line (or from a script using the -i flag), you'll get a familiar-feeling '% ' prompt. To connect to your BreakingPoint box, issue something similar to the following:
% set host bpsbox
% set username elmo
% set password elmo
% set bps [bps::connect $host $username $password]
This sequence is so common that I have wrapped it inside a script I call harness.tcl, which parses its commandline arguments, makes the initial connection, and then drops you into the interactive shell.
Once you're connected, you can take a quick look at the commands and variables available for use by issuing:
% lsort -increasing [info commands]
% lsort -increasing [info vars]
The listed commands will show usage information when you issue them without arguments, so you can just experiment and see what each of the commands accept. Many variables are defined, but the variable we care about at this point is the $bps variable, which represents the connection we have established to the BreakingPoint appliance.
The $bps object gives commands to control many aspects of the device: tests, components, application profiles, attack series, load profiles, DUTs, reports, and device management.
Running a Security Test with TCL
So let's dive in and configure a simple test with a single Security component. The basic steps are:
- Name the test
- Add a security component
- Set the test interfaces for the component
- Save and run the test
- Review the results
The code for this is pretty simple:
% set componentname security
% $bps configure -name "TCL Demo Test $componentname"
% set component [$bps createComponent $componentname tcldemo_${componentname}]
% $component setDomain server 1 default
% $component setDomain client 2 default
% $bps save -force
% $bps run
% set result [$component result]
% foreach p [$result values] { set v [$result get $p]; puts "$p == $v" }
% $bps exportReport -file TCL_Demo_Test_${componentname}_Result.pdf -format pdf
This test will use the default DUT profile of 'BreakingPoint Default,' and the default Network Neighborhood of 'BreakingPoint Switching.' If your test environment requires something different like routing, you'll need to issue the appropriate setDut and setNeighborhood commands before adding the component. The two setDomain commands set the server and client sides of the security component, and specify the default ethernet and IP addressing domains. After running the test, we display the summary results of the test. To get detail about what strikes were blocked, you need to view the report generated from the exportReport call.
The nice thing about this code is that it's general enough to run any component. You can set componentname in the first line to appsim, bitblaster, recreate, routingrobot, security, sessionsender, or stackscrambler. The list of available components can be found by issuing `$bps createComponent false false`. This will show both the canned (BreakingPoint defined) as well as custom (customer defined) components.
The automation afforded by using TCL has been invaluable in reducing the time it takes the BreakingPoint Labs team to test and deploy StrikePacks. I know it will benefit anyone that takes the time to learn it. Over the coming weeks, I'll be sharing hints and code that will help BreakingPoint customers leverage automation in their testing efforts. The next installment will focus on utilizing the Security component to test IPS signatures. In the meantime, please download the code archive for this post and get started with TCL!
Tags: