Appendix C Services and State Engines

This appendix describes the standard services, network service groups, and state engines supported by SunScreen. The following topics are included:

• "Standard Services"

• "* Service"

• "Network Service Groups"

• "State Engines"

Standard Services

SunScreen is shipped with a number of predefined network services. The table below lists the services in SunScreen, along with the state engine and discriminator (port, RPC program number, or type) for each service. Parameters (state engine modifiers, such as time-outs) and BROADCAST are indicated where applicable.

Service information is stored in the common object registry. See "add service" in Appendix B, Configuration Editor Reference.

Some of the services in the table are described at the end of this table. The * service is not included in the table, but is described in "* Service".

* Service

The * service is a special type of internal service which has some of the characteristics of a service group. It includes a number of services, as shown in the list below, but those services are not displayed when you list services in the configuration editor or the GUI, and you cannot edit the services in *.

The * service, which acts as if each of its services were in separate rules, is designed to allow anything through, but it attempts to use the best service first, thereby providing better security. For example, the ftp state engine enforces the proper use of the stateful FTP protocols, in contrast to ipmobile, which does not inspect packets according to any of the stateful protocols. Note that ipmobile, which allows any IP traffic initiated by the source address, is the last service in the list of * services:

• nis

• pmap_nis

• pmap_dup

• pmap_tcp

• rpc_tpc

• rpc_udp

• realaudio

• rsh

• ftp

• tcp

• tcpall

• dns

• udp_datagram

• udp

• udpall

• ping

• icmp

• ipmobile

ah Service

IPsec Authentication Header (ah) uses IP protocol 51 and is used for traffic that has been authenticated using IPsec.

archie Service

SunScreen contains a service definition to handle the Archie UDP protocol. To screen Archie traffic, use the archie service.

CoolTalk Service

The CoolTalk service definition allows calls to be initiated but does not allow calls to be received. To receive calls, define a second rule with the addresses reversed. For example:

CoolTalk joe sam allow
CoolTalk sam joe allow

dns Service

DNS traffic consists of both UDP and TCP traffic. SunScreen includes a state engine to handle the UDP DNS protocol. TCP DNS is handled through the normal TCP state engine. To screen DNS traffic, use the predefined dns service.

esp Service

IPsec Encapsulating Security Payload (esp) uses IP protocol 50 and is used for traffic that has been encrypted or authenticated using IPsec.

ftp Service

The File Transfer Protocol (FTP) is used to copy files from one system to another. FTP is designed to work between hosts using different file structures and character sets.

SunScreen contains an ftp state engine to screen the FTP data connection. You specify the number for the FTP control port; the number for the FTP data port is one less than the FTP control port number. The predefined FTP service definition, ftp, uses the standard FTP control port number (21) and data connection port number (20).

FTP control connections time out after a period of inactivity. The FTP server typically closes the connect before this inactivity timeout occurs; however, if the timeout period elapses, the quit command can take 60 seconds or more to complete. During this time, FTP packets may be logged.

The ftp service supports both PASV and standard FTP connections. By default, the ftp service verifies that the FTP data port is 20 for standard FTP connections. To communicate with FTP servers that do not use port 20 for the data port, modify the ftp service definition to set its three parameters to: 600 600 1. The first parameter is the control session timeout (600 seconds). The second parameter is the data session timeout (600 seconds). The third parameter is a flag; a value of 1 specifies that the system will not verify that the FTP data port is 20.

Note that this does not affect PASV FTP sessions, because they never use port 20 for the data connection.

ICMP Packets

SunScreen provides predefined services for screening ICMP packets including ping.

The icmp state engine can also be used to create other services to pass ICMP messages of a specific type. Most of the common ICMP packets have entries in the predefined services.

These rules allow Inside systems to ping Outside systems, but not vice versa. It also allows ICMP unreachable packets to be sent from Outside systems to Inside systems. Note that the ping service allows packets in two directions (ping-requestpackets from Source to Destination and ping-response packets from Destination to Source) while the icmp-unreach service only allows packets to flow in one direction (from Source to Destination).

icmp Service

SunScreen includes predefined services for screening ICMP packets such as ping. These services use the icmp state engine and allow ICMP ping request-and-response exchanges between a Source and Destination system. Use the predefined service ping if you want to provide ping access.

You can use the icmp state engine to create other services to pass ICMP messages of a specific type. Most of the common ICMP packets have entries in the predefined services, as shown in the table:

