Some sites make use of network monitoring tools to manage their networks. These tools often use protocols such as UDP and ICMP. You cannot use the plug or authenticated circuit proxies to allow these protocols through the Gauntlet firewall because these proxies support only TCP-based traffic. You may also want to allow a TCP-based application through the Gauntlet Firewall. However, the application makes use of multiple ports for communicating and is unsuitable for use with either the plug or authenticated circuit proxies.
The Gauntlet Firewall includes a packet screening facility. Use the packet screening facility to allow various types of traffic, such as UDP and ICMP packets, through the Gauntlet Firewall.
The following sections explain how the packet screening facility works, how packet screening rules work, and how to configure packet screening rules:
The packet screening facility, implemented as part of the IRIX kernel, reads rules you create (and default Gauntlet Firewall rules) and processes packets accordingly. Use the packet screening facility to discard packets, pass packets on to the proxies, or bypass the proxies entirely. You can configure the Gauntlet firewall to screen packets based on these options:
source IP address
destination IP address
interface
protocol
source port
destination port
Using these options, you can configure the Gauntlet Firewall to allow a UDP-based service through on a particular port. For example, a host on one side of your Gauntlet Firewall could use ntpdate, which uses a UDP-based protocol, to set the time on a host on your service network.
The Gauntlet Firewall default packet screening rules implement IP-spoofing checks. These rules deny any packets that appear on the outside interface of the firewall with source IP addresses that match IP addresses of hosts on the inside, trusted network.
The Gauntlet Firewall logs packets denied by the packet screening facility. These logging capabilities are more extensive than those provided without the Gauntlet firewall in place. However, the packet screening facility does not normally log packets permitted through the screen. You do not receive as much logging information when using packet screening as when using an application proxy.
The packet screening facility is part of the IRIX kernel. When the boot process for the firewall begins, the packet screening rules are empty. This causes the firewall to refuse all traffic. As part of the boot process, the packet screening facility loads its screening rules from configuration files. Each time the firewall receives a packet, the kernel compares header information in the packet to appropriate screening rules and determines what to do with the packet.
If header information does not match any of the rules, the firewall drops the packet. This is in keeping with the “that which is not permitted is denied” philosophy of the Gauntlet Firewall.
The packet screening facility understands two different sets of rules: local and forward. Together, these rules cover any packets the Gauntlet Firewall receives.
Local rules apply to any packet destined for the Gauntlet Firewall itself. For example, if the Gauntlet Firewall receives a ping request from an untrusted host for the outside interface of the firewall (ping fire-out.yoyodyne.com), the packet screening facility uses local rules to determine what to do with ping packets.
Forward rules apply to any packets destined for hosts other than the Gauntlet Firewall. For example, if the Gauntlet Firewall receives a TELNET request from a trusted host to connect with an untrusted host (telnet dialin.bigu.edu), the packet screening facility uses forward rules to determine what to do with TELNET packets.
Each packet screening rule specifies one of three actions: deny, permit, or absorb.
A deny rule instructs the Gauntlet Firewall to drop the packet and log information. The kernel does not notify the packet sender that it dropped the packet. The default Gauntlet Firewall forward and local screening rules include rules to detect IP spoofing. These rules deny packets that appear on the outside interfaces of the Gauntlet Firewall pretending to come from inside by presenting source IP addresses that match the IP addresses of hosts on the inside, trusted network.
A permit rule instructs the Gauntlet Firewall to process the packet. If the packet is destined for the Gauntlet Firewall itself, the firewall accepts the packet. The kernel passes handling of the packet to the appropriate program, such as one of the proxies. If the packet is destined for another host, the firewall routes the packet to the destination host, bypassing the proxies.
Local screening rules include a rule that allows the Gauntlet Firewall to accept packets destined for the IP address of each interface. For example, the firewall is listed in DNS as the mail exchanger for your domain. Local screening rules on the firewall include rules that permit the Gauntlet Firewall to accept these packets.
If your security policy permits, you could create a forward screening rule that permits the firewall to forward ICMP packets. This screening rule allows you to use the ping and traceroute networking tools to monitor hosts on your internal network on either side of the firewall.
An absorb rule instructs the Gauntlet Firewall to process the packet as if the packet were destined for the firewall itself. Absorb rules are generally included as part of the forward rules. The local rules affect only those packets that are destined for the Gauntlet Firewall itself. Including an absorb rule in the local rules is redundant.
The Gauntlet Firewall includes default absorb rules that implement transparency from the inside to the outside. These absorb rules tell the packet screening facility to absorb the packet and process the packet locally, even though the destination IP address is some other system.
For example, a user on a trusted host wants to access her account at Big University directly (telnet dialin.bigu.edu). The default route for the trusted network goes through the Gauntlet Firewall. If there is no absorb rule in place, the packet screen uses the permit and deny rules in the forward rules to determine what to do with the packet. The kernel never passes the packet to the proxies.
And, if the forward rules contain an absorb rule, the packet screen accepts the packet for delivery locally. The packet screening facility processes the packet according to the local rules, and passes the packet onto the appropriate proxy service on the firewall itself. The TELNET proxy uses its own rules to determine if the trusted host can TELNET to the untrusted host.
The packet screening rules allow you to permit or deny network traffic, based on several values in packet headers:
source IP addresses
destination IP addresses
network interface
protocol
source ports
destination ports
Rules indicate the source IP address and mask and the destination IP addresses and mask. The address mask indicates how much of the IP address is significant. For example, an IP address of 10.12.1.0 with a netmask of 255.255.255.0 matches all IP addresses beginning with 10.12.1. The IP address 0.0.0.0:0.0.0.0 matches every packet's IP address.
The packet screening utility applies the address mask in the screening rule to the IP address in the packet in a bitwise AND operation. If the result matches the IP address in the screening rule, then the packet screening facility considers the rule a match.
While the packet screening facility can detect attempts to spoof trusted IP addresses, the packet screening facility cannot detect one untrusted network host masquerading as another. Be careful when configuring rules that rely on source IP addresses on an untrusted network.
Rules indicate the interface on which the packet arrives at the Gauntlet Firewall. These match the interface names on your firewall, for example ec0, ec1, and ec2. When using the packet screening options in the administration tools, you can use symbolic names for the interfaces: inside, outside, third (for your service net), and any (for any network).
The packet screening facility applies the rule as packets arrive at the firewall. This ensures that the packets adhere to the defined network configuration, including the name of the network interface that received the packet.
Rules indicate the type of protocol the IP packet uses. Valid values are in RFC 1700. Common values include 6 (TCP) and 17 (UDP). Use the asterisk wildcard (*) to match any protocol.
You can also specify subtypes of the ICMP protocol. Valid subtypes are:
ECHO
ECHOREPLY
IREQ
IREQREPLY
MASKREPLY
MASKREQ
PARAMPROB
REDIRECT
ROUTERADVERT
ROUTERSOLICIT
SOURCEQUENCH
TIMXCEED
TSTAMP
TSTAMPREPLY
UNREACH
For example, Yoyodyne wants to allow only ECHO and ECHOREPLY packets. When creating the packet filtering rule, they use the following syntax as the protocol:
icmp:ECHO|ECHOREPLY |
On another firewall, Yoyodyne wants to allow all ICMP packets except ECHO and ECHOREPLY. When creating the packet filtering rule, they use the following syntax as the protocol:
icmp:!ECHO&!ECHOREPLY |
Rules indicate the source port and destination ports. These rules match ports on which the particular service communicates. Valid values are any number between 1 and 65,534. Use the asterisk wildcard (*) to match any port.
If the protocol is other than TCP or UDP, the packet screening facility considers the port to be the wildcard *, matching any port.
As the packet screening facility reads through the screening rules, the sequence of the rules is significant. The packet screening facility reads rules from top to bottom, stopping when it finds a match. When the interface, source IP address, source port, destination IP address, destination port, and protocol match a rule, the packet screen returns the appropriate permission or denial.
The packet screening rules are loaded into the kernel in this sequence:
User-defined rules specified manually in the netperm-table using the authenIP keyword.
IP spoofing rules and other user-defined rules specified manually in the netperm table using the netconfig keyword.
User-defined rules from the packet screening configuration option in the administration tools.
VPN rules that implement virtual private networks, trusted networks, and passthrough networks.
User-defined rules specified manually in the netperm table.
Transparency rules.
To access packet screening configuration:
Creating packet screening rules involves planning, creating actual rules, and loading screening rules into the kernel.
 | Warning: Allowing packets through the Gauntlet Firewall is a risk. Traffic that goes through the Gauntlet Firewall via the packet screen does not also pass through the proxies. Therefore, the Gauntlet Firewall cannot provide logging or authentication of this traffic as it does on traffic that goes through the proxies. Use of packet screening is optional. Configure packet screening rules only after performing a careful risk analysis. Only advanced firewall systems administrators who can judge the risks and consequences of rules they create should configure packet screening rules. A mistake in configuring packet screening can severely compromise the security of your protected network! |
