Advanced Fragmentation Control in Cisco ASA Post-9.7: A Comprehensive Guide

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.

Configuring Custom SMTP Inspection on Cisco ASA (Post-9.7)

Securing SMTP Traffic on Cisco ASA (Post 9.7)

In today’s email-driven world, securing your mail server is critical. SMTP is a frequent attack vector for spam, phishing, and DoS attempts. Starting with Cisco ASA 9.7, SMTP inspection configuration has become simpler, more flexible, and easier to manage using Layer-7 policy maps.

📧 SMTP Inspection Overview ➕

SMTP (Simple Mail Transfer Protocol) forms the backbone of email delivery but is also widely abused. With proper inspection, Cisco ASA can:

• Limit SMTP command usage
• Block risky commands like VRFY and EXPN
• Protect mail servers from abuse and DoS attacks

Before ASA 9.7, SMTP inspection relied on class maps and service policies. Now, everything can be configured directly inside an L7 inspection policy.

Step 1️⃣ Disable Default SMTP Inspection ➕

Cisco ASA enables SMTP inspection by default. To apply a custom policy, you must first disable the default rule to avoid conflicts.

policy-map global_policy class inspection_default no inspect esmtp

Why? Default inspection overrides custom rules if left enabled.

Step 2️⃣ Create an L7 SMTP Policy Map ➕

Starting with ASA 9.7, SMTP inspection is configured directly using an L7 policy map.

policy-map type inspect esmtp custom_smtp_policy

This policy will hold all SMTP command restrictions and limits.

Step 3️⃣ Control SMTP Commands & Limits ➕

Certain SMTP commands can be abused for reconnaissance and enumeration.

parameters no allow-vrfy no allow-expn

You can also protect against DoS attacks by limiting recipients per session:

limit recipients 100

Step 4️⃣ Apply SMTP Inspection Globally ➕

Match SMTP traffic and apply the inspection globally.

class-map smtp_class match port tcp eq 25

policy-map global_policy class smtp_class inspect esmtp custom_smtp_policy

Step 5️⃣ Verify SMTP Inspection ➕

Confirm that the SMTP inspection policy is active:

show service-policy inspect esmtp

✅ Conclusion ➕

Cisco ASA 9.7 introduced a cleaner and more powerful way to manage SMTP inspection. By disabling default inspection and applying a custom L7 policy, administrators gain precise control over SMTP behavior.

This approach enhances security, reduces attack surface, and allows rapid adaptation to evolving email threats.

💡 Key Takeaways

• SMTP is a common attack vector and must be inspected
• ASA 9.7 simplifies SMTP inspection using L7 policy maps
• Default inspection must be disabled for custom rules
• Blocking VRFY/EXPN reduces reconnaissance risks
• Command limits protect against DoS attacks

Interactive Cisco ASA SMTP Inspection Guide