Verifying Service Readiness with DoS (part 1 of 2)
Recently one of my European colleagues fielded a pretty important customer question about the Mu Test Suite's Denial of Service module’s relevancy to the telecom industry. This customer has been using Mu's Service Level Traffic Variations module pretty successfully for a year or so stateside to find potential points of VoIP weakness and SIP failure and get them fixed. So what makes the Mu’s Denial of Service engine particularly useful to service providers?
Security is definitely an important piece of deploying a successful service offering, and I still recall an old router vulnerability where the routing process ran at a higher system priority than the security process. This allowed an attacker to load the box with interesting routing problems and then bypass authentication for privileged mode entirely. Those are neat things to find, they get you noticed, but it’s ultimately only part of ensuring a good end-user experience on launch day and beyond.
I would sincerely hope (crossed fingers) that Network Operators have learned their lessons about such things - attacks like that are so 90's. Mu's Denial of Service module is all about provisioning, throttling, and planning: or put another way, helping prevent network operators from writing checks their applications can't cash. This is different from the approach that my former employer's network operator customers used to take which was "throw more bandwidth at it" - the network isn't really the bottleneck anymore in most cases - it's the applications themselves.
In previous jobs, I used to play with some primitive load testing tools, but they were fairly basic packet sprayers. They didn't have valid checksums in the right places and you could only busy out the wire. Honestly, you could do the same thing with a power drill by wrapping the cable around the back end and cranking it up to induce current spikes. Nice party trick, by the way.
That's fun, but most vendors have solved the lower-level problems adequately - they can deliver the packets to the target. Problem is, what happens at the all important service layer? My 10GB infrastructure might be able to pass a gazillion packets per second and deliver them to the server and the server NIC might be powerful enough to process them. But, if all these things happen concurrently, you still have to worry about whether the target OS/application itself properly handles the load - especially in a VoIP environment where response time is critical.
Most tools that do generic load testing operate at a low level because dynamically calculating valid checksums and data that the application actually responds to is a very complicated thing. Most vendors have no interest in putting that kind of effort into their testing. They would rather just spray junk and say, "Look, the infrastructure delivered it to the target – I did my part."
So how does Mu solve this problem? Return next week for the exciting conclusion! (Or click here to watch a technical demonstration if you just can’t wait.)
Comments:
Write a comment
- Required fields are marked with *.
|