When planning packet screening rules:
Determine the type of traffic you want to pass through the Gauntlet Firewall.
Perform a careful risk analysis and ensure that this traffic is an acceptable risk.
If you plan to create forward rules that allow access to your inside network, make sure that you are using registered, routable IP addresses for your inside networks. You cannot use one of the reserved (RFC 1918) addresses for your networks.
The packet screening rules editor in the Gauntlet Firewall Manager is appropriate for most configurations and is recommended for creating screening rules. You can also create packet screening rules manually. Use this manual method only if you have an unusual configuration, such as four interfaces. Refer to the Gauntlet Netperm Reference Guide for more information on manually adding packet screening rules.
To create packet screening rules:
In the Packet Screening window, click Add.
The Add Packet Screening Rule window displays.
Provide information about your packet screening rule.
Description
Description for this packet screening rule.
Protocol
Protocol for which this rule applies. If you want to specify a subtype of the ICMP protocol, use the syntax detailed in “Protocol Rules”.
Interface
Interface for which this rule applies.
Filter Access
Action the packet screening rule takes. If you want the firewall to deny this type of traffic, select “Deny Traffic.” If you want the firewall to absorb this type of traffic, select “Deliver Traffic transparently to the Firewall.” If you want the firewall to forward this traffic to the destination host, select “Permit Traffic” to forward without any Proxy Application.
Source IP Address
IP address and mask of the source host for this packet screening rule. Use 0.0.0.0:0.0.0.0 to indicate any host.
Source Port
Port number for source traffic.
Destination IP Address
IP address and mask of the destination host for this packet screening rule. Use 0.0.0.0:0.0.0.0 to indicate any host.
Destination
Port number for destination traffic.
Click OK.
Define the opposite rule on the opposite interface, if necessary.
Order your new user restriction rule, as described below, so that the firewall uses your new rule in the right order.
To modify packet screening rules:
Select the rule you want to modify.
Change the properties about the rule you want to modify.
Repeat the preceding steps for related rules.
To delete packet screening rules:
Select the rule you want to delete.
Click Delete.
Repeat the same steps for related rules.
Remember that the order in which you place your packet screening rules is very important. The firewall reads them from top to bottom and applies the first one that matches. You generally want to place the most restrictive rules first.
To change the order of precedence:
Select the packet screening rule you want to move.
Click Move Up or Move Down as many times as necessary to move the rule to the desired position.
Try to send traffic that uses your new packet screening rule through the Gauntlet Firewall. Watch the log for errors. Use the ipfs utility trace option to display detailed information about each packet processed:
# ipfs -t on |
When you are done testing, confirm that the trace option is off. The trace option creates large logs:
# ipfs -t off |