Using TCP And UDP Service Object In Firewall Builder

Using TCP And UDP Service Object In Firewall Builder Author: [email protected]
http://www.fwbuilder.org

This article continues the series of articles on Fireall Builder, a graphical firewall configuration and management tool that supports many Open Source firewall platforms as well as Cisco IOS access lists and Cisco ASA (PIX). Firewall Builder was introduced on this site earlier with articles Getting Started With Firewall Builder, Using Built-In Revision Control In Firewall Builder, Using Built-in Policy Installer in Firewall Builder, Using Firewall Object In Firewall Builder. This article demonstrates how you can work with TCP and UDP service objects in Firewall Builder.

More information on Firewall Builder, pre-built binary packages and source code, documentation and Firewall Builder Cookbook can be found on the project web site at www.fwbuilder.org. Watch Project Blog for announcements and articles on all aspects of using Firewall Builder.

 

Using TCP and UDP Service Objects in Firewall Builder 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.

U (URG) The "urgent" pointer is valid A (ACK) The acknowledgment number is valid P (PSH) The receiver should pass this data to the application as soon as possible R (RST) Reset the connection S (SYN) Synchronize sequence numbers to initiate a connection. F (FIN) The sender is finished sending data.

"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 can not.

Usually the firewall can not 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. 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.

 

Using TCP Service in rules Single destination TCP port

Let's start with an example of using simple TCP service that describes HTTP protocol. Both the beginning and the end of the source port range in this service object are set to "0" which means the program will leave these out when it generates target firewall configuration. The destination port range is defined as "80-80" which means the object describes just single destination tcp port "80". All flag checkboxes are unchecked which means no flag-matching configuration will be generated.

Now we put this object in the "Service" element of a rule as shown on the next screenshot. To make this trivial example just a little bit more interesting, I configured the policy rule set as "Combined IPv4 and IPv6" and put two address objects in destination, one is IPv4 address and another is IPv6 address.

This rule compiles into the following for iptables:

# ================ 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

And for PF we get the following. Note that PF version was set to "any" or "3.x", this is why "keep state" was added. "Keep state" is default for PF 4.x and if version was configured as "4.x" in this firewall object, policy compiler would have dropped "keep state" from geenrated configuration.

# 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