itself, outside the context of the rest of the cake, even if we have to consume the entire
cake to get that layer.
Stress Testing
Some software, and even hardware, has a hard time handling enormous loads. There
are many reasons for this. In the case of hardware, such as devices that are purpose
built or devices that fall into the category of Internet of Things (IoT), there may be
several reasons that it can’t survive a lot of traffic. The processor that’s built into the
network interface could be underpowered because the design of the overall device
never expected to see a lot of traffic. The application could be written poorly, and
even if it is built into the hardware, a poorly designed application can still cause prob‐
lems. As a result, it’s important for security testers to ensure that the infrastructure
systems they are responsible for will not simply fall over when something bad
happens.
It may be easy to think of stress testing as flooding attacks. However, there are other
ways to stress applications. One way is to send the application unexpected data that it
may not know how to handle. There are techniques to specifically handle this sort of
attack, so we’re going to focus primarily on overwhelming systems here and deal with
fuzzing attacks, where we specifically generate bogus data, later. Having said that,
though, in some cases network stacks in embedded devices may not be able to handle
traffic that doesn’t look like it’s supposed to. One way of generating this sort of traffic
is to use a program called
fragroute
.
The program
fragroute
, written many years ago by Dug Song, takes a series of rules
and applies them to any packet that it sees destined to an IP address you specify.
Using a tool like
fragroute
, you can really mangle and manipulate packets originating
from your system. These packets should be put back together again, since one of the
main functions of
fragroute
is to fragment packets into sizes you identify. However,
not all systems can handle really badly mangled packets. This may especially be true
when the packet fragments are coming in with overlapping segments. With IP pack‐
ets, the IP identification field binds all fragments together. All fragments with the
same IP identification field belong to the same packet. The fragment offset field indi‐
cates where the fragment belongs in the overall scheme of the packet. Ideally, you
would have something like bytes 0–1200 in one packet fragment and the offset in the
second fragment would start at 1201, indicating that it’s the next one to be put back
together. You may get several more of roughly the same size and the network stack on
the receiving end puts them all together like squares in a quilt until the quilt is whole.
If, though, we have one fragment that says it starts at 1150, and we assume a trans‐
mission unit of 1200, but the next one says it starts at 1201, there is a fragment over‐
lap. The network stack needs to be able to handle that event correctly and not try to
put overlapping packets together. In some cases, dealing with this sort of overlapping
