test

SunScreen EFS Release 3.0 Reference Manual

RADIUS Authentication

RADIUS uses a User Datagram Protocol (UDP)-based query and response protocol to authenticate users from databases maintained on remote servers.

There are a variety of server offerings from different commercial and public-server suppliers. Many public-server and some commercial servers are based on a reference implemention created by Livingston.

There have been a few iterations of the RADIUS protocol; the SunScreen EFS 3.0 iteration is based on the latest iteration, per RFC2138.

One of the major distinctions between the iterations is the UDP port number used.

RADIUS authentication requires the following:

Minimum configuration on the Screen requires:

RADIUS var prg=auth name=RADIUSServers

Note -

The vars command in the configuration editor manipulates variables used for RADIUS configuration.

A var controls the RADIUS server(s) to query; its key is:

[ sys=scrnname ] prg=auth name=RADIUSServers

The pre-installed value for this var is:

# ssadm vars print prg=auth name=RADIUSServers PRG="auth" NAME="RADIUSServers" DISABLED VALUES={ host="server1" host="server2" host="1.2.3.4" } DESCRIPTION="RADIUS server name(s) address(es) to query"

Note -

var is initially DISABLED.

The RADIUSServers var is a multiple-valued one (uses the VALUES={ item)

VALUES are the names or the IP addresses of the RADIUS servers; names given are resolved from the Screen registry (not from DNS or NIS).

Up to eight server addresses can be given (or implied by the name(s) referenced).

The following is an example of what you type to create an Address for the RADIUS servers and to edit the var to refer to the proper servers and enable it by typing:


# ssadm edit configedit> add address mork HOST 8.8.8.8edit> add address mindy HOST 8.8.9.9edit> add address radius-servers GROUP { mork mindy }edit> vars add prg=auth name=RADIUSServers VALUES={ host=radius-servers } DESCRIPTION="RADIUS server name(s) address(es) to query"edit> save

Activate these changes.

In centralized management group Screen configurations, there are two possible means to control the use of different servers for different Screens.

The following is an example of what you type to create an Address (or GROUP) that has a standard name but that has the SCREEN attribute, as needed, for different Screens:


# ssadm edit configedit> list screen "msd-screen" ... 	"hq-screen" ...	edit> add address bob HOST 199.190.177.6	edit> add address carol HOST 199.190.177.9	edit> add address ted HOST 134.70.254.11	edit> add address alice HOST 134.70.254.111	edit> add address radius-servers GROUP { bob carol } 		SCREEN hq-screen	edit> add address radius-servers GROUP { ted alice } 		SCREEN msd-screen		edit> vars add prg=auth name=RADIUSServers VALUES={ host=radius-servers }	edit> save

The following is an example of what you type to create multiple var RADIUSServers items, each with a sys=Screen keying value:


# ssadm edit configedit> list screen 	"hq-screen" ... 	"msd-screen" ...edit> add address bob HOST 199.190.177.6edit> add address carol HOST 199.190.177.9edit> add address ted HOST 134.70.254.1	edit> add address alice HOST 134.70.254.11	edit> add address hq-radius-servers GROUP { bob carol }	edit> add address msd-radius-servers GROUP { ted alice }edit> ...	edit> vars add sys=hq-screen prg=auth name=RADIUSServers VALUES={ host=hq-radius-servers }edit> vars add sys=msd-screen prg=auth name=RADIUSServers VALUES={ host=msd-radius-servers }

Combinations of these approaches are possible also.

RADIUS var sys=scrn prg=auth name=RADIUSNodeSecret

A var controls the node secret used by the RADIUS protocol to secure traffic to and from the server(s); its key is:

[ sys=scrnname ] prg=auth name=RADIUSNodeSecret

The pre-installed value for this var is:


edit> vars print prg=auth name=RADIUSNodeSecret PRG="auth" NAME="RADIUSNodeSecret" DISABLED VALUE="....-....1....-....2....-....3.."
DESCRIPTION="shared secret for (this) RADIUS client"

Note -

var is initially DISABLED.

Each client has a node secret; this secret is also called the shared secret by the RFC; the servers maintain a list of the secrets of the clients for which they perform authentication services.

The RFC indicates that the node secret can be up to 32-characters in length (not including a null-terminator).

Note -

Although the RFC specifies a 32-character maximum, many servers (especially those derived from the reference implementation) will only properly utilize a node secret of 16 characters or less in length.

The following is an example of what you type to create a var for each Screens node secret:


edit> vars add sys=hq-screen prg=auth name=RADIUSNodeSecret VALUE="managed2death" DESCRIPTION="shared secret for (this) RADIUS client"edit> vars add sys=msd-screen prg=auth name=RADIUSNodeSecret VALUE="++stayNalive++" DESCRIPTION="shared secret for (this) RADIUS client"

Activate these changes.

Note -

In multiple Screen configurations, you can decide to cheat and utilize a common node secret for all or many Screens. Should such a choice be made, the common var for the node secret (the pre-installed one, that is initially DISABLED) can be ENABLED and provided with a proper secret string.

The following is an example of what you type to utilize a common node secret for all or many Screens:


edit> vars add prg=auth name=RADIUSNodeSecret VALUE="AlwAysAnAgrAms" DESCRIPTION="shared secret for all RADIUS client screens"

This (global, default) secret is used if no specific one is configured for a particular Screen.

RADIUS proxyuser References

RADIUS authentication is enabled by including member references to the pre-installed proxyuser entity "radius" in GROUP proxyuser, where radius is to be trusted.

The following is an example of what you type to enable authentication:


edit> proxyuser add grp-w GROUP DESCRIPTION="w/ RADIUS"edit> proxyuser add grp-wo GROUP DESCRIPTION="w/o RADIUS"edit> proxyuser addmember grp-wo user1edit> proxyuser addmember grp-wo user2edit> proxyuser addmember grp-w grp-woedit> proxyuser addmember grp-w radius

Rules that reference (either directly or indirectly) "grp-wo" only allows users "user1" and "user2"; whereas, ones that reference "grp-w" allow those two users, plus any user that the configured RADIUS server(s) authenticate.

RADIUS Client-->Server Rules

Access from the routing-mode Screen to the RADIUS server(s) must be allowed due to the configuration steps above, a usable Address already exists; if it does not, create such a rule that allows the Screen to communicate with its server(s).

The following is an example of what you type to create a rule to allows the Screen to communicate with its server(s):


# ssadm edit configedit> add rule radius localhost radius-servers ALLOW ...

where the above assumes un-secured RADIUS protocol access; the RADIUS protocol employs a modicum of cryptography, but if SunScreen SKIP security is also needed, then the preceding simple rule does not suffice.

Other vars for RADIUS Configuration

The following additional variables are pre-installed and used to control the RADIUS client protocol; they are pre-ENABLED and generally need not be altered:.


edit> vars print prg=auth PRG="auth" NAME="RADIUSHolddown" ENABLED VALUE="300" DESCRIPTION="seconds to ignore a non-responsive RADIUS server"

Where the client logic avoids contacting an unresponsive server for this many seconds:.


PRG="auth" NAME="RADIUSRetryPasses"
ENABLED VALUE="3" DESCRIPTION="how many times to try each RADIUS
server"

Where the client logic makes this many passes through the server list before giving up.


PRG="auth" NAME="RADIUSService" ENABLED
VALUE="radius" DESCRIPTION="RADIUS service / port # at which to
query server(s)"

Where the name of the RADIUS server port, as given in the Service registry.


PRG="auth" NAME="RADIUSTimeout" ENABLED
VALUE="5" DESCRIPTION="seconds to await each RADIUS server response"

The amount of time to wait for each response before sending another attempt.

The client logic attempts to contact only servers that have not been held-down during the first pass; subsequent passes contact each server regardless of driving record during the first pass, each server is contacted twice in a row before moving onto the next one. During subsequent passes, each server is only contacted once a rough upper-bound on the overall time for total failure for all servers is:


# servers TIMES (#passes + 1) TIMES timeout

This is an upper-bound because of the way the first pass avoids recently un-responsive servers; a lower-bound would be:


# servers TIMES (#passes - 1) TIMES timeout

So, for example, with two servers configured and the default values, the overall failure timeout would be less than: 2 x (3+1) x 5 = 40 seconds, and greater than: 2 x (3-1) x 5 = 20 seconds

Other RADIUS Protocol Items

The client implementation only attempts to use authentication; it does not ask the server to store any accounting information. The client implementation allows for a single node secret for each Screen. It is theoretically possible to use a distinct node secret for each server; however, this was foregone in favor of configuration simplicity whose resistance to basic limitations in the protocol was traded-off against memory size and computation time.

RADIUS Testing

The client implementation has been tested against a commercial server implementation provided with BSDIs BSD/OS, Version 3.1. This server appears to be derived from the Livingston reference implementation and has been tested against a port of the Livingston reference to Solaris.

Testing is done against Sun Directory Services (SDS) and ACE/Server 3.2 SecurID authentication.

Direct SecurID authentication requires the following:

Command Access to the Screen

Minimum installation is required for any SecurID authentication; this includes usage of SecurID for authenticating Screen administrative users:

ACE/Server Rules

You may find it easier to perform Screen setup without SecurID first, as it adds complexities. Consider that the Screen may be in the path between the ACE/Server primary server and its secondary(ies). These things considered, it is important to create rules that allow the ACE/Servers to communicate with each other: Create an address group to contain the various ACE/Servers addresses. Create a rule that allows them to communicate with each other using the securidprop service.

The following is an example of what you type to create an address group to contain the various ACE/Servers addresses, then create a rule that allows them to communicate with each other using the securidprop service:


# ssadm edit config
edit> add rule securidprop ace-servers ace-servers ALLOW ...

The above rule assumes un-secured communication. The ACE/Server protocol uses its own encryption, but if SunScreen SKIP security is also needed, the above simple rule does not suffice.

If the Screen is in the path between the primary and secondary(ies), you can manipulate rules that can be used to test primary --> secondary fallback.

SunScreen EFS 3.0 ACE/Client Rules

You can allow the ACE/Clients to contact the ACE/Servers to perform the SecurID authentication when configuring ACE/Server rules.

The following is an example of what you type to create another address group to contain the various ACE/Client and ACE/Agent hosts addresses, then create a rule that allows them to communicate with the ACE/Server(s) in the address group created above:


# ssadm edit configedit> add rule securid ace-clients ace-servers ALLOW ...

Again, the above assumes un-secured communication and relies on the variety of forms of encryption within the ACE/Client protocol itself; but if SunScreen SKIP security is also needed, the above simple rule will not suffice.

ACE/Server Setup

Refer to the ACE/Server documentation for the setup required to get a server running.

As part of the server-side configuration, the routing-mode Screen must be configured as a Unix client on the server.

Ensure that you either add alias addresses as needed for all routing-mode interfaces or be certain that the address configured for the routing-mode Screen is the one from which SecurID requests originate toward the ACE/Server.

The result of the server-side setup is an important file named "sdconf.rec." This file contains security information required by the client to enable it to contact the server and to establish communication. Arrange for this file to be available on your system for the client-side setup.

Although it is possible to install ACE/Server on a multi-homed host, such as most SunScreen EFS 3.0 Screens, it is unfortunately not convenient to protect the ACE/Server through direct routing-mode installation.

SecurID Client Setup on a Routing-Mode Screen

To learn about the Screen as a client, see sdconf.rec from the server after it has been configured.

Two possible client mechanisms:

This software is on the CD with the server. Install it per the documented instructions.

The stub files are installed by the SUNWicgSS package:

/opt/SUNWicg/SunScreen/etc/securid_stubclient_setup /opt/SUNWicg/SunScreen/etc/securid_stubclient.tar

Note -

The first file is a script that uses the second file.

Become root in the directory where sdconf.rec resides, execute:


# /opt/SUNWicg/SunScreen/etc/securid_stubclient_setup sdconf.rec

Once the client is installed, be sure to test it.

The first time a new client contacts the ACE/Server, it receives the node secret to allow this first-time exchange.

Note -

The first authentication request must be performed as root.

You also need a SecurID token that is configured for a user and for which user is activated on the routing-mode client. A simple means to test it out is to use the SecurID PIN Server:


	# telnet localhost 3855SunScreen Vx.0 SecurID
PIN and Re-Keying Server

Type the SecurID login: user Type PASSCODE: passcode

Whether the passcode is accepted or access is denied, the client and server have exchanged the node secret.

Note -

If the above interaction receives an error about not being able to establish server communications, ensure that you used the correct login and so forth.

SecurID PIN Server Rules

The procedure SecurID client setup on a routing-mode Screen, leads to the issue of the SecurID PIN Server (when operating in daemon mode, securid functions as a SecurID PIN Server).

The PIN Server is used to allow SecurID token holders to enter into a dialog with the ACE/Server to establish the users PIN.

PIN establishment varies depending on the type of token device options selected on the server, and so forth. They all have in common the need to have a more extensive dialog with the server than a simple password request or response, or even a password, challenge, or response. This dialog is called PIN Dance.

SecurIDs ACE/Client and ACE/Agent software contain programs that contain PIN Dance. These programs are installed in place of normal user login programs and other security hooks on a Unix client system, and enables normal user account protection through SecurID.

The PIN Server is accessed from any reasonable telnet client program (the client must allow connection to an arbitrary server port).

Create Rule(s) to allow access to this server from all hosts, where SecurID token holders are able to perform PIN establishment.

There are security issues to be considered when deciding which hosts should be allowed:

Once you have considered the above issues, the following is an example of what you type to create an address group to contain the various client hosts from which to allow PIN establishment, and what you type to create a rule that allows them to communicate with the Screen:


# ssadm edit configedit> add rule "SecurID PIN" PIN-clients localhost ALLOW ...

SecurID authuser Entities

One or more authuser entities must be configured to use SecurID. The following is an example of what you type to edit the default Screen administrative user to use SecurID authentication:


edit> authuser print admin "admin" ENABLED PASSWORD={
"" CRYPT_PASSWORD="1hp1R.xm.w63Q" ENABLED } DESCRIPTION="(created
by install)" REAL_NAME="SunScreen Administrator (before)

