Overview

Firewall functionality analyzes and filters IP packets between network interfaces. The most common application of functionality is to protect traffic between an internal network and the Internet. It allows you to filter packets based on their characteristics and perform actions on packets that match the rule. The Brocade vRouter firewall functionality provides the following features:

Packet filtering for traffic that traverses the router by using the in and out keywords on an interface
Definable criteria for packet-matching rules, including source IP address, destination IP address, source port, destination port, IP protocol, and Internet Control Message Protocol (ICMP) type
Ability to set the firewall globally for stateful or stateless operation

The vRouter firewall offers both IPv4 and IPv6 stateful packet inspection to intercept and inspect network activity and to allow or deny the attempt.

Firewall cannot be applied to outbound local traffic. It can only be applied to inbound interface traffic and forwarded outbound traffic.

Firewall and fragmented packets

An input firewall causes fragments to be reassembled. For both IPv4 and IPv6, if the packets arrive on an interface for which firewall is configured, the fragments are reassembled at the input before passing to the firewall. If all the fragments of a packet are not received, then the packet is dropped. The reassembled packet passes through the remainder of the forwarding path and firewall does not recognize fragments at either input or output. Passing through an output firewall (or DNAT/SNAT) also results in fragment reassembly before processing by the firewall or NAT rules.

Defining firewall instances

Firewalls filter packets on interfaces. Use of the firewall feature has two steps:

Define a firewall instance and save it under a name. A firewall instance is also called a firewall ruleset, where a rule set is just a series of firewall rules. You define the firewall instance and configure the rules in its rule set in the firewall configuration node.
Apply the instance to an interface by configuring the interface configuration node for the interface. After the instance is applied to the interface, the rules in the instance begin filtering packets on that location.

Firewall rules

Firewall rules specify the match conditions for traffic and the action to be taken if the match conditions are satisfied. Traffic can be matched on a number of characteristics, including source IP address, destination IP address, source port, destination port, IP protocol, and ICMP type.

Rules are executed in numeric sequence, according to the rule number, from lowest to highest. If the traffic matches the characteristics specified by a rule, the action of the rule is executed; if not, the system “falls through” to the next rule.

You can configure rules to match IPv4 ICMP, IPv6 ICMP, IPv6 routing header, or TCP without specifying the respective protocol, provided that a protocol-specific match option is present. For example TCP flags, ICMP type.

The action can be one of the following:

Accept Traffic is allowed and forwarded.
Drop Traffic is silently discarded.

To avoid having to renumber firewall rules, a good practice is to number rules in increments of 10. This increment allows room for the insertion of new rules within the ruleset.

Implicit action

When one or more named firewall rules (including the hidden rule used for default-action or default-log) are applied to an interface and a packet does not match any of the rules in a given direction, then the implicit actions occur. The implicit actions are a property of firewall rules having been applied to an interface, not a property of the rules as such.

When rules are present in one direction, there is an implicit action of drop for that direction. If any of the rules are stateful, there is an implicit drop action in the opposite direction even if no rules are present in the opposite direction. Despite this condition, stateful rules always allow for reverse direction stateful traffic to flow.

The security firewall name <name> default-action <action> and security firewall name <name> default-log commands use an explicit rule and as such will prevent implicit actions from occurring in the direction that they are applied to. Hence it is recommended that one not make use of these two commands.

Exclusion rules

Note that you should take care in employing more than one “exclusion” rule, that is, a rule that uses the negation operator (exclamation mark [!]) to exclude a rule from treatment. Rules are evaluated sequentially, and a sequence of exclusion rules could result in unexpected behaviour.

Stateful firewall and connection tracking

On the firewall, connection tracking allows for stateful packet inspection.

Stateless firewalls filter packets in isolation based on static source and destination information. In contrast, stateful firewalls track the state of network connections and traffic flows and allow or restrict traffic based on whether its connection state is known and authorized. For example, when an initiation flow is allowed in one direction, the responder flow is automatically and implicitly allowed in the return direction. While typically slower under heavy load than stateless firewalls, stateful firewalls are better at blocking unauthorized communication.

