6.2.1. IP Service

The IP service object describes protocols that are not ICMP, TCP, or UDP. (ICMP, TCP, and UDP have their own service objects.) An IP protocol is defined by the 8-bit field in the IP packet header. The screenshot below represents the ESP object (Encapsulating Security Payload, part of the IPSEC protocol family) which uses the IP protocol number 50.

Besides the protocol number, the header of the IP packet also has a field called "options" which is a variable-length list of optional information for the packet. Not all firewalls can examine options, and those that can usually have certain limitations as to what options they can match against. Firewall Builder tries to provide controls for many popular options supported by the most sophisticated firewalls. Not all options supported by Firewall Builder are supported by all target firewall platforms (Table 6-2).

Standard IP Service objects that come with Firewall Builder appear in the Standard tree, in the Services/IP branch.

You can create your own IP Service objects in the User library.

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 IP folder in the User tree and select New IP Service to create a service object from scratch.

In either case, the controls are the same.

The IP Service dialog provides the following controls:

• Name:

  This is the name of the object

• Protocol:

  This is the protocol number.

• DiffServ

  You can specify DSCP or TOS using the radio buttons. In either case, specify a code (or class) in the field. If you do not specify a code or class, Firewall Builder ignores the DiffServ type (DSCP or TOS).

• Options:

  These flags represent 'Options' flags in the IP header:

  lsrr (loose source route)

  ssrr (strict source route)

  rr (record route)

  timestamp

  all fragments

  short fragments

• Comments:

  This is a free-style text field used for comments.

6.2.1.1. Using IP service objects in policy rules

Consider the following IP Service objects:

Table 6-3.

Object EF has DSCP matching turned on, matching traffic class EF. Object TOS 0x10 matches packets with TOS bits set to 0x10 (low delay). Object all_fragments has flag "all fragments" turned on, and finally object lsrr matches "loose source routing" option. Here is what we get for iptables when we use these objects in policy rules as follows:

Figure 6-72.

# Rule 0 (global)
# 
$IPTABLES -N RULE_0
$IPTABLES -A FORWARD -p all  -f   -j RULE_0 
$IPTABLES -A FORWARD -p all  -m ipv4options  --lsrr  -j RULE_0 
$IPTABLES -A RULE_0  -j LOG  --log-level info --log-prefix "RULE 0 -- DENY "
$IPTABLES -A RULE_0  -j DROP 
# 
# Rule 1 (global)
# 
$IPTABLES -A FORWARD  -o + -p all  -m dscp --dscp-class EF  -m state \
--state NEW  -j ACCEPT 
$IPTABLES -A FORWARD  -o + -p all  -m tos --tos 0x10  -m state --state NEW  \
-j ACCEPT 

              

The compiler for iptables uses module ipv4options to match lsrr, command line option -f to match all fragments, module tos to match TOS and module dscp to match dscp class.

When compiled for IPv6, these rules yield the following iptables commands:

# Rule 0 (global)
# 
$IP6TABLES -N RULE_0
$IP6TABLES -A FORWARD  -m frag --fragmore  -j RULE_0 
$IP6TABLES -A RULE_0  -j LOG  --log-level info --log-prefix "RULE 0 -- DENY "
$IP6TABLES -A RULE_0  -j DROP 
# 
# Rule 1 (global)
# 
$IP6TABLES -A FORWARD  -o +  -m dscp --dscp-class EF  -m state --state NEW  -j ACCEPT 
$IP6TABLES -A FORWARD  -o +  -m tos --tos 0x10  -m state --state NEW  -j ACCEPT 

              

ip6tables does not have the command line flag -f, instead it uses module frag to match fragments. Firewall Builder currently does not support ip6tables module ipv6header, and source routing options do not exist in IPv6, so object "lsrr" cannot be used in rules.

PF cannot match DSCP bits and source routing options but can match TOS. Trying the same IP Service object "tos 0x10" in policy rules for PF:

Figure 6-73.

pass out  quick inet  from any  to (eth0)  tos 0x10 keep state

              

Cisco IOS access lists cannot match source route options but can match fragments and TOS and DSCP bits. Here is what we get if we try to compile the same rules using the same IP Service objects for Cisco IOS:

Figure 6-74.

ip access-list extended e1_0_out
! 
! Rule  0 (global)
! 
  deny   ip any  any  log fragments 