edit> authuser add admin PASSWORD={ "" CRYPT_PASSWORD="1hp1R.xm.w63Q" } SECURID={
screenadm } DESCRIPTION="(created by install)" REAL_NAME="SunScreen Administrator

where screenadm is the login name by the token as known to the ACE/Server. This string is not interpreted by the Screen logic in any way.

Note -

Configuring the Screen to use SecurID administration provides another way for you to, for example, inadvertently make a rule change that breaks SecurID authentication. Therefore, always have at least one last ditch simple password administration account configured.

SecurID now functions on the routing-mode Screen. By creating additional authusers that employ SecurID authentication, mapping them using proxyuser entities, and referring to those proxyusers in proxy rules, SecurID is used to authenticate users of the proxies as well.

SecurID User Authentication Processing Details

SecurID\256 is a one-time password mechanism supplied by Security Dynamics Technologies, Inc. SecurID is a leading form of hardware-based authentication.

SecurID authentication involves three components: a user-held hardware device (token), client software that solicits input from the token-holding user, and server software that verifies the user authentication information supplied by the token-holder through the client software. The client software runs on a variety of standard operating system platforms (those capable of providing user-level security) and other imbedded system applications. The server software runs on a more restricted set of standard operating systems.

The client software portion (when installed on the Solaris operating system) is known by two names: ACE/Client\256 and ACE/Agent\256. Versions of the Security Dynamics offering before v3.2 used the former name, while v3.2 and thereafter use the latter (the renaming reflects an extension of functionality). Regardless of version, the server component is known as ACE/Server\256. ACE/Client or ACE/Agent software from any version 3.x can properly communicate with any ACE/Server v3.x system with a version greater than or equal to it (client version <= server version).

