test

SunScreen 3.1 Reference Manual

Chapter 3 Packet Screening

This chapter discusses the following topics:

Dynamic Packet Filtering

Dynamic packet filtering enables a Screen, which sits between the client and server, to examine each data packet as it arrives. Based on information in the packet, state retained from previous events, and a set of security policy rules, the Screen either passes the data packet, or blocks and drops it.

SunScreen uses a set of ordered rules to filter packets. When you configure SunScreen, you translate the security policies for your site into a series of policy rules that specify which services are to be allowed, what to do with packets for services that are disallowed, and what to do when packets are dropped. You then place these policy rules in sequence to specify which rules override others.

When the Screen receives a packet, it tests the packet against the rules in a policy in the order in which they are numbered. The Screen does not test each packet against each rule; it assumes that the first rule to match the service, source address, and destination address of the packet addresses is the rule that governs the disposition of the packet. Additionally, if the applicable rule so specifies, the Screen can record a log message or generate an SNMP alert.

If the packet does not match any rule, the Screen uses its default action for the interface on which the packet arrived to determine the disposition of the packet. Typically, this action logs the packet and drops it; other actions such as logging and emitting an ICMP or SNMP message are available options.

The sequence in which a Screen performs packet filtering, network address translation, and encryption and decryption depends on the direction in which the packets are moving, as shown in FIGURE 3-1.

Figure 3-1 Rule Processing Order in a Screen

Graphic

When a host on a private (internal) network sends a packet addressed to an outside host through a Screen, the Screen does the following:

  1. The Screen applies its packet filter rules to the packet to determine whether the packet meets the criteria of an ALLOW or DENY rule. If the packet meets the criteria of a DENY rule, then the packet is denied and, if so specified, can make a log entry identifying the circumstances.

  2. If the packet meets the criteria of an ALLOW rule, the Screen determines whether it should use NAT to convert the source IP address information in the packet. If NAT is being used, the source address information in the packet is modified. Depending on the type of packet, the Screen may also modify address information in the data portion of the packet or modify packet checksums.

  3. The Screen determines if the packet should be encrypted based upon the information in the rule that matched. If the packet should be encrypted, the Screen calls the SKIP key manager, which identifies the appropriate encryption keys and algorithms and encrypts the packet. The SKIP key manager passes the encrypted packet back to the Screen, which then forwards the packet to the public network.

When a Screen receives a packet addressed to an internal host from a host on the public network, it performs a similar sequence of actions:

  1. If the incoming packet has been encrypted with the Screen's public key, the Screen calls the SKIP key manager, which identifies the appropriate keys and decrypts the packet. The SKIP key manager passes the decrypted packet back to the Screen.

  2. The Screen determines whether it should use NAT to convert the packet's destination IP address to an internal IP address. If NAT is being used, the address information in the packet is modified.

  3. The Screen applies its filtering rules to the packet to determine whether the packet meets the criteria of an ALLOW or DENY rule. If the packet meets the criteria of an ALLOW rule, the Screen forwards the packet to the internal network. If the packet meets the criteria of a DENY rule, then the packet is denied.

Policy Rules

You can define rules and order them either from the graphical user interface (GUI) or the command line.

Policy rules are based on sets of ordered policy rules. You set up these rules to reflect the security policy for your site. These rules specify the action to be taken for services between two addresses that are on different interfaces of the Screen. A collection of rules form a policy.

When you install the SunScreen software, you start with a policy called Initial that establishes access rules for basic TCP/IP services. You then define policy rules to allow clear or encrypted communication between hosts that meet your criteria.

Each rule must specify all three selection criteria: source address, destination address, and type of service. Each rule can also specify what action to take if a packet meets those criteria. For example, different rules will specify whether the Screen should forward or drop the packet; encrypt or decrypt the packet; record the packet in the Screen logs; and issue ICMP messages or SNMP traps concerning the packet. The default rule is to drop any packet that does not have a specific SECURE, ENCRYPT. or ALLOW action.