These rules allow Inside systems to ping Outside systems, but block Outside systems from sending ping messages to Inside systems. It also allows ICMP unreachable packets to be sent from Outside systems to Inside systems. Note that the ping service allows packets in two directions (ping-request packets from Source to Destination and ping-response packets from Destination to Source), while the icmp-unreach service only allows packets to flow in one direction (from Source to Destination).

IP Packets

SunScreen can filter IP packets by IP protocol type alone. This is useful in special situations such as passing non-TCP/UDP protocols or when data are being encrypted.

To pass IP packets by protocol type, you need to define a new service using either the ip, ip tunnel, ip mobile, or ip fwd state engine. Specify the protocol of the packets you wish to pass. Note that protocol is always specified in decimal notation. If you specify  * for the protocol, this means to pass all IP packets regardless of protocol type.

There are several predefined services included, such as skip (IP protocols 79 and 57), ip tunnel, ip mobile, and ip fwd.

Using one of the state engines with a protocol specification of * (any protocol), can be dangerous, because any traffic would be allowable. State engines should only be used in special cases or if the data are part of an encrypted tunnel.

The predefined IP services do not pass broadcast traffic. To pass broadcast traffic, you must define a new service or add broadcast to the predefined service.

ip Services

The ip all service is provided for backward compatibility with previous SunScreen products. You can achieve better performance by using either the ip forward (for IP traffic in one direction) or the ip tunnel (for IP traffic in both directions) services instead.

Example of the old method using ip all:

"ip all" host1 host2 allow
"ip all" host2 host1 allow

Example of the new method using ip tunnel:

 "ip tunnel" host1 host2 allow

The ip mobile service is provided for use with mobile, remote clients. Like the ip tunnel service, ip mobile passes all IP traffic between a pair of addresses. Unlike the ip tunnel service, however, a rule specifying ip mobile forces the first connection to be made from the mobile client (a system with one of the addresses in Source Address).

Generally, ip mobile is used for SKIP-encrypted connections with the SKIP identity providing the authentication and access control. For example:

"ip mobile" Internet Mailhost SKIP-VERSION2

SunScreen can filter IP packets by IP protocol type alone. This is useful in special situations such as passing non-TCP/UDP protocols or when data are being encrypted.

If you want a Screen to pass IP packets by protocol type, you define a new service using either the ip, ip tunnel, ip mobile, or ip fwd state engine. Specify the protocol of the packets you wish to pass in decimal notation. If you specify * for the protocol, the service will pass all IP packets regardless of protocol type.

There are several predefined services included, such as skip (IP protocols 79 and 57), ip tunnel, ip mobile, and ip fwd.

Using one of the state engines with a protocol specification of * (any protocol), can be dangerous, because any traffic would be allowable. State engines should only be used in special cases or if the data are part of an encrypted tunnel.

The predefined IP services do not pass broadcast traffic. To pass broadcast traffic, you must define a new service or add broadcast to the predefined service.

ipsec Service

ipsec is a service group that comprises the three packet types that are used in IPsec secure communication.

isakmp Service

Internet Security Association and Key Management Protocol provides communication between security processes such as IKE key negotiation.

ipv6 tunnel Service

ipv6 uses IP protocol 41 and carries encapsulated IPv6 packets over an IPv4 link such as the Internet.

nfs readonly Service

The nfs readonly service allows read-only access to the NFSv3.0 file system. Read-related functions, such as lookup, read, and access, are allowed. Functions that are not read-related, such as rename and write, are blocked; traffic is not permitted to pass under the nfs readonly rule.

ntp Service

To screen NTP traffic, use the ntp service. SunScreen contains a state engine to handle the NTP protocol. The source and destination UDP ports numbers are fixed at port 123. Broadcast NTP is not supported.

realaudio Service

SunScreen contains a service definition to handle RealAudio sessions. To screen RealAudio traffic, use the realaudio service.

rip Service

The Routing Information Protocol (RIP) is a dynamic routing protocol commonly used by Internet routers. RIP messages are carried in UDP datagrams. SunScreen includes a predefined service (rip) for passing RIP packets using the udp-datagram state engine with broadcast enabled. This means that a rule allows RIP packets (including broadcasts) from source to destination.

Enabling RIP in the default rule that passes RIP from the routers to all other addresses is usually sufficient. This enables the Screen to send and receive RIP packets without restriction. To restrict RIP traffic, do not enable RIP using the default access rules. Instead, define rules for RIP based on your security policy, for example:

rpc Service

SunScreen contains a state engine to handle the RPC protocols. This can safely screen RPC protocol as long as they use the portmapper and do not use dynamic RPC program values.

To define a new RPC service, add a new service entry using both the rpc_udp and pmap_udp state engines. You specify the well-known RPC program of the RPC service you wish to pass. If you specify * for the RPC program, the service entry passes all RPC services, regardless of program.