SunScreen EFS 3.0 is compatible with ACE/Server v3.0.1 and greater.

The SunScreen EFS 3.0 product does not include the ACE/Server product, which must be purchased separately.

Typical SecurID authentication involves a hardware device (token) that generates a pseudo-random value. That value is combined with a personal identification number (or PIN) to realize a two-factor authentication scheme. The algorithmic data for computing the pseudo-random value as well as a user's PIN are (idealistically) known only to the token-holder and the ACE/Server. There are several styles of SecurID token device as well as a software implementation, but all operate in basically the same fashion.

In interfacing SecurID to SunScreen EFS 3.0, you are expected to understand the ACE/Agent and ACE/Server implementation to a level sufficient to install and configure the SunScreen EFS 3.0 system as a client of ACE/Server. Further details of the complete SecurID facility, token types, options, and so forth, should be referred to your ACE/Server administrator.

ACE/Client, ACE/Agent, and the SunScreen EFS 3.0 Stub Client

The Security Dynamics ACE/Agent software offering is only supported on SPARC versions of Solaris through version 2.6 (SunOS 5.6). Yet, SunScreen EFS 3.0 is supported on Solaris 2.6 and beyond, and on both SPARC and x86 platforms. To complete the SunScreen EFS 3.0 support matrix, Sun has developed a stub client installation mechanism.

