|Tutorial >> Examples||TOC|
This page gives two examples of filtering with GM (General Match) filters that use TCP flags:
Example A demonstrates basic usage of TCP-flags filtering by showing how to count TCP connection attempts and successful TCP flows.
Example B demonstrates one application of TCP-flag filtering in generating a flood of false TCP connections that might be used to study the robustness of a network algorithm to mitigate SYN attacks.
A new version of the SYN Attack Mitigation Demo will also demonstrate how TCP flag filtering can be used.
You can monitor the control part (SYN, FIN, ACK) of a TCP flow.
Consider the one-NSP configuration shown in Fig. 1 where TCP traffic is
generated by an iperf client running on n1p2.
The traffic goes through the 8 Mbps bottleneck link at port 7;
then out to port 6 where it is forwarded through output port 3;
and finally on to the iperf server running on n1p3.
The ACK path is the reverse path taken by the data packets; i.e.,
out n1p3, into port 3, out port 6, into port 7, out port 2, and
There are three GM filters, all located at port 2. One of the filters is installed on the ingress side, and two are installed on the egress side. In all cases, the 5-tuple part of the GM filter will match any TCP packet: src address = 0.0.0.0/0, src port = *, protocol = tcp, dst address = 0.0.0.0/0, and dst port = *. But the ingress filter matches only TCP packets that have the SYN flag ON; i.e., the connection setup packet from the sender. One of the two egress filters matches only TCP packets that have the FIN and ACK bits ON; i.e., the connection termination packet from the receiver. And the second egress filter is used to count all packets that do not match the FIN-ACK filter.
In the above figure, the three red squares indicate the bandwidth monitoring points. The one at IPP 2 monitors the traffic going toward the receiver before the bottleneck link. The one at IPP 6 monitors the traffic going toward the receiver that leaves the bottleneck link. And the one at IPP 7 monitors the returning ACK traffic coming from the receiver.
Here are the major steps in this example:
|6, 7||Default Forwarding|
Traffic from the source at port 2 should go to port 7 where it loops back into port 6. From port 6, traffic goes to port 3 and out to n1p3. Return TCP traffic (ACK packets) takes the reverse path along port 6, then port 7, and then to port 2 to n1p2. We create a single entry in the route tables at ports 2 and 3 to direct traffic to ports 7 and 6 respectively. At ports 6 and 7, we create local default entries.
For port 2:
For port 3:
The ingress GM filter will be used to count SYN packets, and the egress GM filter will be used to count FIN-ACK packets. The matching packets on the ingress side will be placed in the normal VOQs for forwarding to port 7. The matching packets on the egress side will be placed in its datagram.
Leave the default values for the src and dest address fields (0.0.0.0/0), the src and dest port fields (*), and the protocol field (tcp).
Install one GM filter to count FIN-ACK packets and one to count all other packets. In both cases, the matching packets are placed into queue 300. A FIN-ACK packet will match both filters. But the filter with its FIN-ACK bits ON is given a higher priority (50) than the other more general filter so that it will be selected for a FIN-ACK packet.
The Bandwidth chart shows three bandwidths:
- The sender's traffic bandwidth going into the bottleneck (port 7 link);
- The bandwidth that makes it to port 3; and
- The returning ACK traffic when it reaches port 2.
The Add Parameter dialogue box will appear.
The packet counts associated with the SYN GM filter at ingress port 2 and the FIN-ACK GM filter at egress port 2 can be added to a chart. You should see one SYN packet coming from n1p2 at the beginning of the TCP flow and one FIN-ACK packet going to n1p2 at the end of the TCP flow.
The GM Filter window will appear.
The Statistics dialogue box will appear.
The SYN, FIN-ACK Rate chart appears.
The IPP2Filter0BW dialogue box appears.
The label changes to SYN Pkts.
Repeat the above steps for adding the FIN-ACK packet count rate to the SYN, FIN-ACK Rate chart by using the status field in the FIN-ACK filter at egress port 2.
Start an iperf TCP server at n1p2 to act as a receiver. This server will run until you kill it with ctrl-c. After starting the server, start the iperf TCP client to act as the traffic sender.
onlusr> source ~onl/.topology onlusr> ssh $n1p3 $n1p3> iperf -s
onlusr> source ~onl/.topology onlusr> ssh $n1p2 $n1p2> iperf -c n1p3 -t 5
The same setup could be used to count the number of TCP flows occuring between from n1p2 and n1p3. Furthermore, if you moved the GM filters from port 2 to port 7 or port 6, you could easily monitor TCP flows from any host if their traffic goes through the link between ports 7 and 6.
This example shows how you convert a normal TCP flow into one that is a SYN flood attack. In a SYN flood attack, an attacker repeatedly sends a single SYN packet to a server but never responds to the servers SYN-ACK packet. The result is that the attack eventually consumes all slots in the server's half-open connection table and prevents other legitimate users from connecting to the server. In a real attack, the attacker would use a bogus source IP address. This example shows how a similar traffic pattern could be generated using a GM filter in combination with a normal traffic generator.
The idea is that the attacker generates legitimate TCP traffic, and the GM filters drop all packets except the initial SYN packet. For example, the attacker functionality could be a shell script that repeatedly called a program that does nothing but to attempt to connect to and disconnect from a server. The GM filter shown below will drop all TCP packets except the one with the SYN flag ON.
Although you can generate a SYN flood attack using toolkits designed for this purpose, the user must run as the root user. The example here shows how you can effectively do almost the same thing using an ordinary socket program in combination with a GM filter.
Revised: Fri, Feb 15, 2008
|Tutorial >> Examples||TOC|