! 
! Rule  1 (global)
! 
  permit ip any  any  tos 0x10
  permit ip any  any  dscp EF
exit

              

6.2.2. Using ICMP and ICMP6 Service Objects in Firewall Builder

The ICMP Service object is a generalized representation of the ICMP protocol. ICMP packets are often used to communicate error messages that are acted upon by either the IP layer or higher layer protocols (TCP or UDP). ICMP can also be used as a simple query protocol.

Firewall Builder has service objects for both IPv4 and IPv6. ICMP Service objects for IPv6 are called ICMP6 Service. The standard ICMP Service objects that come with Firewall Builder appear in the Standard Objects library, in the Services/ICMP branch. User-defined ICMP and ICMP6 service objects will appear in the library User in the same Services/ICMP branch.

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 Service to create a service object from scratch.

As a firewall administrator, you need to understand the nature and purpose of ICMP in order to properly configure the firewall to block unwanted ICMP messages while permitting useful ones.

ICMP packets have two header fields that distinguish particular ICMP messages: the type and code fields. There are many different types and classes of ICMP messages. See http://www.iana.org/assignments/icmp-parameters for IPv4 types and classes and http://www.iana.org/assignments/icmpv6-parameters (http://www.iana.org/assignments/icmpv6-parameters) for IPv6 types and classes.

Any combination of the type and code values is allowed in the ICMP or ICMP6 Object. For example the following two screen shots illustrate definitions of ICMP and ICMP6 objects for the request packet of well known ping protocol. The type codes are different for IPv4 and IPv6 variants, although the code is equal to 0 in both:

Both ICMP and ICMP6 allow value "any" in type or code fields. For example, this can be used to build an object to match a family of ICMP messages with the same type but any code:

Both IPv4 and IPv6 ICMP Service dialogs provide the following controls:

• Name: This is the name of the object.

• ICMP Type and Code:

  • Type: The ICMP message type. This control consists of a numeric selector that lets you specify the message type. To specify "any" type, set the control to any.

  • Code: The ICMP message code. This control consists of a numeric selector that lets you specify the message code. To specify "any" code, set the control to any.

• Comment: This is a free-style text field used for comments.

# ================ IPv4

# Rule 0 (global)
# 
$IPTABLES -A FORWARD  -i + -p icmp  -m icmp  --icmp-type 8/0 \
     -m state --state NEW  -j ACCEPT 
 
# ================ IPv6

# Rule 0 (global)
# 
$IP6TABLES -A FORWARD  -i + -p ipv6-icmp  -m icmp6 --icmpv6-type 128/0 \
     -m state --state NEW  -j ACCEPT 

              

# Rule  0 (global)
# 
pass in   quick inet proto icmp  from any  to any icmp-type 8 code 0

# Rule  0 (global)
# 
pass in   quick inet6 proto icmp6  from any  to any

              

6.2.3. TCP Service

The TCP Service object is a generalization of the TCP protocol, which provides a connection-oriented reliable byte stream service. Many well-known, frequently used application protocols use TCP protocol: FTP (File Transfer Protocol), SMTP (Simple Mail Transfer Protocol), HTTP (Hyper Text Transfer Protocol), and so on. The TCP header contains special fields indicating source and destination port numbers that are used to identify the sending and receiving application. These two values, along with the source and destination IP addresses in the IP header, uniquely identify each connection.

Since port numbers are used to distinguish applications using the data stream provided by the TCP protocol, each application should use a unique port number. To ensure interoperability, these numbers must be assigned by a central authority in a coordinated manner. Internet Assigned Numbers Authority (IANA) does just that. Assigned TCP and UDP port numbers can be looked up at http://www.iana.org/assignments/port-numbers. Most Unix systems also come with a /etc/services file that contains a list of assigned port numbers.

Firewall Builder comes with a collection of predefined TCP Service objects with port numbers already configured. You can simply use these objects in your policy rules, so you do not have to look up port numbers every time you need them. These objects are part of the Standard Objects library and are located in the Services / TCP branch.

The typical TCP Service object is represented in the following screenshot:

In Firewall Builder, the TCP Service object is a generalization of TCP protocol. The TCP header of a packet carries only one fixed value for the source port and one fixed value for the destination port. The TCP Service object allows a range of values to be used for the source and destination ports. This allows a single TCP Service object to describe either a family of protocols using consecutive port numbers, or a protocol that may use variable port numbers or simply many protocols that use port numbers from a certain range. For example, on Unix systems, TCP sessions opened by a privileged process always have their source port number assigned from a range below 1024, while unprivileged processes use source port numbers from a range starting from 1024 and above. The TCP Service object with a source port range defined as shown in the following screenshot describes all privileged TCP sessions.

Using "0" as both start and end values for a range means "any value" for that range. The source port range of the "privileged TCP" object starts from 0 and ends at 1023 (port ranges are inclusive in Firewall Builder), while its destination port range's start and end are both set to zero, which means "any destination port". This object describes any TCP protocol with a source port in range 0-1023 and any destination port.

If all you need is to create an object to describe the TCP protocol with a particular destination port, just use the same port number for both the start and end of a destination port range (which effectively creates a range that consists of a single value). The example in Figure 6-70 shows such a service.

The TCP header also contains a collection of one-bit fields, or flags, that carry a variety of control information. For example, the SYN and ACK flags are used for connection establishment and the FIN flag is used for connection termination. Certain combinations of flags are not allowed during the normal protocol operation and may cause unpredicted reactions in some systems; because of this, the firewall administrator may want to block TCP packets with unwanted combination of flags.

There are six flags in the TCP header. We just briefly mention them here; more information can be found in TCP/IP Illustrated, vol 1 by W. Richard Stevens, chapter 17.

"Established" is not a TCP flag. Instead, checking this box causes the firewall to match any packet in an established session. Checking this checkbox disables the other TCP flag controls.

Firewall Builder supports all six flags, although not all target firewall platforms can match all combinations of TCP flags or any flags at all. For example, iptables, pf, ipfilter and ipfw can match flags and their combinations, but Cisco PIX cannot.

Usually the firewall cannot only match a combination of flags, but can also examine only a given subset of TCP flags. Firewall Builder provides two sets of checkboxes for TCP flags and flag masks (see screenshot below). Checkboxes in the first row control TCP flags that we want the firewall to examine and checkboxes in the second row tell it whether they should be set or cleared. Only flags whose checkboxes in the first row are set will be looked at by the firewall. (If you check a box in the bottom row while leaving the checkbox above it unchecked, the flag will be ignored.)

The object in the screenshot matches a TCP packet with any combination of port numbers, the TCP flag SYN set, and all other flags cleared. The firewall will examine all TCP flags.

A Combination of flags and a mask can be used in a rule that looks for some flags to be set or unset and ignores other ones regardless of their state. For example, we can create a rule that detects a so called "null scan" which is done using TCP packets with all flags cleared. For this rule we create a TCP Service object "tcp null scan" where all flag masks are set but all TCP flags are cleared. This means we examine all flags but only match them if they are all cleared. This object is represented in the following screenshot:

TCP Service dialog provides the following controls:

• Name: This is the name of the object

• Source port range: These two controls define the start and end of the source port range. They accept values 0 through 65535.

• Destination port range: These two controls define the start and end of the destination port range. They accept values 0 through 65535.

• TCP Flags: TCP flags and masks, see above. The Established checkbox causes the firewall to match packets in established sessions. Selecting this checkbox disables the other TCP flag controls.

• Comments: This is a free-style text field used for comments.

# ================ IPv4

# Rule 0 (global)
# 
$IPTABLES -A FORWARD -p tcp -m tcp  -d 70.85.175.170 \
     --dport 80  -m state --state NEW  -j ACCEPT 

# ================ IPv4

# Rule 0 (global)
# 
$IP6TABLES -A FORWARD -p tcp -m tcp  -d 2001:470:1f0e:162::2 \
     --dport 80  -m state --state NEW  -j ACCEPT 
              

# Rule  0 (global)
# 
pass in   quick inet proto tcp  from any  to 70.85.175.170 port 80 keep state
pass out  quick inet proto tcp  from any  to 70.85.175.170 port 80 keep state

# Rule  0 (global)
# 
pass in   quick inet6 proto tcp  from any  to 2001:470:1f0e:162::2 port 80 keep state
pass out  quick inet6 proto tcp  from any  to 2001:470:1f0e:162::2 port 80 keep state

              

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

              

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

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

              

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

              

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

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

              

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

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

              

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

              

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

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

              

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

              

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