Several well-known RPC services such as NFS and NIS have been defined to include all the RPC and non-RPC protocols that these systems require.

Some NFS clients use the lock manager. Because the lock manager makes connections in both directions (to NFS server and from NFS server), you may need to use the nlm service when you allow NFS access as shown in the following example:

Broadcast port mapping (NIS) is not supported for encrypted connections.

smtp (Electronic Mail) Service

Simple Mail Transfer Protocol (SMTP) is used to send electronic mail between two message transfer agents using TCP. SunScreen includes a predefined service definition, smtp, to send and receive SMTP mail on TCP port 25.

sqlnet Service

SunScreen contains an sqlnet state engine to screen Oracle SQL*Net protocol. SQL*Net is Oracle's remote data access protocol that enables client-server and server-server communications across networks.

An Oracle client connects to the server using the port address of the listener, which is normally defined as TCP port 1521 during Oracle installation. sqlnet service is defined as using TCP port 1521. If Oracle is installed using a different port for the listener, you can modify the service definition for sqlnet service accordingly.

SQL*Net connections are established in two ways. An Oracle client connects to the listener using TCP port 1521, and the connection is established with the listener process. With Oracle multithreaded servers and prespawned server processes, the client connects to the listener on TCP port 1521. The listener issues a redirect message back to the client containing an IP address and port number, and the client connects to this redirected IP address and port.

SunScreen supports both types of SQL*Net connections.

TCP Services

SunScreen screens TCP services by destination port numbers. Most common TCP services are already defined in the service entries supplied with SunScreen.

To define a new TCP service, define a new service entry specifying the tcp filter state system. Specify the destination TCP port or ports of the service you wish to pass. If you specify * for the port, the service will pass all TCP services regardless of port. Note that some services, such as FTP and RSH, cannot be passed in this way. They are not simple TCP protocols. They make additional connections in the reverse direction. These services must be specified as separate services if you wish to pass them.

The tcp state engine times out unused and silent connections five hours after a connection has been established. Some systems repeatedly retransmit until they receive an error about a terminated TCP connection. To send an ICMP rejection message, therefore, configure a rule using the tcp service, especially on your internal interfaces.

For example, the following rule allows telnet connections to be made from Inside systems to Outside systems.

traceroute Service

The traceroute service entry assumes that the UDP ports being used for traceroute are in the range of 33430-34000. If implementations of traceroute at your site use other ports, modify the port range as appropriate.

tsolpeerinfo Service

When two Trusted Solaris systems communicate with each other using the TSOL protocol, they typically use rpc program 110002 to exchange process attributes for peer processes. The entry in /etc/rpc is tsolpeerinfo 110002 rpc.getpeerinfo peerinfod.

If this service is blocked, services do not work. A connection is established, but Trusted Solaris waits for a response from peerinfod for additional information. Until it gets that response, the connection cannot proceed. The tsolpeerinfo service prevents this problem by ensuring that this service can be initiated from both sides of a connection through a firewall.

A server (ftpd, telnetd, etc., for example) spawned by inetd requests the audit attributes of a connecting client from a Trusted Solaris system. The server sends a getpeerinfo RPC back to the client, which responds with the required information. For example, to allow telnet through the firewall from HostA to HostB, but not from HostB to HostA, your rule base must include the following three rules:

• 1 telnet HostA HostB ALLOW

• 2 tsolpeerinfo HostA HostB ALLOW

• 3 tsolpeerinfo HostB HostA ALLOW

Without the tsolpeerinfo rules, the telnet connection appears to connect and hang. Note that if your rules involve encryption, the tsolpeerinfo rules must be modified to include the relevant encryption parameters as well.

Alternatively, you could define a group--HostA+B--containing both hosts. Rules 2 and 3 could then be combined to form the following rule:

• 2 tsolpeerinfo HostA+B HostA+B ALLOW

The tsolpeerinfo service does not work with dynamic NAT. Assume a client goes through a firewall and its address is dynamically changed with NAT. The server tries to getpeerinfo to the NAT address. Since this is a new connection initiated from a server that is unassociated with any state engine, this connection is dropped. There is no way to "de-NAT" the connection.

See the Trusted Solaris installation instructions in SunScreen 3.2 Installation Guide for details about installing SunScreen on a system running Trusted Solaris.

UDP Services

SunScreen contains several state engines to handle UDP protocols:

• udp - Provides stateful UDP packet filtering. Allows a single request-and-response exchange between source and destination. State entries time out in 20 seconds if no response is received.