The sequence in which rules are ordered is critical. When the Screen processes packets, it compares the packet information to each rule in the order it occurs in the Screen's active policy. When a packet meets the criteria of a rule, the Screen applies the actions specified for that rule and disregards the following rules.

Define services for a service group carefully and place the rules in an order that will permit the services used to pass easily. For example: If services such as ftp, rsh, and realaudio are not part of a service group such as tcp_all and a tcp_all rule occurs first, then the tcp_all rule will pass the ftp packet, which is a tcp packet, because it assumes a simple tcp connection. Other special-case processing, such as a reverse data-port connection from the server back to the client, will not automatically be allowed by the initial connection as it would had the ftp-based rule been placed first.

When a packet filter checks to see if a packet matches a rule, the difference between service or service group, such as ip_all, and a service or service group with BROADCAST, such as ip_all_with_broadcast, is important. If the service or service group has the BROADCAST flag set, the destination IP address in the packet must be a recognized broadcast address. Configure stealth mode to identify the network and netmask that the Screen partitions properly so that it can correctly identify what the valid broadcast addresses are. If a packet must pass through the Screen that has a destination address of one of the broadcast addresses, set BROADCAST in the service used in the rule to pass the traffic. With respect to all other destination addresses, ip_all and ip_all_with_broadcast are identical.

Note -

When you define rules for specific services (such as telnet, HTTP proxy, ftp, and the like), you do not automatically pass network control messages that might be necessary for these rules to work correctly. You may need to add additional rules that allow this traffic to pass. For example, you can add the icmp all rule that allows all internet control messages to pass.

You can use the administration GUI or the command line (see Appendix B, Command-Line Reference) to set up the table of ordered rules for a policy, by means of which you can edit rule components, such as source and destination addresses, directly. You can change the order of the rules by dragging and dropping them through the configuration editor.

Rule Syntax

The basic syntax for a rule is:


Service Source_address Destination_address optional_Time optional_Encryption "action" optional_Proxy

where:

Encryption is only supported if ALLOW is selected. It is not supported if any proxy or VPN is selected. Encryption works as follows:

Example of a Rule Configuration

The XYZ Company wants to set up a series of rules to implement the following security policies:

  1. Allow telnet traffic from A (an address object representing an individual host) to B (an address object representing any host on a specified network).

  2. Deny and log mail traffic between A and B.

  3. Send NET_UNREACHABLE ICMP rejection messages for rejected telnet traffic.

  4. Discard all other packets.

TABLE 3-1 illustrates the rules the XYZ Company would set up to implement this security policy. Note that the default action would be specified as DENY for each interface to implement policy 4.

Table 3-1 Sample Rules Table

Service 

From 

To 

Rule Type 

Log 

SNMP 

ICMP 

telnet 

A 

B 

Allow 

NONE 

NONE 

NONE 

mail 

A 

B 

Deny 

SUMMARY 

NONE 

NONE 

mail 

B 

A 

Deny 

SUMMARY 

NONE 

NONE 

telnet 

* 

* 

Deny 

NONE 

NONE 

NET_UNREACHABLE 

Policy Versions

Each version of a policy has an associated version number. Edited policies automatically generate historical version numbers. Version numbering is implemented through the administration GUI using the edit subcommand of ssadm.

When a particular policy is superseded by a new version of that policy, the older version includes specific information and the actual content of the common object registry instead of just a reference. An older policy version can become invalid because of changes that have occurred in the network topology and hardware.

The types of polices are:

Routing, Stealth, HA, and Administration Interfaces

Network interfaces on a Screen may be configured as routing, stealth, HA, or administration interfaces; or you can disable them.

