Transcript for this video
Here is the opening display for the Maxwell graphical user interface.
We’ll select the third item on the left column, which is Start Maxwell with TCP/IP Impairments.
The Maxwell TCP/IP tests can be initiated on multiple flows to the device under test.
At this point, you need to decide how many flows you would like to establish and what their characteristics or defining attributes should be.
Just to get started, we will keep this simple and work with Flow 0.
We will start with testing IP fragmentation.
You will need to know the IP addresses of the two hosts that will be communicating.
Of course, Maxwell must be in the middle between these to IP addresses.
Now select the Flow Selector tab.
In this test, we are taking all IP packets between the two devices.
We will fragment all of them—that is 100% of the IP packets.
We select IPv4 from the Flow type radio buttons.
Next, we select IP Address.
Here, we will enter the IP addresses.
Notice the tooltips.
The subnet mask is selected automatically because Maxwell makes an assumption that you want an exact match of the IP address.
So 4 times 255 is a mask for an exact match to the IP address.
Next, we will select “Match packets from Address 1 to Address 2”
Finally, we click on the apply button at the bottom of the display to apply our selections.
Next, we want to select the TCP/IP tests.
This entry is in the left-hand pane in the choices for Flow 0.
The first group in the list of TCP/IP test suites is the IPv4 Fragmentation group.
We will select test 050.010.2 and click the activate button.
You can see from the summary and the explanation under “WHAT THE TEST DOES,” what is actually occurring now.
The IP datagrams are fragmented into MTU-sized chunks, starting at the front of the datagram.
So, basically, we are testing the ability of Device 5678 to reassemble the fragmented IP packets that it believes were sent by Device 1234.
The normal size would be 1500.
Thus, fragmenting the IP datagram into smaller parts is a standard part of the IP protocol.
While this is a simple test, receiving devices have been known to fail reassembly because the last remaining packet may be very simple.
To stop the test, click on Deactivate.
Scroll down to 050.010.3
This test is like the previous one, but the fragmented IP packets will be sent in reverse order.
This is legal according to the RFC, yet it has been the downfall of many devices.
We will now deactivate this test and move on to a more complex and interesting example.
Scroll down to 050.010.23
There are several increasingly more complex fragmentation examples, but we will now move to a very interesting and complex example.
This test offers user-selectable parameters.
As in the previous test, IP datagrams are fragmented, but now we have added overlapping fragments.
Thus the destination device must not only reassemble these fragments, but it must reconcile the overlapping information.
This is a security vulnerability. Why?
There are known attacks that use the differences of reassembly with different contents in overlapping fragments to fool firewalls.
This test offers user-selectable parameters.
For Parameter A, we’ve entered 128 as the size of each fragment.
For Parameter B, we have entered 96 as the amount we will shift the window to create the overlap.
Finally, in Parameter C, we are again going to send the packets in reverse order.
Now we will activate to see the result.
Earlier, we looked at this test: test 050.010.2, that is performing a basic fragmentation on a TCP stream flowing from the source device to the destination device.
Now we would like to revisit this test by adding more filters and showing how to analyze the result.
Here’s a snapshot of the traffic before it was modified.
We have used a packet-capture tool called Wireshark that is included with Maxwell. Notice that on the top window, frame number 7 is the TCP protocol.
In the info column on the right, we can see that roughly 1448 bytes of data were sent as indicated by the length field.
It also has the “Don’t Fragment” bitset, but Maxwell will ignore that.
The middle frame has the details for identifying the packet.
The bottom frame has the hex dump of the packet, which we will be not be using.
Here is the Wireshark snapshot of the traffic after it was modified.
Here is TCP frame number 7 in the top window.
We can see from the identification field that it is the same packet.
However, this time we can see from the last column, titled “Info,” that what was originally one large packet is now broken into three smaller packets in this display: numbers 7, 8, and 9.
In the middle window, we can see that number 7 is a shorter packet, and the flags indicate that it was fragmented.
In frame number 11, we can see that the destination device has reassembled the fragments and is acknowledging the data.
The destination device did acknowledge the fragmented packets, indicating that the destination device is handling this case of fragmentation properly.
Want to Know More?
|Find more videos||How to buy||Contact an Expert|