• udpall - Identical to udp. It is useful for avoiding conflicts while defining service groups containing many services.

• udp_datagram - Passes UDP packets from source to destination. You can specify that broadcast packets should be passed.

• udp_stateless - Allows UDP packets to be sent between source and destination. The UDP Port(s) field specifies the list of destination UDP ports that are allowed. The source UDP port must be a unreserved port. Note that this is a two-way exchange of UDP packets.

Because some services use unreserved port numbers, use of this state engine can open up security holes. Its use is not recommended.

For all UDP engines, you define a new service entry specifying the well-known destination, UDP port. Specifying port * passes all UDP traffic.

VDOLive Service

The VDOLive service definition requires that the VDOLive clients be set to use a fixed port, which is port 32649 by default. You can modify the service definitions so that VDOLive will use another port.

www (World-Wide-Web Access) Service

The World Wide Web provides a graphical user interface that enables users to browse a global network of services and documents. SunScreen contains a predefined service definition for WWW that passes TCP connections on port 80.

Not all WWW services on the Internet use port 80; many reside on ports with other numbers, such as 8000 or 8080. If you only allow outbound WWW access under the www service entry, users cannot connect to all WWW resources. To compensate, you can define a new TCP service that enumerates additional nonstandard WWW ports you want to allow, or you can allow TCP access to all ports outbound using the default service.

Do not use the tcp all service to enable inbound www access to your public Web servers. This opens up a large security hole and allows outside users access to any TCP service on your systems. Instead, use a more restrictive service rule, such as the www service definition, with the port your Web server uses (generally port 80).

Network Service Groups

Network services can be organized into service groups, so that a single rule can apply to multiple network services. The table below lists the predefined service groups in SunScreen and the services that each group includes. Note that some services are members of more than one group, and other services are not included in any service group.

The common group compiles to list every service within the group in a specific order based on state-engine precedence. When a packet comes through, it tries to match each state engine in order of its precedence.

See "* Service" for information about the * service, which has some of the characteristics of a service group.

State Engines

SunScreen includes a number of state engines that act as protocol verifiers for services. For example, the ftp state engine checks port numbers when the ftp service is being used.

You cannot define new state engines, and you should not change which state engine is used by a predefined service. However, if you define a new service, you must specify the state engine the newly defined service will use.

Characteristics of State Engines

State engines have the following characteristics:

• Connection management - Each state engine understands the connection management of a particular protocol or set of protocols. State engines can be general, such as the tcp state engine (which allows a simple TCP connection) or specific, such as the ftp state engine (which understands the FTP protocol and parses FTP PORT and PASV commands).

• Precedence level - Each state engine has a precedence level. A service with multiple state engines (that is, a service group) is internally ordered by state engine. This order is given by the order in the ss_stateengine default list.

• Discriminator value - Each state engine has a discriminator value. This value is used to bind the state engine to a particular service. Examples are a port number for TCP and UDP services, an RPC program number for RPC services, or an icmp type for ICMP services.

• Parameters - Each state engine has a set of parameters. These parameters have a default value that can be overridden when the service is defined to modify the behavior of the state engine.

dns State Engine

The dns state engine is used for UDP DNS sessions. It looks inside the DNS responses and verifies that they have the same DNS ID as the request. The predefined service dns uses this state engine and is normally the only service to use it. Because the DNS service also uses the TCP protocol, the predefined service dns also has a second entry using the tcp state engine.

The discriminator for the dns state engine is the UDP port number of the DNS service. This is normally 53.

The dns state engine has two parameters:

• Response timeout in seconds - Specifies the time to wait for DNS responses. Default is 60 seconds. This can be changed (to 120 seconds, for example) in the configuration editor as follows:

  edit> add service "dns" SINGLE FORWARD "tcp" PORT 53 FORWARD "dns" PORT 53 PARAMETERS 120

• Packet count - the number of response packets the state engine will allow for each outgoing packet. The default is 1; it is recommended that this not be changed.

ether State Engine

SunScreen in stealth mode can pass non-IP Ethernet frames between its interfaces. It cannot filter the frames on their content, but can pass (or drop) frames based on the frame "type." It can also determine which interfaces the frames are allowed to and from.

To pass non-IP traffic you need to define a new service entry using the ether state engine, specifying the type of protocol you wish to pass. The discriminator for the ether state engine is the frame type number in decimal.

The location of the value that you specify in the type field within the Ethernet packet depends on the Ethernet frame type. The following four Novell frame type designations, described below, are in common use:

• Ethernet II -- Common name: Ethernet

