Appendix B Configuration Editor Reference

This appendix describes the command line interface and the configuration editor and the options available for each command. The following topics are included:

• "What Is the Configuration Editor?"

• "Solaris (shell) Commands"

• "ssadm"

• "ssadm Subcommands"

• "Unsupported Commands"

• "ssadm SKIP Commands"

• "Configuration Editor"

• "Network Monitoring and Maintenance"

The top-level programs are run directly from a Solaris shell prompt, if the standard administrative command directory, /usr/sbin, is included in your $PATH.

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

If you are familiar with the Solaris shell and SunScreen concepts and terms, the command line is appropriate. If you are new to SunScreen, use the administration GUI to enter network settings.

What Is the Configuration Editor?

All the functionality of SunScreen that is available through the administration GUI is also available through the command line configuration editor. Administering your Screens through the configuration editor is useful if you cannot or do not want to use the GUI. If you are adept with the command line, you can sometimes edit a configuration more quickly. You can also use the command line interface to perform management tasks in an automated fashion using scripts. Finally, the command line interface may be employed by users who require accessibility accommodations.

You can obtain access to a Screen using the command line from its own keyboard when the Screen is administered locally, if you have superuser (root) access. You can also gain access to a Screen using the command line from an Administration Station; when the Screen is administered remotely you must use SKIP or IKE encryption and an administration user name and password.

You maintain user-controlled data--common objects like address and policy entries like rules and NAT--using the edit subcommand of ssadm.

When using the configuration editor, you must usually save any changes before quitting. Some entities (authuser, adminuser, proxyuser, logmacro, vars) are saved automatically when created. See "Save Not Required for Some Common Objects" below for more information.

You invoke the configuration editor with the edit command, a subcommand of ssadm and the name of your policy, such as Initial. The prompt for the configuration editor is edit>.

For a locally administered Screen, type:

# ssadm edit policy_name

For a remotely administered Screen, type:

# ssadm -r Screen_name edit policy_name

Save Not Required for Some Common Objects

You can quit the configuration editor without saving if only authuser, adminuser, proxyuser, logmacro, or vars entities are altered. The following is an example of the nonfatal message you see if you attempt to save after changing only the entities shown above:

edit> save
lock not held 
failed (status 244)

Solaris (shell) Commands

The following Solaris (shell) commands are available at your shell prompt if the standard administrative command directory /usr/sbin is included in your $PATH.

• ssadm

• ss_client

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

ssadm

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

The Solaris 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 or IPsec/IKE to encrypt IP network communications passing between them. See the SunScreen SKIP User's Guide, Release 1.5.1 for more information regarding SKIP encryption.

Usage:

ssadm [-b] [-n] subcommand [parameters...]

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

The table below describes the options for this command.

The available ssadm subcommands are each described in "ssadm Subcommands".

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 From 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 named Initial, you type:

# ssadm activate Initial

The ssadm command resides in the /usr/sbin 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 named Initial on a remote Screen called SunScreen1, you type:

# ssadm -r SunScreen1 activate Initial

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 Subcommands

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

• activate

• active

• algorithm

• backup

• certdb

• certlocal

• certrldb

• configure

• debug_level

• edit

• ha

• lock

• log

• logdump

• login

• logmacro

• logout

• logstats

• patch

• policy

• product

• restore

• skipca

• skipdb

• skiplocal

• sys_info

• traffic_stats

ssadm Subcommand Summary

The table below lists the SunScreen ssadm subcommands and their descriptions. Many ssadm subcommands duplicate the functions of the administration graphical user interface, while others provide a context for other subcommands.

ssadm activate

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.

Usage:

ssadm activate [-n] [-l] policy

The table below describes the options for this command.

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.

ssadm active

ssadm active prints a description of the configuration that is currently being executed by the Screen. When run with the -x option, the 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 Solaris 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, 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 -x option differs from a normal policy. A normal policy file contains only policy rules, which are combined with the currently-defined common objects. The policy saved by the -x option contains a full snapshot of all common objects, in addition to the policy rules.

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.

ssadm algorithm

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

Usage:

ssadm algorithm [-i]alg_type[crypt_type]

OR

ssadm algorithm [-k]alg_type[crypt_type]

where alg_type must be one of key, data, mac, compression, encryption, or authentication, and crypt_type, if supplied, must be SKIP_VERSION_1, SKIP_VERSION_2, or IPSEC.

The following combinations are valid:

ssadm algorithm i/k-opt key SKIP_VERSION_1ssadm algorithm i/k-opt data SKIP_VERSION_1ssadm algorithm i/k-opt key SKIP_VERSION_2ssadm algorithm i/k-opt data SKIP_VERSION_2ssadm algorithm i/k-opt mac SKIP_VERSION_2ssadm algorithm i/k-opt compression SKIP_VERSION_2ssadm algorithm i/k-opt encryption [IPSEC]ssadm algorithm i/k-opt authentication [IPSEC]

The i/k-opt is either -i, or -k. Note that -i lists only algorithms (with the specified restrictions) that are currently installed on the Screen and that -k lists all possible (known) algorithms (with the specified restrictions). The default is -k.

As shown above, the default crypt_type for key, data, mac, and compression is SKIP_VERSION_2; the default crypt_type for encryption and authentication is IPSEC.

ssadm backup

ssadm backup writes a Screen backup file to standard output.

Usage:

ssadm backup [-v] > file

The backup file contains the complete configuration of SKIP and IKE, 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 and IKE secret keys) that must be stored and disposed of appropriately to protect the integrity of the Screen.

ssadm certdb

ssadm certdb allows a user to manually administer the two databases of public key certificates used by IKE and SKIP. These databases store long term certificates so that they may be accessed by the key manager.

Usage:

ssadm certdb -[I|S] -[a|e|h|l|r] [action specific arguments]

where -I or -S instructs the command to access the IKE or SKIP database and a, e, h, l, and r represent add, extract, help, list, or remove. See the man page ssadm-certdb(1M) for details.

The semantics and applicability of the options may vary between IKE and SKIP usage. For SKIP options, see the skipdb man page

ssadm certlocal

ssadm certlocal is a utility for managing the two local identity databases used by IKE and SKIP on a system.

Usage:

ssadm certlocal -[I|S] -[a|e|h|k|l|r] [action specific arguments]

where -I or -S instructs the command to access the IKE or SKIP database and a, e, h, l, and r represent add, extract, help, generate key, list, or remove. See the man page ssadm-certlocal(1M) for details.

The semantics and applicability of the options may vary between IKE and SKIP usage. For SKIP options, see the skiplocal man page

ssadm certrldb

ssadm certrldb is a utility for managing the certificate revocations lists in the IKE certificate database.

Usage:

ssadm certrldb -[I] -[a|e|h|l|r] [action specific arguments]

where -I instructs the command to access the IKE database and a, e, h, l, and r represent add, extract, help, list, or remove. See the man page ssadm-certrldb(1M) for details.

ssadm configure

ssadm configure (formerly ss_install) is a text-based command-line utility that runs during SunScreen installation to create an initial configuration. ssadm configure, combined with pkgadd, is the command-line equivalent to the installation wizard graphical user interface on the CD-ROM.

ssadm configure interactively queries you with various configuration options. It then creates a configuration, stores it under the policy name Initial, and activates it.

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

ssadm debug_level

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 Solaris 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.

ssadm edit

ssadm edit runs the SunScreen configuration editor.

Usage:

ssadm edit policy

ssadm edit policy < file

ssadm edit policy -c commandstring

See "Configuration Editor" 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 Solaris shell it usually has to be quoted with single or double quotes.

ssadm ha

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

Usage:

ssadm ha function parameters...

The table below describes the function parameters for this command.

ssadm lock

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

ssadm log

ssadm log retrieves and clears the SunScreen log.

Usage:

ssadm log get filter_args...

ssadm log get_and_clear filter_args...

ssadm log clear

See Chapter 11, Logging for detailed information.

ssadm logdump

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

Usage:

ssadm logdump parameters...

See Chapter 11, Logging for detailed information.

ssadm login

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 multiuser Administration Stations, any other user can snoop the admin user and password using ps, then (because SKIP or IKE is enabled from that host) access the Screen as that user.

Do not have a general-use Solaris system act as a remote 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.

ssadm logout

ssadm logout terminates the session created by ssadm login.

Usage:

ssadm -r remotehost logout

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

ssadm logmacro

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 plaintext description string desc to be associated with the object.

See Chapter 11, Logging for detailed information.

ssadm logstats

ssadm logstats prints information about the SunScreen log.

Usage:

ssadm logstats

ssadm patch

ssadm patch installs a patch, as needed.

Usage:

For stealth-mode Screens from Remote Administration Stations, use:

ssadm [-r screen_name] patch Install [NOREBOOT] < patch.tar.Z

ssadm [-r screen_name] patch Backout [NOREBOOT] patchID

On routing-mode Screens, the standard Solaris patchadd and patchrm commands can be used.

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

ssadm policy

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

The table below describes the options for this command.

ssadm product

ssadm product prints out a single line of text describing the SunScreen product in use.

Usage:

ssadm product

ssadm restore

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

Usage:

ssadm restore < file

ssadm spf2efs

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

Usage:

ssadm spf2efs < file

ssadm sys_info

ssadm sys_info prints a description of the running SunScreen software.

Usage:

ssadm sys_info

For example:

# ssadm sys_info
Product:    SunScreen
Version:    Release 3.1, March 10 2000(v0310991418)
System Boot Time:    03/15/1999 03:51 PST
SunScreen Boot Time:    Mon Mar 13 03:51:56 PST 200

traffic_stats Subcommand

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

Usage:

ssadm traffic_statsinterfaces...]

Unsupported Commands

Commands listed in this section are only used for abnormal maintenance or customer support functions, or as a temporary workaround 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/nattables

ssadm lib/screeninfo

ssadm lib/statetables

ssadm lib/support

ssadm SKIP commands

ssadm lib/nattables

ssadm lib/nattables lists the contents of internal NAT tables.

ssadm lib/screeninfo

ssadm lib/screeninfo runs in sequence several of the functions of the ssadm lib/screeninfo 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's Support services if you encounter problems with your Screen.

ssadm lib/statetables -f

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.

The -f option is often useful after activating a modified policy that disallows some traffic that was previously allowed. Without running statetables -f, you allow any previously existing connections to remain active even if the new policy does not allow them. Running statetables -f causes all previously existing state sessions to be disconnecte; the active policy applies to any subsequent connections.

The -fs or -f -s option sets all IKE security associations (SAs) that are in kernel SADB to "expired" by setting their lifetime to the current time. The expired SAs can be renegotiated if they are needed. This option does not apply to IPsec manual SAs. Manually-keyed SAs never expire.

ssadm lib/support

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 Sun's Support services: http://www.sun.com/service/support/index.html.

The major functions are shown in the table below.

ss_client

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 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 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 SunScreen SKIP software. They are primarily useful when a Screen is not physically accessible or does not allow logging in 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 User's Guide, Release 1.5.1 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 table below 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 individual 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, 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 Table B-8 are stored as part of a policy. Policy objects often refer to common objects and, therefore, can behave differently 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 stored immediately, and persist even if the savecommand is not used.

Object types marked as having policy list storage in Table B-8 represent the names of the policies themselves. 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 Subcommands

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

The table below lists the SunScreen configuration editor ssadm edit subcommands and their descriptions. Many subcommands duplicate administration GUI functions, while others provide a context for other subcommands.

In the following command descriptions, name_TYPE indicates that it requires the name of an object of a particular TYPE. A pound sign (#) indicates that it needs an index. <KEYWORD> now indicates a keyword that previous SunScreen releases required and that now is optional.

add

Creates or redefines 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

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

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

add address "name_ADDRESS" #.#.#.# - #.#.#.#

add address "name_ADDRESS" #.#.#.#/#.#.#.#

add address "name_ADDRESS" #.#.#.#/#bits

add address "add address "name_ADDRESS" <GROUP> { "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

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)

SNMP_TIMER # (if SNMP is set)

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

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

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

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

LOGSIZE # {default is 100 MBytes if not present}

DEST_CHECK {destination address checking}

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

STEALTH_NET #.#.#.#/#.#.#.#

STEALTH_NET #.#.#.#/#bits

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 CMG slave Screen, the following SKIP and/or IKE fields must be specified as well. They can be specified in any order after the SCREEN keyword. The SKIP fields are:

ADMIN_IP #.#.#.# or name_ADDRESS

ADMIN_CERTIFICATE "name_CERTIFICATE"

KEY "name_key_algorithm"

DATA "name_data_algorithm"

MAC "name_mac_algorithm"

COMPRESSION "name_compression_algorithm"

TUNNEL "name_address"

The IKE fields are:

ADMIN_IP #.#.#.# or "name_ADDRESS"

AH( "name_auth_algorithm" )

ESP( "name_encr_algorithm" )

ESP( "name_encr_algorithm", "name_auth_algorithm" )

At least one of the above must be present. At most, one of the ESP forms can be present.

IKE( "name_encr_algorithm", "name_auth_algorithm", "oakley_group_#", name_auth_method", name_CERTIFICATE" )

If both SKIP and IKE CMG are in use, only one instance of ADMIN_IP is allowed (or needed).

If the Screen is to be a CMG master Screen, the following SKIP and/or IKE fields must be specified as well. They can be specified in any order after the SCREEN keyword. The SKIP fields are:

ADMIN_IP #.#.#.# or "name_ADDRESS"

ADMIN_CERTIFICATE "name_CERTIFICATE"

The IKE fields are:

ADMIN_IP #.#.#.# or "name_ADDRESS"

IKE( "name_CERTIFICATE" )

If both SKIP and IKE CMG are in use, only one instance of ADMIN_IP is allowed (or needed).

The screen * is reserved and cannot be edited.

add service

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. Each Discriminator list also must 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 #-# (No space is allowed before or after the - character)

BROADCAST #

BROADCAST #-#

An optional parameter for discriminators, which appears immediately after discriminator 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"

The service * is reserved and cannot be edited.

add interface

add interface "name_INTERFACE" type "name_ADDRESS"

type must be one of ADMIN, DISABLED, ROUTING, HA, or STEALTH.

The following fields are optional for stealth interface types and can be specified in any order after the interface keyword. Up to fiveROUTERs per stealth interface can be specified. More can be specified, but only five are used by the system. The system may use the five stealth interfaces randomly in any order

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

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

add certificate "name_CERTIFICATE" SINGLE IKE "ike certspec" ...

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

add certificate "name_CERTIFICATE" { "name_CERTIFICATE" ... }

add certificate "name_CERTIFICATE" { "name_CERTIFICATE" ... } " { "name_CERTIFICATE" }

For GROUP certificates, a space-separated list of name_CERTIFICATE entries is given in the first pair of braces (or after the GROUP keyword).

For IKE certificate groups, a list of name_CERTIFICATE entries may also be given in the second pair of braces. Like the Address object, this second list represents certificates (or criteria) which are to be excluded. Unlike Address group objects, only a top-level Certificate group may have a non-empty exclusion list.

Groups which intermix SKIP and IKE Certificates are not allowed.

The following field is optional for SINGLE entries and may be specified in any order after the certificate keyword:

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 key

add key "name_KEY" SINGLE hexadecimal key value

Key objects exist in the same namespace as Certificate objects. Therefore, you cannot use the same name for both. Keys can also have SCREEN and COMMENT option fields.

add time

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"

The time object * cannot be modified.

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 }. Twenty-four-hour time format is used, so the valid times are 0:00 (starting at midnight) through 24:00 (ending at midnight).

add rule

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 DETAIL {also LOG_DETAIL}

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

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

USER "name_USER" {required only if PROXY_FTP or PROXY_Telnet set below; optional if 'PROXY_HTTP' set below; otherwise not allowed}

TIME "name_TIME"

SCREEN "name_SCREEN"

COMMENT "comment string"

Any one of the following combo-fields 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"

IPSEC SYMMETRIC AH(ah_spi_value, "name_AUTHENTICATION_ALGORITHM", "name_KEY")

IPSEC SYMMETRIC AH(ah_spi_value "name_AUTHENTICATION_ALGORITHM", "name_KEY") ESP( esp_spi_value, "name_ENCRYPTION_ALGORITHM", "name_KEY")

IPSEC SYMMETRIC ESP(esp_spi_value, "name_ENCRYPTION_ALGORITHM", "name_KEY",name_AUTHENTICATION_ALGORITHM", "name_KEY")

IPSEC FORWARD AH(ah_spi_value, "name_AUTHENTICATION_ALGORITHM", "name_KEY") ESP( esp_spi_value, "name_ENCRYPTION_ALGORITHM", "name_KEY") REVERSE AH(ah_spi_value, "name_AUTHENTICATION_ALGORITHM", "name_KEY") ESP( esp_spi_value, "name_ENCRYPTION_ALGORITHM", "name_KEY")

IPSEC IKE( "name_ENCRYPTION_ALGORITHM", name_AUTHENTICATION_ALGORITHM", OAKLEY_GROUP, "name_AUTHENTICATION_METHOD", "name_CERTIFICATE", name_CERTIFICATE")

IPSEC IKE( "name_ENCRYPTION_ALGORITHM", name_AUTHENTICATION_ALGORITHM", OAKLEY_GROUP, PRE-SHARED, "name_KEY")

The first three IPsec symmetric forms (those with SPI values) specify manual keying. The asymmetric manual key form uses forward and reverse directions with AH and ESP specified separately for each direction. The last two IPsec forms utilize Internet Key Exchange (IKE) keying. Of those, the first form uses certificates, the last uses pre-shared keying. For either of the IKE forms, one of the following three data security parameter options (phase 2 transforms) must be specified. It may be issued after the IPSEC keyword:

AH( "name_AUTHENTICATION_ALGORITHM" )

AH( "name_AUTHENTICATION_ALGORITHM" ) ESP( "name_ENCRYPTION_ALGORITHM" )

ESP( "name_ENCRYPTION_ALGORITHM",name_AUTHENTICATION_ALGORITHM" )

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

SOURCE_TUNNEL "name_ADDRESS"

DESTINATION_TUNNEL "name_ADDRESS"

One or both of the following fields must be specified in conjunction with either IPsec manual keying or IKE pre-shared keying. They indicate to the SunScreen compiler the (encryption) role being played by a given Screen. They can be specified in any order after the IPSEC combo-field. Tip: when in doubt, completely specify both Screen roles:

SOURCE_SCREEN name_SCREEN

DESTINATION_SCREEN name_SCREEN

For IKE with certified keying material, the Screen roles are determined automatically, by determining which certificate (source or destination) is local to the Screen for which a policy is being compiled. If both source and destination certificates are (or contain) local entities, the *_SCREEN option may be used to disambiguate roles.

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, IKE, IPsec, or proxy 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, IKE, or IPsec 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}

FTP_ALL {same as FTP_GET FTP_PUT FTP_CHDIR FTP_MKDIR FTP_RENAME FTP_REMOVE_DIR FTP_DELETE}

NO_FTP_ALL {default if no FTP options are present}

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}

HTTP_ALL {same as ACTIVE_X COOKIES JAVA SSL}

NO_HTTP_ALL {default if no HTTP options are present}

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

In the following two subcommands, name_ADDRESS has four different meanings: the first is source, the second is destination, the third is translated source, and the fourth is translated destination.

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

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

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"

add accessremote USER "name_USER""name_ADDRESS"IPSEC IKE( "name_ENCRYPTION_ALGORITHM", "name_AUTHENTICATION_ALGORITHM", OAKLEY_GROUP, "name_AUTHENTICATION_METHOD", "name_CERTIFICATE" )

For the IKE form, one of the following three data security parameter options (phase 2 transforms) must be specified. It may be issued after the IPSEC keyword:

AH( "name_AUTHENTICATION_ALGORITHM" )

AH( "name_AUTHENTICATION_ALGORITHM" ) ESP( "name_ENCRYPTION_ALGORITHM" )

ESP( "name_ENCRYPTION_ALGORITHM",name_AUTHENTICATION_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

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

add vpngateway "name_VPN" "name_ADDRESS" IPSEC IKE( "name_ENCRYPTION_ALGORITHM", name_AUTHENTICATION_ALGORITHM", OAKLEY_GROUP, "name_AUTHENTICATION_METHOD", "name_CERTIFICATE" )

For the IKE form, one of the following three data security parameter options (phase 2 transforms) must be specified. It may be issued after the IPSEC keyword:

AH( "name_AUTHENTICATION_ALGORITHM" )

AH( "name_AUTHENTICATION_ALGORITHM" ) ESP( "name_ENCRYPTION_ALGORITHM" )

ESP( "name_ENCRYPTION_ALGORITHM",name_AUTHENTICATION_ALGORITHM" )

For the SKIP form 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"

All vpngateway entries with the same name should have exactly the same encryption parameter settings, except for name_CERTIFICATE.

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

TUNNEL "name_ADDRESS"

COMMENT "comment string"

add_member

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"* { add to include list }

add_member certificate "name_CERTIFICATEEXCLUDE "name_CERTIFICATE"* { add to exclude list; certificate groups can have exclude lists, which behave syntactically like address groups}

The * 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, you can specify it after the TYPE keyword:

SCREEN "name_SCREEN"

authuser

Manipulates the list of authorized users.

Usage:

authuser add name parameters...

authuser delete name

authuser print

authuser names

See "Authorized User" for detailed information.

delete

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 #

*del[ete] key name_KEY

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

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"* { from include list }

del[ete]_member certificate "name_CERTIFICATE" EXCLUDE"name_CERTIFICATE" { from exclude list }

 *  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

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

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

Usage:

jar_hash add name hash

jar_hash del name

jar_hash rename oldname newname

jar_hash list

jar_hash list_names

 Te table below describes the functions for this command.

jar_sig

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

Usage:

jar_sig add name sig-hash

jar_sig del name

jar_sig rename oldname newname

jar_sig list

jar_sig list_names

The table below describes the functions for this command.

list

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 key

list keyname_KEY

*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 SCREEN "name_SCREEN" field is optional and can be specified after the TYPE keyword in any of the above requests except those that are preceded by an asterisk ( * ).

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

Displays the set of unique basenames and subtype 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, state engine, interface, certificate, key, time, or vpngateway.

load

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

M

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

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. 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

Searches the registry for objects that match specified criteria.

Usage:

search TYPE [SCREEN "name_SCREEN"] [ SUBTYPE subtype ] <EXACT> Substring...

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

The EXACT keyword requires a substring be specified and will only match entries whose name is an exact match.

move

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

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. It is shorthand 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

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

Usage:

refer address "name_ADDRESS"

refer key "name_KEY"

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

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 key "name_KEY"

referlist service "name_SERVICE"

referlist stateengine "name_STATEENGINE"

referlist certificate "name_CERTIFICATE"

referlist time "name_TIME"

referlist vpn "name_VPN"

rename

Renames a specified named object of a given TYPE.

Usage:

rename address "name_ADDRESS""name_ADDRESS"

rename key "name_KEY""name_KEY"

*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

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

Usage:

renamereference address "name_ADDRESS" "name_ADDRESS"

renamereference key "name_KEY" "name_KEY"

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

Saves any current edits. It also creates a new version of the policy.

Usage:

save

save "name_POLICY"

If a name is specified, the current policy is written to the new name, but it remains the policy in the editor until you activate the policy written to the new name.

saveas

Saves the data currently in the editor under a new name.

Usage:

saveas policy "name_POLICY"

saveas policy "name_POLICY" registry Registry

saveas policy "name_POLICY" registry "name_POLICY"

saveas policy registry Registry

These are the only supported legal requests. The first saves the current policy data under the new name with a reference to the current common objects. The second saves the policy data under the new name and overwrites the current common objects with whatever is currently in the editor. This may affect other policies and should be done with caution. The third saves the contents of the editor, policy objects and common objects into a single self-contained policy file of the specified name. The last saves the common objects currently in the editor as the current common objects. This may affect other policies and should be done with caution.

reload

Discards any and all edits (if any were made) and reloads 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, those edits will be lost if a reload is not performed before the current editor process makes further edits.

Usage:

reload

verify

Takes no arguments and verifies the currently loaded policy.

Usage:

verify

mail_relay

Manipulates the list of allowed and disallowed destination domains used by the SMTP proxy.

Usage:

mail_relay add relay_domain

mail_relay add !relay_domain

mail_relay del relay_domain

mail_relay del !relay_domain

mail_relay list

add adds a domain suffix string to be allowed (or disallowed, if preceded by a !) in recipients of mail messages.. del deletes a domain suffix string. list produces a list of the current set of relay domain suffixes.

mail_spam

Manipulates the list of "spam" domains or addresses used by the SMTP proxy.

Usage:

mail_spam add spam_domain

mail_spam add IPaddress

mail_spam add IPstartaddress..IPendaddress

mail_spam del spam_domain

mail_spam del IPaddress

mail_spam del IPstartaddress..IPendaddress

mail_spam list

add adds a domain suffix string to be blocked as an origin of incoming mail messages. add can also be configured to use an IP address or range of addresses; this blocks incoming messages from the addressed hosts lacking registered domain names. del removes a spam_domain suffix or IP address spam restrictor. list produces a list of the current set of spam restrictors.

proxyuser

Manipulates the list of proxy users.

Usage:

proxyuser add name parameters...

proxyuser delete name

proxyuser print

See "Proxy Users" for detailed information.

vars

Manipulates general-purpose SunScreen variable objects.

Usage:

vars add varkey varvalue

vars del varkey

vars print [,sortopt] [varkey]

vars names [,sortopt]

varkey is of the form:

[ SYS=scrnname ]

[ PRG=prgname [ PGRP=pgrpname ] ]

NAME=name

quit

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

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

Usage:

QUIT

Network Monitoring and Maintenance

The following sections describe how to monitor and maintain your SunScreen.

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, SunScreen's logging mechanisms add information such as the interface on which the packet was received and the reason that the packet was logged. Any filtering language operation that works in snoop will work in logdump.

For details about ssadm logdump, see Chapter 11, Logging and the ssadm-logdump man page.

To run ssadm logdump and display packets in a saved log file:

# ssadm logdump -i logfile

Where log_file is a log file that is downloaded from the Screen.

Except for the differences detailed in Chapter 11, Logging, logdump uses the same filter language as the snoop(1m) program. Note also that logdump does not handle IPv6.

Using the ssadm debug_level Command

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

Typing ssadm debug_level with no arguments 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, the kernel debugging mask is set to that level. To get a list of debugging bit choices, type:

# ssadm debug_level ?

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 because they do not match any rule are reported. This is a quick way to see if the SunScreen is passing packets that you expect it to pass. You can also achieve this same result by setting the default action on 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.

TIP: it is often useful to employ a pair of ssadm debug_levelcommands, separated by the Solaris sleep(1) command, especially for levels which generate large amounts of output:

# ssadm debug_level
Current debug level is: 00000001<>
# ssadm debug_level 1c01 ; sleep 30 ; ssadm debug_level 1

This would ensure that only 30 seconds of debug would be logged. This also avoids the mistake of leaving debugging enabled by accident.

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/support/index.html.

For the most efficient help, first gather information describing your configuration. This information can be collected by saving the output of the following SunScreen support command. You invoke these commands to gather information that is useful in troubleshooting through the ssadm lib/support command.

The support command has the form: ssadm [ -r Screen_Name ] lib/support function parameters...

See "Unsupported Commands".