Once you have the configuration set, you can run
fragroute
on the system where you
are originating traffic. If you can use it on a device that is capable of routing, you can
manipulate traffic passing
from one network to another, but this is generally going to
be something to test from a single system. Testing out the fragmentation on my local
network, I used the command line in
Example 2-4
and received the results that you
can see. The testing of the system was done by just issuing ping requests to the target.
I could have just easily done testing against another system
using traffic like web
requests.
Example 2-4. fragroute output using rules file
root@kali:~# fragroute -f frag.rules 192.168.86.1
fragroute: ip_chaff -> ip_frag -> drop -> dup -> order -> print
192.168.86.227 > 192.168.86.1: icmp:
type
8
code 0
192.168.86.227 > 192.168.86.1: icmp:
type
77
code 74
192.168.86.227 > 192.168.86.1: icmp:
type
8
code 0
192.168.86.227 > 192.168.86.1: icmp:
type
90
code 83
192.168.86.227 > 192.168.86.1: icmp:
type
8
code 0
192.168.86.227 > 192.168.86.1: icmp:
type
90
code 83
192.168.86.227 > 192.168.86.1: icmp:
type
102
code 77
192.168.86.227 > 192.168.86.1: icmp:
type
102
code 77
192.168.86.227 > 192.168.86.1: icmp:
type
8
code 0
Floating point exception
The interesting thing we see in this test is the floating-point error. This happened in
fragroute
from just manipulating the traffic. This particular testing appears to have
turned
up a bug in
fragroute
. The unfortunate thing is that once the floating-point
error happened, network communication stopped. I was no longer able to get any
network traffic off my Kali box, because of the way
fragroute
works.
All traffic is set
up to run through
fragroute
, but when the program fails, the hook doesn’t get unset.
As a result, the operating system is trying to send network communication to some‐
thing that just isn’t there. This is another example of the reason we test. Software can
be complex, and especially when underlying
libraries have changed, behaviors can
also change.
Ultimately, any failure resulting from a stress test is a problem with availability. If the
system crashes, no one can get to anything. If the application fails, the service isn’t
available to users. What you are performing is a denial-of-service attack. As a result,
it’s important to be careful when performing these sorts of attacks. There are defi‐
nitely
ethical implications, as noted earlier, but there are also very real possibilities to
cause damage, including significant outage to customer-facing services. More on that
in a moment. A simple way to do stress testing is to use a tool like
hping3
. This fabu‐
lous tool can be used to craft packets on the command line. Essentially, you tell
hping3
what you want
different fields to be set to, and it will create the packet the way
you want.