• Ethernet 802.3 -- Common name: "Raw" 802.3

• Ethernet 802.2 -- Common name: 802.3

• Ethernet SNAP -- Common name: 802.3/SNAP or 802.3/802.2/SNAP

Ethernet II -- Common name: Ethernet

Ethernet II is the most common frame type and is used for TCP/IP as well as many other protocols. Ethernet type 0x8137 is used by IPX.

Ethernet 802.3 -- Common name: "Raw" 802.3

Ethernet 802.3 has no protocol ID and can only carry IPX packets. It is distinguishable from Ethernet_802.2 only because the first 2 bytes of all IPX packets carried on Ethernet 802.3 must be all ones, which makes no sense in Ethernet 802.2. "Raw" 802.3 was the default frame type for NetWare software until NetWare v4.0 was released.

Ethernet 802.2 -- Common name: 802.3

Note that the 802.2 header is implied by the 802.3 standard. Ethernet 802.2 is also known as: 802.3/802.2, to distinguish it from "raw" 802.3. It is used for OSI packets on 802.3 networks. Ethernet 802.2 is the default frame type for the NetWare v4.0 release. Values in parentheses in the table below are the values used by IPX.

Ethernet SNAP -- Common name: 802.3/SNAP or 802.3/802.2/SNAP

Ethernet SNAP is an extension to 802.2, indicated by SAP value of hex AA. Ethernet SNAP is used by AppleTalk and is allmost never used for IPX. Values in parentheses in the table below are the values used by IPX.

How SunScreen Checks the type Field

SunScreen checks the type field as follows:

• For Ethernet II packets, the type field specifies the value of the Ethernet type field located as offset 12 from the beginning of the packet. Any packet that has its Ethernet type field set to a value greater than 1526 is considered an Ethernet II packet. The range of applicable values for type is 1527 through 65536.

• For other Ethernet packets, the values of the DSAP and SSAP are examined, located at offsets 14 and 15 from the beginning of the packet. If the DSAP and SSAP are both 0xAA, the packet is assumed to be an Ethernet SNAP packet. For SNAP packets, the type field specifies the value of Ethernet type field located in the SNAP header at offset 20 from the beginning of the packet. The range of type values is 0 through 65536

• If the DSAP and SSAP are not 0xAA, the type field specifies the value of the DSAP field, located at offset 14. The range of type values is 0 to 169 and 171 to 255; 170 (0xAA) is not allowed.

Example: Passing IPX Packets Between Host A and Host C

Imagine you want to pass IPX packets between HOST A and HOST C in the figure below:

Figure C-1 Ether State Engine: Passing IPX Packets [NEW GFX NEEDED]

You have decided that the frame types used by these systems are 33079 & 33080 (hex 0x8137 and 0x8138).

1. Create and save new services using the ether state engine for each of these frame types. Create a service group (call it "ipx," for example) containing both of these services.

   ---

   Note -

   The ether state engine takes a decimal value for type.

   ---

2. Pick an IP host on the qe2 interface and an IP host on the qe1 interface and create an address list called "qe1andqe2."

   If you have defined interface objects for qe1 and qe2 (which you should do for anti-spoofing) these could be combined into a list called "qe1andqe2."

3. Define a rule:

   Service: ipxSource: qe1andqe2Destination: qe1andqe2Action: normal

   This rule passes all frames with the specified types between the qe1 and qe2 interfaces. That is, a frame from any host on the network attached to qe2 (Host B, for example) will get passed to the network attached to qe1, if the type matches.

   Note that there is no logging with the ether state engine, even if LOG_DETAIL is in the rule--because all SunScreen logging starts at the IP layer and there is no IP layer here.

ftp State Engine

The ftp state engine is used for FTP sessions. This state engine understands the control protocol used by FTP sessions including parsing PORT commands. It supports both traditional and PASV modes. The ftp service is typically the only service that uses this state engine.

The discriminator for the ftp state engine is the port number of the control connection, which is normally 21. The port number of the data session is always one less than the control connection unless this is overridden by the parameters below.

The ftp state engine has the following parameters:

• Lifetime of idle control session in seconds - Specifies the lifetime of an idle control session (default = 600 seconds)

• Lifetime of idle data session in seconds -Specifies the lifetime of an idle data session (default = 600 seconds)

• Flag value - Flag value is a set of bits. If bit 0x01 is set, non PASV data sessions are allowed to originate from a port other than one less than the control port. This feature is sometimes needed to communicate with FTP servers that incorrectly implement the FTP protocol so they do not need to run the data connection as root (default = 0).

icmp State Engine