The stub client allows SunScreen EFS 3.0 to be configured with a minimum of information such that it can communicate with an ACE/Server for purposes of authenticating users of SunScreen EFS 3.0-protected resources. The stub client does not provide the full suite of functions available within the ACE/Agent, nor does it supplant the need to purchase and deploy the ACE/Server software and SecurID tokens from Security Dynamics.

In summary, for SecurID support for SunScreen EFS 3.0, if you are installing SunScreen EFS 3.0 on SPARC-based Solaris 2.6, you can choose either the stub client or the complete ACE/Agent installation on the Screen. For SunScreen EFS 3.0 on other platforms or versions of Solaris, you must use the stub client.

The installation of ACE/Agent can be performed prior to or after the installation of SunScreen EFS 3.0. The SecurID stub client configuration step can be performed any time after SunScreen EFS 3.0 installation. SunScreen EFS 3.0 does not require SecurID to function, so it is possible (even recommended) to perform basic installation and configuration of the Screen first and, once running, add SecurID authentication as needed before full-scale deployment.

For purposes of SunScreen EFS 3.0 and its usage of SecurID authentication, it is necessary that the SecurID client software be installed on any Screen(s) that makes use of SecurID authentication. For example, if only users of proxies are authenticated using SecurID, then the client software need only be installed on Screens that run proxy servers. If SecurID is to be used for authentication of SunScreen EFS 3.0 administrators, then the client software must be installed on all Screens. It is not necessary to install SecurID software on the SunScreen EFS 3.0 Administration Station platform (for remote administration), nor on the end-systems of users of SunScreen EFS 3.0-protected resources (for example, proxy clients or backend servers).

