Welcome to the Firewall Filters: Framework and Functionality module. By the end of this module, you should be able to describe the functionality and the framework of firewall filters. Other vendors often refer firewall filters to as, access control lists or ACLs. The Junos firewall filters are stateless and the software primarily uses them to control traffic passing through a Junos device. Stateless firewall filters examine each packet individually. Thus, unlike a stateful firewall that tracks connections and permits you to specify an action to take on all packets within a flow, a stateless firewall filter does not detect connections. The stateless nature of these filters can affect the way you write the firewall filters. Because the system does not keep state information about connections, you must explicitly allow traffic in both directions for each connection that you want to permit. Stateful firewall filters only require you to permit the initial connection and then automatically permit bidirectional communications for this connection. You can use firewall filters to restrict certain types of traffic from passing into and out of your network. You can also use firewall filters to perform monitoring tasks that help you plan an effective security strategy for your environment. Although routing policies and firewall filters serve different purposes and have different match and action conditions, they both have a common structure. As with routing policy, the fundamental building block of a firewall filter is the term. A firewall filter consists of one or more terms. The software evaluates the term sequentially until it reaches a terminating action. A term contains zero or more matched conditions and one or more actions. The from statements in the conditions described match conditions. The then statements describe the actions to be taken, if a match with the from statement occurs. If all the match conditions are true, Junos OS takes the specified action within the term. If no match conditions are specified, all traffic matches the firewall filter term and is subjected to the stated action. You use a filter to group multiple terms and establish the order in which the system evaluates the terms. The Junos firewall filters require at least one term. Firewall filters always include an invisible default term that discards all packets that the configuration does not explicitly permit through the defined terms. The default action is inbuilt. You cannot configure or disable it. Note that when implementing firewall filters, keep in mind that the order of the terms is important and can affect the results. If you must reorder terms within a filter, consider using the insert CLI command. You can specify the criteria to use for matching packets in from clauses within firewall filter terms. You can use many header fields as match criteria. However, remember that all header fields may not be available to you because of the way firewall filters are processed. When you specify a header field, Junos OS searches for a match at the location in the header where that field should exist. However, it does not verify to ensure that the header field makes sense in the given context. For example, if you specify that the software should search for the ACK flag in the TCP header, the software examines for that bit to be set at the appropriate location. But it does not verify that the packet is actually a TCP packet. Therefore, you must account for how the software examines for a match when writing filters. Here, you would have the system check that the packet was a TCP packet and whether the TCP ACK flag was set. The stateless nature of firewall filters can affect the information available in the processing of fragmented packets. Processing fragments are more complicated with stateless firewall filters than with a stateful firewall filter. The first fragment should have all the layer for headers, but subsequent fragments do not. Additionally, attempting to check layer for headers and fragments produces unpredictable results. Junos OS still attempts to evaluate the layer for headers, but the second and subsequent fragments do not contain these headers, so the matches are unpredictable. Match conditions fall into three categories, numeric range, address, and bit-field match conditions. You can generally use the same evaluation options for each condition within the category. Several texts synonyms exist that function as matched conditions. A text synonym match condition is equivalent to one or more matched conditions. For example, the tcp-established match condition is a text synonym for the tcp-flag ack or the tcp-flag rst match conditions. You can specify actions in the then clause of a term. Common firewall filter actions include terminating actions, flow control, and action modifiers. Terminating actions cause the evaluation of the firewall filter to stop. The accept action causes the system to accept the packet and continue the input or output processing of the packet. The discard action causes the system to discard the packet silently without sending an Internet Control Message Protocol or ICMP message to the source address. The reject action causes the system to discard the packet and send a message back to the source address. The default message sent by the system is an ICMP message with the destination unreachable message type and administratively prohibited message code. You can use an optional argument with the reject action to cause the system to send an ICMP message with a different message code or to cause it to send a TCP reset instead of an ICMP message. If you specify the TCP reset option, the system responds to TCP packets with a TCP reset, but it sends no message in response to non-TCP packets. Other common firewall filter actions affect the flow of policy evaluation. The next term action causes Junos OS to evaluate the next term. The next term action is useful if you want to set a policer or a DiffServ code point or DSCP value and still have the traffic evaluated by the rest of the filter. The next filter action does not exist for firewall filters. You can specify one or more action modifiers with any terminating or flow control action. If you specify an action modifier, but do not specify a terminating action, the system implies an action of accept. You can use the count, log, and syslog action modifiers to record information about packets. The forwarding-class and loss-priority action modifiers are used to specify class of service or CoS information. The policer action modifier provides you to invoke a traffic policer. Note that when you apply a firewall filter, the traffic that does not match a term that has an explicit or implicit accept action will be discarded even if it does not match any term with a discard action. Sometimes the action specified in a term is not one of the terminating actions accept, discard, or reject. In this case, the default behavior is that Junos applies an implicit accept action and filter evaluation terminates. In this filter, term 2 is never evaluated because term 1 always matches and accepts. If you want to apply an action modifier such as count, log, syslog, forwarding-class, loss-priority to a packet, and then continue to evaluate terms to decide whether to accept, discard, or reject, you need to use the next term flow control action. In this filter, term 2 is always evaluated because term 1 contains the next term action.