A disabled interface will not filter any traffic. If it is on a Screen in stealth mode, it passes no traffic. If it is on a Screen in routing mode, the traffic between the disabled interface is not filtered, but the traffic that leaves the Screen using an "active" interface (an interface that has not been disabled) will be filtered. All active interfaces describe what to do with packets that arrive on that interface that do not match a packet-filtering rule. The fields are LOG, ICMP, and SNMP. If no values are set in these fields, no action is taken.

The values for LOG are NONE (which is the same as not present), SUMMARY, and DETAIL.

The values for ICMP are NONE (which is the same as not present), NET_UNREACHABLE, HOST_UNREACHABLE, PORT_UNREACHABLE, NET_FORBBIDEN, and HOST_FORBIDDEN.

If SNMP is present, an SNMP packet will be sent; if it is not present no SNMP packet will be sent.

You can, as an option, associate all interfaces with a specific screen object. In this case, the value of the interface is only used with the screen object with which it is associated. If the Screen is part of a centrally managed group of Screens this association is necessary to distinguish which interface definition belongs to which Screen.

You can include an optional description of all interfaces in the COMMENT field. This cannot be longer than 256 characters

Routing Interfaces

Routing interfaces have an IP address and route packets using the standard IP routing mechanisms in the operating system. Each routing interface is connected to a different IP network just like a standard IP router. In terms of network placement, a Screen with routing interfaces replaces a router. A routing interface can receive remote Administration Station traffic.

Connections to and from proxies can only occur over routing interfaces. Thus, to run proxies or if you want to install additional network services on the Screen, you must configure the Screen with routing interfaces.

In summary, use routing interfaces to replace an existing router, to control packet flow between different IP networks, or if you want to install proxies or other network services on the Screen.

Stealth Interfaces

Stealth interfaces have no IP address. All stealth interfaces on a Screen are part of the same IP network. Thus, a Screen with stealth interfaces partitions one IP network and controls packet flow between those partitions.

Although it operates much like an IP bridge or switch, the Screen with stealth interfaces does not implement the bridging algorithms that detect loops. Make sure no loops exist in your network configuration where a packet could be sent out from one stealth interface and be received on another.

Stealth interfaces also provide a higher degree of security than routing interfaces because they are separate from the standard IP mechanisms used by the operating system. Thus, packets flowing through stealth interfaces cannot inadvertently leak into other network applications running on the system, thereby compromising the security of the firewall.

A stealth interface can define a set of five routers by IP address, using the ROUTER #.#.#.# keyword.

In summary, use stealth interfaces when you want to partition an existing IP network and control packet flow between those partitions without having to modify the configuration of your existing network.

Administration Interfaces

Because stealth interfaces have no IP address, they cannot provide the IP address needed for administration traffic. You must, therefore, configure a Screen that has only stealth interfaces with an additional administration interface. This interface is a special case of a routing interface configured to only pass administration traffic for the Screen.

An administration interface is not required for a Screen with routing interfaces.

Mixing Routing and Stealth Interfaces on a Single Screen

You can configure a Screen with a mixture of routing and stealth interfaces subject to the following restrictions:

  1. Packets do not flow between the routing and stealth interfaces. You can model a Screen with a mixture of routing and stealth interfaces as though it were two completely separate Screens: one configured with the stealth interfaces and the other configured with routing interfaces. Packets received on a stealth interface are only sent out to another stealth interface. Packets received on a routing interface are only send out to another routing interface.

  2. Any packet affected by NAT or encryption rules must only pass through the Screen once.

HA Interface

If the Screen is part of an HA cluster, it must have a single HA interface. You administer the HA cluster over this interface.

Addresses

Addresses can be an individual address, a range of addresses, or a group of addresses.

Individual IP Addresses

SunScreen identifies an individual host by linking its unique IP address to an address object, which can use the name or IP address of the host or some other identifier. FIGURE 3-2 shows an example of a host identified by its IP address (172.16.1.1).

Figure 3-2 Single Host Address

Graphic

Address Ranges

An address range is a set of numerically contiguous IP addresses. Networks and subnetworks are typically identified by an IP address range name. You use the beginning and ending addresses to identify an IP address range.