The installation of ACE/Agent is not discussed herein, as it is detailed fully in the documentation for that product. One important note regarding ACE/Agent use on SunScreen EFS 3.0 is that it is not necessary to actually create Solaris user accounts on the Screens that are protected by ACE/Agent login mechanisms to enable the authentication of SunScreen EFS 3.0 users by that Screen. (It is certainly permissible and recommended to use ACE/Agent authentication to secure the Solaris platform of a SunScreen EFS 3.0 system in any way deemed important for administration of that system as a Solaris platform; but it is not required to make any changes to the Solaris user configuration to make full use of SecurID within SunScreen EFS 3.0 itself.)

With those notes, all other issues regarding use of SecurID within SunScreen EFS 3.0 are common to both types of client software installation. The following section discusses the stub client.

SecurID Stub Client

Two files required for the SecurID stub client are loaded onto the Solaris system when the SunScreen EFS 3.0 packages are added; they are:

In addition, the stub client installation requires a file that is created on the ACE/Server; this file is called:

The instructions for creating this file are found in the ACE/Server documentation and your ACE/Server administrator must provide this file. sdconf.rec contains addressing information for your ACE/Servers (primary and secondary) as well as cryptographic data that enables the SecurID client to establish secure and authentic communication with the ACE/Server.

When the ACE/Server administrator creates sdconf.rec, you must first inform the server of the SunScreen EFS 3.0 system. The ACE/Server must consider the Screen to be a client, specifically, a UNIX client system. The ACE/Server must also be configured to know the IP addresses of the Screen; it is important that all IP addresses the Screen will use to access the ACE/Server be configured into the server.

Once the above configuration is performed on the ACE/Server and is saved, the sdconf.rec file contains the information needed to run the stub client installation. You must get the sdconf.rec file from your ACE/Server administrator and onto the SunScreen EFS 3.0 system.

To complete the stub client installation, you must be root.

Change into the directory where you loaded sdconf.rec and execute the setup script by typing:


# /opt/SUNWicg/SunScreen/lib/securid_stubclient_setup sdconf.rec

The script creates and deposits a few files into the /opt/ace directory and creates the /etc/sdace.txt file. It also edits /etc/inet/services to add a pair of service definitions required by SecurID.

SecurID Access Paths

The protocol used to communicate between the SecurID client and its server(s) is based on UDP datagrams. This protocol typically uses port 5500, although this can be altered by changing the configuration on all client and ACE/Server systems. Awareness of this port number assignment on SunScreen EFS 3.0 is found in two places:

The protocol is named securid in both locations.

In more robust SecurID configurations, a secondaryACE/Server is configured to serve as a backup to the primary server.