6.2.5. User Service

User Service object matches the owner of the process on the firewall that send the packet. It translates to the "owner" match in iptables and "user" parameter for PF.

• Name:

  This is the name of the object

• User id

  The user ID of the user account on the firewall device that the firewall should use to match packets.

• Comments:

  This is a free-style text field used for comments.

User Service object has only one parameter besides the name and comment: it is user id that the firewall should use to match packets.

The User Service object is only supported for iptables and PF.

Let's look at how the simple rule shown in Figure 6-95 compiles for iptables and PF.

The firewall can associate a packet with a user only if the packet originated on the firewall. Packets that transit the firewall have no information about the user who owned the process that created these packets and sent them out because this process ran on an entirely different computer. For this reason, the object in the Source column must be the firewall.

# Rule 0 (global)
# 
$IPTABLES -A OUTPUT -m owner --uid-owner 500  -j DROP 
	

The User Service translated into the owner match for iptables. See the iptables man page for a more detailed explanation of this match.

# Tables: (1)
table  { en0 , 192.168.1.1 }

# Rule  0 (global)
# 
# 
block out  quick inet  from   to any user 500 
	

Here the table tbl.r0.s was created to hold IP addresses that belong to the firewall. The rule matches source addresses and also the user ID of the owner using the "user" clause.

User Service is actually one of the simplest service object types in Firewall Builder, but it provides the facility for a basic per-user control on Linux and BSD machines. This service object can be used in rules with actions that reroute packets ("Route" action) or in the NAT rules, for example to redirect web access via proxy.

6.2.6. Custom Service

The Custom Service object can be used to inject arbitrary code into the generated firewall script. Any combination of options allowed in the target firewall command line language that does not fit into a strict model of standard service object types can be expressed using the Custom Service object. For example, iptables comes with a collection of modules that adds an ability to match complex combinations of packet parameters or header fields that are not supported by a standard code. One of the modules adds the ability to match any string in the packet's payload which can be quite useful to quickly build firewall rule to block some new protocol that uses non-specific combination of ports and other parameters. This ability is sometimes used to write rules to block network trojans or viruses with known signatures.

The following screenshot represents a Custom Service object that uses the capabilities of the string module. Command line options specific for this module are in the "Code String" field.

The Custom Service dialog provides the following controls:

• Name: This is the name of the object.

• Platform: This is a pull-down menu that shows a list of all firewall platform targets available in Firewall Builder.

• Code String: This is a line of code in the target firewall language. (This is the heart of the Custom Service object.)

• Protocol Name: Use this if you want to restrict the Custom Service Object to a particular protocol: TCP, UDP, or ICMP. Default is "any". For example, if this field is set to "tcp", then policy compiler for iptables generates command with parameter "-p tcp" and then inserts code defined in the "Code String" field of the custom service object.

• Address Family: Specify IPv4 or IPv6. Policy compilers use information about address family to properly use the object while compiling IPv4 or IPv6 rule sets.

• Comments: This is a free-style text field used for comments.

# Rule 0 (global)
# 
$IPTABLES -N In_RULE_0
$IPTABLES -A INPUT  -i + -p tcp -m tcp  --dport 22 \
      -m recent --rcheck --seconds 60 --hitcount 2  -j In_RULE_0 
$IPTABLES -A In_RULE_0   -j LOG  --log-level info --log-prefix "RULE 0 -- DENY "
$IPTABLES -A In_RULE_0  -j DROP 
# 
# Rule 1 (global)
# 
$IPTABLES -A INPUT  -i + -p tcp -m tcp  --dport 22 -m recent --set \
      -m state --state NEW  -j ACCEPT 
# 

                

# 
# Rule 0 (global)
# 
$IPTABLES -N In_RULE_0
$IPTABLES -A INPUT  -i + -p tcp -m tcp  --dport 22 \
      -m recent --rcheck --seconds 60 --hitcount 2  -j In_RULE_0 
$IPTABLES -A In_RULE_0   -j LOG  --log-level info --log-prefix "RULE 0 -- CUSTOM "
$IPTABLES -A In_RULE_0 -j TARPIT
# 
# Rule 1 (global)
# 
$IPTABLES -A INPUT  -i + -p tcp -m tcp  --dport 22 -m recent --set \
      -m state --state NEW  -j ACCEPT 
#