You can set up an address object to represent an address range in SunScreen. FIGURE 3-3 shows examples of ranges of addresses for the Corporate and Sales networks. For example, the Corporate address object is defined as a range of addresses from 172.16.3.2 to 172.16.3.255. You could then establish access or encryption rules for hosts on the Corporate network by indicating the rule applies to the Corporate address object.

Figure 3-3 Examples of IP Address Ranges

Graphic

Address Groups

An address group is a collection of host addresses, address ranges, and other address groups. After you set up an address group, you can use it to identify multiple hosts as a single element. You can define groups in terms of the addresses they include ("Address group A consists of the IP address 1.2.3.4 and the members of address group B"), the addresses they exclude ("Address group C consists of all the hosts on the 192.4.5.0 network except 192.4.5.5 and 192.4.5.9"), or both. Address groups cannot be self-referential; that is, you cannot include address group X as a member of address group Y and then define address group Y as a member of address group X.

Note -

There are two addresses you cannot modify: localhost, which is the IP address or addresses of the actual Screen, and *, which represents all IP addresses.

The value is determined by first, all addresses are included, which means that all the IP addresses contained in any of them are added to the Address Group. Next, all IP addresses of all the Addresses that are excluded are removed from the Address group. You cannot control the order in which the IP addresses are added or removed, as all includes are done before all excludes.

Designing an Addressing Scheme

You can take several steps when creating address objects to simplify maintenance of your security policies. When you are planning your addressing scheme, choose interface names that describe which addresses are on that interface or that reflect the names of the interfaces. Make naming conventions meaningful and consistent so that maintenance and daily administration are uneventful.

A network interface is a network connection coming into a Screen through which one or more IP addresses are accessible. These IP addresses need to be identified to SunScreen so that IP spoofing can be detected and prevented.

The easiest way to define address objects for network interfaces is to define an address group for each network interface. You can choose names that identify which addresses are on that network interface (such as, Corporate, Sales, ftp-www, and Internet) or names that identify the interfaces by type (such as le0 or qe0).

In most cases, one interface usually has the majority of addresses on it. For example, the Internet network interface (qe0) in the network illustrated in FIGURE 3-4 has the most addresses, because it is the interface for all addresses except those in the Corp, ftp-www, and Sales networks.

Figure 3-4 SunScreen as Internet Firewall

Graphic

Rather than enumerating all the addresses for the Internet, you can define the address group for the Internet address object to include all network addresses ("*") and then exclude those that you do not want to be part of that address. In the example shown in the figure, you would define the Internet address object as an address group that includes all addresses except Corp, Sales, and ftp-www. You would then define which hosts, networks, or address groups are members of the Corp, Sales, and ftp-www addresses to exclude them from the Internet address group.

Services

SunScreen is shipped with a number of predefined network services, such as ftp, telnet, dns, and rsh. You can modify these services or define new services as needed, except that you cannot modify the service named * in any way.

Note -

A well-defined service must not include two entries for the same port with different attributes, such as two different filters for the same port but with different state engines, or the same state engine but with different parameters set.

Standard Services

Part of setting up your network security policy is to define what network services will be available to hosts on your internal network and to hosts on the external network. Generally, most sites need to determine or set up rules that govern the basic services.

Besides the basic services, every TCP/IP implementation provides services such as echo, discard, daytime, chargen, and time. For services such as ftp, you can allow anyone in the internal corporate network to send outbound traffic, but only allow inbound traffic in this protocol to go to the FTP server. This requires two rules: one for the outbound traffic and one for the inbound traffic going to the public server.

Each service uses a state engine, a sort of protocol checker. For example, the FTP state engine checks port numbers when the ftp service is being used. For more information on state engines, see Appendix C, Services and State Engines. Table C-1 lists the single services in SunScreen, along with the state engine and discriminator (port, RPC program number, or type). Parameters (state engine modifiers, such as time-outs) and BROADCAST are indicated where applicable.