As was previously described, the SecurID client software obtains the IP addresses of the ACE/Servers from the sdconf.rec file during client installation. Additionally, the SunScreen EFS 3.0 policy must contain rules that allow the SecurID client software on the SunScreen EFS 3.0 to access the primary and secondary ACE/Servers. This involves:

For the primary and secondary ACE/Server mode to function, all SecurID clients must be able to access both servers. Additionally, the servers communicate between themselves, using an additional path through a TCP connection, typically on port 5510; again, this can be altered by changing the configuration on both ACE/Servers. Awareness of this port number assignment is found in the same places as that of the UDP datagram securid service; this TCP server-to-server protocol is named securidprop in both locations.

Rules are needed to allow the primary and secondary servers to communicate using securidprop.

SecurID PIN Establishment

Part of the use of SecurID tokens involves the establishment of the personal identification number or PIN. There are a number of variations possible regarding PIN establishment; these are all determined by the choice of SecurID token device and ACE/Server administration policy regarding PIN formulation and mode of establishment.

ACE/Server administrative choice allows the possibility that the token-holder can establish their own PIN. The experienced SecurID user knows that the standard ACE/Agent client software allows token-holder PIN establishment using the shell surrogate program sdshell. SunScreen EFS 3.0 does not require the use of the shell surrogate to use SecurID authentication; this avoids the severe security problems and administrative difficulties that would be associated with creation of user accounts on the Screen for each token-holder. Each token-holder must nevertheless be able to establish their PIN.

The SunScreen EFS 3.0 solution is to provide a daemon process, called the PIN server. This server is started automatically whenever a policy is activated if the Screen has been configured as a SecurID client (either through ACE/Agent or stub client installation). The PIN server normally listens on TCP port 3855 (in the standard installation). This port number assignment is found in:

In /etc/inet/services, it is named securidpin; in the active configuration, it is named SecurID PIN. In the proxy startup script, it is referenced by numeric value.

SecurID token-holders use the PIN server to establish a new PIN as necessary. Access to this server is obtained using a standard telnet client program, specifying the alternative port number (3855). For example, using the Solaris telnet program:


% telnet Screen 3855Trying 1.2.3.4...

Connected to Screen.

Escape character is '^]'.

SunScreen V3.0 SecurID PIN / Re-keying Serve

Enter SecurID login: loginnameEnter PASSCODE: passcode

The interaction is familiar to users of the sdshell and to ACE/Server administrators. Beyond the Enter PASSCODE: prompt, interaction varies depending upon the state of the SecurID token and the PIN options configured for that token on the ACE/Server.

An administrative task that must be performed on the Screen is the addition of policy rules to allow connections to the PIN server from hosts where you feel it is appropriate to allow PIN establishment. For example, you may wish to require PIN establishment to occur only from hosts behind your Screens and from external hosts whose traffic is protected by SKIP encryption.

Typical SecurID Configuration

This section attempts to bring together the various configuration elements described in previous sections with an example setup that illustrates the pertinent details of establishing a working SunScreen EFS 3.0 policy utilizing SecurID authentication.

The example presumes the following pre-existent state:

A standard (non-PINPAD) SecurID token is used, which has been given a login name of ssadmin; that login has been activated on screen on the ACE/Servers; the token has been configured for user establishment of a 4- to 8-digit PIN and is in new-PIN mode.

The overall steps performed are:

The command-line interface (using ssadm commands) is shown here for brevity; however, except for the stub client configuration, all other steps can be performed using equivalent administration GUI operations.

The following is an example of what you type to perform the SecurID stub client configuration (while root in a shell on screen):


# cd /var/tmp# /opt/SUNWicg/SunScreen/lib/securid_stubclient_setup sdconf.rec

The following is an example of what you type to create the registry address objects to describe the ACE/Servers (while logged in to the Screen):


admin% ssadm -r screen edit Initialedit> add address acemaster HOST ....edit> add address aceslave HOST ....edit> add address aceservers GROUP { acemaster aceslave } { } ...edit> save

The following is an example of what you type to continue adding the SecurID client-to-server policy rule:


edit> add rule securid localhost aceservers ALLOW

And to add the ACE/Server server-to-server policy rule:


edit> add rule securidprop aceservers aceservers ALLOW

