behavior has caused systems to crash because they just can’t deal with the conflicting
information they are receiving.
Example 2-3
shows a configuration file that can be
used with
fragroute
to generate potentially problematic traffic.
Example 2-3. fragroute configuration
ip_chaff dup 7
ip_frag
64
new
drop random 33
dup random 40
order random
print
The first line indicates that IP packets should be interleaved with duplicates. The
7
in
that line indicates to set the time to live field at 7 hops. This can cause packets to be
dropped in transmission. The second line says to fragment IP packets at a packet size
of 64 bytes. The
new
tells
fragroute
to overlap packets by favoring new data rather
than old data. 33% of the time, we are going to drop packets. 40% of the time we are
going to duplicate random packets.
fragroute
is also going to randomize the order
that packets hit the wire, which means nothing will be in the correct sequence, ideally,
when it hits the endpoint. Finally, the details are printed, indicating what was done to
the packet that was received. In order to use this, we would use
fragroute -f frag.rules
192.168.5.40
. In this example, the name of the rules file is
frag.rules
and 192.168.5.40
is the target to which we want to send garbled traffic. These parameters can be
changed to suit your own particular setup.
Using a tool like
fragroute
with a set of rules like this will likely mean nothing useful
will end up at the target. However, that’s not really the point. The point is to check
your target and see how it’s handling what it is receiving. Are the packets just being
discarded? Is the operating system behaving correctly? This part is essential. Just
knocking things over isn’t helpful. You need to be able to document the behavior so
you can provide some indications of what may need to be done. Documenting your
efforts in as detailed a way as possible is important in order to be successful and asked
back or retained.
Ethics Warning
You need to ensure that the systems you are working on—espe‐
cially when there could be damage or disruption, and just about
everything we will be talking about has that potential—are either
yours or systems you have permission to be testing. It’s unethical at
a minimum and likely even illegal to be testing any system you
don’t own or have permission to be testing. Testing, no matter how
simple it may seem to be, always has the potential to cause damage.
Get your permission in writing, always!
