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:

• What protocol(s) does the new service use?

• What port(s) does the protocol use?

• If your service is an RPC protocol, what program numbers does it use?

• If your service is a UDP protocol, how many responses can be sent back for each request?

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.