Controlling fragments across a cisco ASA interfaces

Fragments are not good and could be downright bad if your doing packet inspection and recovery.

The reasons for the bad, there's no L4 header information in any succeeding  fragments. IPS/FIREWALL and  DoS detection gear can freak out and drop these. With UDP and ICMP large payload data is used in a lot for attacks.

note: Some gear will complain and drop flows upon re-assembly if the payload is just flat to big

Ping-of-Death ( aka PoD ) and Smurf took advantage of the typical os stack that allowed large packets and with PoD, windows was greatly effected and could crash.

In this post, we will look at a simple means for eliminating any fragments across interfaces.

1st let's look at the default fragments settings;

Okay the size = 200 chain = 24 and timeout = 5


Okay what this really means, 24 packets of  fragment can be allow and we allow for a total of 200 packets to be buffer for reassembly. The timeout value of 5sec  simpliy means we allow for 5secs for the fragments to be received, just encase some are slow getting back.

note: You might be able to use scappy to craft large packets and delay transmission for testing the delay
http://www.secdev.org/projects/scapy/

Okay let's look at how you drop all fragments across interfaces. Most will try to do something similar to the following;

But as you can see, the size can not less than the chain limit ( default = 24 )

So here's a means for dis-allowing fragments over all interfaces

config t
     fragment  chain 1
    fragment  size 1
end

Now let see a large icmp-ping and what happens when we block fragments ( 6k byte ping )

So when we dis-allow the  fragments, the  ASA drops these fragments. You can use the  show fragment command to get an ideal of fragments statistics.

( example  from a 8kbyte packet size  1 ping )

Ken Felix
NSE ( network security expert) and Route/Switching Engineer
kfelix  -----a----t---- socpuppets ---dot---com
   ^      ^
=(  $  $ )=
       o 
      /  \