Stateful Firewalls
Junos Network Secure Overview
Routers use firewalls to track and control the flow of traffic. Adaptive Services and MultiServices PICs employ a type of firewall called a . Contrasted with a firewall that inspects packets in isolation, a stateful firewall provides an extra layer of security by using state information derived from past communications and other applications to make dynamic control decisions for new communication attempts.
On ACX Series routers, the stateful firewall configuration is supported only on the ACX500 indoor routers.
Stateful firewalls group relevant into . A flow is identified by the following five properties:
Source address
Source port
Destination address
Destination port
Protocol
A typical Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) conversation consists of two flows: the initiation flow and the responder flow. However, some conversations, such as an FTP conversation, might consist of two control flows and many data flows.
Firewall rules govern whether the conversation is allowed to be established. If a conversation is allowed, all flows within the conversation are permitted, including flows that are created during the life cycle of the conversation.
You configure stateful firewalls using a powerful rule-driven
conversation handling path. A consists of
direction, source address, source port, destination address, destination
port, IP protocol value, and application protocol or service. In addition
to the specific values you configure, you can assign the value any to rule objects, addresses, or ports, which allows them
to match any input value. Finally, you can optionally negate the rule
objects, which negates the result of the type-specific match.
Firewall rules are directional. For each new conversation, the router software checks the initiation flow matching the direction specified by the rule.
Firewall rules are ordered. The software checks the rules in the order in which you include them in the configuration. The first time the firewall discovers a match, the router implements the action specified by that rule. Rules still unchecked are ignored.
Starting in Junos OS Release 14.2, MS-MPC and MS-MIC interface cards support IPv6 traffic for Junos Network Secure Stateful Firewall.
For more information, see Configuring Stateful Firewall Rules.
Stateful Firewall Support for Application Protocols
By inspecting the application protocol data, the AS or MultiServices PIC firewall can intelligently enforce security policies and allow only the minimal required packet traffic to flow through the firewall.
The firewall rules are configured in relation to an interface. By default, the stateful firewall allows all sessions initiated from the hosts behind the interface to pass through the router.
Stateful firewall ALGs are not supported on ACX500 routers.
Stateful Firewall Anomaly Checking
The stateful firewall recognizes the following events as anomalies and sends them to the IDS software for processing:
IP anomalies:
IP version is not correct.
IP header length field is too small.
IP header length is set larger than the entire packet.
Bad header checksum.
IP total length field is shorter than header length.
Packet has incorrect IP options.
Internet Control Message Protocol (ICMP) packet length error.
Time-to-live (TTL) equals 0.
IP address anomalies:
IP packet source is a broadcast or multicast.
Land attack (source IP equals destination IP).
IP fragmentation anomalies:
IP fragment overlap.
IP fragment missed.
IP fragment length error.
IP packet length is more than 64 kilobytes (KB).
Tiny fragment attack.
TCP anomalies:
TCP port 0.
TCP sequence number 0 and flags 0.
TCP sequence number 0 and FIN/PSH/RST flags set.
TCP flags with wrong combination (TCP FIN/RST or SYN/(URG|FIN|RST).
Bad TCP checksum.
UDP anomalies:
UDP source or destination port 0.
UDP header length check failed.
Bad UDP checksum.
Anomalies found through stateful TCP or UDP checks:
SYN followed by SYN-ACK packets without ACK from initiator.
SYN followed by RST packets.
SYN without SYN-ACK.
Non-SYN first flow packet.
ICMP unreachable errors for SYN packets.
ICMP unreachable errors for UDP packets.
Packets dropped according to stateful firewall rules.
ACX500 routers do not support IP fragmentation anomalies.
If you employ stateful anomaly detection in conjunction with stateless detection, IDS can provide early warning for a wide range of attacks, including these:
TCP or UDP network probes and port scanning
SYN flood attacks
IP fragmentation-based attacks such as teardrop, bonk, and boink
Configuring Stateful Firewall Rules
To configure a stateful firewall rule, include the rule rule-name statement at the [edit
services stateful-firewall] hierarchy level:
[edit services stateful-firewall] rule rule-name { match-direction (input | output | input-output); term term-name { from { application-sets set-name; applications [ application-names ]; destination-address (address | any-ipv4 | any-ipv6 | any-unicast) <except>; destination-address-range low minimum-value high maximum-value <except>; destination-prefix-list list-name <except>; source-address (address | any-ipv4 | any-ipv6 | any-unicast) <except>; source-address-range low minimum-value high maximum-value <except>; source-prefix-list list-name <except>; } then { (accept <skip-ids>| discard | reject); allow-ip-options [ values ]; syslog; } } }
ACX500 routers do not support applications and application-sets at the [edit services stateful-firewall rule rule-name term term-name from] hierarchy level.
On ACX500 routers, to enable syslog, include the stateful-firewall-logs CLI statement at the [edit services
service-set service-set-name syslog host local class] hierarchy
level.
edit services stateful-firewall hierarchy is not supported on SRX
series.
Each stateful firewall rule consists of a set of terms,
similar to a filter configured at the [edit firewall] hierarchy
level. A term consists of the following:
fromstatement—Specifies the match conditions and applications that are included and excluded. Thefromstatement is optional in stateful firewall rules.thenstatement—Specifies the actions and action modifiers to be performed by the router software. Thethenstatement is mandatory in stateful firewall rules.
ACX500 Series routers do not support the following while configuring stateful firewall rules:
match-direction(output | input-output)post-service-filterat the interface service input hierarchy level.IPv6 source address and destination address.
application-sets,application,allow-ip-optionsat the [edit services stateful-firewall] hierarchy level.Application Layer Gateways (ALGs).
Chaining of services within Multiservices Modular Interfaces Card (MS-MIC) and with inline-services (-si).
Class of service.
The following
show services stateful-firewallCLI commands are not supported:show services stateful-firewall conversations—Show conversationsshow services stateful-firewall flow-analysis—Show flow table entriesshow services stateful-firewall redundancy-statistics—Show redundancy statisticsshow services stateful-firewall sip-call—Show SIP call informationshow services stateful-firewall sip-register—Show SIP register informationshow services stateful-firewall subscriber-analysis—Show subscriber table entries
The following sections explain how to configure the components of stateful firewall rules:
- Configuring Match Direction for Stateful Firewall Rules
- Configuring Match Conditions in Stateful Firewall Rules
- Configuring Actions in Stateful Firewall Rules
Configuring Match Direction for Stateful Firewall Rules
Each rule must include a match-direction statement
that specifies the direction in which the rule match is applied. To
configure where the match is applied, include the match-direction statement at the [edit services stateful-firewall rule rule-name] hierarchy level:
[edit services stateful-firewall rule rule-name] match-direction (input | output | input-output);
ACX500 Series routers do not support match-direction (output
| input-output).
If you configure match-direction input-output, sessions
initiated from both directions might match this rule.
The match direction is used with respect to the traffic flow through the AS or Multiservices PIC. When a packet is sent to the PIC, direction information is carried along with it.
With an interface service set, packet direction is determined by whether a packet is entering or leaving the interface on which the service set is applied.
With a next-hop service set, packet direction is determined by the interface used to route the packet to the AS or Multiservices PIC. If the inside interface is used to route the packet, the packet direction is input. If the outside interface is used to direct the packet to the PIC, the packet direction is output. For more information on inside and outside interfaces, see Configuring Service Sets to be Applied to Services Interfaces.
On the PIC, a flow lookup is performed. If no flow is found, rule processing is performed. Rules in this service set are considered in sequence until a match is found. During rule processing, the packet direction is compared against rule directions. Only rules with direction information that matches the packet direction are considered. Most packets result in the creation of bidirectional flows.
Configuring Match Conditions in Stateful Firewall Rules
To configure stateful firewall match conditions, include the from statement at the [edit services stateful-firewall
rule rule-name term term-name] hierarchy level:
[edit services stateful-firewall rule rule-name term term-name] from { application-sets set-name; applications [ application-names ]; destination-address (address | any-ipv4 | any-ipv6 | any-unicast) <except>; destination-address-range low minimum-value high maximum-value <except>; destination-prefix-list list-name <except>; source-address (address | any-ipv4 | any-ipv6 | any-unicast) <except>; source-address-range low minimum-value high maximum-value <except>; source-prefix-list list-name <except>; }
ACX500 routers do not support applications and application-sets at the [edit services stateful-firewall rule rule-name term term-name from] hierarchy level.
The source address and destination address can be either IPv4 or IPv6.
You can use either the source address or the destination address
as a match condition, in the same way that you would configure a firewall
filter; for more information, see the Routing Policies, Firewall Filters, and Traffic Policers User Guide. You can
use the wildcard values any-unicast, which denotes matching
all unicast addresses, any-ipv4, which denotes matching
all IPv4 addresses, or any-ipv6, which denotes matching
all IPv6 addresses.
Alternatively, you can specify a list of source or destination
prefixes by configuring the prefix-list statement at the [edit policy-options] hierarchy level and then including either
the destination-prefix-list or the source-prefix-list statement in the stateful firewall rule. For an example, see Examples: Configuring Stateful Firewall Rules.
If you omit the from term, the stateful firewall
accepts all traffic and the default protocol handlers take effect:
User Datagram Protocol (UDP), Transmission Control Protocol (TCP), and Internet Control Message Protocol (ICMP) create a bidirectional flow with a predicted reverse flow.
IP creates a unidirectional flow.
You can also include application protocol definitions you have
configured at the [edit applications] hierarchy level;
for more information, see Configuring
Application Properties.
To apply one or more specific application protocol definitions, include the
applicationsstatement at the[edit services stateful-firewall rule rule-name term term-name from]hierarchy level.To apply one or more sets of application protocol definitions you have defined, include the
application-setsstatement at the[edit services stateful-firewall rule rule-name term term-name from]hierarchy level.Note:If you include one of the statements that specifies application protocols, the router derives port and protocol information from the corresponding configuration at the
[edit applications]hierarchy level; you cannot specify these properties as match conditions.
Configuring Actions in Stateful Firewall Rules
To configure stateful firewall actions, include the then statement at the [edit services stateful-firewall rule rule-name term term-name] hierarchy
level:
[edit services stateful-firewall rule rule-name term term-name] then { (accept | discard | reject); allow-ip-options [ values ]; syslog; }
You must include one of the following actions:
accept—The packet is accepted and sent on to its destination.accept skip-ids—The packet is accepted and sent on to its destination, but IDS rule processing configured on an MS-MPC is skipped.discard—The packet is not accepted and is not processed further.reject—The packet is not accepted and a rejection message is returned; UDP sends an ICMP unreachable code and TCP sends RST. Rejected packets can be logged or sampled.
The ACX500 indoor routers do not support the action accept
skip-ids.
You can optionally configure the firewall to record information
in the system logging facility by including the syslog statement
at the [edit services stateful-firewall rule rule-name term term-name then] hierarchy level.
This statement overrides any syslog setting included in
the service set or interface default configuration.
Configuring IP Option Handling
You can optionally configure the firewall to inspect IP header
information by including the allow-ip-options statement
at the [edit services stateful-firewall rule rule-name term term-name then] hierarchy level.
When you configure this statement, all packets that match the criteria
specified in the from statement are subjected to additional
matching criteria. A packet is accepted only when all of its IP option
types are configured as values in the allow-ip-options statement.
If you do not configure allow-ip-options, only packets
without IP header options are accepted.
ACX500 indoor routers do not support the configuration of allow-ip-options statement.
The additional IP header option inspection applies only to the accept and reject stateful firewall actions. This
configuration has no effect on the discard action. When
the IP header inspection fails, reject frames are not sent; in this
case, the reject action has the same effect as discard.
If an IP option packet is accepted by the stateful firewall, Network Address Translation (NAT) and intrusion detection service (IDS) are applied in the same way as to packets without IP option headers. The IP option configuration appears only in the stateful firewall rules; NAT applies to packets with or without IP options.
When a packet is dropped because it fails the IP option inspection, this exception event generates both IDS event and system log messages. The event type depends on the first IP option field rejected.
Table 1 lists the possible values
for the allow-ip-options statement. You can include a range
or set of numeric values, or one or more of the predefined IP option
settings. You can enter either the option name or its numeric equivalent.
For more information, refer to http://www.iana.org/assignments/ip-parameters.
IP Option Name |
Numeric Value |
Comment |
|---|---|---|
|
|
Any IP option |
|
|
– |
|
|
– |
|
|
– |
|
|
– |
|
|
– |
|
|
– |
|
|
– |
See Also
Configuring Stateful Firewall Rule Sets
The rule-set statement defines a collection of stateful
firewall rules that determine what actions the router software performs
on packets in the data stream. You define each rule by specifying
a rule name and configuring terms. Then, you specify the order of
the rules by including the rule-set statement at the [edit services stateful-firewall] hierarchy level with a rule statement for each rule:
[edit services stateful-firewall] rule-set rule-set-name { rule rule-name; }
The router software processes the rules in the order in which you specify them in the configuration. If a term in a rule matches the packet, the router performs the corresponding action and the rule processing stops. If no term in a rule matches the packet, processing continues to the next rule in the rule set. If none of the rules matches the packet, the packet is dropped by default.
Examples: Configuring Stateful Firewall Rules
The following example shows a stateful firewall configuration containing two rules, one for input matching on a specified application set and the other for output matching on a specified source address:
[edit services]
stateful-firewall {
rule Rule1 {
match-direction input;
term 1 {
from {
application-sets Applications;
}
then {
accept;
}
}
term accept {
then {
accept;
}
}
}
rule Rule2 {
match-direction output;
term Local {
from {
source-address {
10.1.3.2/32;
}
}
then {
accept;
}
}
}
}
The following example has a single rule with two terms. The first term rejects all
traffic in my-application-group that originates from the specified
source address, and provides a detailed system log record of the rejected packets. The
second term accepts Hypertext Transfer Protocol (HTTP) traffic from anyone to the
specified destination address.
[edit services stateful-firewall]
rule my-firewall-rule {
match-direction input-output;
term term1 {
from {
source-address 10.1.3.2/32;
application-sets my-application-group;
}
then {
reject;
syslog;
}
}
term term2 {
from {
destination-address 10.2.3.2/32;
applications http;
}
then {
accept;
}
}
}
The following example shows use of source and destination prefix lists. This requires two separate configuration items.
You configure the prefix list at the [edit policy-options] hierarchy
level:
[edit]
policy-options {
prefix-list p1 {
10.1.1.1/32;
10.2.2.0/24;
}
prefix-list p2 {
10.3.3.3/32;
10.4.4.0/24;
}
}
You reference the configured prefix list in the stateful firewall rule:
[edit]
services {
stateful-firewall {
rule r1 {
match-direction input;
term t1 {
from {
source-prefix-list {
p1;
}
destination-prefix-list {
p2;
}
}
then {
accept;
}
}
}
}
}
This is equivalent to the following configuration:
[edit]
services {
stateful-firewall {
rule r1 {
match-direction input;
term t1 {
from {
source-address {
10.1.1.1/32;
10.2.2.0/24;
}
destination-address {
10.3.3.3/32;
10.4.4.0/24;
}
}
then {
accept;
}
}
}
}
}
You can use the except qualifier with the prefix lists, as in the
following example. In this case, the except qualifier applies to all
prefixes included in prefix list p2.
[edit]
services {
stateful-firewall {
rule r1 {
match-direction input;
term t1 {
from {
source-prefix-list {
p1;
}
destination-prefix-list {
p2 except;
}
}
then {
accept;
}
}
}
}
}
For additional examples that combine stateful firewall configuration with other services and with virtual private network (VPN) routing and forwarding (VRF) tables, see the configuration examples.
You can define the service-set and assign it either as interface style or next-hop style.
See Also
Example: BOOTP and Broadcast Addresses
The following example supports Bootstrap Protocol (BOOTP) and broadcast addresses:
[edit applications]
application bootp {
application-protocol bootp;
protocol udp;
destination-port 67;
}
[edit services]
stateful-firewall bootp-support {
rule bootp-allow {
direction input;
term bootp-allow {
from {
destination-address {
any-unicast;
255.255.255.255;
}
application bootp;
}
then {
accept;
}
}
}
}
Example: Configuring Layer 3 Services and the Services SDK on Two PICs
You can configure the Layer 3 service package and the Services SDK on two PICs. For this example, you must configure an FTP or HTTP client and a server. In this configuration, the client side of the router interface is ge-1/2/2.1 and the server side of the router interface is ge-1/1/0.48. This configuration enables Network Address Translation (NAT) with stateful firewall (SFW) on the uKernel PIC and application identification (APPID), application-aware access list (AACL), and intrusion detection and prevention (IDP) on the Services SDK PIC for FTP or HTTP traffic.
The Services SDK does not support NAT yet. When NAT is required, you can configure the Layer 3 service package to deploy NAT along with the Services SDK such as APPID, AACL, or IDP.
The IDP functionality is deprecated for the MX Series for Junos OS release 17.1R1 and above.
To deploy the Layer 3 service package and the Services SDK on two PICs:
Example: Virtual Routing and Forwarding (VRF) and Service Configuration
The following example combines virtual routing and forwarding (VRF) and services configuration:
[edit policy-options]
policy-statement test-policy {
term t1 {
then reject;
}
}
[edit routing-instances]
test {
interface ge-0/2/0.0;
interface sp-1/3/0.20;
instance-type vrf;
route-distinguisher 10.58.255.1:37;
vrf-import test-policy;
vrf-export test-policy;
routing-options {
static {
route 0.0.0.0/0 next-table inet.0;
}
}
}
[edit interfaces]
ge-0/2/0 {
unit 0 {
family inet {
service {
input service-set nat-me;
output service-set nat-me;
}
}
}
}
sp-1/3/0 {
unit 0 {
family inet;
}
unit 20 {
family inet;
service-domain inside;
}
unit 21 {
family inet;
service-domain outside;
}
[edit services]
stateful-firewall {
rule allow-any-input {
match-direction input;
term t1 {
then accept;
}
}
}
nat {
pool hide-pool {
address 10.58.16.100;
port automatic;
}
rule hide-all-input {
match-direction input;
term t1 {
then {
translated {
source-pool hide-pool;
translation-type source napt-44;
}
}
}
}
}
service-set nat-me {
stateful-firewall-rules allow-any-input;
nat-rules hide-all-input;
interface-service {
service-interface sp-1/3/0.20;
}
}
}
Change History Table
Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.
accept skip-ids—The packet is accepted
and sent on to its destination, but IDS rule processing configured
on an MS-MPC is skipped.