All the SunScreen functionality that is available through the administration GUI is also available through a command line interface. Administering your Screens through the command line can be useful when you want to manage one or more remote Screens or if you use more than one network address.
You can use the command line to access a Screen from its own keyboard when the Screen is being administered locally; this requires that you have superuser (root) access. You can also use the command line to access a Screen from an Administration Station when the Screen is being administered remotely; this requires that you use SKIP or IPsec encryption and an admin user name and password.
For more information on the command line, see "Configuration Editor Reference" in SunScreen 3.2 Administrator's Overview.
The following commands are available at your shell prompt when /usr/sbin is included in your $PATH. The following table lists the SunScreen UNIX (shell) commands and their descriptions. Many of these commands duplicate administration GUI functions; some provide context for other commands.
Table 10-1 SunScreen Command Summary
UNIX Command |
Description |
---|---|
ssadm |
Primary command line tool for SunScreen administration. ssadm subcommands perform various operations, such as editing and activating a SunScreen configuration and examining the status of a Screen. |
ss_client |
Provide communication between a SunScreen Administration Station and a Screen that is running an earlier SunScreen firewall product release. ss_client is provided only for the purpose of remotely administering such products using the SunScreen system as a remote Administration Station. |
The commands used for administering SunScreen SKIP are meant to be run only on a pure Administration Station, not on a Screen. They can be found in "Using the Command-Line Interface" in SunScreen SKIP User's Guide, Release 1.5.1.
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.
ssadm runs directly on a locally administered Screen, or indirectly from a remote Administration Station that is using SKIP or IPsec to encrypt IP network communications passing between them. See "How SKIP Works" in SunScreen SKIP User's Guide, Release 1.5.1 for more information regarding SKIP encryption.
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.
Usage:
ssadm [-b] [-n] subcommand [parameters...]
ssadm [-b] [-n] -r remotehost [-F ticketfile] subcommand [parameters...]
Allow binary data (instead of text) in standard input and output.
Do not read any input from standard input.
The available ssadm subcommands are described in "ssadm Subcommand Summary".
The -b option normally is not needed since those subcommands that process binary data enable the binary mode automatically. 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.
You can configure a local Screen by typing the commands listed in this appendix on 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.
To configure a Screen from a remote Administration Station, precede the subcommands listed in this appendix with ssadm -r and the address or hostname 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 |
If you are using remote administration, you must log in before you can perform most ssadm commands.
To log into SunScreen remotely, type the following on the remote Administration Station:
# SSADM_TICKET_FILE=$HOME/.ssadmticket # export SSADM_TICKET_FILE # touch $SSADM_TICKET_FILE # chmod go= $SSADM_TICKET_FILE # ssadm -r SunScreen1 login username password / WRITE access <E23B344150C702EC> |
To log out of SunScreen remotely, type the following:
# ssadm -r SunScreen1 logout |
The following table lists the SunScreen ssadm subcommands and their descriptions. Many ssadm subcommands duplicate administration GUI functions, while others provide a context for other subcommands.
Table 10-2 SunScreen ssadm Subcommand Summary
ssadm Subcommand |
Description |
---|---|
Activate a Screen policy |
|
List information about the currently active policy |
|
List algorithms supported by SKIP |
|
Write a SunScreen backup file to standard output |
|
Allows a user to manually administer the two databases of public key certificates used by SKIP and IKE. These databases store long term certificates so that they may be accessed by the key manager. |
|
A utility for managing the two local identity databases on a Screen. ssadm certlocal is the primary tool for administering local IDs. |
|
certrldb |
A utility for managing the certificate revocations lists in the IKE certificate database. ssadm certrldb can add, delete, extract, and list IKE certificates based on the command option specified. |
Create an initial SunScreen configuration. ssadm configure, when combined with pkgadd, is equivalent to using the installation wizard graphical user interface. |
|
Set or clear the level of debugging output generated by a Screen |
|
Run the SunScreen configuration editor (see "Configuration Editor Reference" in SunScreen 3.2 Administrator's Overview) |
|
Configure the features of a high availability (HA) Screen |
|
Examine or remove the protection lock that the configuration editor places on a policy file |
|
Maintain the Screen log file |
|
Interpret Screen logs and display their contents |
|
Authenticate a user for administrative access through ssadm to a Screen from a remote Administration Station |
|
Expands SunScreen logmacro objects |
|
Terminate the session created by ssadm login. |
|
Print information about the SunScreen log |
|
Install patch, as needed |
|
Create, delete, list, rename Screen policies |
|
Print single line describing the SunScreen product in use |
|
Read a backup file from standard input |
|
Configure the client layer of the SecurID system |
|
Print a description of running SunScreen software |
|
Report summary information about the traffic flowing through the SunScreen, classified by interface |
You maintain user-controlled data by using the ssadm edit subcommand.
To look at or change a policy in some way, invoke the configuration editor and type a series of commands that end with save and quit requests.
ssadm configure is a text-based command line utility for creating an initial SunScreen configuration. ssadm configure, combined with pkgadd, is the command line equivalent of the installation wizard graphical user interface.
ssadm configure interactively queries you with various options for configuring the SunScreen, creates a configuration, stores it under the policy name Initial, and activates it. After ssadm configure finishes, you can administer the firewall.
You use the ssadm edit subcommands when running the configuration editor, which is responsible for maintaining the SunScreen configuration database.
Be sure to save changes made using commands such as add, del, rename, renamereference, insert, replace, and move, before you quit. Run save only once, just before the quit command to avoid accumulating too many policy versions.
The following table lists the SunScreen configuration editor ssadm edit subcommands and their descriptions. Many subcommands duplicate administration GUI functions; the remainder provide context for other subcommands.
Table 10-3 SunScreen Configuration Editor (ssadm edit) Subcommand Summary
edit Subcommand |
Description |
---|---|
Create or redefine an entry |
|
Add a member to a group or list |
|
Manipulates the list of authorized users (see Table 10-4) |
|
Delete the specified entry of the given TYPE |
|
Delete a member from a centralized management group or list |
|
Insert a new object of one of the ordered (indexed) types in a specified position in the corresponding list |
|
Manipulates the list of Jar hashes used by the HTTP proxy |
|
Manipulates the list of Jar signatures used by the HTTP proxy |
|
Display all data for all entries or a specific entry of a give TYPE |
|
Display the set of unique base names and subtype of all of a given TYPE |
|
Load a policy into the configuration editor |
|
Lock the policy in anticipation of performing edits |
|
Return the status of the lock relative to this editor |
|
Manipulates the list of mail relays used by the SMTP proxy |
|
Manipulates the list of spam domains used by the SMTP proxy |
|
Move an indexed entry from its current location in the ordered list to the new location |
|
Manipulates the list of proxy users |
|
Cause the editor to terminate if there are no unsaved changes |
|
Cause the editor to terminate even if there are unsaved changes |
|
Determine if a named-object of a given TYPE is referred to in the current policy |
|
Display a list of all entries in the current policy that refer to a specified named-object of a given TYPE |
|
Discard any and all edits, if made, and reload the data into the editor from the database |
|
Rename a specified named-object of a given TYPE |
|
Renames all references to a specified named-object of a given TYPE |
|
Replace an object at a specified index |
|
Save all current edits to the policy or common objects |
|
Save the policy rules to a different policy name |
|
Search for objects that match specified criteria |
|
The vars command in the configuration editor manipulates variables used for RADIUS configuration. See the section on RADIUS configuration in the "RADIUS User Authentication Details" in SunScreen 3.2 Administrator's Overview for more information |
|
Verifies the currently loaded configuration without saving it |
The configuration editor lets you edit only one policy at a time. When you are in an editing session, others are unable to edit the same policy, although they can read it. If you modify any of the common objects, other people are unable to modify common objects until you save your changes.
Invoke the configuration editor with the edit command, which is a subcommand of ssadm, and the name of your policy, such as Initial. Once the configuration editor is running, the prompt changes to: edit>.
For a locally administered Screen, type:
# ssadm edit policy_name |
For a remotely administered Screen, type:
# ssadm -r Screen_name edit policy_name |
Use the ssadm command to add a new policy using local administration by typing:
# ssadm policy -a policy_name |
Use ssadm -r to add the same policy using remote administration by typing:
# ssadm -r Screen_name policy -a policy_name |
If you create a new policy, it will not have the administrative access rules necessary for GUI or remote administration. It may be safer to copy an existing, working policy and modify it than to create a new policy.
Using local administration, use the -c option to copy a policy by typing:
# ssadm policy -c policy_name policy_copy_name |
Using remote administration, use the -c option with the ssadm -r command to copy a policy by typing:
# ssadm -r Screen-name policy -c policy_name policy_copy_name |
Using local administration, rename a policy by typing:
# ssadm policy -r old_name new_name |
Using remote administration, rename a policy by typing:
# ssadm -r Screen_name policy -r old_name new_name |
Using local administration, delete a policy by typing:
# ssadm policy -d name |
Using remote administration, delete a policy by typing:
# ssadm -r Screen_name policy -d name |
Verify the validity of a policy, for example, myconfig, using local administration by typing:
# ssadm activate -n myconfig |
Verify the validity of a policy, for example, myconfig, using remote administration by typing:
# ssadm -r Screen_name activate -n myconfig |
Activate a policy using local administration by typing:
# ssadm activate myconfig |
Activate a policy using remote administration by typing:
# ssadm -r Screen_name activate myconfig |
Using local administration, type the following to back up a policies:
# ssadm backup > filename |
Using remote administration, type the following to back up a policies:
# ssadm -r Screen_name backup > filename |
Restore policies using local administration by typing:
# ssadm restore < filename |
Restore policies for remote administration by typing:
# ssadm -r Screen_name restore < filename |
The tasks in this section describe how to work with single services and service groups.
Type the following to add the service ftp-34, service engine, discriminator, parameters, and description (which is optional) within quotation marks.
In the example below, all you need to type is "PARAMETERS 1200 1200 1" if you do not want to use the default values. See "Services and State Engines" in SunScreen 3.2 Administrator's Overview for the default parameters for the state engines
edit> add service ftp-34 SINGLE FORWARD ftp PORT 34 PARAMETERS 1200 1200 1 COMMENT "ftp-34 uses port 34 instead of port 21. Use ftp-34 instead of the supplied ftp service." |
Type the following to see the new service ftp-34:
edit> list service ftp-34 "ftp-34" SINGLE FORWARD "ftp" PORT 34 PARAMETERS 1200 1200 1 COMMENT "ftp-34 uses port 34 instead of port 21. Use ftp-34 instead of the supplied ftp service." |
SunScreen lets you change the default services in service groups; however, to make troubleshooting easier, it is better to add a new service group that contains the services that you want rather than modify an existing service group.
Type the following to add the service group useful services and description (which is optional) within quotation marks:
edit> add service "useful services" GROUP www archie gopher COMMENT "A new service group that is used instead of common services." |
The description will appear in the Service Details field that appears when you choose a service or service group for a policy rule using the Policy Rule Definition dialog box.
Type the following to list the new service group, useful services:
edit> list service "useful services" "useful services" GROUP "www" "archie" "gopher" COMMENT "A new service group that is used instead of common services." |
This procedure needs more information and an accurate example.
Add the GROUP again with the modified member list. The new definition overwrites the old definition.
Type the following to rename a service or service group without modifying references to it:
edit> rename service "useful services" "dmz services" |
The changes take effect when you activate the policy whose rules you have edited.
SunScreen lets you rename a single service or a service group. To make troubleshooting easier, do not rename the single services and service groups that are supplied with SunScreen.
Type the following to rename all references to a service or service group:
For example:
edit> renamereference service "useful services" "dmz services" |
SunScreen lets you delete a single service or a service group. To make troubleshooting easier, do not delete the single services and service groups that are supplied with SunScreen.
Type the following to delete a service or service group.
For example, to delete the service group dmz service type:
edit> del service "dmz services" |
This command does not check for references to the single service or service group that you are deleting. The changes take effect when you activate the policy whose rules you have edited.
To check references to the single service or service group that you want to delete or have deleted:
Type the following to find references to the service or service group that you want to delete or have deleted
For example:
edit> referlist service "dmz services" |
This displays a list of all the instances where the service or service group is used.
Remove the service or service group if you have not already done so.
Edit the rule to remove obsolete references from the rule or rules displayed after typing the command in Step 1.
The tasks in this section describe how to work with addresses, address ranges, and address groups.
Type the following to add the new host address 172.16.1.2 and a description (which is optional) within quotation marks:
edit> add address ftp-www HOST 172.16.1.2 COMMENT "Address of the DMZ host" |
The changes take effect when you activate the policy whose rules you have edited.
Type the following to add an address range from 172.16.3.2 to 172.16.3.255 and a description (which is optional) within quotation marks:
edit> add address corp RANGE 172.16.3.2 172.16.3.255 COMMENT "All hosts in corporate" |
The changes take effect when you activate the policy whose rules you have edited.
Type the following to add an address group and a description (which is optional) within quotation marks, for example:
edit> add address Internet GROUP { corp sales ftp-www } {} COMMENT "The ranges corporate and sales and the host ftp-www have access to the Internet" |
The changes take effect when you activate the policy whose rules you have edited.
Type the following to add a network group and a description (which is optional) within quotation marks, for example:
edit> add address cidr2 RANGE 10.100.253.0/24 COMMENT "The network group consists of an IP address and a mask." |
The changes take effect when you activate the policy whose rules you have edited.
To make troubleshooting easier, do not delete the names of the addresses, ranges of addresses, and lists of addresses that were defined when SunScreen was installed.
This command does not check for references to the address, range of addresses, or list of addresses that you are deleting.
Type the following to delete an address, a range of addresses, or a list of addresses, for example:
edit> del address host0 |
To have the changes take effect, you must activate the policy.
Type the following to find the reference to an address, a range of addresses, or a list of addresses that you want to delete or have deleted, for example:
edit> referlist address host0 |
This displays a list of all the instances where the address, range of addresses, or list of addresses is used. You can now remove the address, range of addresses, or list of addresses from the address list in which it is used and edit the policy rule to remove it from the rule or rules in which it is used.
To make troubleshooting easier, do not delete or rename the names of addresses, ranges of addresses, or lists of address that were defined when SunScreen was installed.
Type the following to rename an address, a range of addresses, or a list of addresses and all reference to it, for example:
edit> renamereference address ftp-www DMZ |
Type the following to rename an address, a range of addresses, or a list of addresses only, for example:
edit> rename address ftp-www DMZ |
The changes take effect when you activate the policy whose rules you have edited.
Each SKIP certificate object requires a particular Name Space ID (NSID) and the Master Key ID (certificate ID) of the certificate. NSIDs and certificate IDs are described in "Common Objects" in SunScreen 3.2 Administrator's Overview.
Certificate IDs that use the IP address use the NSID 0 convention with the IP address as the MKID.
Certificate IDs use the NSID 1 convention with an MKID of 8 hexadecimal digits (32 bits}.
Self-generated certificates use the NSID 8 convention with an MKID of 32 hexadecimal digits (128 bits).
You can add SKIP X.509 keys and certificates from a diskette or file, or from a directory that contains only one set of private key and certificate files.
You cannot add Screen certificates remotely. To add Screen certificates to Screens that are administrated remotely, go to each Screen in turn and follow the steps to add Screen certificates from a diskette or a file.
Insert the diskette that contains the private certificate into the diskette drive of the Administration Station.
Mount the diskette by typing:
# volcheck |
Type the following command, including the path to the directory where the private key and certificate are stored:
# install_skip_keys -icg /floppy/diskette_name |
Eject the diskette.
# eject diskette_name |
Store the diskette that contains the private key and public certificate safely and securely. It contains sensitive information that is not encrypted.
Type the following to restart the SKIP key manager to update the certificate database:
# skipd_restart |
Type the following to name the private key and certificate you have just added, and an optional comment if desired:
edit> add certificate sales-home SINGLE NSID 1 MKID "0xA00050E" COMMENT "Use this cert for tunnelling to home from NY" |
Type the following command, including the path to the directory where the private key and certificate are stored:
# install_skip_keys -icg /directory_name |
Type the following to restart the SKIP key manager to update the certificate database:
# skipd_restart |
Type the following to name the private key and certificate you have just added, and an optional comment if desired:
edit> add certificate sales-home SINGLE NSID 1 MKID "0xA00050E" COMMENT "Use this cert for tunnelling to home from NY" |
You can add Screen local identities only with local administration; therefore, for a remotely administrated Screen, you must gain access to the Screen's shell prompt, for instance with the rlogin command.
To use the rlogin command, you must first save the local identity and the secret key to separate files. For example, you may have extracted the self-generated certificate ID keys that you generated on a Screen to a diskette (because it is impossible to generate the same key later, should you have to reinstall the SunScreen software). Once you have swapped certificate IDs with a number of peer systems, it becomes difficult to fix things in a timely manner. If this seems cumbersome, use telnet, which is more secure than rlogin.
SunScreen installation programs re-key the Screen being installed, so you have to add your old keys back into the database before configuring the Screen for virtual private networks (see "Encryption, Tunneling, and Virtual Private Networks" in SunScreen 3.2 Administrator's Overview for more information about VPNs).
Type the following to use the skiplocal command to add the Screen's local identity.
# skiplocal -a -T soft -t x509 -n 1 -c certificate_filename -s secret_filename |
This example shows adding a CA key and certificate. If you are adding a self-generated key and certificate, the value for -t is dhpublic and the value for -n is 8.
Type the following to restart the SKIP key manager to update the certificate database:
# skipd_restart |
Type the following to name the private key and certificate you have just added, for example:
edit> add certificate sales-home SINGLE NSID 1 MKID "0xA000050E" COMMENT "certificate for home sales" |
sales-home is the name that you are giving the certificate
1 is the NSID
A00050E is the MKID
The following example illustrates how to generate a global (512-bit) key.
Use the skiplocal command to create a self-generated Screen certificate.
For example:
# skiplocal -k -m 512 |
If you have installed more than one encryption strength, use the -m flag followed by the modulus size, in bits, of the encryption for which you want to create a new certificate. The modulus sizes are:
Global (1024 bits)
U.S. and Canada Only (2048. 3072, or 4096 bits)
The highest modukus size that works with PC-SKIP in the U.S. and Canada is 2048.
You see the following message on the Screen:
generating local secret with 512 modulus size It would help the quality of the random numbers if you would type 50-100 random keys on the keyboard. Hit return when you are done. |
Type 50 to 100 random keys.
As you type the random keys, the number of keys appears on the screen.
Press the Return key.
The continuation of the message appears on the screen:
100 Format: Hashed Public Key (MD5) Name/Hash: 3f 3c f9 d0 52 85 a3 be 1e 6d 4e cb e4 9e 49 e7 Not valid Before: Fri Apr 17 17:00:00 1998 Not valid After: Thu Apr 17 17:00:00 2003 g: 2 p: f52aff3ce1b1294018118d7c84a70a72d686c40319c807297aca950cd9969 fabd00a509b0246d3083d66a45d419f9c7cbd894b221926baaba25ec355e92a055f public key: 9945eb0a204efd9643a3aeb42f80d18a22a194232ef6e18809b4b80ac62271000 b24fbd0a01608a6b3fe92a3ab107efd1970c398cdc2d0f73effea55c1cb0565 Added local identity slot 12 |
Type the following to restart the SKIP key manager to update the certificate database:
# skipd_restart |
Type the following to add the new certificate and its name to the certificate database, for example:
edit> add certificate sales-home SINGLE NSID 8 MKID "0x3f3cf9d05285a3be1e6d4ecbe49e49e7" COMMENT "This is the Screen's key for the home sales network." |
Because this is a self-generated UDH certificate, the NSID is 8.
Type the certificate ID:
The example shows generating a global (1024 bit) key.
Use the ssadm -r command to create a self-generated Screen certificate.
For example:
# ssadm -r Screen_name lib/skiplocal -k -m 1024-f |
You must use the -f flag with remote administration. This flag suppresses the prompt to type random keys on the keyboard.
If you have installed more than one encryption strength, use the -m flag followed by the modulus size, in bits, of the encryption for which you want to create a new certificate. The modulus sizes are:
Global (1024 bits)
U.S. and Canada Only (2048. 3072, or 4096 bits)
The highest modukus size that works with PC-SKIP in the U.S. and Canada is 2048.
The following message appears on the screen:
generating local secret with 1024 modulus size Format: Hashed Public Key (MD5) Name/Hash: 3f 3c f9 d0 52 85 a3 be 1e 6d 4e cb e4 9e 49 e7 Not valid Before: Fri Apr 17 17:00:00 1998 Not valid After: Thu Apr 17 17:00:00 2003 g: 2 p: f52aff3ce1b1294018118d7c84a70a72d686c40319c807297aca950cd9969fabd 00a509b0246d3083d66a45d419f9c7cbd894b221926baaba25ec355e92a055f public key: 9945eb0a204efd9643a3aeb42f80d18a22a194232ef6e18809b4b80ac622710 00b24fbd0a01608a6b3fe92a3ab107efd1970c398cdc2d0f73effea55c1cb0565 Added local identity slot 12 |
Type the following to restart the SKIP key manager to update the certificate database:
# ssadm -r Screen_name lib/skipd_restart |
Start the editor on the remote Screen.
Type the following to add the new certificate and its name to the certificate database.
For example:
edit> add certificate sales-home NSID 8 MKID "0x3f3cf9d05285a3be1e6d4ecbe49e49e7" COMMENT "This is the Screen's key for the home sales network." |
Because this is a self-generated UDH certificate, the NSID is 8.
Type the certificate ID:
For tunnelling with a remote Administration Station, see the editor command accessremote. For tunnelling with encrypted packet filtering, see "Working With Policies". Tunnelling is also described in "Encryption, Tunneling, and Virtual Private Networks" in SunScreen 3.2 Administrator's Overview.
You can do this only with local administration; therefore, for a remotely administrated Screen, you must go to the Screen to add Screen certificates from a diskette or a file.
Insert the diskette that contains the public certificate, if you are using issued certificates, into the diskette drive of the Administration Station.
You also can add new private keys from a directory that contains only one set of certificate files. If you are adding private certificate from a directory, you do not need this step and step 2.
Mount the diskette by typing:
# volcheck |
Type the path to the directory where the public certificates are stored and the following command and the name of the directory to add the public certificate, for example:
# /floppy/floppy0/install_skip_keys A00050B |
This example shows adding a public certificate ID.
If you are using issued certificates, type the following in the terminal window to eject the diskette:
# eject floppy0 |
If you are adding a public certificate from a directory, you do not need this step.
Type the following to name the public certificate you have just added, for example:
edit> add certificate NYcert NSID 1 "0xA00050B" COMMENT "NY office public cert" |
Each SKIP certificate requires a particular Name Space ID (NSID) and the Master Key ID (certificate ID) of the certificate.
Issued certificates that use the IP address use the NSID 0 convention with the IP address as the certificate ID.
Issued certificates use the NSID 1 convention with a certificate ID of 8 hexadecimal digits (32 bit).
Self-generated certificates use the NSID 8 convention with an certificate ID of 32 hexadecimal digits (128 bits).
The tunnel address can be specified as an option in the rule that uses the certificate or in the remote administration rule.
These procedures describe how to create and work with certificate groups. The examples in these tasks use a list of U.S. sales offices (sales-list) as the certificate group and individual sales offices (such as sales-il for the Illinois office).
After you have named certificate IDs in the rule, you can group them into logical groups so that you can use a group instead of single names in a rule.
Use the GROUP option to group named certificate IDS.
For example:
edit> add certificate sales-list GROUP {sales-co sales-il sales-tx sales-sca sales-nca} {} COMMENT "list of U.S. sales offices" |
Use the add_member subcommand to add a new member to a certificate group.
For example:
edit> add_member certificate sales-list sales-wy |
Use the del_member subcommand to remove a member from a certificate group.
For example:
edit> del_member certificate sales-list sales-wy |
To make troubleshooting easier, do not rename the certificates that were created when you installed SunScreen.
Use the renamerefernce subcommand to rename a certificate or certificate group.
For example:
edit> renamereference certificate sales-ny sales-northeast |
When you rename a certificate group using this command, SunScreen checks for all instances in the certificate policy object for the old name and changes them to the new name. It does not rename references in other places, such as administrative rules and policy rules.
To make troubleshooting easier, do not delete the certificates that were created when you installed a remotely administered SunScreen.
This command does not check for references to the certificate or certificate group that you are deleting.
Use the del subcommand to delete a certificate or certificate group.
For example:
edit> del certificate sales-la |
Use the refer subcommand to find the reference to a certificate and certificate group that you want to delete or have deleted.
For example:
edit> refer certificate sales-la |
Use the referlist subcommand to find the reference to a certificate and certificate group that you want to delete or have deleted, for example:
edit> referlist certificate sales-west |
This displays a list of all the instances in the certificate database where the certificate group is used. You can remove it from the access entries in which it is used and edit any policy rule in which it is used to remove it.
For tunneling mode, pre-shared key usage:
[SCREEN scrn] svc srcaddr dstaddr \ IPSEC { AH(authalg1) | ESP(encralg1[, authalg2]) }+ \ IKE(encralg2, authalg3, oakleygroup, PRE-SHARED, pskey) \ [SOURCE_SCREEN srcscrn] [DESTINATION_SCREEN dstscrn] \ [SOURCE_TUNNEL srctunaddr] [DESTINATION_TUNNEL dsttunaddr] \ ALLOW |
For tunneling mode, certificate usage:
[SCREEN scrn] svc srcaddr dstaddr \ IPSEC { AH(authalg1) | ESP(encralg1[, authalg2]) }+ \ IKE(encralg2, authalg3, oakleygroup, authmethod, \ srccert, dstcert) \ [SOURCE_SCREEN srcscrn] [DESTINATION_SCREEN dstscrn] \ [SOURCE_TUNNEL srctunaddr] [DESTINATION_TUNNEL dsttunaddr] \ ALLOW |
For tunneling mode, manual key usage:
[SCREEN ] \ IPSEC { AH(spi1, authalg, key1) \ | ESP(spi2, encralg2, key2 [, spi3, authalg3, key3]) } \ [SOURCE_SCREEN srcscrn] [DESTINATION_SCREEN dstscrn] \ [SOURCE_TUNNEL srctunaddr] [DESTINATION_TUNNEL dsttunaddr] \ ALLOW |
An alternative syntax follows:
[SCREEN scrn] svc srcaddr dstaddr \ IPSEC { AH(spi1, authalg, key1) | ESP(spi2, encralg2, \ key2 [, add key "key_des" SINGLE "1234567812345678" edit> add key "key_ah" SINGLE "1234567890abcdef1234567890abcdef" |
See the SunScreen 3.2 Configuration Examples manual for an example of how to use the GUI to perform this same function.
On Screen 1:
1 "telnet" "screen1_host" "screen2_host" IPSEC ESP(0x123, "DES", "key_des") AH(0x345, "MD5", "key_ah") SOURCE_SCREEN "screen1" ALLOW 2 "telnet" "screen2_host" "screen1_host" IPSEC ESP(0x123, "DES", "key_des") AH(0x345, "MD5", "key_ah") DESTINATION_SCREEN "screen1" ALLOW |
On Screen 2:
1 "telnet" "screen2_host" "screen_host1" IPSEC ESP(0x123, "DES", "key_des") AH(0x345, "MD5", "key_ah") SOURCE_SCREEN "screen2" ALLOW 2 "telnet" "screen1_host" "screen2_host" IPSEC ESP(0x123, "DES", "key_des") AH(0x345, "MD5", "key_ah") DESTINATION_SCREEN "screen2" ALLOW |
The hex values 0x123, 0x345 are SPI values and must be between 0x000 and 0xFFF.
If you choose different algorithms, like 3DES or SHA1, define manual keys of the proper length.
In hex strings, the lengths are respectively.
CBC 16
3DES 48
MD5 32
SHA1 40
Save and activate the policy.
See the SunScreen 3.2 Configuration Examples manual for an example of how to use the GUI to perform this same function.
Add the pre-shared secret key on both Screens
edit> add key "shared-secret" SINGLE "shared_secret" |
Add rules like the following using keys added on both Screens.
On Screen1:
1 "telnet" "screen1_host" "screen2_host" IPSEC ESP("DES") IKE("DES", "MD5", 2, PRE-SHARED, "shared-secret") SOURCE_SCREEN "screen1" ALLOW 2 "telnet" "screen2_host" "screen1_host" IPSEC IPSEC ESP("DES") IKE("DES", "MD5", 2, PRE-SHARED, "shared-secret") DESTINATION_SCREEN "screen1" ALLOW |
On Screen2:
1 "telnet" "screen2_host" "screen1_host" IPSEC ESP("DES") IKE("DES", "MD5", 2, PRE-SHARED, "shared-secret") SOURCE_SCREEN "screen2" ALLOW 2 "telnet" "screen1_host" "screen2_host" IPSEC IPSEC ESP("DES") IKE("DES", "MD5", 2, PRE-SHARED, "shared-secret") DESTINATION_SCREEN "screen2" ALLOW |
Save and activate policy.
See the SunScreen 3.2 Configuration Examples manual for an example of how to use the GUI to perform this same function.
Generate certificates or private keys on both Screens using ssadm certlocal:
Export the certificates to the other Screen.
Securely transport the file /tmp/cert1 to the Screen1 and /tmp/cert2 to Screen 2.
Import the exported certificate to the Screen certificate database.
Add certificate objects on both systems:
edit> add certificate "screen1_cert" SINGLE IKE "C=US, O=YourOrg,CN=screen1_name" edit> add certificate "screen2_cert" SINGLE IKE "C=US, O=YourOrg,CN=screen2_name" |
Mark the certificate you imported in Steps 3 and 4 as trusted on both systems using ssadm edit:
Add packet filtering rules on both Screens.
On Screen1:
1."telnet" "screen1_host" "screen2_host" IPSEC ESP("DES") IKE("DES", "MD5", 2, RSA-SIGNATURES, "screen1_cert", "screen2_cert") ALLOW 2 "telnet" "screen2_host" "screen1_host" IPSEC IPSEC ESP("DES") IKE("DES", "MD5", 2, RSA-SIGNATURES, "screen2_cert", "screen1_cert") ALLOW |
On Screen2:
1."telnet" "screen2_host" "screen1_host" IPSEC ESP("DES") IKE("DES", "MD5", 2, RSA-SIGNATURES, "screen2_cert", "screen1_cert") ALLOW 2 "telnet" "screen1_host" "screen2_host" IPSEC IPSEC ESP("DES") IKE("DES", "MD5", 2, RSA-SIGNATURES, "screen1_cert", "screen2_cert") ALLOW |
Refer to the man page of ssadm-certlocal(1M) and ssadm-certdb(1M) for more information.
Save and activate the policy.
See the SunScreen 3.2 Configuration Examples manual for an example of how to use the GUI to perform this same function.
Generate keys and certificate requests on each Screen.
Bring the requests to a certificate server and have them signed and you should get three files from the CA:
screen1_issued.cert: screen1's cert. screen2_issued.cert: screen2 's cert root.cert: the CA's cert |
Further detailed instructions on this step depends on your certificate server.
Securely transport the files to each system under /tmp and import them.
Import three certificates on each Screen:
# ssadm certdb -I -a < /tmp/screen1_issued.cert # ssadm certdb -I -a < /tmp/screen2_issued.cert # ssadm certdb -I -a < /tmp/root.cert |
In this example, it is assumed you are using a certificate server with CA's subject
DN = "C=US, O=YourOrg.com, OU=sunscreen, CN=Certificate Manager" |
Add certificate objects for each Screen and mark the root CA as trusted. On each Screen:
edit> add certificate root_cert SINGLE IKE "C=US, O=YourOrg.com, OU=sunscreen, CN=Certificate Manager" edit> add certificate screen2_issued_cert SINGLE IKE "C=US, O=YourOrg, CN=screen2_issued" edit> add certificate screen1_issued_cert SINGLE IKE "C=US, O=YourOrg, CN=screen1_issued" edit> add_member certificate "IKE root CA certificates" root_cert |
The group name "IKE root CA certificates" is reserved for a trusted Certificate Group.
Add packet filtering rules on both Screens.
On Screen1:
1."telnet" "screen1_host" "screen2_host" IPSEC ESP("DES") IKE("DES", "MD5", 2, RSA-SIGNATURES, "screen1_issued_cert", "screen2_issued_cert") ALLOW 2 "telnet" "screen2_host" "screen1_host" IPSEC IPSEC ESP("DES") IKE("DES", "MD5", 2, RSA-SIGNATURES, "screen2_issued_cert", "screen1_issued_cert") ALLOW |
On Screen2:
1."telnet" "screen2_host" "screen1_host" IPSEC ESP("DES") IKE("DES", "MD5", 2, RSA-SIGNATURES, "screen1_issued_cert", "screen2_issued_cert") ALLOW 2 "telnet" "screen1_host" "screen2_host" IPSEC IPSEC ESP("DES") IKE("DES", "MD5", 2, RSA-SIGNATURES, "screen2_issued_cert", "screen1_issued_cert") ALLOW |
Save and activate the policy.
A Screen object controls much of the identity of a Screen. It contains information for your stealth, HA, cluster, and administrative rules. Upon installation, a Screen object that you can edit is created. As with other common objects, when you redefine a Screen object, you must specify all the parameters that you want to set; otherwise the parameters are set to default values.
To add a screen object with a previously-created certificate, using DNS and NIS for Name Service and passing routing information, type the following:
edit> add screen vorticity ADMIN_CERTIFICATE vorticity.admin RIP DNS NIS COMMENT "The screen that protects the sales office" |
Adding a comment is optional.
Type the following to list all the Screens:
edit> list screen |
To add an SNMP receiver to the Screen used in the previous procedure:
edit> add screen vorticity ADMIN_CERTIFICATE vorticity.admin RIP DNS NIS SNMP 10.100.253.200 |
To add multiple SNMP receivers to the previous Screen object:
edit> add screen vorticity ADMIN_CERTIFICATE vorticity.admin ROUTING DNS NIS SNMP 10.100.253.200 10.100.253.254 |
To add a Time Status Indicator of 30 minutes to the previous Screen object:
edit> add screen vorticity ADMIN_CERTIFICATE vorticity.admin ROUTING DNS NIS SNMP_TIMER 30 SNMP 10.100.253.200 10.100.253.254 |
To remove SNMP receivers from the Screen, do not include them in the Screen object when you set it:
edit> add screen vorticity ADMIN_CERTIFICATE vorticity.admin RIP DNS NIS |
At the editor prompt, type:
edit> add screen vorticity ADMIN_CERTIFICATE vorticity.admin RIP STEALTH_NET 10.100.253.0 255.255.255.0 COMMENT "The screen in Stealth Mode" |
For Routing interfaces, there are two types of spoof detection : Complete and Incomplete. On the Interface Definition panel (see "To Add or Edit Interfaces"), you can set the spoof detection by clicking on the "Spoof Protection" pulldown and making the selection (see "Interface Object" in SunScreen 3.2 Administrator's Overview for information on Complete and Incomplete spoof detection).
For Stealth interfaces, the type of spoof detection is always set to Complete and is not modifiable.
The maximum number of stealth interfaces per Screen is 15; however, the number of routing interfaces is virtually limitless.
Before you add a new interface, you must define the address group that the interface will use.
Type the following to define the interface named qe0 with no logging, no SNMP alerts, and ICMP_PORT_UNREACHABLE:
edit> add interface qe0 ROUTING qe0 ICMP PORT_UNREACHABLE |
Type the following to define the interface qe0 with detailed logging and SNMP alerts:
edit> add interface qe0 ROUTING qe0 LOG DETAIL SNMP ICMP PORT_UNREACHABLE |
List the currently active interfaces by typing:
edit> list interface |
A list of active interfaces is displayed.
Find the interface you want to delete and type the following:
edit> del interface interface_name |
Any interfaces that you remove with this procedure remain active until you reactivate a policy.
The authorized user object is used to establish a user identity and provide a mechanism to authenticate it by:
To manipulate authorized user objects, use the authuser subcommand. authuser is unusual in that it uses its own subcommands, which are listed in the following table.
Table 10-4 authuser Subcommands
authuser Subcommand |
Description |
---|---|
Creates or overwrites an object. This subcommand takes a complete description of the object, beginning with its name, followed by desired items and subitems. |
|
Deletes a named object. |
|
Displays the names of all authorized user objects. The default is asc. The sort options are:asc ascending order by name (case-sensitive) desc descending order by name (case-sensitive).iasc ascending order by name (case-insensitive).idesc descending order by name (case-insensitive).raw order stored in database. |
|
|
Displays one or more objects. With no object specified, print displays all AUTHUSER objects; specifying a name causes only that object's definition to be displayed. |
Type the following to add an authorized user named Audrey Farber for local administration:
edit> authuser add admin1 PASSWORD={ "foo" } CONTACT_INFO=bj@bobo REAL_NAME="Audrey Farber" DESCRIPTION="created for remote administration" |
Although the password is in plain text when you add a user, it is automatically encrypted, and the password will be displayed as empty quotation marks (" "). Enabled is the default.
The description field cannot contain single (` `) or double (" ") quotation marks, as in the description: This user, test_user, is for `testing' only.
All changes apply to the object immediately; however, for the changes to take effect in policy and administrative access rules, you must activate the policy.
Type the following to add an authorized user named Audrey Farber for local administration:
edit> authuser add admin1 SECURID={ "C2BR" } CONTACT_INFO=bj@bobo REAL_NAME="Audrey Farber" DESCRIPTION="created for local administration" |
Type the following to add an authorized user for remote administration:
edit> authuser add admin1 SECURID={ "C2BR" } CONTACT_INFO=bj@bobo DESCRIPTION="created for remote administration" |
Enabled is the default. All changes apply to the object immediately; however, for the changes to take effect in policy and administrative access rules, you must activate the policy.
Type the following to display a list of authorized user objects as they appear in the database:
edit> authuser names,raw |
The following list is displayed:
barbara.bobo admin melanie.haber admin audry.farber admin |
Use the authuser add subcommand to modify the information for a user.
For example, to change the SecurID name from C3BR to C4BR:
edit> authuser add admin1 SECURID={ "C4BR" } CONTACT INFO=bj@bobo REAL_NAME="Audrey Farber" DESCRIPTION="created for remote administration" |
The new parameters for the user will overwrite the old parameters. All changes apply immediately.
Modifications to passwords or SecurID passcodes take place immediately. For other changes to take effect in policy and administrative access rules, you must activate the policy.
Use the authuser delete subcommand to delete an authorized user, for example:
edit> authuser delete admin1 |
Policy Rules are ordered, that is, they are executed in the order in which they are listed. You can define them in the order in which you want them to take effect or you can reorder your policy rules after you have defined them.
Type the following to add a new rule at the end of a policy with the attributes listed below:
edit> add Rule ping * * ALLOW SKIP_VERSION_2 cert-1 cert-2 DES-CBC RC2-40 MD5 NONE LOG SUMMARY |
ping
*
*
SKIP Version 2
Siource Certificate is cert-1
Destination Certificate is cert-2
Key algorithm is DES-CBC
Data algorithm is RC2-40
MAC algorithm is MD5
NONE for the compression (This is the only possible value, at present.)
ALLOW
ALLOW
NONE
All other options assume default values unless specified (for example, SNMP is off).
Type the following to add a new rule at a particular position, for example, 1 to add it at the beginning of the policy:
edit> insert Rule 1 ping * * ALLOW SKIP_VERSION_2 cert-1 cert-2 DES-CBC RC2-40 MD5 NONE LOG SUMMARY |
If a filtering rule fails to detect any issued certificate (key) encryption algorithms, it may display the following error message:
An error occurred in detecting the Encryption algorithms. Please check if skipd process is running.
If this occurs, restart the skipd process with the skipd_restart command.
Use the list subcommand to produce an ordered list of rules for the policy:
edit> list rule |
An ordered list of policy rules is displayed, as shown in this example.
1 "www" "*" "*" ALLOW 2 "finger" "*" "*" ALLOW 3 "ftp" "*" "localhost" USER "admin" ALLOW LOG DETAIL PROXY_FTP FTP_GET FTP_CHDIR FTP_RENAME FTP_DELETE 4 "daytime" "localhost "*" ALLOW 5 "telnet" "*" "*" ALLOW 6 "echo" "localhost" "*" ALLOW |
Use the move subcommand to move a policy rule to a new position, for example, from fourth to fifth position:
edit> move rule 4 5 |
The list of policy rules now shows the change in the order of the rules.
1 "www" "*" "*" ALLOW 2 "finger" "*" "*" ALLOW 3 "ftp" "*" "localhost" USER "admin" ALLOW LOG DETAIL PROXY_FTP FTP_GET FTP_CHDIR FTP_RENAME FTP_DELETE 4 "telnet" "*" "*" ALLOW 5 "daytime" "localhost "*" ALLOW 6 "echo" "localhost" "*" ALLOW |
Use the del subcommand to delete policy rule 5:
edit> del rule 5 |
Generate the ordered list of policy rules:
edit> list rule |
The new list of policy rules reflects the deletion of rule 5; the former rule 6 now occupies the fifth position.displayed.
1 "www" "*" "*" ALLOW 2 "finger" "*" "*" ALLOW 3 "ftp" "*" "localhost" USER "admin" ALLOW LOG DETAIL PROXY_FTP FTP_GET FTP_CHDIR FTP_RENAME FTP_DELETE 4 "telnet" "*" "*" ALLOW 5 "echo" "localhost" "*" ALLOW |
You can edit a component or the components of a policy rule by using the following procedure. The example shows how to modify the action.
List all the rules in the policy:
edit> list rule |
An ordered list of policy rules is displayed.
1 "www" "*" "*" ALLOW 2 "finger" "*" "*" ALLOW 3 "ftp" "*" "localhost" USER "admin" ALLOW LOG DETAIL PROXY_FTP FTP_GET FTP_CHDIR FTP_RENAME FTP_DELETE 4 "telnet" "*" "*" ALLOW 5 "echo" "localhost" "*" ALLOW |
Use the replace subcommand to edit the policy. For example, to change the action of policy rule 4 from ALLOW to DENY, insert a new policy rule with the action changed:
edit> replace rule 4 telnet * * DENY LOG DETAIL |
List the rules for the policy:
edit> list rule |
The list of policy rules is displayed, showing the rule with the new values replaces the old rule.
1 "www" "*" "*" ALLOW 2 "finger" "*" "*" ALLOW 3 "ftp" "*" "localhost" USER "admin" ALLOW LOG DETAIL PROXY_FTP FTP_GET FTP_CHDIR FTP_RENAME FTP_DELETE 4 "telnet" "*" "*" DENY LOG DETAIL 5 "echo" "localhost" "*" ALLOW |
The changes take effect when you activate the policy whose rules you have edited.
Use the add subcommand with the accesslocal argument to add an administrative access rule for local administration.
For example:
edit> add accesslocal USER admin3 PERMISSION ALL |
List the administrative access rules for local administration:
edit> list AccessLocal |
By default, an admin user is created during installation.
The following approximates the output that is displayed:
1 USER "admin" PERMISSION ALL 2 USER "admin3" PERMISSION ALL |
Use the replace subcommand to replace an administrative access rule with a new value for a particular user for local administration:
edit> replace AccessLocal 2 USER "admin3" PERMISSION STATUS |
Do not delete all the administrative access rules.
Use the del subcommand to delete the administrative access rule for local administration.
For example, to delete rule 2, type:
edit> del AccessLocal 2 |
Use the add subcommand with the accessremote argument to add an administrative access rule for remote administration:
edit> add accessremote USER admin3 * SKIP_VERSION_2 admin-group DES-CBC DES-CBC MD5 NONE |
This administrative access rule allows the access level ALL for the admin 3 user at a remote Administration Station on the Internet to use the GUI and command line to administer the Screen.
Make a note of the encryption parameters if you change them, because they have to match the encryption parameters on the remote Administration Station.
List the administrative access rules for remote administration, for example:
edit> list accessremote |
The following approximates the output that is displayed:
1 USER "admin" "*" SKIP_VERSION_2 "admin-group" "DES-CBC" "DES-CBC" "NONE" "NONE" PERMISSION ALL 2 USER "admin3" "*" SKIP_VERSION_2 "admin-group" "DES-CBC" "DES-CBC" "NONE" "NONE" PERMISSION ALL |
Make a note of the encryption parameters if you change them, because they have to match the encryption parameters on the remote Administration Station.
Use the replace subcommand to replace an administrative access rule with the value or values for a particular user for remote administration with a new value (for example, STATUS, for the access level):
edit> replace accessremote USER admin3 * SKIP_VERSION_2 admin-group DES-CBC DES-CBC NONE NONE PERMISSION STATUS |
This administrative access rule changes the access level for admin3 at a remote Administration Station on the Internet to STATUS.
Do not delete all the administrative access rules.
Use the del subcommand to delete an administrative access rule for remote administration:
edit> del accessremote 2 |
Where 2 is the number, in the ordered rules, that you want to delete.
If you are using NAT, the when you define a static mapping, be sure that the ranges and groups used in the Source, Destination, Translated Source, and Translated Destination fields are exactly the same size.
Use the arp command with the -s flag if the networks that attach to the Screen on the inside have internal addresses (including any network on which there are addresses to which you want to allow external access):
# arp -s IP_Address ether_address pub |
You must either add this entry each time you reboot the Screen or write your own script to automate this function. If you are administering the Screen remotely, you must either go to the Screen to add this entry or have a rule in your policy that allows you to use a command or protocol such as telnet or ssh to access the Screen. See also the arp(1M) man page.
For local administration, you can create either a static or a dynamic NAT entry by specifying either the STATIC or DYNAMIC option.
Use the add subcommand to create a static NAT entry that maps an internal address to an external address:
edit> add nat STATIC src dest translated_src translated_dest |
When you define a static mapping, the internal address and external address are both single addresses, but either can be a range or a list. In most cases, you should add a reverse entry for static mapping.
To create the equivalent dynamic NAT entry, substitute the DYNAMIC option for the STATIC option.
edit> add nat DYNAMIC src dest translated_src translated_dest |
You can also use a range of addresses or a group of addresses.
Activate the policy to have the changes take effect.
Use the del subcommand to delete a NAT entry that maps an internal address to an external address, regardless of whether mapping is static or dynamic:
edit> del nat 1 |
The changes take effect when you activate the policy whose rules you have edited.
Use the list subcommand to list a NAT entry that maps internal address to a external address, regardless of whether mapping is static or dynamic:
edit> list nat |
You will see a listing that shows type of NAT, the internal address, and the external address:
1 STATIC "105-range" "*" "nat-range" "*" |
Setting up a VPN requires you to have a certificate per Screen and to define the address groups involved. For descriptions and concepts of the virtual private network, see "Encryption, Tunneling, and Virtual Private Networks" in SunScreen 3.2 Administrator's Overview.
At the command line prompt, type:
edit> add vpngateway vpn-net addrgrp-a SKIP cert-a KEY DES-CBC DATA RC4-40 MAC MD5 COMPRESSION NONE |
Where:
vpn-net is the name of the VPN
addrgrp-a is an address group that uses the following certificate
SKIP cert-a is the certificate
If you are using a tunnel address, append TUNNEL address_name to the add/replace.
To setup the VPN completely, you should have all the certificates, address groups, and VPN gateways defined on each Screen. In a VPN configuration that has two networks connected, you would see something like the following:
edit> list vpngateway 1 "vpn-net" "addrgrp-a" SKIP "cert-a" KEY "DES-CBC" DATA "RC4-40" MAC "MD5" COMPRESSION "NONE" 2 "vpn-net" "addrgrp-b" SKIP "cert-b" KEY "DES-CBC" DATA "RC4-40" MAC "MD5" COMPRESSION "NONE" |
Create an address group to contain the address groups for both networks, for example:
edit> add address vpn-grp GROUP { addrgrp-a addrgrp-b } {} |
Define a rule to specify the VPN gateway:
edit> add rule common vpn-grp vpn-grp ALLOW VPN vpn-net |
VPN gateways are set up in an ordered manner.
To change values, at the command line prompt, type (for example):
edit> replace vpngateway 1 vpn-net addrgrp-a SKIP cert-new KEY DES-CBC DATA RC4-40 MAC MD5 COMPRESSION NONE |
To remove the VPN gateway, you must delete the rules and VPN object.
At the command line prompt, type (for example):
edit> del vpngateway 1 |
The ssadm sys_info subcommand provides information such as product, system boot time, SunScreen boot time, and version.
To display information using local administration, type the following:
# ssadm sys_info |
To display the equivalent information using remote administration, use the -r flag and specify the name of the remote Screen:
# ssadm -r Screen_name sys_info |
The traffic_stats option displays information about the traffic flowing through a Screen.
Using local administration, type the following:
# ssadm traffic_stats |
Using remote administration:
# ssadm -r Screen_name traffic_stats |
You can use LOGSIZE to set the maximum size of your log file. The values are expressed in Mbytes, where 200 represents 200 Mbytes.
At the editor prompt, type:
edit> add screen vorticity ADMIN_CERTIFICATE vorticity.admin CDP RIP DNS SNMP 10.100.253.200 LOGSIZE 200 |
SunScreen provides flexible logging of packets. A packet can be logged when it matches a policy rule, when it does not match a policy rule, or when it matches a policy rule whose action is DENY.
Configure SunScreen to log packets that do not match any particular policy rule.
Most frequently, packets are logged because of the DENY action in a rule or because they do not match any policy rule.
Set the type of logging you want in the details for the ALLOW action in a policy rule.
Set the type of ICMP reject in the details for the DENY action in a policy rule.
On the Interfaces panel of the Interface page, set logging for packets that are dropped because they do not match any policy rule.
Once a log is retrieved, use the ssadm logdump command to examine it.
Examining logged packets can be useful for troubleshooting problems encountered while you set up security policies. For example, when first creating policies, make the default DENY action "log packets." This enables you to review the logs easily. You can also use logging to capture any attempts to break in.
You can examine a saved log file only from the command line.
Use the ssadm logdump command to display packets in the log file:
# ssadm logdump -i ssadm_log_file |
ssadm_log_file is the name of a log file that has been downloaded from the Screen.
Type the following to view the current log using local administration:
# ssadm log get | ssadm logdump -i - |
See the ssadm-logdump manpage for a list of options.
Using local administration, use ssadm log get to save a log record to a file for local administration:
# ssadm log get > filename |
Using remote administration use ssadm with the -r option:
# ssadm -r Screen_name log get > filename |
This action clears the log browser's display of any log records without saving them and clears the SunScreen log file.
Using local administration, type the following to clear the log file:
# ssadm log clear |
Using remote administration, use ssadm with the -r option:
# ssadm -r Screen_name log clear |
This action saves a log to a file and clears the display of any log records.
Using local administration, type the following to save the log to a file and clear the log:
# ssadm log get_and_clear > filename |
Using remote administration, use the ssadm with the -r option:
# ssadm -r Screen_name log get_and_clear > filename |
See Chapter 5, Using High Availability and "Encryption, Tunneling, and Virtual Private Networks" in SunScreen 3.2 Administrator's Overview before using the command line to set up HA.
To install HA on the Screen designated to be the primary HA Screen, type the following:
# ssadm ha init_primary interface |
This step creates a new HA cluster containing one Screen.
To install HA on the Screen designated to be the secondary HA Screen type the following:
# ssadm ha init_secondary interface primaryIP |
Where:
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 Screen in the cluster
You can receive the following error message after you issue the ssadm ha init_secondary command because the primary screen has not sent the policy to the secondary screen. This is normal and the error message can be ignored.
Error: No filtering interfaces defined. |
To add the HA secondary Screen to the existing HA cluster, execute the following command on the primary machine in the cluster:
# ssadm ha add_secondary secondaryIP |
Where secondaryIP is the IP address (on the dedicated HA network) of the secondary Screen to be added.
After adding an HA secondary Screen and activating your policy, the new secondary Screen may become active. If you need to perform additional administration on the primary Screen, first direct the secondary Screen to become passive so that you can communicate with the primary Screen.
By default, only administrative traffic is allowed on the HA interface (ping and SunScreen Administration services). This design keeps the network as secure as possible. However, sometimes administrators have some need to open up other services on this private network.
This can be accomplished by adding filtering rules that include the HA network as the destination address. For example, suppose that the dedicated HA network is 172.16.0.0/24. The following policy would allow telnet traffic to and from any address on the HA network.
Add the filtering rule as follows:
edit> list interface qfe0 "qfe0" HA "hanetwork" INCOMPLETE edit> list address hanetwork "hanetwork" RANGE 172.16.0.0/24 edit> list rule 1 1 "telnet" "hanetwork" "hanetwork" ALLOW |
The destination address must be the same network object that is used in the interface definition. An equivalent object with a different name will not work.
For example, the following change would work, since only the source is a newly defined object.
edit> add address hanetwork2 RANGE 172.16.0.0/24 edit> replace rule 1 telnet hanetwork2 hanetwork ALLOW |
edit> add address hanetwork2 RANGE 172.16.0.0/24 edit> replace rule 1 telnet hanetwork hanetwork2 ALLOW |
HA setup requires commands that are outside the configuration editor. Removing the HA setup consists of removing the HA_* options from the Screen objects on the appropriate machines. The three steps below assume the following:
edit> list screen "vorticity" MASTER "barotropic" CDP RIP NIS HA_SECONDARY HA_IP 129.192.1.2 "barotropic" ADMIN_CERTIFICATE "barotropic.admin" CDP DNS NIS HA_PRIMARY HA_IP 129.192.1.5 HA_ETHER 8:0:20:9e:e0:66 |
Remove the HA Screen:
edit> del screen vorticity |
Redefine the primary Scrren to no longer be an HA-PRIMARY::
edit> add screen barotropic ADMIN_CERTIFICATE barotropic.admin CDP DNS NIS |
Save and activate your configuration.
The next two steps display information such as the current active or passive status of the HA machine in question and the current state of the HA daemon.
Using local administration, type the following:
# ssadm ha status |
Using remote administration, use the -r flagssadm with the -r option to display the same information:
# ssadm -r Screen_name ha status |
To view the status of all HA machines in a cluster, type the following from the primary HA machine:
# ssadm ha status -Z |
Use the following commands to set up a CMG cluster. Centralized management groups are explained in Chapter 7, Configuring Centralized Management Groups and in "Centralized Management Group" in SunScreen 3.2 Administrator's Overview.
The example below illustrates a two-machine cluster setup.
Type the following on both machines in the cluster:
edit> add screen sphere ADMIN_CERTIFICATE "sphere.admin" CDP RIP NIS LOGSIZE 100 edit> add screen velocity ADMIN_IP 10.100.105.5 ADMIN_CERTIFICATE vorticity.admin KEY"DES" DATA "RC4-40" MAC "MD5" COMPRESSION "NONE" MASTER sphere CDP DNS NIS |
Type the following on the primary Screen ("sphere" in this example):
edit> del screen vorticity |
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.
You can collect useful diagnostic information by saving the output of the SunScreen support commands shown in the following table.
Table 10-5 SunScreen Support Commands
Command |
Description |
---|---|
Brings over configuration files for the active configuration |
|
Sets and gets current time/date |
|
Checks disk space (df -k) |
|
Checks EEPROM settings |
|
Checks for a core file |
|
help |
Provides a list of the available support commands |
Checks boot history |
|
Checks pkginfo and patch history |
|
Checks processes (ps -elf) |
|
Checks contents of /etc/skip/ directory |
|
Checks the kernel networking statistics (netstat -k) |
|
Checks the STREAMS statistic (netstat -m) |
|
Brings over version information on major SunScreen components |
These commands, sent from a remote Administration Station, are used for remote diagnostics.
Type the following to start any of these support commands:
From a local administration station, type:
# ssadm Screen_name lib/support Command_Name |
From a remote administration station, type:
# ssadm -r Screen_name lib/support Command_Name |
The following table list additional support commands that are available using lib/Command_Name instead of lib/support::
Table 10-6 Other Support Commands
Type the following to start any of these other support commands:
You can use several commands to gather system information from the Screen. This information may be requested by Sun Service, should you encounter problems with your Screen.
These commands should only be used for debugging in conjunction with a support call.
To see internal statetable information, type:
# ssadm lib/statetables |
This command gathers a complete set of data for your Sun Service representative, including:
State tables
ARP table information
Disk usage
Streams information
SunScreen configuration information and files
Uptime
SKIP information
At the command line prompt, type:
# ssadm lib/screeninfo > output_filename |
This command gives you access to the commands in the support directory, all of which are invoked by the screeninfo command. However, if you are seeking limited data, you may want to run this command alone.
At the command line prompt, type:
# ssadm lib/support subcommand [parameters...] |
See the following procedure for information on the subcommands or parameters used with this CLI.
At the command line prompt, type:
# ssadm lib/support help |
A list of the subcommnads is displayed.
You can use the ssadm debug_level command to control the printing of debugging information from the SunScreen kernel.
If you type the command with no arguments, ssadm debug_level displays the current debug-level mask. By default, this mask has a value of 1, which means it reports only significant errors.
If you specify a hexadecimal number as an argument for ssadm debug_level, the command sets the kernel debugging mask to that level.
To list the debugging bit choices, type the following:
# ssadm debug_level ? |
Select a ssadm debug_level mask by setting all of the debugging bits in which you are interested.
Probably the most useful example of the ssadm debug_level debugging bit is DEFAULT_DROP.
When using the Java Plug-In for Netscape Navigator, follow the instructions in the Netscape release notes. In particular, define the MOZILLA_HOME environment variable and include the Netscape installation directory in your PATH, so you do not have to type the full path name every time you run Netscape.
Set up an environment for installing and running the Java Plug-In.
For sh or ksh users, type:
# unset CLASSPATH # MOZILLA_HOME=/opt/netscape # PATH=$MOZILLA_HOME:$PATH # export PATH MOZILLA_HOME |
For csh users, type:
% unsetenv CLASSPATH % setenv MOZILLA_HOME /opt/netscape % set path = ( $MOZILLA_HOME $path ) |
Install the Java Plug-In by typing:
# sh Java_Plugin_File_Name.sh |
Save the identitydb.obj file. See "To Save the identitydb.obj File".
Access the SunScreen administration GUI in one of two ways:
Set the CLASSPATH environment variable only if you need to install special Java files in Netscape Communicator.
Communicator uses CLASSPATH to find local .class files. If CLASSPATH is set in your environment, only the .jar files and directories specified in the CLASSPATH are searched. If you set your CLASSPATH, you must make sure that each .jar file in $MOZILLA_HOME/java/classes is listed individually in your CLASSPATH.
After installing the Java Plug-In, save the identitydb.obj file to distribute to the Administration Stations.
Save the file identitydb.obj by going to the following URL:
http://localhost:3852/plugin/plugins/ |
In Netscape, press mouse button 3 and choose Save Link As.
If your browser does not support this save operation, access identitydb.obj in the /usr/lib/sunscreen/admin/htdocs/plugin/plugins/ directory.
Copy the identitydb.obj file onto a diskette to distribute to all Administration Stations.
If the identitydb.obj file already exists in its proper location, add SunScreen as an accepted signer.
Operating System | Proper Location |
---|---|
UNIX | $HOME |
Single-user Win95 | C:\WINDOWS |
Multi-user Win95/98 | C:\WINDOWS\PROFILES\username |
WinNT | C:\WINNT\PROFILES\username |
If the identitydb.obj file does not exist, copy the file from the diskette to one of the above locations, then perform Step 4.