test

SunScreen 3.2 Administrator's Overview

Service Object

SunScreen is shipped with a number of predefined network services, such as ftp, telnet, dns, and rsh. See Appendix C, Services and State Engines for a complete list of services and service groups. These services describe the network protocol that is used in the packet-filtering rules. You manipulate them through the SunScreen administration GUI or the configuration editor. You can modify these services or define new services as needed.

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.

There are two types of service objects, described below:

Single Service

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, for most sites you 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 public 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. The state engine is a read-only object that describes the filtering behavior of the packet-filtering engines in SunScreen. For example, the FTP state engine checks port numbers when the ftp service is being used. For more information about state engines, see Appendix C, Services and State Engines. Table C-1 lists the predefined single service objects in SunScreen, along with the state engine and discriminator (port, RPC program number, or type). It also indicates the parameters (state engine modifiers, such as time-outs) and BROADCAST where applicable.

You can modify 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 ones you have modified. 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.

You control the filtering activities by specifying what packet-filtering engine you want to use and the various discriminators and parameters applicable to that filtering engine.

Before you 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 in both the forward and the reverse direction. The FORWARD filter applies when traffic originates from the From Address and goes to the To Address in a rule. The REVERSE filter applies 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 is always 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 non-stateful traffic to return. An example is a rule that uses the nlm (network lock manager) service, which uses the non-stateful ICMP filter engine. It allows nlm requests (ICMP type 8) in the forward direction and nlm replies (ICMP type 0) in the reverse direction.

State engines can have a single port or a range of ports as a discriminator. A single port is just a number (#) ; a range of ports is denoted by a number-to-number range, written as #-# with no space before or after the hyphen. The keyword PORT or BROADCAST is used to identify the type of discriminator. 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 non-broadcast addresses, you must include a filter discriminator both with broadcast selected (BROADCAST) and without it selected (PORT) .

Optionally, a set of parameters can immediately follow the port or range of ports that they modify. They are indicated by keywords and are a space-separated list of numbers.

A service's unique name is its given name plus the name of the Screen if it is associated with one. All references to a service are to its generic name, without regard to any associated Screen.

Service Group

A service group comprises a collection of single services and/or other groups of services. You can group network services together to apply a single rule to multiple network services. "SunScreen Network Service Groups" in Appendix C, Services and State Engines, shows the predefined service groups in SunScreen and the services each includes. Note that not every service is included in a service group.

The predefined common service group, for example, contains the following services: tcp, all, udp all, syslog, dns, rpc all, nfs, prog, icmp all, rip, ftp, rsh, real audio, pmap, udp all, pmap, and tcp all. 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 choosing state engines when a rule includes a service group. Table 4-1 below shows state engines in order of preference--the greater the class/subclass number, the higher the preference. If you have a rule that uses a group of state engines, the one with the higher preference is matched.

A state engine that is followed by an asterisk(*) may conflict with another state engine because another state engine is in the same class and subclass.

Table 4-1 State Engine Class and Subclass

State Engine Name 

Class 

Subclass 

nfsro

11 

0 

nis

10 

0 

pmap_nis

9 

0 

pmap_udp

8 

0 

pmtp_tcp

7 

0 

realaudio*

4 

1 

rpc_tcp

6 

0 

rpc_udp

5 

0 

rsh*

4 

1 

sqlnet*

4 

1 

ftp*

4 

1 

tcpall

4 

0 

dns*

3 

2 

ntp*

3 

2 

udp_stateless*

3 

1 

udp_datagram*

3 

1 

udp*

3 

1 

udpall

3 

0 

ping

2 

1 

icmp

2 

0 

ipmobile

1 

3 

iptunnel

1 

2 

ipfwd

1 

1  

ip

1 

0 

ether

0 

0 

A given service that you have 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.