Modifying or Creating New Services

You can modify or define existing services or define new services as needed. Each service must use a predefined state engine. Troubleshooting is easier if you create a new service rather than modifying an existing one because you do not have to examine the services to see which one or ones have been modified. You should note the purpose of the new (or edited) service in the description.

When you define a new service, you must specify a state engine for the new service to use and identify the various discriminators and parameters appropriate for that state engine.

Before you can define a new network service, you need to identify how the new service will work:

For example, if you have an FTP implementation that uses port 45 for its control port and port 44 for data, you could define a new FTP service called ftp-45. Refer to Appendix C, Services and State Engines for more information on state engines, their discriminators, and their parameters.

You can specify state engines as filters for both the forward and the reverse direction. The forward filters apply when traffic originates from the From Address and goes to the To Address in a rule. The reverse filters apply to traffic originating from a machine in the To Address going to the From Address of a rule.

Normally, rules for stateful services do not have reverse filtering rules. For instance, an FTP connection always gets established in the forward direction, and the returning traffic is handled by a state-table entry created when the connection is initiated. Reverse filtering rules are mostly valuable when you want to allow nonstateful traffic to return. An example is the nlm rule, which uses the nonstateful ICMP filter engine. It allows network lock manager (nlm) requests (ICMP type 8) in the forward direction and nlm replies (ICMP type 0) in the reverse direction.

State engines' discriminators can optionally be tagged with a BROADCAST attribute. When BROADCAST is specified for a service, the rules where the service is used allow communication to broadcast and multicast addresses. If you also want the service to work for nonbroadcast addresses, you must include a filter line both with and without BROADCAST selected.

Service Groups

You can group network services together to apply a single rule to multiple network services. This group is called a service group. Table C-1 shows the predefined service groups in SunScreen and the services each includes. Not every service is included in a service group.

You can create additional service groups using any combination of the individual network services. A useful group to define might be an "internet services" group, consisting of public services, such as FTP, email, and WWW.

State engines that you use in describing services come in distinct classes and each class has subclasses. The subclasses form an order for preference. Table 3-2shows the classes in order of preference--the greater the number, the higher the preference. The state engines that are followed by an * can conflict with another state engine because it is in the same class and has the same subclass ID. An * also follows the state engine with which it can conflict.

Table 3-2 Classes and Subclass of State Engines

Class 

Subclass 

State Engine Name 

11 

0 

nfsro

10 

0 

nis

9 

0 

pmap_nis

8 

0 

pmap_udp

7 

0 

pmtp_tcp

6 

0 

rpc_tcp

5 

0 

rcp_udp

4 

1 

realaudio*

4 

1 

rsh*

4 

1 

sqlnet*

4 

1 

ftp*

4 

0 

tcpall

3 

2 

dns*

3 

2 

ntp*

3 

1 

upd_stateless*

3 

1 

udp_datagram*

3 

1 

udp*

3 

0 

udpall

2 

1 

ping

2 

0 

icmp

1 

3 

ipmobile

1 

2 

iptunnel

1 

1  

ipfwd

1 

0 

ip

0 

0 

ether

A given service, defined manually to contain multiple state engines or in a service group that includes multiple services, can only contain a single state engine in a particular class or subclass for a particular port.

Time

Time objects are specified using a 24-hour clock in 5-minute increments. You use time objects to set a policy's time-of-day, day-of-week, and the like in time-based rules. For instance, you can allow telnet, but only during regular business hours, or after hours, or outside certain hours.

The policy rule default setting is ANY time, which applies the rule at all times. You can set a few time-based policy rules that reference the same set of hours, or you can specify the hours covered for a particular day or range of days, such as Monday to Friday, 9 am to 5 pm, local time.

Time is always interpreted as the Screen's time zone, which requires that you either have Screen-specific time definitions to coordinate traffic between the Screens in different time zones, or have distinctly named time objects and Screen-specific rules.