By default, the vRouter firewall is stateless. If you want the firewall to operate stateless in general, you can configure state rules within a specific ruleset. Alternatively, you can configure the firewall globally to operate statefully. For more information, refer to security firewall global-state-policy <protocol>.

For all protocols, the following are tracked for each session: interface, protocol, source address, and destination address. For ICMP, the ICMP identifier is also included. For TCP/UDP/UDP-Lite/DCCP/SCTP, the source and destination ports are also included.

TCP strict tracking

Applying firewall instances to interfaces

Interaction between fireall, NAT and routing

Control plane policing

Firewall denial of service protection

A stateful firewall or NAT creates a session for each traffic flow matching that firewall or NAT provided it is not blocked. This applies to both connection-oriented protocols (for example, TCP) and nonconnection-oriented protocols (for example, UDP and ICMP echo).

The Firewall Denial-of-Service Protection feature provides commands that perform the following tasks:
• Monitor the number of sessions, rate of session creation, and time last session was created
• Limit the maximum number of half-open sessions
• Rate-limit new sessions

Maximum half-open sessions

The definition of a half-open session depends upon the protocol. For TCP, a session is deemed to be half-open while it is going through the SYN, SYN-ACK, and ACK three-way handshake. For nonconnection-oriented protocols, a session is deemed half-open when traffic has been seen only in the forward direction.

A half-open session has a default timeout period of 30 seconds. If no further traffic is seen on this session for that time period, the session is "expired". An expired session then exists for a further 5 to 10 seconds before it is deleted and memory released. Once expired, a session is not available to traffic.

When the maximum half-open limit is reached, a matching packet is prevented from creating a session.

Session rate limiting

Session rate limiting limits the maximum rate at which a session can be created. A "rate" value and a "burst" value may be configured. These values combine to determine the interval over which the rate-limiting is evaluated. For example, if the rate limit is 20 sessions per second, and the burst is 100 sessions, the interval is 5 seconds (100/20). A maximum of 100 new sessions is allowed during that 5-second interval. In the show command output, the interval is shown in milliseconds.

When the rate-limit rate is reached, a matching packet is prevented from creating a session.

Rate limiting itself limits the maximum number of half-open sessions. For example, if the rate limit is 20 seconds and the default timeout of 30 seconds applies, the maximum number of half-open sessions is 600 sessions (20 x 30, that is, the number of sessions that can be created before the oldest expires).

If the rate-limiting and maximum half-open features are combined, with a rate limit of 20 sessions per second and a maximum half-open value of 300, then it takes 15 seconds (300/20) for the maximum half-open limit to be reached.

Example - limit max-halfopen TCP sessions inbound on dp0p1s1 only

interfaces {
        dataplane dp0p1s1 {
                address 10.10.1.1/24
                firewall {
                        in ACCEPT_ALL
                }
        }
        dataplane dp0p1s2 {
                address 10.10.2.1/24
        }
}

security {
        firewall {
                name ACCEPT_ALL {
                        rule 10 {
                                action accept
                                session
                        }
                }
        }
}

system {
        session {
                limit {
                        group {
                                name PROTOTCP {
                                        interface dp0p1s1
                                        rule 10 {
                                                parameter MAX_HALFOPEN_200
                                                protocol tcp
                                        }
                                }
                        }
                        parameter {
                                name MAX_HALFOPEN_200 {
                                        max-halfopen 200
                                }
                        }
                }
        }
}

The session limiter is configured on interface dp0p1s1, which means it is applied to both inbound and outbound sessions created on that interface. However because there in only an inbound firewall on dp0p1s1 then that means the session limiter only 'sees' inbound sessions.