The icmp state engine is used for ICMP protocols. It allows one-direction ICMP traffic to flow.

The discriminator for the icmp state engine is the ICMP type of the packet.

The icmp state engine has no parameters.

ip State Engine

The ip state engine is a stateless filter that passes unidirectional IP traffic of a particular IP type. The data can only flow in the forward direction (Source to Destination address) This state engine is supplied to provide backwards compatibility with the ip state engine in the SunScreen SPF-100. New service definitions should use either the ipfwd, iptunnel, or ipmobile state engines.

The discriminator for the ip state engine is the IP packet type.

The ip state engine has no parameters.

ipfwd State Engine

The ipfwd state engine allows unidirectional IP traffic of a certain IP type. The data can only flow in the forward direction (Source to Destination address)

The discriminator for the ipfwd state engine is the IP packet type.

The ipfwd state engine has the following parameters:

• Cache timeout in seconds - Specifies the amount of time before the system forgets about IP traffic between a pair of hosts (default is 60 seconds)

• Flag value - Must be 1

ipmobile State Engine

The ipmobile state engine allows bidirectional IP traffic of a certain IP type. The first connection must be initiated by the From address in the rule. Subsequent connections can be initiated from either side as long as the cache entry has not timed out.

The discriminator for the ipmobile state engine is the IP packet type.

The ipmobile state engine has the following parameters:

• Cache timeout in seconds - Specifies the amount of time before the system forgets about IP traffic between a pair of hosts (default is 3600 seconds or 1 hour).

• Flag value - Must be 0 (zero)

iptunnel State Engine

The iptunnel state engine allows bidirectional IP traffic of a certain IP type. Either side of the connection can initiate connections.

The discriminator for the iptunnel state engine is the IP packet type.

The iptunnel state engine has the following parameters:

• Cache timeout in seconds - Specifies the amount of time before the system forgets about IP traffic between a pair of hosts (default is 60 seconds)

• Flag value - Must be 0 (zero)

nis State Engine

The nis state engine is used to define services that are NIS UDP sessions. The predefined service ypserv uses the nis state engine and is normally the only service definition that uses this state engine.

The discriminator for this state engine is the RPC program number of the service. Normally, this is always 100004, the RPC program number for NIS.

The nis state engine has the following parameters:

• Response timeout in seconds - Specifies the time to wait for NIS responses. -1 specifies the state engine will wait forever (default = 60 seconds).

• Number of expected responses per request - Typically 1, because an NIS server sends only a single response to a request (default = 1).

• Flag value - If this value is set to 2, then the system accepts NIS responses from a different port than the NIS request port. This case occurs when an NIS server is responding to name lookups that is mapping to DNS entries (default = 2).

ntp State Engine

SunScreen contains a state engine to handle the NTP protocol. The source and destination UDP ports numbers are fixed at port 123. To screen NTP traffic, use the ntp service. Broadcast NTP is not supported.

ping State Engine

The ping state engine is used for an ICMP ping exchange. It allows ping requests in the forward direction and ping responses in the reverse direction.

The discriminator of the ping state engine is the ICMP type of the request packet. This is normally set to 8 to match that of an ICMP echo request packet.

The ping state engine has one parameter:

• Response timeout in seconds - Specifies the amount of time to wait for ICMP echo responses (default is 10 seconds).

pmap_nis State Engine

The pmap_nis state engine is used for the portmap protocol used by NIS services. It monitors NIS portmap requests and responses and builds a table of host/port to NIS service mappings. The ypserv service is typically the only service definition that uses the pmap_nis state engine.

The discriminator for the pmap_nis state engine is the RPC program number of the service. This is always 100004, which is the RPC program number for NIS.

The pmap_nis state engine has the following parameters:

• Response timeout in seconds - Specifies the time to wait for NIS portmap responses (default = 60 seconds)

• Lifetime of NIS portmap mapping entries in seconds - -1 specifies an infinite lifetime. Because NIS clients cache portmap information indefinitely at boot time, this value is normally set to -1 (default = -1).

pmap_tcp State Engine

The pmap_tcp state engine is used for the TCP portmap protocol used by TCP RPC services. It monitors the TCP portmap requests and responses and builds a table of hosts and ports to RPC service mappings. Normally, a service definition for a TCP RPC service requires both a pmap_tcp and a rcp_tcp state engine entry. The discriminator for the pmap_tcp state engine is the RPC program number of the service.

The pmap_tcp state engine has the following parameters:

• Response timeout in seconds - Specifies the time to wait for portmap responses. (Default = 60 seconds)

• Lifetime of portmap mapping entries in seconds - -1 specifies an infinite lifetime (default = 3600 seconds).