Note -

Although you can define many time objects, only 31 distinct time objects can be in actual use on any given Screen. You cannot modify the time object named * in any way; it represents 24 hours a day, 7 day a week--it is the same as if no time object is used. It is not included in the limit of 31 time objects.

For example, Los Angeles (LA) and New York (NY) have a three-hour difference. Suppose each site is protected by a Screen. If you only want the two sites to communicate when they are both within "regular" hours (that is, 8 am to 5 pm), then NY is available to communicate to LA between 11 am and 5 pm, and LA is available to communicate to NY between 8 am and 2 pm.

A downside to this is that during hours that do not overlap, one of the two Screens allows traffic through while the other does not. So, early in the morning the NY Screen allows traffic through, but it is blocked by the LA Screen. Similarly, in the afternoon, the LA Screen is blocked by the NY Screen.

Case 1: Screen-Specific Time Objects

Name 

Screen 

Value 

regular  

NY 

MONDAY { 11:00 17:00 } TUESDAY { 11:00 17:00 } ... 

regular 

LA 

MONDAY { 08:00 14:00 } TUESDAY { 08:00 14:00 } ... 

Set the rules by typing:


telnet LA NY TIME regular ALLOW
telnet NY LA TIME regular ALLOW

These rules apply to both Screen, although the definition of regular is different for each Screen

Case 2: Distinctly Named Time Objects

Name 

Value 

ny-business  

MONDAY { 11:00 17:00 } TUESDAY { 11:00 17:00 } ... 

la-business 

MONDAY { 08:00 14:00 } TUESDAY { 08:00 14:00 } ... 

Set the rules by typing:


SCREEN LA telnet LA NY TIME la-business ALLOW
SCREEN LA telnet NY LA TIME la-business ALLOW
SCREEN NY telnet LA NY TIME la-business ALLOW
SCREEN NY telnet NY LA TIME la-business ALLOW

Screen

In general, editing is better than creating one because they are automatically created during installation. If you specify a Screen, you can define packet-filtering rules that encrypt traffic between any two machines, not just between an Administration Station and a Screen.

Screen Object

The common object Screen defines attributes associated with each distinct Screen. You can set miscellaneous Screen parameters, SNMP parameters, and mail proxy parameters for screen objects that already exit.

You create new screen objects to configure high availability (HA) and centralized management.

Define Screen's Name Properly

SunScreen automatically chooses a name for each Screen based on the hostname setting output by uname -n. Various situations exist in which this name is used as an IP host name (IP address) for remote administration and centralized management groups.

You must, therefore, define each Screen's name as a valid IP address for that Screen. The definition must be accessible through /etc/hosts, NIS, or DNS on every remote administration station as well as every Screen in a centralized management group.

You cannot modify the Screen named * in any way.

Certificate and Certificate Groups

Use certificate objects to configure the certificates you use for your SunScreen host and for remote hosts that communicate securely through your SunScreen.

Note -

Changes to the certificate object that pertain to loading into SKIP take effect immediately without having to be saved. Changes to the certificate object as stored in the common objects do not take effect immediately and must be saved and only take effect when the policy in which they are used is activated. For example, in adding a new certificate, (the certificate is created and loaded immediately into SKIP, but the name has not been saved as part of the common objects and must be saved. Renaming a certificate only affects the common objects and must be saved.

The certificate object provides a way to associate a usable name with a SKIP certificate name space ID/master key ID (NSID/MKID) pair. This naming facility makes using certificates easier, as well as isolating the Screen configuration from exact SKIP names. The certificate group allows grouping single certificates that you want to use together.

Generate Screen Certificate

This task generates a certificate for the Screen.

Associate MKID

This task is also called the certificate ID and assigns a name to a certificate that already exists (typically on another machine). You associate a certificate ID when you want to encrypt communication between two screens or between a screen and an Administration Station.