When managing firewalls like Cisco's Adaptive Security Appliance (ASA), handling fragmented packets is a critical aspect of network security. Fragmentation occurs when large packets are broken into smaller chunks to traverse networks with varying maximum transmission units (MTUs). However, this process can be exploited for Denial of Service (DoS) attacks or data exfiltration.
In earlier versions of the Cisco ASA, one common approach was to limit the number of fragments accepted for reassembly by setting the fragment limit to a value of 1, effectively preventing the firewall from accepting fragmented packets altogether. This was achieved using the `fragment chain` configuration. However, with the release of ASA 9.7 and beyond, there have been significant improvements in how the ASA handles fragmented traffic, offering more granular control and enhanced protection mechanisms.
In this blog, we’ll explore how the management of fragmented packets has evolved in ASA post-9.7, providing better security and performance without having to rely on older, restrictive methods.
## Overview of the Pre-9.7 Approach to Fragmentation
Before ASA version 9.7, fragmentation control primarily relied on two main configuration parameters:
1. **Fragment Chain Limit**: Set the maximum number of fragments that the ASA would accept for reassembly. By default, the ASA could accept up to 24 fragments for reassembly. However, to prevent potential fragment-based attacks, administrators could set this value to `1`, ensuring that no fragmented packets were accepted, as only full, unfragmented packets would be allowed.
2. **Reassembly Buffer Limit**: The ASA also provided a buffer for fragment reassembly, with a default limit of 200 packets. Increasing this buffer could potentially expose the ASA to DoS attacks by allowing attackers to flood the buffer with fragmented packets, overwhelming the device.
While effective, this approach had its downsides:
- Setting the fragment chain to `1` was an all-or-nothing method, which completely blocked fragmented packets, even if they were legitimate.
- Limiting fragmentation too much could result in connectivity issues for applications that legitimately send fragmented packets.
## ASA Post-9.7: A Modern Approach to Fragment Handling
Starting with ASA 9.7, Cisco introduced **Flexible Packet Matching (FPM)**, which allows for more fine-tuned control over how fragmented packets are handled. This new approach offers more flexibility and security without the rigid constraints of older methods. Here's how the post-9.7 ASA handles fragmentation:
### 1. **Adaptive Fragmentation Control**
ASA 9.7 introduced smarter, adaptive fragmentation handling. Instead of a binary accept/reject approach, the ASA can now assess fragmented packets and reassemble them based on more granular security policies. This is part of the broader enhancements in deep packet inspection and threat intelligence in newer ASA versions.
### 2. **Class Map and Policy Map for Fragmented Traffic**
One of the most significant improvements is the ability to create specific policies for fragmented packets using **Modular Policy Framework (MPF)**. With MPF, administrators can define class maps and policy maps to inspect fragmented traffic. This provides greater control over which types of fragmented packets are accepted, reassembled, or dropped.
Here’s an example of how you might configure a class map to drop all fragmented packets:
class-map FRAGMENTS
match packet fragmentation
!
policy-map global_policy
class FRAGMENTS
drop
!
service-policy global_policy global
In this configuration:
- A class map named `FRAGMENTS` is created to match fragmented packets.
- A policy map called `global_policy` applies a `drop` action to any packets that match the `FRAGMENTS` class.
- This policy is applied globally, ensuring that all fragmented packets are dropped.
Alternatively, you could use the policy map to limit fragment chains, inspect, or rate-limit fragmented packets rather than dropping them outright, depending on your security needs.
### 3. **Fragment Chain and Reassembly Limits with More Flexibility**
While the concept of fragment chain limits still exists, ASA 9.7 and newer versions offer more flexible handling of fragmented traffic. Instead of rigidly setting the fragment chain limit to 1, you can allow a reasonable number of fragments, depending on your network’s specific traffic patterns, while still using more advanced inspection techniques to filter out malicious fragments.
Here’s how you might adjust the fragment chain limit:
fragment chain 10
fragment reassembly-timeout 10
- **fragment chain**: This command sets the maximum number of fragments that can be part of a reassembly. In this case, we’ve reduced the limit from the default 24 to 10, a more conservative yet functional setting.
- **fragment reassembly-timeout**: This specifies how long (in seconds) the ASA will hold fragments in memory while waiting for a complete packet. By default, the timeout is 5 seconds, but it can be adjusted to optimize performance or security.
### 4. **DoS Protection and Rate-Limiting**
ASA 9.7 also brings enhanced capabilities for detecting and mitigating DoS attacks that exploit fragmentation. By leveraging FPM and MPF, you can set up rate-limiting or deep inspection for fragmented packets to mitigate risks without completely blocking fragmented traffic.
For example, using MPF, you can create a policy to rate-limit the number of fragmented packets processed by the ASA:
class-map FRAGMENTS
match packet fragmentation
!
policy-map LIMIT_FRAGMENTS
class FRAGMENTS
police input 100 kbps
!
service-policy LIMIT_FRAGMENTS interface outside
In this configuration:
- The `FRAGMENTS` class matches fragmented packets.
- The `LIMIT_FRAGMENTS` policy applies an input rate limit of 100 kbps to fragmented packets arriving on the outside interface. This limits the impact of fragment-flooding attacks while still allowing legitimate fragmented traffic through.
### 5. **Enhanced Logging and Monitoring**
Post-9.7 ASA versions provide better logging and monitoring for fragmented traffic, making it easier to detect and respond to fragmentation-related attacks. By using syslog or SNMP, network administrators can monitor fragment activity and fine-tune their policies accordingly.
For example, you can configure logging for fragments that are dropped or denied by the ASA:
logging enable
logging trap warnings
logging message 106023
This configuration ensures that any packets dropped due to fragmentation issues are logged for review.
## Conclusion
The older method of setting the fragment chain limit to `1` was effective but came with significant trade-offs in terms of functionality. With the introduction of ASA 9.7 and newer versions, Cisco has provided more advanced, flexible, and secure ways to handle fragmented packets. Administrators can now use modular policy frameworks to define tailored policies, enforce rate limits, and monitor fragmentation traffic in real-time, all while protecting the network from potential DoS attacks.
In summary, post-9.7 ASA fragmentation handling focuses on flexibility, allowing for both the security needed to prevent attacks and the functionality required to support legitimate fragmented traffic. This approach minimizes disruptions while offering greater protection from potential threats.
