Preparing for DDoS and Botnet Attacks: Webcast and Test Methodology
DDoS and botnet attacks are an imminent threat to every network. Just look at the damage we saw over the summer. In July, cyber attacks targeted a number of government, news media, and financial websites in both South Korea and the United States. Shortly after, we witnessed DDoS attacks, aided by botnets, bringing down social networking services such as Twitter, Facebook and Google. In the face of an imminent threat how do you prepare?
If I can channel my inner Sun Tzu for a second; it is critical to know your enemy in order to protect your network assets. This means testing your network elements and application servers with genuine DDoS and botnet attacks to determine your weak points, before someone else does.
Next Wednesday, three BreakingPoint experts are getting together to discuss how to prepare for DDoS and botnets through replicating these attacks during testing. Dennis Cox, the CTO of BreakingPoint, will be joined by Tod Beardsley and Dustin Trammell for what plans to be a lively conversation. The webcast will also highlight some of the information in the soon to be published "BreakingPoint DDoS and Botnet Test Methodology". The methodology will be sent to all registrants of the webcast and details, step-by-step, how to replicate these scenarios in your testing environment.
Register now for the webcast and secure your copy of the test methodology.
Demonstrating Cyber Range Simulation During MILCOM
This week we have a team in Boston at MILCOM 2009, demonstrating cyber range simulation. MILCOM, for those not familiar, is a "conference for military communications, and attracts the best and brightest with high-level attendance from government, military, industry and academia. MILCOM 2009 gives industry the opportunity to promote communications technologies and services to commanders from all branches of the armed forces, Department of Defense, federal government, and the heads of multi-national forces from around the globe."
BreakingPoint will be demonstrating how our products deliver cyber simulation on a scale never before possible without building and maintaining an enormous environment similar to the vision for the U.S. Defense Advanced Research Projects Agency’s National Cyber Range. During the show we will be showing off the three-slot BreakingPoint chassis in booth number 453. Show attendees will be able to see how BreakingPoint replicates massive Internet-scale network traffic in order to find and address critical performance issues and security vulnerabilities, all in order to assure network resiliency.
If you are attending MILCOM let us know or stop by the booth. I will also be blogging a bit from the show during the week for those of you who are not attending.
Realistic Testing of Server Load Balancers
Realistic server load balancer testing is now critical, as load balancers have become a key network device. Lack of proper testing has unfortunately resulted in serious performance and security issues. One primary example would be the recent problems for Google's Gmail. Testing load balancers means hitting them with realistic and actual network scenarios, rather than the "ideal scenario", in order to assure their resiliency. BreakingPoint has published an updated Server Load Balancer Test Methodology and I took this opportunity to sit down with BreakingPoint CTO Dennis Cox to talk server load balancer testing.
You can download the BreakingPoint Server Load Balancer Test Methodology, which includes multiple test scenarios including:
- Testing the number of TCP connections per second the load balancer is able to handle to provide a baseline test of the device’s performance capabilities.
- Determining the overall bandwidth the load balancer can support through testing the number of HTTP/HTTPs connections per second the device can handle.
- Emulating blended application traffic to validate the load balancer can handle a true network scenario.
- Simulating dynamic pages and image files to validate HTTP Caching performance.
- Confirming the load balancer can handle malformed packets or errors with the packet through application fuzzing.
- And more...
Open Letter to Twitter: Can We Help?
Dear Twitter,
In December 2006 I jumped onto Twitter, not realizing the impact it would have on my life. Twitter helped introduce me to Pam O’Neal (@poneal) at BreakingPoint (@breakingpoint) and subsequently move my family from Boston to Austin to work here. Now, each day at BreakingPoint, we use Twitter (30%+ of our employees are registered) to communicate with our community of server load testing professionals and network and security engineers, as well as communicate amongst one another.
As a company, BreakingPoint recognized the potential of Twitter early and in 2008, even added a product feature to test the ability of network devices' and application servers' to handle the load of Twitter traffic. Our team has worked for decades developing the latest in networking and data center technology and they know first-hand how hard it can be to sustain a reliable network and service. It is why they created a better network and load testing solution.
Yesterday, when Twitter was down due to a "bug triggered by an edge case in one of the core services", I thought about how important Twitter had become to our business and me. I watched the predictable posts complaining about the fail whale and it hit me; rather than throwing criticism, I would be best served getting my hands dirty and helping with the problem. An idea surfaced, which I talked through with our CTO and co-founder Dennis Cox (@denniscox), and the green flag was waved.
BreakingPoint wants to help Twitter by providing the use of its server load testing product and wicked smart folks (sorry, the Boston still in me) to help assure the resiliency of your company's network devices, servers and overall data center infrastructure. We want to provide the use of our BreakingPoint Elite, combined with a team of experts, many of them industry-recognized resources in security, Ruby, software engineering and load testing. As your company will see, we can provide server load testing on the scale a service like Twitter would need. I can have someone from our San Francisco office meet with your team today if needed (and I can be on the next flight).
BreakingPoint is a huge fan of Twitter and hopes that it can help! I've included the Twitter profiles for some of our team below. We are all looking forward to working with your company.
|
denniscox - Dennis Cox
CTO and founder of @breakingpoint
|
tmanning - Todd Manning
Author of @breakingpoint Twitter testing protocol
|
||||
|
todb - Tod Beardsley
@breakingpoint "protocol monkey" (his words, not mine)
|
poneal - Pam Oneal
Vice President of Marketing @breakingpoint
|
||||
|
mikehamilton - Michael Hamilton
Product Marketing @breakingpoint
|
kkuehl -Kirby Kuehl
Writes protocol (de|en)coders in C/C++ @breakingpoint
|
||||
|
jgstroud - Jonathan Stroud
Hardware design @breakingpoint
|
druidian - I)ruid
@breakingpoint Labs
|
||||
|
chrisfenton - Chris Fenton
@breakingpoint--West Region
|
KyleFlaherty - Kyle Flaherty
Communications for @breakingpoint
|
Many thanks for everything your company has provided our community,
UPDATE: I'd be remiss if I didn't also link to @busterbcook and @rhythmx, two more great BreakingPoint Tweeters!
Cisco Security Agent Exits the Market?
This morning, Ron Gula tweeted a link regarding the possible discontinuation of Cisco Security Agent (CSA). Gula, the CEO/CTO of Tenable Security, pondered whether this was the first of many Cisco security products to be discontinued. While I think he may be right in that regard, I was hoping CSA remained alive. Patrick Ogenstad wrote the actual blog post in Network Lore to which Gula referred in his tweet. It's a wonderful article and I agree with most of what Ogenstad writes, with the exception of a sentence in the last paragraph:
"Perhaps Cisco is the wrong vendor to have this specific product in its portfolio, and perhaps someone else will buy it."
While I do hope someone picks up the product, I actually think Cisco is the best company to own CSA. This was its trojan horse into the desktop to disseminate a whole host of other products and services. Perhaps even TelePresence?
Cisco has the manpower, a technical sales force and a strong technical support organization. Those are key factors, in my opinion, to make CSA successful. CSA reminds me a lot of Network Flight Recorder (NFR), acquired by Check Point in 2006. The products are (were?) both extremely powerful. You could do most anything you wanted and neither product required constant upgrading. The general feedback on both, however, was that they were complicated and required knowledgeable people to set them up and get the most out of them. I really dislike that as an argument for their demise: "I'm too lazy to read the manual and do a few Bing searches, Mr. Vendor. Just make it all auto-magically happen for me.".
Sorry, buddy, but networking doesn't work that way and network security definitely doesn't work that way. It's a detail-oriented profession and if you are not detailed enough to understand the difference between UDP and TCP, get out of networking. You are not doing anybody any favors by judging everything on presets and defaults. You sir, are the type of person being mocked in beer commercials.
We see this all the time in testing. Vendor A has built a new content-aware firewall, and its QA team tests the product using a bit blaster to see how many UDP packets can go through at any given packet size and any second. When does that happen on a real network? Never. The QA team is doing what they did in the past and is now simply being lazy. They are not helping the product succeed in the real world. Here is a suggestion to anyone with a content-aware firewall, test with some actual content, and you'll be surprised by the results.
As I noted in my last blog post, network administrators are once again failing to secure their networks properly, whether it's failing to update their routers and switches with the latest Cisco patches or not deploying solid security solutions such as CSA. It leads me to a couple of important questions for the peanut gallery: Why is CSA leaving the market (or is it)? And what could Cisco have done to save it?
Oh, one last thing, what are you doing to save your product? God knows I hope you're testing.