Appendix B Command Line Reference

This appendix describes the command line user interface for SunScreen EFS 3.0 and the options available for each command.

The top-level programs that you run directly from a Unix shell prompt or shell script are available if the /opt/SUNWicg/SunScreen/bin directory is included in your $PATH.

Other sections in this appendix describe the commands of the two major SunScreen EFS 3.0 subsystems that interpret commands: the ssadm command and the configuration editor. There is also a section on unstable commands that are obsolete or otherwise not guaranteed to exist in future releases of this product.

The following sections describe:

• What is the command line?

• Unix (shell) commands

• ssadm command

• Configuration editor

• Unstable commands

• Network monitoring and maintenance

  ---

  Note -

  As the system administrator for SunScreen EFS 3.0, the command line is most appropriate if you are familiar with the Unix shell and SunScreen EFS 3.0 concepts and terms. If you are new to SunScreen EFS 3.0, use the administration graphical user interface (GUI) to enter network settings.

  ---

What Is the Command Line?

All the functionality of SunScreen EFS 3.0 that is available through the administration GUI is also available through a command. Administering your Screens through the command line can be useful when you want to manage one or more remote Screen or if you use more than one network address.

You can access a Screen using the command line from its own keyboard, when the Screen is being administered locally and requires that you have superuser (root) access; or you can access a Screen using the command line from an Administration Station, when the Screen is being administered remotely and requires that you use SKIP encryption and an Administration User name and password.

You maintain user-controlled data, such as common objects like Edit, and policy objects like Rules and NAT entries, using the edit command that is a sub-command of ssadm.

When you need to look at or change a policy in some way like Move or Delete, you invoke the configuration editor and enter a series of commands that end with save and quit requests.

Be sure to save change commands like add, del, rename, renamereference, insert, replace, and move, before you quit. Run save just before the quit command to avoid accumulating too many policy versions.

You invoke the configuration editor with the edit command, which is a sub-command of ssadm, and the name of your policy, such as Initial. Once it is running, the prompt becomes: edit>.

For a locally administered Screen, type:

# ssadm edit policy_name

For a remotely administered Screen, type:

# ssadm -r Screen_name edit policy_name

Sub-Command man Pages

When running Solaris 7, if you are not able to read the man pages for the following ssadm sub-commands, use the workaround shown below.

ssadm-activate(1M) ssadm-active(1M) ssadm-algorithm(1M) ssadm-backup(1M) ssadm-debug_level(1M) ssadm-edit(1M) ssadm-ha(1M) ssadm-lock(1M) ssadm-log(1M) ssadm-logdump(1M) ssadm-login(1M) ssadm-logout(1M) ssadm-logstats(1M) ssadm-patch(1M) ssadm-policy(1M) ssadm-product(1M) ssadm-restore(1M) ssadm-spf2efs(1M) ssadm-sys_info(1M) ssadm-traffic_stats(1M)

To read the man pages, type the following:

# man -F ssadm-activate

Unix (shell) Commands

The following Unix (shell) commands are available at your shell prompt when /opt/SUNWicg/SunScreen/bin is included in your $PATH.

• ss_install

• screenInstaller

• adminInstaller

• ssadm

• ss_client

  ---

  Note -

  Commands used by the skiptool GUI can be found in the SunScreen SKIP 1.5 User's Guide.

  ---

The following table lists the SunScreen EFS 3.0 Unix (shell) commands and their descriptions. Many of these commands duplicate administration GUI functions, while others provide a context for other commands.

ss_install Command

A text-based command-line utility run during SunScreen EFS 3.0 installation to create an initial configuration. ss_install, combined with pkgadd, is the command-line equivalent to the installation-wizard graphical user interface.

Usage: ss_install

ss_install interactively queries you with various configuration options, creates a configuration, stores it under the policy name "Initial", and activates it.

After ss_install is complete, the Screen is ready to be administered using the administration GUI or the command-line configuration editor and other tools.

screenInstaller Command

Runs the installation wizard that installs the SunScreen EFS 3.0 software on the Screen and creates the Initial configuration.

Usage: ScreenInstaller

adminInstaller Command

Runs the installation wizard that installs the SunScreen EFS 3.0 software on the Administration Station. It is also a quick way to add packages for the remote Administration Station.

Usage: adminInstaller

ss_client Command

ss_client is equivalent to the command of the same name provided with earlier SunScreen firewall products, such as SunScreen EFS, Release 2.0, or SunScreen SPF-200. ss_client is provided only for the purpose of remotely administering such products using the SunScreen EFS 3.0 system as a remote Administration Station.

Usage: ss_client hostname command

For information on how to use ss_client to administer an earlier SunScreen firewall product, see the documentation for that product.

ssadm Command

ssadm is the primary command-line tool for SunScreen EFS 3.0 administration. ssadm has a number of sub-commands that perform various operations such as editing and activating a configuration, and examining the status of a Screen.

The Unix command ssadm provides character-set translation between embedded strings and the local character set of the Solaris system on which it runs.

ssadm runs directly on a locally administered Screen, or indirectly from a remote Administration Station that is using SunScreen SKIP to encrypt IP network communications passing between them. See the SunScreen SKIP User's Guide for more information regarding SKIP encryption.

Usage:

ssadm [-b] [-n] sub-command [parameters...]

ssadm [-b] [-n] -r remotehost [-F ticketfile] sub-command [parameters...]

Options:

-b -- Allow binary data (instead of text) in standard input and output.

-n -- Do not read any input from standard input.

-r remotehost -- Access remote Screen using address or hostname remotehost.

-F ticketfile -- Use authorization ticket stored in ticketfile.

The available ssadm sub-commands are each described in the ssadm Sub-Command section of this document.

The -b option normally is not needed since those commands that process binary data automatically enable the binary mode. For example, ssadm backup, ssadm restore, ssadm log, ssadm logdump, and ssadm patch handle binary data even if -b is not specified.

When ssadm is executed locally on the Screen (that is, without the -r option) no login or authentication is required, but you must be superuser to have any effect.

When ssadm is used with the -r option to access a remote Screen, login authentication is required. You must use the ssadm login command to get a ticket that is used by subsequent invocations of ssadm to allow access to the remote Screen. Normally, the ticket is stored in a ticketfile, the name of which can be specified using the -F option, or through the SSADM_TICKET_FILE environment variable. See the ssadm login command for information about ticket files and remote administration using ssadm.

Executing an ssadm Command on a Local Screen

You can configure a local Screen by typing the commands listed in this appendix using the Screen's keyboard. For example, to activate a policy called "Initial," you would type:

# ssadm activate Initial

where ssadm is the command you want to execute, activate is the name of the ssadm subcommand, and Initial is the name of the policy you want to activate.

The ssadm command resides in the /opt/SUNWicg/SunScreen/bin directory. Include this directory in your directory search path to have access to the commands on the local Screen.

Executing an ssadm -r Command on a Remote Administration Station

You can configure a Screen from a remote Administration Station by preceding the commands listed in this appendix with ssadm -r and the name of the Screen you want to administer. For example, to activate the policy "Initial" on a remote Screen called SunScreen1, you would type:

# ssadm -r SunScreen1 activate Initial

where ssadm -r indicates that you want to execute a command on a remote Screen called SunScreen1, activate is the name of the ssadm sub-command, and Initial is the name of the policy you want to activate.

A local ssadm command can be turned into a remote ssadm command by adding -r remote_screen_name immediately after ssadm.

When ssadm is used with the -r option to access a remote Screen, the name of the ticketfile can be specified using the -F option, or through the SSADM_TICKET_FILE environment.

ssadm Sub-Commands

The following commands, which can be used as the sub-command argument to the ssadm command, are described in this section.

• activate

• active

• algorithm

• backup

• debug_level

• edit

• ha

• lock

• log

• logdump

• login

• logout

• logstats

• patch

• policy

• product

• restore

• sys_info

• traffic_stats

ssadm Sub-Command Summary

The following table lists the SunScreen EFS 3.0 ssadm sub-commands and their descriptions. Many ssadm sub-commands duplicate administration graphical users interface functions, while others provide a context for other sub-commands.

activate Sub-Command

ssadm activate causes the Screen to begin "executing" a particular configuration that is formed when the named policy is combined with the common objects. After activation, the configuration controls the behavior of packet filtering, encryption and decryption, proxies, logging, and administrative access.

Syntax:

ssadm activate [-n] [-l] policy

Options:

-n -- Do not actually make the configuration active, just verify that it is valid.

-l -- Do not send the configuration to other Screens in the centralized management group, only activate it on the local Screen.

The named policy is combined with the common objects to form a configuration.

If you omit the policy argument, ssadm activate reads a configuration file from standard input. Since the format of a configuration file is undocumented and private to the SunScreen internal software, using ssadm activate in this way is not supported.

active Sub-Command

ssadm active prints out a description of the configuration that is currently being executed by the Screen. When run with the -x option, the actual configuration file is extracted from the running system and can be saved for later examination.

Usage:

ssadm active

ssadm active -x policy

Without the -x option, ssadm active describes the active configuration with two lines of text. The first line lists the name of the Screen on which the configuration was originally stored, the name of the internal database in which it was stored (this name is always "default"), and the name of the policy, including its version number. The second line lists the date and time when the configuration was activated, and the user (either a Unix user or SunScreen administration authorized user) who caused it to be activated.

For example:

# ssadm active
Active configuration: greatwall default
Initial.3
Activated by admin on 03/09/1999 02:58:36
PM PST

In this example, the Screen is currently running a configuration that came from the Screen named "greatwall" (which might be the current Screen, or if the Screen is a member of a centralized management group, it might be the primary Screen of the centralized administration group). The configuration includes version 3 of the policy "Initial."

With the -x option, ssadm active saves the active configuration into the named policy that can be examined using the edit command. The named policy must not already exist; ssadm active creates the policy. The saved policy contains a full set of common objects in addition to the policy rules. The -x option is different from a normal policy that contains only policy rules and is meant to be combined with the currently defined common objects.

If the -x option is specified and the policy argument is omitted, ssadm active writes a configuration file to standard output. Since the format of a configuration file is undocumented and private to the SunScreen internal software, using ssadm active in this way is not supported.

algorithm Sub-Command

ssadm algorithm lists the SKIP algorithms that are available for a specified algorithm type.

Usage:

ssadm algorithm type [skipversion]

where type must be one of "key", "data", "mac", or "compression". skipversion, if supplied, must be either "SKIP_VERSION_1" or "SKIP_VERSION_2".

backup Sub-Command

ssadm backup writes a Screen backup file to standard output.

Usage:

ssadm backup [-v] > file

The backup file contains the complete configuration of SKIP, plus all currently defined common objects, policies, and, if the -v option is specified, all of the saved versions of the policies.

The backup file can be restored at a later time using the ssadm restore command.

SECURITY WARNING. The file created by ssadm backup contains sensitive information (SKIP secret keys) that must be stored and disposed of appropriately to protect the integrity of the Screen.

debug_level Sub-Command

ssadm debug_level controls the output of internal debugging information from the SunScreen kernel.

Usage:

ssadm debug_level [newlevel]

ssadm debug_level ?

With no arguments, ssadm debug_level prints out the current debug level in hexadecimal. With the newlevel argument, ssadm debug_level sets the debug level to newlevel. With the question mark argument (may need to be quoted in the Unix shell) ssadm debug_level prints out a list of bit values and their meanings.

The debugging information, when enabled, is written through the kernel message mechanism and typically ends up on the system console or the kernel message logs. The format of the messages is not documented and is only used by Sun support personnel.

edit Sub-Command

ssadm edit runs the SunScreen EFS 3.0 configuration editor.

Usage:

ssadm edit policy

ssadm edit policy < file

ssadm edit policy -c commandstring

See the "Configuration Editor Sub-Command" section for information regarding commands supported by ssadm edit. The configuration editor can be used in any of three modes: interactive, batch, or "-c" mode. In interactive mode, the editor prints a prompt (edit>) before each command is read from your terminal. In batch mode, the editor silently reads commands from standard input. Commands are read until the editor receives end-of-file or a quit command.

If ssadm edit is run on an interactive terminal and its input and output are not redirected, it automatically enters interactive mode. If standard input is a pipe or a file, the configuration editor runs in batch mode.

If ssadm edit is run with the -c option, it executes the commandstring and then exits without reading any other commands. commandstring must be a single argument to the program, so in the Unix shell it usually has to be quoted with single or double quotes.

ha Sub-Command

ssadm ha performs operations on a Screen in a high availability (HA) cluster.

Usage:

ssadm ha function parameters...

Functions:

status -- Display status of the HA cluster.

active_mode -- Put the Screen in active mode.

passive_mode -- Put the Screen in passive mode.

init_primary interface -- Turn a standalone (non-HA) Screen into an HA primary Screen, thereby creating a new HA cluster containing one Screen. interface is the interface to be used for the HA heartbeat and synchronization. primaryIP is the IP address (on the HA network) of the primary machine in the cluster.

init_secondary interface primaryIP -- Turn a standalone (non-HA) Screen into an HA secondary screen ready to join an existing HA cluster. Where interface is used for the HA heartbeat and synchronization, and primaryIP is the IP address (on the HA network) of the primary machine in the cluster.

add_secondary secondaryIP -- Add an initialized HA secondary Screen (see init_secondary above) into an existing HA cluster. This command is executed on the primary Screen in the HA cluster. Where secondaryIP is the IP address (on the HA network) of the secondary machine to be added.

lock Sub-Command

ssadm lock manipulates the lock that protects a policy from simultaneous modification by multiple administrators.

Usage:

ssadm lock -w policy

ssadm lock -c policy

ssadm lock -w prints a line of text describing the status of the lock.

ssadm lock -c forcibly breaks the lock and attempts to terminate (with a SIGHUP signal) the previous holder of the lock.

For example:

# ssadm lock -w Initial
Lock held by admin@198.41.0.6 process
id:8977
# ssadm lock -c Initial
# ssadm lock -w Initial
Lock available

log Sub-Command

ssadm log retrieves and clears the SunScreen EFS 3.0 log.

Usage:

ssadm log get filter_args...

ssadm log get_and_clear filter_args...

ssadm log clear

logdump Sub-Command

ssadm logdump is used to filter or display log records, as retrieved by ssadm log get.

Usage:

ssadm logdump parameters...

login Sub-Command

ssadm login authenticates a user for administrative access through ssadm to a Screen from a remote Administration Station.

Usage:

ssadm -r remotehost login username password

ssadm login creates a session on the remote Screen and provides a ticket that allows subsequent invocations of the ssadm command to access the remote Screen without using a password.

ssadm login is only available with the -r remotehost option.

The ticket is written to standard output. If a ticketfile is specified using the -F option to ssadm or the SSADM_TICKET_FILE environment variable, then ssadm login automatically stores the ticket in ticketfile in addition to writing it to standard output.

For example:

# SSADM_TICKET_FILE=$HOME/.ssadmticket
# export SSADM_TICKET_FILE
# touch $SSADM_TICKET_FILE
# chmod go= $SSADM_TICKET_FILE
# ssadm -r greatwall login admin password
WRITE access <E23B344150C702EC>
# ssadm -r greatwall activate Initial
Configuration activated successfully on greatwall.
# ssadm -r greatwall active
Active configuration: greatwall default Initial.3
Activated by admin on 03/09/1999 02:58:36 PM PST
# ssadm -r greatwall logout

The above example is for sh or ksh; other shells may require different commands. ssadm login is only available with the -r remotehost option.

When using the ssadm login command on multi-user Administration Stations, any other user can snoop the admin user and password using ps, then (because SKIP is enabled from that host) access the Screen(s) as that user.

It is inadvisable to have a general-use Solaris system act as a SunScreen EFS 3.0 Administration Station. Additionally, never use the ssadm login command on a Solaris system while other users are logged in.

Screen administration is discouraged from non-Solaris platforms. Serious security holes with other operating systems can readily be exploited to compromise the network security infrastructure.

See the ssadm-login(1M) man page for more information on the login command.

logout Sub-Command

ssadm logout terminates the session created by ssadm login.

Usage:

ssadm -r remotehost logout

ssadm logout is only available with the -r remotehost option.

You are encouraged to log out from the SunScreen EFS 3.0 administration GUI on the Administration Station upon completion of the administrative tasks. If you remain logged into the Administration Station without activity for a twenty-four hour period, the administration GUI stops responding.

logmacro Sub-Command

ssadm logmacro expands a SunScreen logmacro object.

Usage:

ssadm logmacro expand macroname

logmacro add macrokey macrovalue

logmacro delete macrokey

logmacro print[,sortopt] [ macrokey ]

logmacro names[,sortopt]

where macrokey is of the form [ SYS=scrnname ] NAME=name macrovalue is of the form VALUE="macrobody" sortopt is one of asc, desc, iasc

(for example: desc specifies a plain-text description string desc to be associated with the object.

logstats Sub-Command

ssadm logstats prints information about the SunScreen EFS 3.0 log.

Usage:

ssadm logstats

patch Sub-Command

ssadm patch installs a patch, as needed.

Usage:

ssadm patch < patchfile

If a SunScreen EFS 3.0 software patch is needed, detailed instructions are provided with the patch.

policy Sub-Command

ssadm policy creates, deletes, renames, or lists the defined policies.

Usage:

ssadm policy -a policies...

ssadm policy -c oldname newname

ssadm policy -d [-v] policies...

ssadm policy -l [-v] [policies...]

ssadm policy -r oldname newname

Options:

-a -- Creates policies with the specified names. The newly created policy contains no rules and reference the currently defined common objects.

-c -- Creates a policy named newname as a copy of the existing policy named oldname.

-d -- Deletes the named policies. The specified policies can be either generic policy names, such as "Initial", or specific versions, such as "Initial.3". When a generic policy name is specified and the -v option is specified, ssadm policy -d deletes all of the versions of the policy. When a specific version is specified, only that version is deleted.

-l -- Lists the named policies (or all policies available if no policies are given). The -v option also lists all of the saved versions of the policies.

-r -- Renames the existing policy oldname as newname.

product Sub-Command

ssadm product prints out a single line of text describing the SunScreen product in use. For SunScreen EFS 3.0 this is simply "EFS".

Usage:

ssadm product

restore Sub-Command

ssadm restore reads a backup file from standard input. The backup file must have been created using the backup command.

Usage:

ssadm restore < file

spf2efs Sub-Command

ssadm spf2efs converts a set of configuration data saved from a SunScreen SPF Screen into SunScreen EFS 3.0 format.

Usage:

ssadm spf2efs < file

sys_info Sub-Command

ssadm sys_info prints a description of the running SunScreen software.

Usage:

ssadm sys_info

For example:

# ssadm sys_info
Product: 											SunScreen EFS
3.0
System Boot Time: 											03/15/1999
03:51 PST
SunScreen Boot Time: 											Mon
Mar 15 03:51:56 PST 1999
Version: 											Release 3.0 Beta1,
March 10 
											1999(v0310991418)

traffic_stats Sub-Command

ssadm traffic_stats reports summary information about the traffic flowing through the Screen, classified by interface.

Usage:

ssadm traffic_stats [interfaces...]

Unsupported Commands

Commands listed in this section are obsolete. They are only used for abnormal maintenance or customer support functions, or as a temporary work around to limitations of the current software.

These commands are "unstable," which means that they may not be provided in future SunScreen product releases, or in versions for other operating systems.

ssadm lib/screeninfo Command

ssadm lib/statetables -f Command

ssadm lib/support Command

ssadm SKIP Commands

ssadm lib/screeninfo Command

ssadm lib/screeninfo runs in sequence several of the functions of the ssadm lib/support command, printing out a large set of information about the Screen and its current configuration.

Usage:

ssadm lib/screeninfo

The output of this command can be redirected to a file and may be requested by Sun Service if you encounter problems with your Screen.

ssadm lib/statetables -f Command

ssadm lib/statetables -f causes the Screen to flush (discard) all of its connection state information. This causes all previously active connections through the Screen to be effectively disconnected.

This command is often useful after activating a modified policy which disallows some traffic which was previously allowed. Without running ssadm lib/statetables -f, you allow any previously existing connections to remain active even if the new policy does not allow them. By running ssadm lib/statetables -f, you cause all previously existing connections to be disconnected and the active policy will apply to any subsequent connections.

ssadm lib/support Command

ssadm lib/support provides various diagnostic and status information that can be useful when requesting customer support for the SunScreen product.

Usage:

ssadm lib/support function parameters...

This information may be requested by Enterprise Services if you encounter problems with your Screen.

If you have any support issues, call your authorized service provider. For further information about support, use the following URL to contact Enterprise Services: http://www.sun.com/service/contacting.

The major functions are:

ssadm SKIP Commands

ssadm lib/skipca

ssadm lib/skipd_restart

ssadm lib/skipdb

ssadm lib/skiplocal

ssadm lib/skipstat

These commands provide access to the command-line administration tools of the SKIP software. They are primarily useful when a Screen is not physically accessible or does not allow logins over the network and you want to configure SKIP using the ssadm command with the -r option from a remote Administration Station.

See the corresponding commands in the SunScreen SKIP 1.5 User's Guide for information on the parameters.

Configuration Editor

The configuration editor is the primary command-line tool for creating and manipulating the objects that control the operation of a Screen.

Configuration Editor Data Model

The following table lists the data types that compose the Data Model as maintained by the configuration editor (ssadm edit) and the ssadm policy command.

Object types marked as having "common" storage in the table are normally stored in the common objects registry that is not part of any particular policy. These objects are used by all policies, so changes to the common objects can affect the behavior of multiple policies. To edit the common objects, it is necessary to specify a policy name when starting the configuration editor even if you are not modifying any policy objects.

Object types marked as having "policy" storage in the table are stored as part of a policy. Policy objects often refer to common objects and therefore can have different meaning depending on the value of common objects. for example, a policy can contain a rule object that allows address A to communicate with address B. The address objects A and B are defined in the common objects.

Object types marked as having "external" storage in the table are almost equivalent to "common" objects, but they are stored in a separate database that is not affected by the "quit," "reload," or "save" commands. Changes to these objects are always immediate, and persist even if the "save" command is not used.

Object types marked as having "policy list" storage in the table represents the names of the policies themselves. Minimal capabilities are provided by the configuration editor to manage the policy. A policy currently being edited can be saved or "cloned" (or portions of it) into a new policy. Other policy requests, such as add, delete, and rename are provided by the ssadm policy command.

Configuration Editor Commands

The ssadm edit commands are used when running the configuration editor, which is responsible for maintaining the SunScreen EFS 3.0 configuration database.

The following table lists the SunScreen EFS 3.0 configuration editor ssadm edit sub-commands and their descriptions. Many sub-commands duplicate administration GUI functions, while others provide a context for other sub-commands.

In the following command descriptions, when the name of an object of a particular TYPE is required, it is indicated by name_TYPE. If an index is needed, it is indicated by #. A keyword that was required in previous SunScreen releases but is now optional, is indicated by KEYWORD.

add Sub-Command

Creates or re-defines an entry.

Usage:

add TYPE parameters...

If a named-type is specified and an entry with that name already exists, it is replaced with the new entry. If it does not exist, one is created with the new name. All of the following have a similar request of add_nocheck, which does not perform consistency checking.

add address Sub-Command

add address "name_ADDRESS" <HOST> #.#.#.#

add address "name_ADDRESS" <RANGE> #.#.#.# #.#.#.#

add address "name_ADDRESS" <GROUP> { "name_ADDRESS" ... } { "name_ADDRESS" ... } { "name_ADDRESS" ... }

The following fields are optional and can be specified in any order after the "address" keyword:

SCREEN "name_SCREEN"

COMMENT "comment string"

The addresses "*" and "localhost" are reserved and cannot be edited.

add screen Sub-Command

add screen "name_SCREEN"

The following fields are optional and can be specified in any order after the "screen" keyword:

MASTER "name_SCREEN"

HA_PRIMARY

HA_SECONDARY

TIMEOUT #

SNMP #.#.#.# ... (list can be empty; not output if empty list)

CDP {"on" if present, "off" otherwise}

ROUTING {"on" if present, "off" otherwise}

DNS {"on" if present, "off" otherwise}

NIS {"on" if present, "off" otherwise}

LOGSIZE # {default is 100MB if not present}

SPF #.#.#.# #.#.#.# {Network and Netmask for stealth type Interfaces}

HA_IP #.#.#.# (required if HA_PRIMARY is set)

HA_ETHER xx:xx:xx:xx:xx:xx (required if HA_PRIMARY is set)

COMMENT "comment string"

If the Screen is to be a part of an HA cluster, and administered remotely, then the following fields must be specified as well. They can be specified in any order after the "screen" keyword:

ADMIN_IP #.#.#.#

ADMIN_CERTIFICATE "name_CERTIFICATE"

KEY "name_KEY_ALGORITHM"

DATA "name_DATA_ALGORITHM"

MAC "name_MAC_ALGORITHM"

COMPRESSION "name_COMPRESSION_ALGORITHM"

TUNNEL "name_ADDRESS"

The screen "*" is reserved and cannot be edited.

add service Sub-Command

add service "name_SERVICE" <SINGLE> filter ...

add service "name_SERVICE" GROUP "name_SERVICE" ...

For SINGLE services, a list of Filters follows the SINGLE keyword. The list must not be empty, and each Discriminator list must also not be empty. A Filter is of the form:

FORWARD "name_STATEENGINE" discriminator ...

REVERSE "name_STATEENGINE" discriminator ...

An individual discriminator is as follows:

PORT #

PORT #-# (Note, no space is allowed before or after the "-" character)

BROADCAST #

BROADCAST #-#

An optional parameter for discriminators, which appears immediately after the number or range it modifies, is:

PARAMETERS space-separated list of #

For GROUP services, a space-separated list of "name_SERVICE" entries follows the GROUP keyword.

The following fields are optional and can be specified in any order after the "service" keyword:

SCREEN "name_SCREEN"

COMMENT "comment string"

add interface Sub-Command

add interface "name_INTERFACE" type "name_ADDRESS"

type must be one of ADMIN, DISABLED, EFS, HA, or SPF.

The following fields are optional for stealth interface types and can be specified in any order after the "interface" keyword. Up to 5 ROUTERs per stealth interface can be specified. More can be specified, but only 5 (no guarantee which ones) are used by the system.

ROUTER #.#.#.#

The following fields are optional for all interface types and can be specified in any order after the "interface" keyword:

SCREEN "name_SCREEN"

COMMENT "comment string"

The following fields are optional for all interface types except DISABLED and can be specified in any order after the "interface" keyword.

LOG NONE {default if no LOG is specified}

LOG SUMMARY

LOG DETAIL

ICMP NONE

ICMP NET_UNREACHABLE

ICMP HOST_UNREACHABLE

ICMP PORT_UNREACHABLE

ICMP NET_FORBIDDEN

ICMP HOST_FORBIDDEN

SNMP {"on" if present, "off" otherwise}

add certificate Sub-Command

add certificate "name_CERTIFICATE" SINGLE NSID # MKID "#"

add certificate "name_CERTIFICATE" GROUP "name_CERTIFICATE" ...

For GROUP certificates, a space-separated list of "name_CERTIFICATE" entries follows the GROUP keyword.

The following fields are optional for SINGLE entries and may be specified in any order after the "certificate" keyword:

G #

P #

KEY_LENGTH #

LOCAL "name_SCREEN"

The following fields are optional and can be specified in any order after the "certificate" keyword:

SCREEN "name_SCREEN"

COMMENT "comment string"

add time Sub-Command

add time "name_TIME"

The following fields are optional and can be specified in any order after the "time" keyword:

EVERYDAY

SUNDAY

MONDAY

TUESDAY

WEDNESDAY

THURSDAY

FRIDAY

SATURDAY

SCREEN "name_SCREEN"

COMMENT "comment string"

Following any of the *DAY keywords can be a time of day specification in the form {timespec ...} . timespec is a time range in the form:

Start Hour:Start Minute Stop Hour:Stop Minute

Examples are: "{ 1:00 2:30 }" and "{ 1:00 2:30 4:00 6:00 }". 24-hour time format is used, so the valid times are 0:00 (starting at midnight) through 24:00 (ending at midnight).

add rule Sub-Command

add rule "name_SERVICE" name_ADDRESS

Appends the rule to the end of the list of rules in the policy. "insert rule" should be used to position a new rule into an existing policy.

The following fields are optional and can be specified in any order after the "rule" keyword:

ALLOW {default if no ACTION specified}

DENY

LOG NONE {also LOG_NONE, default if no LOG is specified}

LOG SUMMARY {also LOG_SUMMARY}

LOG DETAILED {also LOG_DETAILED}

LOG SESSION {also LOG_SESSION, only valid for ALLOW rules, will be error for DENY}

SNMP {"on" if present, "off" otherwise}

USER "name_USER" {only used if PROXY_FTP or PROXY_Telnet set below }

TIME "name_TIME"

SCREEN "name_SCREEN"

COMMENT "comment string"

The following combo-field is optional and only valid in a rule that has ALLOW specified. It can be specified anywhere after the "rule" keyword:

SKIP_VERSION_1 "name_CERTIFICATE" "name_CERTIFICATE" "name_KEY_ALGORITHM" "name_DATA_ALGORITHM"

SKIP_VERSION_2 "name_CERTIFICATE" "name_CERTIFICATE" "name_KEY_ALGORITHM" "name_DATA_ALGORITHM" "name_MAC_ALGORITHM" "name_COMPRESSION_ALGORITHM"

The following fields are optional and only valid within a SKIP_VERSION_1 or SKIP_VERSION_2 combo-field. They can be specified in any order after the SKIP_VERSION_# keyword:

SOURCE_TUNNEL "name_ADDRESS"

DESTINATION_TUNNEL "name_ADDRESS"

The following field is optional and only valid in a rule that has DENY specified. It can be specified anywhere after the "rule" keyword:

ICMP NONE {also ICMP_NONE, default if nothing is specified}

ICMP NET_UNREACHABLE {also ICMP_NET_UNREACHABLE}

ICMP HOST_UNREACHABLE {also ICMP_HOST_UNREACHABLE}

ICMP PORT_UNREACHABLE {also ICMP_PORT_UNREACHABLE}

ICMP NET_FORBIDDEN {also ICMP_NET_FORBIDDEN}

ICMP HOST_FORBIDDEN {also ICMP_HOST_FORBIDDEN}

The following field is optional and only valid in a rule that has ALLOW specified and NO SKIP information. It can be specified anywhere after the "rule" keyword:

VPN "name_VPN"

The following fields are optional and only valid in a rule that has not specified any SKIP information and no VPN. They can be specified anywhere after the "rule" keyword. Only one of them can be specified in a given rule.

PROXY_FTP

PROXY_HTTP

PROXY_SMTP

PROXY_Telnet

The following fields are optional and only valid in a rule that has specified PROXY_FTP. They can be specified anywhere after the "PROXY_FTP" keyword:

FTP_GET

NO_FTP_GET {default if FTP_GET not specified}

FTP_PUT

NO_FTP_PUT (default if FTP_PUT not specified}

FTP_CHDIR

NO_FTP_CHDIR {default if FTP_CHDIR not specified}

FTP_MKDIR

NO_FTP_MKDIR {default if FTP_MKDIR not specified}

FTP_RENAME

NO_FTP_RENAME {default if FTP_RENAME not specified}

FTP_REMOVE_DIR

NO_FTP_REMOVE_DIR {default if FTP_REMOVE_DIR not specified}

FTP_DELETE

NO_FTP_DELETE {default if FTP_DELETE not specified}

The following fields are optional and only valid in a rule that has specified PROXY_HTTP. They can be specified anywhere after the "PROXY_HTTP" keyword:

COOKIES

NO_COOKIES {default if COOKIES not specified}

ACTIVE_X

NO_ACTIVE_X {default if ACTIVE_X not specified}

SSL

NO_SSL {default if SSL not specified}

JAVA_SIGNATURE

JAVA_HASH

JAVA_SIGNATURE_HASH

JAVA

NO_JAVA {default if no other JAVA setting is specified}

The following fields are optional and only valid in a rule that has specified PROXY_SMTP. They can be specified anywhere after the "PROXY_SMTP" keyword: RELAY

NO_RELAY {default if RELAY not specified}

add nat Sub-Command

add nat STATIC "name_ADDRESS" "name_ADDRESS" "name_ADDRESS" "name_ADDRESS"

add nat DYNAMIC "name_ADDRESS" "name_ADDRESS" "name_ADDRESS" "name_ADDRESS"

The following fields are optional and can be specified in any order after the "nat" keyword:

SCREEN "name_SCREEN"

COMMENT "comment string"

add accesslocal Sub-Command

add accesslocal USER "name_USER"

The following fields are optional and can be specified in any order after the "accesslocal" keyword:

SCREEN "name_SCREEN"

COMMENT "comment string"

add accessremote Sub-Command

add accessremote USER "name_USER" "name_ADDRESS" SKIP_VERSION_1 "name_CERTIFICATE" "name_KEY_ALGORITHM" "name_DATA_ALGORITHM"

add accessremote USER "name_USER" "name_ADDRESS" SKIP_VERSION_2 "name_CERTIFICATE" "name_KEY_ALGORITHM" "name_DATA_ALGORITHM" "name_MAC_ALGORITHM" "name_COMPRESSION_ALGORITHM"

The following field is optional for accessremote entries. It can be specified in any order after the "accessremote" keyword:

TUNNEL "name_ADDRESS" { if the remote machine is using tunneling }

The following fields are optional and can be specified in any order after the "accesslocal/accessremote" keyword:

PERMISSION ALL

PERMISSION WRITE

PERMISSION READ

PERMISSION STATUS

PERMISSION NONE { default if no PERMISSION is specified }

SCREEN "name_SCREEN"

COMMENT "comment string"

add vpngateway Sub-Command

add vpngateway "name_VPN" "name_ADDRESS" SKIP "name_CERTIFICATE"

The following fields are required and can be specified in any order after the "vpngateway" keyword:

KEY "name_KEY_ALGORITHM"

DATA "name_DATA_ALGORITHM"

MAC "name_MAC_ALGORITHM"

COMPRESSION "name_COMPRESSION_ALGORITHM"

The following fields are optional and can be specified in any order after the "vpngateway" keyword:

TUNNEL "name_ADDRESS"

COMMENT "comment string"

add_member Sub-Command

Adds a member to a group or list.

Usage:

add_member address "name_ADDRESS" "name_ADDRESS"* { add to include list }

add_member address "name_ADDRESS" EXCLUDE "name_ADDRESS"* { add to exclude list }

add_member service "name_SERVICE" "name_SERVICE"*

add_member certificate "name_CERTIFICATE" "name_CERTIFICATE"*

"*" denotes that multiple space-separated names can be specified in a single request.

The following field may be necessary to uniquely identify an entry. If so, it can be specified after the TYPE keyword:

SCREEN "name_SCREEN"

authuser Sub-Command

Manipulates the list of authorized users.

Usage:

authuser add name parameters...

authuser delete name

authuser print

delete Sub-Command

Deletes the specified entry of the given TYPE.

Usage:

del[ete] address "name_ADDRESS"

*del[ete] screen "name_SUNSCREEN"

del[ete] service "name_SERVICE"

del[ete] interface "name_INTERFACE"

del[ete] certificate "name_CERTIFICATE"

del[ete] time "name_TIME"

*del[ete] rule #

*del[ete] nat #

*del[ete] accesslocal #

*del[ete] accessremote #

*del[ete] vpngateway #

The following field may be necessary to uniquely identify an entry. If so it can be specified after the TYPE keyword, except for the entries preceded by an "*" above:

SCREEN "name_SCREEN"

delete_member Sub-Command

Deletes a member from a group or list.

Usage:

del[ete]_member address "name_ADDRESS" "name_ADDRESS"* { from include list }

del[ete]_member address "name_ADDRESS" EXCLUDE "name_ADDRESS"* { from exclude list }

del[ete]_member service "name_SERVICE" "name_SERVICE"*

del[ete]_member certificate "name_CERTIFICATE" "name_CERTIFICATE"*

"*" denotes that multiple space-separated names can be specified in a single request.

The following field may be necessary to uniquely identify an entry. If so it can be specified after the TYPE keyword:

SCREEN "name_SCREEN"

insert Sub-Command

Inserts a new object of one of the ordered (indexed) types in a specified position in the corresponding list.

Usage:

insert rule # parameters...

insert nat # parameters...

insert accesslocal # parameters...

insert accessremote # parameters...

insert vpngateway # parameters...

Index indicates the position the new entry holds in the list after it is inserted. The same syntax used for add is used for insert, with the index coming immediately after the TYPE keyword.

jar_hash Sub-Command

Manipulates the list of JAR hashes used by the HTTP proxy.

Usage:

jar_hash add name hash

jar_hash delete name

jar_hash rename oldname newname

jar_hash list

jar_hash list_names

Functions:

add -- Add an entry to the jar_hash database.

del -- Delete an entry from the jar_hash database.

rename -- Rename an entry in the jar_hash database.

list -- List the entries in the jar_hash database.

list_names -- List the names of the entries in the jar_hash database.

jar_sig Sub-Command

Manipulates the list of JAR signatures used by the HTTP proxy.

Usage:

jar_sig add name sig-hash

jar_sig delete name

jar_sig rename oldname newname

jar_sig list

jar_sig list_names

Functions:

add -- Add an entry to the jar_sig database.

del -- Delete an entry from the jar_sig database.

rename -- Rename an entry in the jar_sig database.

list -- List the entries in the jar_sig database.

list_names -- List the names of the entries in the jar_sig database.

list Sub-Command

Displays all data for all entries or a specific entry of a given TYPE. The format of the output is the same as the syntax of the corresponding Add TYPE request.

Usage:

*list address

list address "name_ADDRESS"

*list screen

*list screen "name_SCREEN"

*list service

list service "name_SERVICE"

*list stateengine

*list stateengine "name_STATEENGINE"

*list interface

list interface "name_INTERFACE"

*list certificate

list certificate "name_CERTIFICATE"

*list time

list time "name_TIME"

*list rule

*list rule #

*list nat

*list nat #

*list accesslocal

*list accesslocal #

*list accessremote

*list accessremote #

*list vpngateway

*list vpngateway #

The following field is optional and can be specified after the TYPE keyword in any of the above requests except those which are preceded by an "*".

SCREEN "name_SCREEN"

If no SCREEN option is present, only entries not associated with a specific SCREEN are listed. If the SCREEN option value is "*", then all entries that otherwise match are displayed. Requests that do not specify a name always display all entries of the given type.

list_name Sub-Command

Displays the set of unique basenames and sub-type of all of a given TYPE. These are the values that can be used when another object refers to an object of the specified TYPE.

Usage:

list_name TYPE

TYPE can be any of address, screen, service, stateengine, interface, certificate, time, or vpn.

load Sub-Command

Loads a policy into the configuration editor.

Usage:

load "name_POLICY"

Any edits to the current policy must be saved or discarded before this operation will succeed.

lock Sub-Command

ssadm lock manipulates the lock that protects a policy from simultaneous modification by multiple administrators.

Usage:

ssadm lock -w policy

ssadm lock -c policy

ssadm lock -w prints a line of text describing the status of the lock.

ssadm lock -c forcibly breaks the lock and attempts to terminate (with a SIGHUP signal) the previous holder of the lock.

For example:

# ssadm lock -w Initial
Lock held by admin@198.41.0.6 process
id:8977
# ssadm lock -c Initial
# ssadm lock -w Initial
Lock available

lock_status Sub-Command

Returns the status of the Lock relative to this editor. If this editor holds a lock, the type of lock is returned. If it does not hold a lock, another process acquired a WRITE lock, in which case, if that WRITE lock is still in effect, information about that WRITER is presented. If that WRITE lock is no longer in effect, then Lock available is returned.

Usage:

lock_status

search Sub-Command

Searches the Registry for objects that match specified criteria.

Usage:

search TYPE [SCREEN "name_SCREEN"] [ SUBTYPE subtype] Substring...

TYPE can be any of address, screen, service, stateengine, interface, certificate, or time. SUBTYPE values depend upon the TYPE being searched according to the following table.

move Sub-Command

Moves an indexed entry from its current location in the ordered list to the new location.

Usage:

move rule # #

move nat # #

move accesslocal # #

move accessremote # #

move vpngateway # #

replace Sub-Command

Replaces an object at a specified index.

Usage:

replace rule # parameters...

replace nat # parameters...

replace accesslocal # parameters...

replace accessremote # parameters...

replace vpngateway # parameters...

replace is similar to insert, except it replaces the entry at the specified index. A short-hand for an insert n / del n+1 pair of requests. The same syntax used for add is used for replace, with the index coming immediately after the TYPE keyword.

refer Sub-Command

Determines if a named-objects of a given TYPE is referred to in the common data or the current policy.

Usage:

refer address "name_ADDRESS"

refer screen "name_SCREEN"

refer service "name_SERVICE"

refer stateengine "name_STATEENGINE"

refer certificate "name_CERTIFICATE"

refer time "name_TIME"

refer vpn "name_VPN"

referlist Sub-Command

Displays a list of all entries in the common objects and/or the current policy that refer to a specified named-object of a given TYPE.

Usage:

referlist address "name_ADDRESS"

referlist screen "name_SCREEN"

referlist screen "name_SCREEN"

referlist service "name_SERVICE"

referlist stateengine "name_STATEENGINE"

referlist certificate "name_CERTIFICATE"

referlist time "name_TIME"

referlist vpn "name_VPN"

rename Sub-Command

Renames a specified named-object of a given TYPE.

Usage:

rename address "name_ADDRESS" "name_ADDRESS"

*rename screen "name_SCREEN" "name_SCREEN"

rename service "name_SERVICE" "name_SERVICE"

rename interface "name_INTERFACE" "name_INTERFACE"

rename certificate "name_CERTIFICATE" "name_CERTIFICATE"

rename time "name_TIME" "name_TIME"

The following field may be necessary to uniquely identify an entry. If so it can be specified after the TYPE keyword except for the entries preceded by an "*" above:

SCREEN "name_SCREEN"

If an entry already exists with the new name, it is replaced by this operation.

renamereference Sub-Command

Renames all references to a specified named-object of a given TYPE.

Usage:

renamereference address "name_ADDRESS" "name_ADDRESS"

renamereference screen "name_SCREEN" "name_SCREEN"

renamereference service "name_SERVICE" "name_SERVICE"

renamereference certificate "name_CERTIFICATE" "name_CERTIFICATE"

renamereference time "name_TIME" "name_TIME"

renamereference vpn "name_VPN" "name_VPN"

save Sub-Command

Saves all current edits to the common objects and policy.

Usage:

save

save "name_POLICY" [types...]

If a name is specified, then the current policy is written to the new name, but remains the policy in the editor.

The following types can be specified.

• Rule

• Nat

• AccessLocal

• AccessRemote

• VPNGateway

reload Sub-Command

Discards any and all edits (if any were made) and re-loads the data into the editor from the database. If another process has performed edits and saved them since the current editor process loaded its data, and the current editor process wants to perform edits, it must perform a reload first, to re-acquire its read lock and ensure that no saved edits are lost.

Usage:

reload

verify Sub-Command

Takes no arguments and "verifies" the currently loaded policy.

Usage:

verify

mail_relay Sub-Command

Manipulates the list of mail relays used by the SMTP proxy.

Usage:

mail_relay parameters

mail_spam Sub-Command

Manipulates the list of spam domains used by the SMTP proxy.

Usage:

mail_spam add domain-string

mail_spam del domain-string

mail_spam list

proxyuser Sub-Command

Manipulates the list of proxy users.

Usage:

proxyuser add name parameters...

proxyuser delete name

proxyuser print

vars Sub-Command

Manipulates variables used for RADIUS configuration.

Usage:

vars add variables

quit Sub-Command

Causes the editor to terminate if there are no unsaved changes.

Usage:

quit

When the editor is used interactively, typing quit twice consecutively causes the editor to terminate even if there are unsaved changes.

QUIT Sub-Command

QUIT (typed in upper case) causes the editor to terminate even if there are unsaved changes.

Usage:

QUIT

Network Monitoring and Maintenance

The following describes how to monitor and maintain your SunScreen EFS 3.0.

Installing a Patch

If and when patches are necessary, follow the instructions accompanying the patch.

Examining Logged Packets (ssadm logdump)

SunScreen EFS 3.0 provides flexible logging of packets. A packet can be logged when it matches a rule, or SunScreen EFS 3.0 can be configured to log packets that do not match any particular rule. Most frequently, packets matching Fail rules or packets that are dropped because they do not match any rule are logged. The action definition of a rule controls whether a packet is logged and whether the logging is detailed or summary.

To set the logging type of packets being dropped because they do not match any rule, use the administration GUI.

Examining logged packets can be a very useful tool in troubleshooting problems in setting up configurations. For example, when first creating configurations, make the default Fail action "log packets." This way, the logs can be reviewed to discover forgotten protocols that then can be added to the configuration. A system administrator can also use logging to capture any attempts to break in.

Logs are retrieved and cleared using the Logs page of the administration GUI. Once a log is retrieved, it can be examined using the ssadm logdump command.

Using the ssadm logdump Command

ssadm logdump is based on the Solaris snoop program and has similar characteristics. In addition to the packet information available with snoop, ssadm logdump also adds additional information such as the interface on which the packet was received and the reason that the packet was logged.

For details on the ssadm logdump command, refer to the ssadm logdump man page, by typing:

man logdump < log_file

to run ssadm logdump and display packets in the log. log_file is a log file that is downloaded from the Screen.

Session Records

When the ssadm logdump program is run with the loglvl sess filter expression, it outputs the data about sessions in the log files.

Sessions can be either TCP sessions (connections), UDP sessions (request/response pairs), or IP sessions (traffic of a particular IP type between a pair of hosts).

These session data track the state saved in the state tables in the firewall. Session data are enabled by setting the log type to "session" for encryption and pass rules.

The format of the log entries is as follows:

TCP session: ID id SRC srcaddr:srcport DST dstaddr:dstport FWD fwdpackets:fwdbytes REV revpackets:revbytes TIME starttime:stoptime STATE finalstate

UDP session: ID id SRC srcaddr:srcport DST dstaddr:dstport FWD fwdpackets:fwdbytes REV revpackets:revbytes TIME starttime:stoptime

IP session: ID id SRC srcaddr DST dstaddr PROTO proto FWD fwdpackets:fwdbytes REV revpackets:revbytes TIME starttime:stoptime

where:

Using the ssadm debug_level Command

If you have access to the console on your SunScreen EFS 3.0 (through a serial line or directly connected CRT), you can use the ssadm debug_level command to control the printing of debugging information from the SunScreen EFS 3.0 kernel.

If you type ssadm debug_level with no arguments, it displays the current debug-level mask. By default, this mask is "1," which means it only reports significant errors.

If you specify a hex number as an argument for ssadm debug_level, it sets the kernel debugging mask to that level. To get a list of debugging bit choices type

ssadm debug_level -h

You select a ssadm debug_level mask by setting all of the debugging bits in which you are interested.

Probably the most useful of the ssadm debug_level debugging bit is DEFAULT_DROP. For example, if you type:

ssadm debug_level 1001

any packets being dropped by SunScreen EFS 3.0 because they do not match any rule are reported. This is a quick way to see if the SunScreen EFS 3.0 is passing packets that you expect it to pass. You can also achieve this same result by setting the default action for the interface to "log summary" or "log detail" and examine the logs.

Another useful debugging bit to set is STATE_CHANGE. This causes the kernel to report any additions or deletions from its internal state tables.

Some of the debugging bits produce a very large amount of output on a production Screen and should be used with caution. An example is ACTION, which reports execution of any PFL action.

Gathering Information From Your System to Report Support Issues

If you have any support issues, call your authorized service provider. For further information about support, use the following URL to contact Enterprise Services: http://www.sun.com/service/contacting.

It is helpful to first gather information describing your configuration. This information can be collected by saving the output of the following SunScreen EFS 3.0 support commands. You invoke these commands for infomation that is useful in troubleshooting through the ssadm lib/support command.

The support command has the form:

ssadm [ -r Name_of_the_Screen ] lib/support function parameters ...

See the Unstable Command section earlier in this appendix.

More Details About Creating New Services

In most cases, the predefined SunScreen EFS 3.0 services provide all of the service definitions needed to create the rules. However, your particular version may need to define a new Single Service for your environment. A new single service can be easily defined using the list of protocol engines provided.

A brief description of other services you may need to add or to modify for your environment follows:

• IP Packets

• ICMP Packets

• TCP Services

• UDP Protocols

• NTP Traffic

• Archie Traffic

• RCP Traffic

IP Packets

SunScreen EFS 3.0 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 above state engines, especially with protocol specified as "*" (any protocol), is very dangerous. They 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. If you wish to pass broadcast traffic, you must define a new service or add broadcast to the predefined service.

ICMP Packets

SunScreen EFS 3.0 provides predefined services for screening ICMP packets including ping.

These services are built upon the icmp state engine and allow ICMP ping request-and-response exchange to occur between a Source and Destination system. Use the predefined service ping if you want to provide ping access.

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.

1. Example:

   Service	Source	Destination	Action
   ping	Inside	Outside	accept
   icmp-unreach	Outside	Inside	accept

The above rules allow Inside machines to ping Outside machines, but not vice versa. It also allows ICMP unreachable packets to be sent from Outside machines to Inside machines. 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).

