Using TCP And UDP Service Object In Firewall Builder - Page 2

Source port range

In the next example we look at the TCP service object that defines specific source port range to match source ports greater than or equal to 1024:

Using this object in a rule as follows:

To make the rule slightly more realistic, I made it stateless using its options dialog (double click in the column "Options" of this rule and check checkbox "Stateless" in the first tab of the dialog). Lets see what the prgram generates when this rule is compiled for iptables:

# Rule 0 (global) 
# 
$IPTABLES -A FORWARD -i + -p tcp -m tcp --sport 1024:65535 -j ACCEPT

Here is what is generated for PF 3.x:

# Rule 0 (global) 
# 
pass in quick inet proto tcp from any port >= 1024 to any

And for PF 4.x we get "no state" because the rule is stateless and state matching is the default in PF 4.x:

pass in quick inet proto tcp from any port >= 1024 to any no state

Cisco IOS access list statement looks like this:

ip access-list extended e1_1_in 
! 
! Rule 0 (global) 
! 
permit tcp any gt 1024 any 
exit

Established

Some of the supported firewalls understand special flag "established" intended to match reply packets of the tcp session. Stateless systems, such as Cisco IOS extended access lists, match combination of tcp flags where flag "ACK" is set but flag "SYN" is cleared when this keyword is used in the acl rule. Stateful firewalls such as iptables or PF offer much better way to track and match reply packets because they can follow the states a tcp session goes through when it is opened, data transferred and finally session is closed. Firewall Builder provides an option of using flag "established" but supports it only for those firewall platforms where there is no better alternative. Attempt to use TCP service object with this flag set in rules for the firewall that supports stateful inspection causes an error.

Here is an example of the TCP service object with flag "Established" set and source port range "80-80", that is, this object describes TCP packets coming from the web server operating on the standard port 80 back to the client.

Using this object in a rule:

Here is the access list generated for Cisco IOS:

ip access-list extended e1_0_in 
! 
! Rule 0 (global) 
! 
permit tcp any eq 80 any established 
!

Here we have source port specification "eq 80" and keyword "established"

Attempt to compile this rule for iptables or PF causes an error:

Error (pf): TCPService object with option "established" is not supported 
by firewall platform "pf". Use stateful rule instead.

UDP Service

The UDP Service object is a generalization of the UDP protocol, which is a connectionless transport layer protocol. Many well-known applications use UDP as their transport, such as DNS (Domain Name System), DHCP (Dynamic Host Configuration Protocol), NTP (Network Time Protocol), and SNMP (Simple Network Management Protocol)..

As in TCP, UDP uses port numbers to distinguish applications from one another. The UDP packet header carries two port numbers: the source port and the destination port. The UDP Service object in Firewall Builder allows for a definition of ranges for both the source and the destination ports. The meaning of values assigned to the start and end of the range is the same as in the TCP Service object: ranges are inclusive, that is, both start and end ports of the range are included. Using ’0’ for both the start and end of the range means ’any port’. These rules work for both the source and destination ranges. The following screenshot shows the ’dns’ UDP Service object that represents the Domain Name System protocol which uses destination port 53.

Service objects in the Standard are not editable. However, you can copy-and-paste a copy of a service object into the User tree and edit it there, or you can right-click the ICMP folder in the User tree and select New ICMP Ser vice to create a service object from scratch.

The UDP Service dialog provides the following controls:

• Name: This is the name of the object
• The Source port range: These two controls define the start and the end of the source port range. They accept values 0 through 65535.
• The Destination port range: These two controls define the start and the end of the destination port range. They accept values 0 through 65535.
• Comments: This is a free-style text field used for comments.

Using UDP Service in rules

Single destination UDP port

In this example we'll use the UDP service object "domain" shown on screenshot above. The rule looks like this:

Here is iptables command generated for this rule:

# Rule 0 (global) 
# 
$IPTABLES -A FORWARD -i + -p udp -m udp --dport 53 -m state --state NEW -j ACCEPT

This rule got "-i +" clause because direction was set to Inbound but "Interface" column was left empty. To enforce inbound direction compiler uses "-i" option but since interface was not speficied, the rule gor attached to all interfaces which is defined by the +.

Here is generated PF 4.x configuration:

# Rule 0 (global) 
# 
pass in quick inet proto udp from any to any port 53

In the pf config direction is defined by the "in" keyword, and since no interface was requested, there is no "on <interface>".

Generated Cisco access list statement is quite trivial:

ip access-list extended fe0_0_in 
! 
! Rule 0 (global) 
! 
permit udp any any eq 53 
! 
exit

Source port range

The following UDP service object defines source port range of the ports with values greater than or equal to 1024:

Using this object in policy rule yields the following code for iptables:

# Rule 0 (global) 
# 
$IPTABLES -A FORWARD -i + -p udp -m udp --sport 1024:65535 -m state --state NEW -j ACCEPT

And for PF:

# Rule 0 (global) 
# 
# 
pass in quick inet proto udp from any port >= 1024 to any

Cisco access list statement:

ip access-list extended e1_0_in 
! 
! Rule 0 (global) 
! 
permit udp any gt 1024 any 
! 
exit