And the PIN server policy rule (actually, two rules are shown being created, one that allows the end-user SKIP Administration Station to access the PIN server, the other for unencrypted access for inside hosts):


edit> add rule "SecurID PIN" admin localhost SKIP_VERSION_2 remote screen.admin DES-CBC RC4-40 MD5 NONE ALLOW
edit> add rule "SecurID PIN" inside localhost ALLOW

Note -

These rules should be placed early enough in the policy to preempt other conflicting (DENY or less-secure) rules.

Now, augment the standard admin user to allow SecurID authentication (the existing value is first displayed for clarity):


edit> authuser print admin"admin" ENABLED PASSWORD={
"" CRYPT_PASSWORD="1hp1R.xm.w63Q" ENABLED } DESCRIPTION="(created
by install)" REAL_NAME="SunScreen Administrator"

edit> authuser add admin password={ "" crypt_password="1hp1R.xm.w63Q" } securid={ ssadmin } description="updated for either simple password or SecurID" real_name="SunScreen Administrator"

Save and activate the augmented policy:


edit> saveedit> quit% ssadm -r screen activate Initial

Now, perform PIN establishment of the token (from the Administration Station):


% telnet screen 3855Trying 1.2.3.4...

Connected to screen.

Escape character is '^]'.

SunScreen V3.0 SecurID PIN / Re-keying Server

Enter SecurID login: ssadminEnter PASSCODE: 6-digit-passcode-from-tokenNew PIN required; do
you wish to continue? (y/n) [n]: y

Now enter your new PIN, containing 4 to 8 digits, or press Return to
generate a new PIN and display it on the Screen, or end the connection
to cancel the New PIN procedure:

Now enter your new PIN, containing 4 to 8 digits, or press Return to
generate a new PIN and display it on the Screen, or end the connection
to cancel the New PIN procedure:

% 4-digit-PINPlease re-enter new
PIN: 4-digit-PINWait for the code on
your token to change, then connect again with the new PIN

Connection closed by foreign host.

The configuration is now complete. After the code on the token changes (up to one minute later), administrative access to the Screen can be obtained using SecurID. The SunScreen administrative user's name is still admin, but you supply as the password the 4-digit-PIN value (established above) followed immediately by the 6-digit value displayed by the token.

In the example, the simple-text password can also be allowed to establish administrator authenticity.

Other SecurID Details

Use of SecurID authentication by SunScreen EFS 3.0 requires the UDP and TCP protocols and further that the Screen has at least one IP address. This implies that a Screen configured with no routing-mode interfaces cannot use SecurID authentication (as it lacks the ability to speak these protocols).

Caution should be exercised in the deployment of SecurID authentication for protection of SunScreen EFS 3.0 administration (and indeed any other critical SunScreen EFS 3.0-control facility where authentication is required). Because the ability to authenticate using SecurID requires use of policy rules in SunScreen EFS 3.0, it is possible that a mistake in configuring a policy can leave the Screen in a state where SecurID authentication is broken. Additionally, the ACE/Server could be down or inaccessible for other reasons. This can result in an administrative lockout. As a precautionary measure, at least one SunScreen EFS 3.0 administrator should always be configured with ALL access and a simple-text password (perhaps in addition to SecurID).

ACE/Server v3.2 and newer can be hosted on SPARC Solaris 2.6. Because of the additional security features of SunScreen EFS 3.0, it is tempting to install ACE/Server on the SunScreen EFS 3.0. This is a perfectly acceptable deployment, but you are cautioned to understand thoroughly the ramifications of installing ACE/Server on a multi-homed host. There are numerous complexities to be dealt with on an on-going basis if your SunScreen EFS 3.0 does not have a single IP address that can service all queries from other SecurID software components. (See your ACE/Server installation documentation regarding "Multiple Server IP Addresses.")

HTTP proxy

The HTTP proxy only blocks certain types of outbound Web references and content and does not indicate usage to attempt to protect interior Web servers.

Using the HTTP proxy helps implement NAT because it originates all outbound connections to Web servers. It reuses a single IP address for multiple browser clients.

The HTTP proxy configuration is configured on a per-rule basis in the configuration editor to remove cookies (see also the following limitations section); to block Active-X content; to block or allow all Java content (see the following HTTP proxy limitations); and to block SSL content.

The HTTP proxy configuration is configured on a global basis in the configuration editor to verify the list of acceptable signatures and hash values on Java ARchive (JAR) content.