pmap_udp State Engine

The pmap_udp state engine is used for the UDP portmap protocol used by UDP services. It monitors the UDP portmap requests and responses and builds a table of hosts and ports to RPC service mappings. Normally, a service definition for a UDP RPC service requires both a pmap_udp and a rpc_udp state engine entry. The discriminator for the pmap_udp state engine is the RPC program number of the service.

The pmap_udp state engine has the following parameters:

• Response timeout in seconds - This parameter specifies the time to wait for portmap responses (default = 60 seconds)

• Lifetime of portmap mapping entries in seconds - -1 specifies an infinite lifetime (default = 3600 seconds or 1 hour)

realaudio State Engine

The realaudio state engine is used for RealAudio sessions. This state engine understands the control protocol used by these sessions including enabling the UDP ports used for the audio traffic. The realaudio service is typically the only service that uses this state engine. The discriminator for the realaudio state engine is the port number of the TCP control connection, which is normally 7070.

The realaudio state engine has one parameter:

• Lifetime of an idle control session in seconds - Specifies the lifetime of an idle control session (default = 3600 seconds)

rpc_tcp State Engine

The rpc_tcp state engine is used for RPC protocols that use the TCP protocol. Normally, a service definition for such a protocol requires both an rpc_tcp and pmap_tcp state engine entry. The discriminator for the rpc_tcp state engine is the RPC program number for the service.

The rpc_tcp state engine has one parameter:

• Idle session lifetime in seconds - Specifies the lifetime of an idle TCP RCP session in seconds (default = 86400 seconds or 24 hours)

rpc_udp State Engine

The rpc_udp state engine is used for RPC protocols that use the UDP protocol. Normally, a service definition for such a protocol requires both an rpc_udp and pmap_udp state engine entry. The discriminator for the rpc_udp state engine is the RPC program number for the service.

The rpc_udp state engine has the following parameters:

• Response timeout in seconds - Specifies the time to wait for RPC responses. -1 specifies to wait forever (default = 60 seconds)

• Number of expected responses per request (default is 1)

• Flag value - Specifies whether RPC responses must come from the same host or port that the RPC request specified. If the 0x01 bit is set, RPC responses from a different host than the request are allowed. If the 0x02 bit is set, RPC responses from a different port than the request port are allowed (default = 0)

rsh State Engine

The rsh state engine is used for remote shell (rsh) sessions. This state engine understands the control protocol used by these sessions, including the enabling of the TCP connection used for stderr messages. The rsh service is typically the only service that uses this state engine. The discriminator for the rsh state engine is the port number of the RSH server. This is normally 514.

The rsh state engine has one parameter:

• Lifetime of idle session in seconds - Specifies the lifetime of an idle session (default = 86400 seconds or 24 hours)

sqlnet State Engine

The sqlnet state engine is used for Oracle SQL*Net sessions.

It understands the network protocol used by SQL*Net, including redirected sessions (see "sqlnet Service"). The sqlnet service is typically the only service using the sqlnet state engine. Its discriminator is the port number of the Oracle listener, which is normally TCP port 1521.

The sqlnet service is typically the only service using this state engine.

tcp State Engine

The tcp state engine is used for TCP sessions. This state engine allows simple TCP connections. It cannot handle protocols such as FTP or RSH that have more complicated connection management protocols, especially if they open connections in the reverse direction. In those cases, the appropriate, more specific state engine should be used.

The discriminator for the tcp state engine is the port number of the TCP service.

The tcp state engine has one parameter:

• Lifetime of idle connection in seconds - Specifies the lifetime of an idle connection (default = 86400 seconds or 24 hours)

tcp_keepalive State Engine

The tcp_keepalive state engine is for use with protocols that spend long periods in an idle mode (telnet, for example). This state engine prevents the statetable entry from timing out if no packets are sent for a long time. Some SunScreen services (telnet, rlogin, ssh, X11) use tcp_keepalive by default. tcp_keepalive should be used for any TCP-based service that by its nature can include long periods of idle time.

tcp_keepalive causes the Screen to emit a "fake" keepalive packet to the session's source host, claiming to have been sent by the session's destination host. The keepalive packet is sent a few minutes before the Screen normally would drop the session. If the source host is still alive, it responds with an ACK, which causes the Screen to rejuvenate the session lifetime. The ACK is forwarded to the destination host, which responds if it is still alive. If either host has reset or timed out its end of the connection, it will respond with an RST, which causes the Screen to discard the session.

