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

ServerIron ADX Security Guide 125
53-1002440-03
DDoS protection
5
Configuring a security filter
Configuring a a security filter requires you to define it by name and configure rules within it as
shown in the following.
ServerIronADX(config)# security filter filter1
ServerIronADX(config-sec-filter1)#rule xmas-tree drop
Syntax: security filter <filter-name>
The <filter-name> variable specifies the filter being defined that will then be bound to a port.
The rule command defines the attack method that is being filtered for. For each rule, you can
configure whatever action needs to be taken if an attack occurs. The ServerIron ADX can log the
attack and drop the attacking packet. Rules that can be used are described in Tables 12 thorugh
17 of this chapter.
Some rules are hardware-based and are programmed in the CAM. For these rules, the default
action is to drop the packet. These rules cannot be logged, and no message can be logged when an
attack occurs. But there are counters that you can check to determine if an attack has occurred.
Example
ServerIronADX(config)# security filter filter1
ServerIronADX(config-sec-filter1)# rule xmas-tree log
ServerIronADX(config-sec-filter1)# rule address-sweep 1 3 drop log
NOTE
There is no set limit on the number of filters that can be configured on a ServerIron ADX but a
maximum of 10 rules can be bound to a single interface. The global limit depends upon the available
memory.
Configuring a Generic Rule
Apart from regular rules, such as those configured above, there is also a generic rule. A generic rule
needs to be defined before it can be bound to a filter. In the following example, a rule (gen1) is
configured to match a tcp packet with source-ip greater than 10.10.1.101, a tcp dest-port greater
than 20 and a string "400" at the 3rd byte offset from l4-data.
ServerIronADX(config)# security generic gen1
ServerIronADX(config-sec-gen-gen1)# ip-source gteq ip 10.10.1.101
ServerIronADX(config-sec-gen-gen1)# tcp-dest gt val 20
ServerIronADX(config-sec-gen-gen1)# l4-data 3 eq str "400"
Syntax: {no} security generic <generic-rule-name>
The <generic-rule-name> variable specifies the generic rule defined that will then be bound to a
filter.
The following conditions can be applied to any of the fields in the mac-header, ip-header, l4-header
(TCP/UDP), and l4-data offset to create generic rules:
eq equals
gt greater-than
gteq greater-than-or-equals










