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 stateful firewall. Contrasted with a stateless 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.

Stateful firewalls group relevant flows into conversations. 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 rule 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.

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 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.

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

• from statement—Specifies the match conditions and applications that are included and excluded. The from statement is optional in stateful firewall rules.

• then statement—Specifies the actions and action modifiers to be performed by the router software. The then statement 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-filter at the interface service input hierarchy level.

• IPv6 source address and destination address.

• application-sets, application, allow-ip-options at 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-firewall CLI commands are not supported:

  • show services stateful-firewall conversations—Show conversations

  • show services stateful-firewall flow-analysis—Show flow table entries

  • show services stateful-firewall redundancy-statistics—Show redundancy statistics

  • show services stateful-firewall sip-call—Show SIP call information

  • show services stateful-firewall sip-register—Show SIP register information

  • show services stateful-firewall subscriber-analysis—Show subscriber table entries

• 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:

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:

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 applications statement 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-sets statement 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:

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.

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.

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.

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:

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 show 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:

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.

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:

You reference the configured prefix list in the stateful firewall rule:

This is equivalent to the following configuration:

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.

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.

Example: BOOTP and Broadcast Addresses

The following example supports Bootstrap Protocol (BOOTP) and broadcast addresses:

Example: Configuring Layer 3 Services and the Services SDK on Two PICs

1. In configuration mode, go to the following hierarchy level:
2. In the hierarchy level, configure the conditions for the stateful firewall rule r1.

   In this example, the stateful firewall term is ALLOWED-SERVICES. Enclose the application names—junos-ftp, junos-http, and junos-icmp-ping—in brackets for application-name.
3. Configure the conditions for the stateful firewall rule r2.

   In this example, the stateful firewall term is term1.
4. Go to the following hierarchy level and verify the configuration:
5. Go to the following hierarchy level:
6. In the hierarchy level, configure the NAT pool.

   In this example, the NAT pool is OUTBOUND-SERVICES and the IP address is 10.48.0.2/32.
7. Configure the NAT rule.

   In this example, the NAT rule is SET-MSR-ADDR, the NAT term is TRANSLATE-SOURCE-ADDR, and the source pool is OUTBOUND-SERVICES. Enclose the application names—junos-ftp, junos-http, and junos-icmp-ping—in parentheses for application-name.
8. Go to the following hierarchy level and verify the configuration:
9. Go to the following hierarchy level:
   Note

   The [edit security idp] statements are deprecated for the MX Series for Junos OS release 17.1R1 and above.

10. In the hierarchy level, configure the IDP policy.

    In this example, the IDP policy is test1, the rule is r1, the predefined attack is FTP:USER:ROOT, and the predefined attack group is "Recommended Attacks".
11. Configure the trace options for IDP services.

    In this example, the log file name is idp-demo.log.
12. Go to the following hierarchy level and verify the configuration:
13. Go to the following hierarchy level:
14. In the hierarchy level, configure the AACL rules.

    In this example, the AACL rule is app-aware and the term is t1.
15. Go to the following hierarchy level and verify the configuration:
16. Go to the following hierarchy level:
17. Configure the APPID profile.

    In this example, the APPID profile is dummy-profile.
18. Configure the IDP profile.

    In this example, the IDP profile is test1.
19. Configure the policy decision statistics profile.

    In this example, the policy decision statistics profile is lpdf-stats.
20. Configure the AACL rules.

    In this example, the AACL rule name is app-aware.
21. Configure two stateful firewall rules.

    In this example, the first rule is r1 and the second rule is r2.
22. In the hierarchy level, configure the service set to bypass traffic on service PIC failure.
23. Configure interface-specific service set options.

    In this example, the services interface is ms-0/1/0.
24. Go to the following hierarchy level and verify the configuration:
25. Go to the following hierarchy level:
26. In the hierarchy level, configure optional notification parameters for the services interface. Note that it is required only for debugging.

    In this example, the host to notify is local.
27. Configure two stateful firewall rules.

    In this example, the first rule is r1 and the second rule is r2.
28. Configure NAT rules.

    In this example, the NAT rule is SET-MSR-ADDR.
29. Configure interface-specific service set options.

    In this example, the services interface is sp-3/1/0.
30. Go to the following hierarchy level and verify the configuration:
31. Go to the following hierarchy level:
32. In the hierarchy level, configure the interface.

    In this example, the interface is ge-1/2/2.1.

33. Go to the following hierarchy level:
34. In the hierarchy level, configure the service set for received packets.

    In this example, the input service set is App-Aware-Set.

35. Configure the service set for transmitted packets.

    In this example, the output service set is App-Aware-Set.

36. Go to the following hierarchy level:
37. In the hierarchy level, configure the interface address.

    In this example, the interface address is 10.10.9.10/30.

38. Go to the following hierarchy level and verify the configuration:
39. Go to the following hierarchy level:
40. In the hierarchy level, configure the interface.

    In this example, the interface is ge-1/1/0.48.

41. Go to the following hierarchy level:
42. In the hierarchy level, configure the service set for received packets.

    In this example, the service set is NAT-SFW-SET.

43. Configure the service set for transmitted packets.

    In this example, the service set is NAT-SFW-SET.

44. Go to the following hierarchy level:
45. Configure the interface address.

    In this example, the interface address is 10.48.0.1/31.
46. Go to the following hierarchy level and verify the configuration:
47. Go to the following hierarchy level:
48. In the hierarchy level, configure the interface.

    In this example, the interface is ms-0/1/0.0.

49. Go to the following hierarchy level:
50. In the hierarchy level, configure the protocol family.
51. Go to the following hierarchy level and verify the configuration:
52. Go to the following hierarchy level:
53. In the hierarchy level, configure the interface.

    In this example, the interface is sp-3/1/0.0.

54. Go to the following hierarchy level:
55. In the hierarchy level, configure optional notification parameters for the services interface. Note that it is required only for debugging.

    In this example, the host to notify is local.
56. Go to the following hierarchy level:
57. In the hierarchy level, configure the protocol family.
58. Go to the following hierarchy level and verify the configuration:
59. Go to the following hierarchy level:
60. In the hierarchy level, configure the redundancy settings.
61. Configure the FPC and PIC.

    In this example, the FPC is in slot 0 and the PIC is in slot 1.
62. Configure the number of cores dedicated to run control functionality.

    In this example, the number of control cores is 1.
63. Configure the number of processing cores dedicated to data.

    In this example, the number of data cores is 7.
64. Configure the size of the object cache in megabytes. Only values in increments of 128 MB are allowed and the maximum value of object cache can be 1280 MB. On MS-100, the value is 512 MB.

    In this example, the size of the object cache is 1280 MB.
65. Configure the size of the policy database in megabytes.

    In this example, the size of the policy database is 64 MB.
66. Configure the packages.

    In this example, the first package is jservices-appid, the second package is jservices-aacl, the third package is jservices-llpdf, the fourth package is jservices-idp, and the fifth package is jservices-sfw. jservices-sfw is available only in Junos OS Release 10.1 and later.
67. Configure the IP network services.
68. Go to the following hierarchy level and verify the configuration:

Example: Virtual Routing and Forwarding (VRF) and Service Configuration

The following example combines virtual routing and forwarding (VRF) and services configuration: