Juniper SRX: Understanding Firewall Filters
This post is going to be focussed on Juniper SRX firewall filters. They are important to understand and configure because they protect your firewall from malicious traffic passing through or destined to the firewall.
What is a Firewall Filter?
A firewall filter in Juniper SRX is a security feature that defines a policy that evaluates the context of connections and permits or denies traffic based on the context (source IP address, destination IP address, port numbers, TCP sequence information, and TCP connection flags), updating this information dynamically.
Firewall filters are also known as access control lists by other vendors like Cisco. Other names also include authorization profile and packet filter.
How does Juniper SRX Firewall Filter Work?
The firewall filter inspects each and every packet coming in and going out of the SRX device interfaces. It is stateless and does not keep track of the state of the connections. It can be configured to accept or discard a packet before it enters or exits a port or interface. That is how we control the type and quantity of traffic that enters the device or exits the device.
If a packet is inspected and deemed to be acceptable, a class-of-service and traffic can be applied. If a packet arrives on an interface for which no firewall filter is applied for the incoming traffic on that interface, the packet is accepted by default. By default, a packet that does not match a firewall filter is discarded.
Firewall filters can be applied to all interfaces, including the loopback interface to filter traffic entering or exiting the device.
An IPv6 filter cannot be applied to an IPv4 interface that is because the protocol family of the firewall filter and interface must match.
Firewall Filter Components
Terms
A term is a named structure in which match conditions and actions are defined. Each term has a unique name. A firewall filter contains one or more terms, and each term consists of match conditions and actions. Let's note that a firewall filter with a large number of terms can adversely affect both the configuration commit time and the performance of the Routing Engine. The order of terms is important and impact the results. A firewall filter include a default term that discards all traffic that other terms did not explicitly permit.
The implicit term looks like:
term implicit-discard-all {
then discard;
}
Match Conditions
A match condition or packet filtering criteria defines the values or fields that the packet must contain to be considered a match. If no match condition is specified, all packets are a match. So if we want an action to be taken for all packets, we can just ommit the match condition. We use the from keyword to specify the match statement. If a packet contains multiple match conditions, the packet must match all conditions to be considered as a match for the term.
If a single match condition is configured with multiple values, such as a range of values, a packet must match only one of the values to be considered a match for the firewall filter term.
The match condition that is selected for the term depends on the protocol family the we select for the firewall filter.
Example of match conditions:
- Source IP
- Destination IP
- TCP and UDP ports
- TCP flags
- IP options
- Incoming interface
- Outgoing interface
- ICMP packet type
- etc...
Actions
If all match conditions specified in the term are true, the action is taken. If the match condition of a term is ommited, the action specified is also taken.
It is a good practice to explicitly configure one or more actions per firewall filter term. Any packet that matches all the conditions of the term is automatically accepted unless the term specifies other or additional actions.
There are three (3) types of actions:
Terminating actions
-
Stops the evealuation for the filter for a specified packet
-
The specified action is performed, no additional term is evaluated
-
Terminating actions include
accept,discard, andreject.The
acceptaction causes the system to accept the packet. Thediscardaction causes the system to silently drop the packet without sending and ICMP message back to the source address. Therejectaction causes the systemt to discard the packet and send an ICMP message back to the source address.
Nonterminating actions
Nonterminating actions are used to perform other actions on a packet that do not halt the evaluation of the filter. Those actions include incrementing a counter (count), logging information about the packet header (log), sampling the packet data, sending information to a remote host using the system log functionality (syslog), or rate limiting traffic (policer).
If a term contains a nonterminating action without an explicit terminating action, such as accept, discard, or reject, the system will accept the matching packet by default. If we don't want the firewall filter action to terminate, we can use the next term action after the nonterminating action.
example 1: term 2 never get evaluated because term 1 action is nontermiating. So, the default accept action is taken right after log.
[edit firewall filter demo]
term 1 {
from {
source-address {
192.168.10.0/24;
}
}
then {
log;
}
}
term 2 {
then {
discard;
}
}
example 2: The have term 2 evaluated, we explicitly said it in term 1 using next term
[edit firewall filter test]
term 1 {
from {
source-address {
192.168.11.0/24;
}
}
then {
log;
next term;
}
}
term 2 {
then {
reject;
}
}
Flow control actions
A flow control action enables a device to perform configured actions on the packet and then evaluate the following term in the filter, rather than terminating the filter.
A standard firewall filter can have a maximum of 1024 next term actions. A commit error will occur if we exceed this number.
Firewall filter configuration
interfaces ge-0/0/1 {
unit 0 {
family inet {
filter {
input: inbound-filter-demo;
ouput: outbound-filter-demo;
}
}
}
}
input is used to filter traffic entering the interface and output is used to filter traffic exiting the interface.
Example of firewall filter configurations
# to enter firewall filter configuration
edit firewall filter
Block all bad ICMP messages
# create the filter
edit firewall filter BLOCK-BAD-ICMP
# create the term with the matching condition
set term ALLOW-TRUSTED-ICMP from protocol icmp
# allow icmp from selected ips
set term ALLOW-TRUSTED-ICMP from source-address 192.168.10.10/32
set term ALLOW-TRUSTED-ICMP from source-address 172.16.24.24/32
# accept ICMP from trusted sources
set term ALLOW-TRUSTED-ICMP then accept
# block untrusted ICMP
set term BLOCK-UNTRUSTED-ICMP from protocol icmp
set term BLOCK-UNTRUSTED-ICMP then discard
# allow all other traffice
set term ALLOW-OTHER-TRAFFIC then accept
# apply filter to interface
edit interfaces ge-0/0/1 unit 0 family inet
filter input BLOCK-BAD-ICMP
commit
See the configured filter
show firewall filter BLOCK-BAD-ICMP
Block all telnet
edit firewall filter BLOCK-ALL-TELNET
set term BLOCK-TELNET from protocol tcp
set term BLOCK-TELNET from destination-port telnet
set term BLOCK-TELNET then discard
set term ALLOW-OTHER-TRAFFIC then accept
then apply it to the loopback interface then commit the configuration