The following is an example of what you type to manage JAR hashes:


edit> jar_hash parameters...

Hashes can be added, deleted, listed, or renamed. They are named; you assign the names, which are strings, ephemerally. They are used only for purposes of reference to items when managing them using the jar_hash command.

Signatures can be added, deleted, listed, or renamed. They are named and you assign the names, which are strings, ephemerally. They are used only for purposes of reference to items when managing them using the jar_sig command.

Both the JAR hashes and signatures are actually stored in the vars database.

Note -

Currently, there is no provision to create Screen-specific versions of these data items.

HTTP Proxy Limitations

The COOKIE restriction simply removes cookies in both directions, rather than refusing requests to set and get them within the HTTP protocol; this behavior often breaks access to pages that are viewable by simply refusing the cookies, which is how today's modern browsers work.

JAR validation facilities acquire the hash and signature values that are added to the configuration.

ACTIVEX filtering currently blocks certain types of Java content and does not support certain types of FTP downloads. It multiplexes and demultiplexes URL references that contain explicit port numbers (for example: http://foo.com:12345/), which is good because without the proxy, and lacking a proper www state engine in the kernel, you must either forgo access to such URLs or allow insecure tcpall outbound from all browser hosts.

The proxy provides the option to allow tcpall from the routing-mode Screen outbound, which, in conjunction with the HTTP proxy, affords access to such URLs through the proxy.

However, the HTTP proxy can also have untoward security problems by permitting client host browsers to gain outbound access to systems and ports for which you did not intend.

For example:


# ssadm edit configedit> add address sensitive1 HOST 222.1.1.1edit> add address sensitive2 HOST 222.1.2.2edit> add address sensitive GROUP { sensitive1 sensitive2 }edit> add address browser HOST 222.1.3.3edit> add address router HOST 222.1.254.254edit> add address qe0 RANGE 222.1.254.0 222.1.254.255edit> add address qe1 RANGE 222.1.1.0 222.1.1.255edit> add address qe2 RANGE 222.1.2.0 222.1.2.255edit> add address qe3 RANGE 222.1.3.0 222.1.3.255edit> add address outside GROUP { } { qe1 qe2 qe3 localhost router }edit> add rule sensitive-stuff sensitive sensitive ALLOWedit> add rule telnet sensitive router ALLOWedit> add rule telnet localhost router ALLOWedit> add rule telnet localhost sensitive ALLOWedit> add rule www browser "*" ALLOW PROXY_HTTP

It appears as if sensitive is well protected, but, in fact, the browser can cause the HTTP proxy to access the telnet service of both router and sensitive.

Including the following rule worsens the configuration situation:


edit> add rule "common services" localhost "*" ALLOW

Such a rule affords browser access to any TCP service in any rule with the source localhost (unless contrary DENY rules are created).

SMTP Proxy

The SMTP proxy provides a minimum of filtering on inbound SMTP mail traffic and does not handle outbound SMTP mail well. Although, it can provide some control over inbound mail with respect to requests for relaying services.

You can, however, consider it to be a first-line of defense against mail spam. Its filtering is restricted to information that is either obtained from the client host or the DNS.

The SMTP configuration can be configured to restrict relaying of inbound mail on a per-rule basis in the configuration editor by specifying a RELAY flag on a rule, all inbound mail is accepted even if a recipient address specifies relaying the absence of the flag (or specifying NO_RELAY) causes the inbound recipients to be checked against a list of allowed relay servers; the default for this list is simply the server of the routing-mode Screen whereon the proxy is running.

Managing the list of allowed relay servers, uses the following command:


edit> mail_relay parameters...

Allowed servers are maintained in a list of unnamed items that can be added, deleted, and listed.

Managing the list of spam servers, uses the following command:


edit> mail_spam parameters...

spam servers are maintained in a list of unnamed items that can be added, deleted, and listed.

Currently, there is no way to create Screen-specific versions of these data items.

SMTP Mail Handling

Mail is relayed from any source address specified in the source of a rule to the first destination in the rule that accepts the connection. The order for contacting actual inside SMTP servers (for destinations with multiple addresses) is IP-numerical order (lowest-numbered host first). If more precise ordering is needed, create multiple rules.

SMTP Proxy Filtering

When the relay flag is not set on a rule, each recipient mailbox name is checked against a list of allowed servers on which to perform relaying of inbound mail server name matching.