Home Theater Server User Manual
Table Of Contents
- Contents
- About This Document
- Network Security
- TCP SYN attacks
- IP TCP syn-proxy
- Granular application of syn-proxy feature
- Syn-def
- No response to non-SYN first packet of a TCP flow
- Prioritizing management traffic
- Peak BP utilization with TRAP
- Transaction Rate Limit (TRL)
- Understanding transaction rate limit
- Configuring transaction rate limit
- Configuring the maximum number of rules
- Saving a TRL configuration
- Transaction rate limit command reference
- Global TRL
- TRL plus security ACL-ID
- security acl-id
- Transaction rate limit hold-down value
- Displaying TRL rules statistics
- Displaying TRL rules in a policy
- Displaying IP address with held down traffic
- Refusing new connections from a specified IP address
- HTTP TRL
- Overview of HTTP TRL
- Configuring HTTP TRL
- Displaying HTTP TRL
- Display all HTTP TRL policies
- Display HTTP TRL policy from index
- Display HTTP TRL policy client
- Display HTTP TRL policy starting from index
- Display HTTP TRL policy matching a regular expression
- Display HTTP TRL policy client index (MP)
- Display HTTP TRL policy client index (BP)
- Display HTTP TRL policy for all client entries (BP)
- Downloading an HTTP TRL policy through TFTP
- HTTP TRL policy commands
- Logging for DoS Attacks
- Maximum connections
- clear statistics dos-attack
- Maximum concurrent connection limit per client
- Firewall load balancing enhancements
- Syn-cookie threshhold trap
- Service port attack protection in hardware
- Traffic segmentation
- DNS attack protection
- Access Control List
- How ServerIron processes ACLs
- Default ACL action
- Types of IP ACLs
- ACL IDs and entries
- ACL entries and the Layer 4 CAM
- Configuring numbered and named ACLs
- Modifying ACLs
- Displaying a list of ACL entries
- Applying an ACLs to interfaces
- ACL logging
- Dropping all fragments that exactly match a flow-based ACL
- Enabling ACL filtering of fragmented packets
- Enabling hardware filtering for packets denied by flow-based ACLs
- Enabling strict TCP or UDP mode for flow-based ACLs
- ACLs and ICMP
- Using ACLs and NAT on the same interface (flow-based ACLs)
- Displaying ACL bindings
- Troubleshooting rule-based ACLs
- IPv6 Access Control Lists
- Network Address Translation
- Syn-Proxy and DoS Protection
- Understanding Syn-Proxy
- Configuring Syn-Proxy
- DDoS protection
- Configuring a security filter
- Configuring a Generic Rule
- Configuring a rule for common attack types
- Configuring a rule for ip-option attack types
- Configuring a rule for icmp-type options
- Configuring a rule for IPv6 ICMP types
- Configuring a rule for IPv6 ext header types
- Binding the filter to an interface
- Clearing DOS attack statistics
- Clearing all DDOS Filter & Attack Counters
- Logging for DoS attacks
- Displaying security filter statistics
- Address-sweep and port-scan logging
- Secure Socket Layer (SSL) Acceleration
- SSL overview
- SSL acceleration on the ServerIron ADX
- Configuring SSL on a ServerIron ADX
- Basic SSL profile configuration
- Advanced SSL profile configuration
- Configuring Real and Virtual Servers for SSL Termination and Proxy Mode
- Configuration Examples for SSL Termination and Proxy Modes
- SSL debug and troubleshooting commands
- Displaying socket information
74 ServerIron ADX Security Guide
53-1002440-03
Enabling ACL filtering of fragmented packets
2
Syntax: [no] ip access-group frag inspect | deny
The inspect | deny parameter specifies whether you want fragments to be sent to the CPU or
dropped:
• inspect – This option sends all fragments to the CPU.
• deny – This option begins dropping all fragments received by the port as soon as you enter the
command. This option is especially useful if the port is receiving an unusually high rate of
fragments, which can indicate a hacker attack.
Throttling the fragment rate
By default, when you enable CPU filtering of packet fragments, all fragments are sent to the CPU.
Normally, the fragment rate in a typical network does not place enough additional load on the CPU
to adversely affect performance. However, performance can be affected if the device receives a
very high rate of fragments. For example, a misconfigured server or a hacker can affect the
device’s performance by flooding the CPU with fragments.
You can protect against fragment flooding by specifying the maximum number of fragments the
device or an individual interface is allowed to send to the CPU in a one-second interval. If the device
or an interface receives more than the specified number of fragments in a one-second interval, the
device either drops or forwards subsequent fragments in hardware, depending on the action you
specify. In addition, the device starts a holddown timer and continues to either drop or forward
fragments until the holddown time expires.
The device also generates a Syslog message.
To specify the maximum fragment rate per second, enter commands such as the following.
The first command sets the fragment threshold at 15,000 per second, for the entire device. If the
device receives more than 15,000 packet fragments in a one-second interval, the device takes the
specified action. The action specified with this command is to drop the excess fragments and
continue dropping fragments for a holddown time of ten minutes. After the ten minutes have
passed, the device starts sending fragments to the CPU again for processing.
The second command sets the fragment threshold at 5,000 for individual interfaces. If any
interface on the device receives more than 5,000 fragments in a one-second interval, the device
takes the specified action. In this case, the action is to forward the fragments in hardware without
filtering them. The device continues forwarding fragments in hardware for five minutes before
beginning to send fragments to the CPU again.
Both thresholds apply to the entire device. Thus, if an individual interface’s fragment threshold is
exceeded, the drop or forward action and the holddown time apply to all fragments received by the
device.
Syntax: [no] ip access-list frag-rate-on-system <num> exceed-action drop | forward reset-interval
<mins>
and
Syntax: [no] ip access-list frag-rate-on-interface <num> exceed-action drop | forward reset-interval
<mins>
ServerIronADX(config)# ip access-list frag-rate-on-system 15000 exceed-action
drop reset-interval 10
ServerIronADX(config)#ip access-list frag-rate-on-interface 5000 exceed-action
forward reset-interval 5