The tcp_keepalive state engine definition specifies that the first keepalive probe be sent 15 minutes before the session expires. If there is no response, multiple probes are sent, rapidly at first, then slowing: 900, 880, 860, 820, 740, 580, and 260 seconds before the session expires.

If you use this state engine for a service, it could lead to a connection being left open through the firewall for an extended period of time. Imagine, for example, someone telnets through the firewall, leaves the connection sitting at a prompt, and then goes on vacation for two weeks. Keepalive probes will continue to be successfully sent and the connection will stay open for two weeks.

It is up to the security administrator of the site to determine if use of this state engine is appropriate. Use of this state engine coupled with an inactivity timeout on login sessions would prevent such a situation from occurring and would make the firewall much more transparent to users, as there would be no "hung" sessions. Careful consideration should be given to the tradeoff between risk and convenience.

The tcp_keepalive state engine has two parameters:

• Lifetime of idle connection in seconds - Specifies the lifetime of an idle connection (default = 86400 seconds or 24 hours)

• Number of seconds before timeout that keepalive probes start

tcpall State Engine

The tcpall state engine is used for TCP service definitions that specify a large range of ports such as the predefined service tcp all. because it has a lower precedence than tcp, ftp, rsh, or realaudio, it does not override any of those services. Normally, this state engine is only used for the predefined service tcp all.

The discriminator for the tcpall state engine is the port number of the TCP service.

The tcpall state engine has the following parameter:

• Lifetime of idle connection in seconds - Specifies the lifetime of an idle connection (default = 86400 seconds or 24 hours)

udp State Engine

The udp state engine is used for UDP services. It allows one or more responses to a UDP request. The requests are validated to make sure they come from the correct address and port and are sent to the correct address and port. The response source address and port checking can be modified using the parameters below.

The discriminator for the udp state engine is the port number of the UDP service.

The udp state engine has the following parameters:

• Response timeout in seconds - Specifies the amount of time to wait for UDP responses. -1 specifies an infinite response timeout. (Default = 60 seconds).

• Number of responses per request - Specifies the number of expected responses for each request. If the number of response specified is 0, any number of responses can be received and the session terminates only after an idle period when no responses have been received. Never specify both a response time of -1 and 0 for the number of responses per request.

• Flag value - Specifies valid sources for UDP responses.

  • If bit 0x01 is set, the UDP response can come from a different host than the request, which is useful for UDP services on multihomed servers that respond using a different address.

  • If bit 0x02 is set, the UDP response can come from a different port than the request.

  • If both bit 0x02 and bit 0x04 are set, then requests can come from a different port than the request, and subsequent requests can also use that new port. This is useful for handling TFTP servers that sometimes switch ports in mid-session.

udpall State Engine

The udpall state engine is used for UDP services where a large number of ports are specified. It has a lower precedence than the dns and udp state engines and does not override services defined with those state engines. It allows one or more responses to a UDP request. The requests are validated to make sure they come from the correct address and port and are sent to the correct address and port. The response source address and port checking can be modified using the parameters below.

The discriminator for the udpall state engine is the port number of the UDP service.

The udpall state engine has the following parameters:

• Response timeout in seconds - Specifies the amount of time to wait for UDP responses. -1 specifies an infinite response timeout (default = 60 seconds).

• Number of responses per request - Specifies the number of expected responses for each request. If the number of response specified is 0, any number of responses can be received and the session terminates only after an idle period when no responses have been received. Never specify both a response time of -1 and 0 for the number of responses per request.

• Flag value - Specifies valid sources for UDP responses.

  • If bit 0x01 is set, the UDP response can come from a different host than the request, which is useful for UDP services on multihomed servers that respond using a different address.

  • If bit 0x02 is set, the UDP response can come from a different port than the request.

  • If both bit 0x02 and bit 0x04 are set, then requests can come from a different port than the request, and subsequent requests can also use that new port. This is useful for handling TFTP servers that sometimes switch ports in mid-session.

udp_datagram State Engine

The udp_datagram state engine is used for one-way UDP protocols. It allows UDP packets to pass in the forward direction only. It is used for services that send UDP packets in one direction, such as syslog.

The discriminator for the udp_datagram state engine is the port number of the UDP service.

The udp_datagram state engine has no parameters.

udp_stateless State Engine

The udp_stateless state engine is used for stateless UDP session filtering. This engine is included for backwards compatibility with older SunScreen products. It has been replaced in most cases with stateful UDP filtering. Because this engine is stateless UDP packet filtering, services defined using it cannot safely validate that the responses go to the same port as the request.

The discriminator for the udp_stateless state engine is the port number of the UDP service.

The udp_stateless state engine has no parameters.