TCP Services

SunScreen EFS 3.0 screens TCP services by TCP destination port. Most common TCP services have been predefined in the services entries supplied with SunScreen EFS 3.0.

If you need to define a new TCP service, define a new service entry specifying the tcp filter state machine. Specify the well-known destination TCP port(s) of the service you wish to pass. If you specify "*" for the port, this means to pass all TCP services regardless of port. Note that some services such as FTP and RSH cannot be passed in this way since they are not simple TCP protocols because they make additional connections made in the reverse direction. They must be specified as separate services if you wish to pass them.

The TCP state engine times out unused and silent connections. Currently, this time-out is set to five hours after a connection has been established. Since some systems repeatedly retransmit until receiving some sort of error on terminated TCP connections, you might wish to enable sending ICMP rejects on illegal TCP connections, especially on your internal interfaces.

1. Example:

   Service	Source	Destination	Action
   telnet	Inside	Outside	normal

The above rule allows telnet connections to be made from Inside machines to Outside machines.

UDP Protocols

SunScreen EFS 3.0 contains several state engines to handle UDP protocols. They are:

• udp--Stateful UDP packet filtering. Allows a single request-and-response exchange between Source and Destination. State entries are timed out in 20 seconds if no response is received.

• udpall--This state engine is identical to udp, but has a lower precedence. (For an explanation of precedence, see Appendix C of this SunScreen EFS 3.0 Reference Manual.) It is useful for avoiding conflicts while defining service groups containing many services.

• udp_datagram--This engine passes UDP packets in one direction; from Source to Destination. You can specify that broadcast packets should be passed.

• udp_stateless--This state engine allows UDP packets to be sent between Source and Destination. The field UDP Port(s) 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. We do not recommend its use.

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

NTP Traffic

SunScreen EFS 3.0 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 predefined service ntp.

Broadcast NTP is not supported.

Archie Traffic

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

RPC Traffic

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

If you need to define a new RPC service, define 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, this means it 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. Since a lock manager makes connections in both directions (to NFS server and from NFS server) you m ay need to use the "nlm" service when you allow NFS access.

1. Example:

   Service	Source	Destination	Action
   nfs	Inside	DM	accept
   nlm	DMZ	Inside	accept

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