Define stateful configurations for firewall policies
Deep Security's Firewall Stateful Configuration mechanism analyzes each packet in the context of traffic history, correctness of TCP and IP header values, and TCP connection state transitions. In the case of stateless protocols like UDP and ICMP, a pseudo-stateful mechanism is implemented based on historical traffic analysis. Packets are handled by the stateful mechanism as follows:
- A packet is passed to the stateful routine if it has been allowed through by the static Firewall Rule conditions,
- The packet is examined to determine whether it belongs to an existing connection, and
- The TCP header is examined for correctness (e.g. sequence numbers, flag combinations, etc.).
The Firewall Stateful Configurations page lets you define multiple stateful inspection configurations which you can then include in your Policies. From the toolbar or shortcut menu you can:
- Create New
()Firewall Stateful Configurations from scratch
()Firewall Configuration from an XML file (located under the New menu.)
- Examine or modify the Properties
()of an existing Firewall Stateful Configuration
()(and then modify) existing Firewall Stateful Configurations
- Delete a Firewall Stateful Configuration
- Export one or more Firewall Stateful Configurations to an XML or CSV file. (Either export them all using the ... button, or choose from the list to export only those that are selected or displayed)
- Add/Remove Columns
()columns can be added or removed by clicking Add/Remove Columns. The order in which the columns are displayed can be controlled by dragging them into their new position. Listed items can be sorted and searched by the contents of any column.
Firewall Stateful Configuration Properties
- Name: The name of the Firewall Stateful Configuration.
- Description: Type a description of the Firewall Stateful Configuration. This description will only appear here.
IP Packet Inspection
- Deny all incoming fragmented packets: If this option is enabled, all fragmented packets are dropped with the following log entry: "IP fragmented packet". The one exception to this rule is the presence of packets with a total length smaller than the IP header length. Such packets are dropped silently.
Attackers sometimes create and send fragmented packets in an attempt to bypass Firewall Rules.The Firewall Engine, by default, performs a series of checks on fragmented packets. This is default behavior and cannot be reconfigured. Packets with the following characteristics are dropped:
- Invalid fragmentation flags/offset: A packet is dropped when either the DF and MF flags in the IP header are set to 1, or the header contains the DF flag set to 1 and an Offset value different than 0.
- First fragment too small: A packet is dropped if its MF flag is set to 1, its Offset value is at 0, and it has total length of less than 120 bytes (the maximum combined header length).
- IP fragment out of boundary: A packet is dropped if its Offset flag value combined with the total packet length exceeds the maximum datagram length of 65535 bytes.
- IP fragment offset too small: A packet is dropped if it has a non-zero Offset flag with a value that is smaller than 60 bytes.
TCP Packet Inspection
- Deny TCP packets containing CWR, ECE flags:
These flags are set when there is network congestion.
RFC 3168 defines two of the six bits from the Reserved field to be used for ECN (Explicit Congestion Notification), as follows:
Automated packet transmission (such as that generated by a denial of service attack, among other things) will often produce packets in which these flags are set.
- Bits 8 to 15: CWR-ECE-URG-ACK-PSH-RST-SYN-FIN
- TCP Header Flags Bit Name Reference:
- Bit 8: CWR (Congestion Window Reduced) [RFC3168]
- Bit 9: ECE (ECN-Echo) [RFC3168]
- Enable TCP stateful inspection: Enable stateful inspection at the TCP level. If you enable stateful TCP inspection, the following options become available:
- Enable TCP stateful logging: TCP stateful inspection events will be logged.
- Limit the number of incoming connections from a single computer to: Limiting the number of connections from a single computer can lessen the effect of a denial of service attack.
Incoming connection limits are only available on Deep Security Agent 8.0 and earlier.
- Limit the number of outgoing connections to a single computer to: Limiting the number of outgoing connections to a single computer can significantly reduce the effects of Nimda-like worms.
Outgoing connection limits are only available on Deep Security Agent 8.0 and earlier.
- Limit the number of half-open connections from a single computer to: Setting a limit here can protect you from DoS attacks like SYN Flood. Although most servers have timeout settings for closing half-open connections, setting a value here can prevent half-open connections from becoming a significant problem. If the specified limit for SYN-SENT (remote) entries is reached, subsequent TCP packets from that specific computer will be dropped.
Half-open connection limits are only available on Deep Security Agent 8.0 and earlier.When deciding on how many open connections from a single computer to allow, choose your number from somewhere between what you would consider a reasonable number of half-open connections from a single computer for the type of protocol being used, and how many half-open connections from a single computer your system can maintain without getting congested.
- Enable ACK Storm protection when the number of already acknowledged packets exceeds: Set this option to log an event that an ACK Storm attack has occurred.
ACK Storm protection options are only available on Deep Security Agent 8.0 and earlier.
- Drop Connection when ACK Storm detected: Set this option to drop the connection if such an attack is detected.
- Active FTP
- Allow Incoming: Allow Active FTP when this computer is acting as a server.
- Allow Outgoing: Allow Active FTP when this computer is acting as client.
- Passive FTP
- Allow Incoming: Allow Passive FTP when this computer is acting as a server.
- Allow Outgoing: Allow Passive FTP when this computer is acting as a client.
- Enable UDP stateful inspection: Check to enable stateful inspection of UDP traffic.
The UDP stateful mechanism drops unsolicited incoming UDP packets. For every outgoing UDP packet, the rule will update its UDP "stateful" table and will then only allow a UDP response if it occurs within 60 seconds of the request. If you wish to allow specific incoming UDP traffic, you will have to create a Force Allow rule. For example, if you are running a DNS server, you will have to create a Force Allow rule to allow incoming UDP packets to destination port 53.Without stateful inspection of UDP traffic, an attacker could masquerade as a DNS server and send unsolicited UDP "replies" from source port 53 to computers behind a firewall.
- Enable UDP stateful logging: Checking this option will enable the logging of UDP stateful inspection events.
- Enable ICMP stateful inspection: Check to enable stateful inspection of ICMP traffic.
The ICMP (pseudo-)stateful mechanism drops incoming unsolicited ICMP packets. For every outgoing ICMP packet, the rule will create or update its ICMP "stateful" table and will then only allow a ICMP response if it occurs within 60 seconds of the request. (ICMP pair types supported: Type 0 & 8, 13 & 14, 15 & 16, 17 & 18.)With stateful ICMP inspection enabled, you can, for example, only allow an ICMP echo-reply in if an echo-request has been sent out. Unrequested echo-replies could be a sign of several kinds of attack including a Smurf amplification attack, a Tribe Flood Network communication between master and daemon, or a Loki 2 back-door.
- Enable ICMP stateful logging: Checking this option will enable the logging of ICMP stateful inspection events.
The Assigned To tab lists the Policies and computers that are making use of this stateful inspection configuration.