15: Firewall Filters

Junos firewall filters are stateless; they process each packet individually. They do not track connections. Traffic must be explicitly allowed in both directions. Other vendors call these ACL’s.

Like routing policies, firewall filters consist of terms. If all parts of the ‘from’ filter match, the ‘then’ action is executed. The default action is ‘discard’. The order of terms is important. Terms can be reordered with the ‘insert’ CLI command.

Processing fragments is more complicated. The first fragment has all the Layer 4 filters, so all checks work for the first fragment. Checks on the TCP header will only work for the first fragment, so a check should also be made that the packet is the first fragment. Otherwise, the results are unpredictable.

Actions

Flow Control

‘next term’ causes Junos to evaluate the next term. Can be used, for example, to set a DSCP value and still have the traffic evaluated by the rest of the filter.

Action Modifiers

‘count’, ‘log’, ‘syslog’. If an action modifier is specified but there is no terminating action, the implied terminating action is ‘accept’ (not ‘discard’, which is the default action). If evaluation should continue, ‘next term’ must be added to the action.

Applying Filters

interfaces ge-0/0/1 {
    unit 0 {
        family inet {
            filter {
                input filter-in;
                output filter-out
            }
            address ...;
        }
    }
}

Example Filter

Confusingly, ‘from’ has nothing to do with the ‘source’ of the traffic.

filter web-server {
    from allow-web-traffic {
        destination-address {
            ....;
        }
        protocol tcp;
        port http;
    }
    then accept;
}

Example: Limiting SSH Access to the Management Plane

First, accept SSH traffic from trusted networks. Then, deny all other SSH traffic. Finally, allow all other traffic (such as OSPF, BGP, etc.).

policy-options {
    prefix-list trusted {
        ...;
    }
}

filter limit-ssh-access {
    term ssh-accept {
        from {
            source-prefix-list {
                trusted;
            }
            protocol tcp;
            destination-port ssh;
        }
        then accept;
    }
    term ssh-reject {
        from {
            protocol tcp;
            destination-port ssh;
        }
        then {
            discard;
        }
    }
    term else-accept {
        then accept;
    }
}

lo0 {
    unit 0 {
        family inet {
            filter {
                input limit-ssh-access;
            }
            address ...;
        }
    }
}

Show Commands

show firewall counter filter input-ff inbound-discarded
show firewall counter filter output-ff outbound-acccepted
clear firewall filter ...
show firewall log

Policing

If the first term in the firewall filter lacks a ‘from’ clause and contains a policer, all packets are subject to policing.

Two rate limits are configurable: * Bandwidth (average bits per second) * Maximum burst size (total number of bytes in a burst exceeding the bandwidth limit)

Calculate the maximum burst size by interface speed times time.

For example, interface speed is 100,000,000 and burst size is 5ms.

100,000,000bit/s * 5/1000s = 500,000bit/s = 62,500B/s

Policer in the ‘then’ clause:

then {
    policer class-example;
    forwarding-class assured-forwarding;
    accept;
}

policer class-example {
    if-exceeding {
        bandwidth-limit 10m;
        burst-size-limit 62500;
    }
    then forwarding-class best-effort;
}

Unicast RPF Check

Reverse Path Forwarding (RPF) checks that the routing table has a best route to the source address of the packet. If the routing table does not have a best route to the source address via the interface the packet arrived at, the packet is discarded into the bitbucket.

RPF works in ‘strict’ mode by default, which checks that the best route to the packet’s source address is via the interface it arrived at. In ‘loose’ mode, the router checks only that there is a route (not necessarily the best) via that interface. On interfaces with a default route, ‘loose’ mode is little use, as all packets will be accepted.

In networks with the possibility of asymmetric routing, ‘strict’ mode can cause legitimate traffic to be dropped. To work around this, consider all feasible routes;

routing-options {
    forwarding-table {
        unicast-reverse-path feasible-paths;
    }
}

Typically, only the edge devices need to be configured for RPF.

By default, DHCP and BOOTP packets will fail the RPF check (they use special addressing).

filter rpf-dhcp {
    term dhcp {
        from {
            source-address {
                0.0.0.0/32;
            }
            destination-address {
                255.255.255.255/32;
            }
        }
        then accept;
    }
}

ge-0/0/3 {
    unit 0 {
        family inet {
            rpf-check fail-filter rpf-dhcp;
            address ...'
        }
    }
}