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:

• What protocol does the new service use?

• What ports 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 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.