v@vm-rtr-1# run sh session limit
Session limit parameter "MAX_HALFOPEN_200":
    Sessions allowed                                                               200
    Sessions blocked                                                               100
    Current session counts (estab/half-open/terminating)                     [0:200:0]
    Max session counts (estab/half-open/terminating)                         [0:200:0]
    Time since last session created                                              23.0s
    Sessions per sec avg (1sec/1min/5mins)                                     [0:0:0]
    Max sessions per sec avg (1sec/1min/5mins)                                 [0:0:0]
    Time since max sessions per sec (1sec/1min/5mins)              [never:never:never]
    Time since last session blocked                                              23.0s
    Max sessions blocked per sec avg (1sec/1min/5mins)                         [0:0:0]
    Features                                                              max-halfopen
    Max half-open sessions                                
        Maximum                                                                    200
        Sessions blocked                                                           100

Session limit group "PROTOTCP":
    Active on (dp0p1s1)
    rule    parameter  proto           allowed         blocked        
    ----    ---------  -----           -------         -------        
    10      PARAM1     tcp             200             100            
    condition - proto tcp

Example - rate-limit TCP sessions inbound on dp0p1s1 and dp0p1s2

interfaces {
        dataplane dp0p1s1 {
                address 10.10.1.1/24
                firewall {
                        in FW1
                }
        }
        dataplane dp0p1s2 {
                address 10.10.2.1/24
                firewall {
                        in FW1
                }
        }
}

security {
        firewall {
                name FW1 {
                        rule 10 {
                                action accept
                                session
                        }
                }
        }
}

system {
        session {
                limit {
                        group {
                                name GROUP1 {
                                        interface dp0p1s1
                                        interface dp0p1s2
                                        rule 10 {
                                                parameter PARAM1
                                                protocol tcp
                                        }
                                }
                        }
                        parameter {
                                name PARAM1 {
                                        rate-limit {
                                                rate 10
                                                burst 20
                                }
                        }
                }
        }
}

Example - using the global session limiter to rate-limit all sessions created on all interfaces.

Example - rate-limit TCP, UDP and ICMP sessions with a single rate-limit parameter, whilst maintaining separate counts for each protocol

After sending 100 packets each of UDP, TCP and ICMP (with different ports and/or source addresses):

Example - session limit outbound SNAT sessions on interface dp0p1s2

DoS protection configuration considerations

DoS protection requires that you configure a system session limit parameter and a session limit group. The parameter contains the configuration and state for maximum half-open and rate-limiting. The group contains the match criteria rule set and a list of interfaces to which that rule set is applied. The rule set contains a list of rules, each of which must reference a parameter.

Multiple interfaces can be configured on the same session limit group. A session limit group's rule set can reference multiple session limit parameters. Multiple session limit groups can reference the same session limit parameter.

A session limit parameter can be configured with one, both, or neither of the following features:
• Policing of maximum half-open sessions
• Rate-limiting new sessions

If not configured with either feature, the session limit parameter just gathers session rate and statistics
information.

A session limiter configured on an interface applies to both inbound and outbound sessions created on that interface. There is no direction (in or out) when configuring a session limit interface. The session limiter is applied to sessions that are created for both inbound and outbound if other firewall or NAT rules exist to create those sessions. Therefore, if a session limiter is configured for the dp0p1s1 interface, and there is only an input firewall on dp0p1s1, the session limiter applies only to inbound sessions because outbound sessions
exist.

A session limiter can limit only sessions that are created after the session limiter is created. For example, if there are 100 half-open sessions and a session limiter is created with max-half open configured

Session and packet logging

Configuration examples

List of configuration examples based on protocol and port numbers

Block SSH -

name blk-ssh {
rule 11 {
action drop
destination {
port 22
}
protocol tcp
}
}

Block HTTP/HTTPs -

name blk-http {
rule 16 {
action drop
destination {
port 80
}
protocol tcp
}
}
name blk-https {
rule 17 {
action drop
destination {
port 443
}
protocol tcp
}
}

Validation -

Post applying to interface -

sudo nc -vz -w 1 67.1.1.1 22
67-1-1-1.tcso.qwest.net [67.1.1.1] 22 (ssh) : Connection timed out

Before FW rule apply -

vyatta@danos-vnf1:~$ sudo nc -vz -w 1 67.1.1.1 22
67-1-1-1.tcso.qwest.net [67.1.1.1] 22 (ssh) open
vyatta@danos-vnf1:~$