test

SunScreen EFS Release 3.0 Reference Manual

Chapter 5 Proxies

A proxy is a user-level application that runs on the Screen. The main purpose of proxies is to provide content filtering (for example, allow or deny Java applets) and user authentication.

SunScreen EFS 3.0 lets you set up proxies for FTP, HTTP, SMTP, and telnet traffic protocols. Although each proxy has different filtering capabilities and requirements, you can allow or deny sessions based on source or destination addresses of packets. Proxies share common objects and policy rule files. To start a proxy, you set up rules for a proxy in your security policy and activate the policy.

Use of these proxies does not require installation of any additional client or server system software. However, some changes may be required in system configurations or user-supplied commands to access protected destinations through the proxies.

The script checks to see if the policy being activated contains one or more rules that utilize a given proxy. If so, the corresponding proxy is automatically started. If this same script determines that the Screen has been configured as a SecurID\256 client, then the SecurID PIN server is started as well.

The following diagram shows a Screen using a proxy to filter packets for the HTTP protocol.

Figure 5-1 Screen With a Proxy

Graphic

How Proxies Work

Each proxy is a multi-threaded program provided with SunScreen EFS 3.0. Each is configured through common objects and policy rules. A particular proxy is initiated or reconfigured whenever a policy is activated that contains rules that specify its type of access regulation.

Note -

SunScreen EFS 3.0 proxies require the facilities of TCP and UDP internet protocols. As such, only Screens with at least one routing-mode (IP-address-bearing) interface can provide proxy services.

Policy Rule Matching

Each proxy is interposed in the middle of rules that reference it by the rule compilation process. In proxy rules, as in other Screen rules, you refer to originating client and destination (or backend) server address objects, not the Screen itself.

Note -

The Screen rule compilation process actually produces two sub-rules for each proxy-use rule; one that allows client access to the proxy server program, and the other that allows the proxy server program to access the backend server(s). You do not see these rules as they are hidden but effect a similar kernel-based stateful filtering mechanism to other rules for the Screen. The proxies themselves employ the original proxy-use rules for their own, more detailed, access control mechanisms.

In addition to stateful packet filtering within the Screen kernel, each proxy performs additional rule processing to control access. The additional checking enforces end-to-end (client-to-server) address and service matching, as well as user authentication, command restriction, and content filtering as may be configured.

The general flow of the rule that tests each proxy applies to access requests for FTP and telnet proxies is, has the user been properly authenticated?

Note -

User authentication occurs only once, regardless of the number of rules configured. Authentication is based upon the user identity and accompanying passwords (if any) supplied by interaction with the client host. See the section entitled "User Authentication."

Then, for each rule configured for a particular proxy:

  1. Is the requested service port one handled by the proxy?

This check is rather trivial, as the proxy only receives connection requests for the port(s) on which it is configured to listen.)

  1. Is the address of the client contained in the set of source addresses for the policy rule?

  2. Is the address of the backend server (if applicable) in the set of destination addresses for the policy rule?

  3. For HTTP URL references with specific port numbers -- is the target service port allowed by the proxy?

  4. For FTP or telnet proxies -- Is the authenticated user a member of the GROUP proxy user specified in the rule?

As with other Screen rules, these tests are performed in the order in which they appear within the policy. The first rule that matches all tested criteria takes effect with respect to any incoming request for a proxy-provided service. If no rule is found that matches all (applicable) criteria, the requested access is denied.

Proxy User Authentication

The FTP and telnet proxies of SunScreen EFS 3.0 provide the ability to restrict access to users who can verify their authenticity.

User authentication mechanisms of SunScreen EFS 3.0 are described in detail in a subsequent major section "User Authentication." In this section, the discussion is prefaced by notes that pertain especially to how these user mechanisms are employed by the proxies.

The goals of user authentication within a proxy are to:

A side-effect of the establishment of an authentic user is a collateral mapping to a backend user identity. This identity is a string that is supplied (by the FTP proxy) as the user of the backend server (for example: a users userid on Solaris).

The second goal is achieved during the rule matching steps previously described. A rule that references the authentic Proxy User itself, or that references a GROUP Proxy User that contains an ENABLED member reference to that authentic Proxy User causes a successful user match.

Proxy Limitations

Proxy implementation in SunScreen EFS 3.0 has the following limitations:

FTP Proxy

The FTP proxy functions as a relay for the File Transfer Protocol to let you control connections based upon source and destination addresses and user authentication. It can also limit access to certain file transfer commands, such as put and get, based on source or destination addresses and user authentication.

You can configure the FTP proxy to ask for user authentication as an additional mechanism for controlling access to sites and commands.

FTP Proxy Operation

When the FTP proxy starts, it reads its policy files and then listens on the standard FTP port (21) for connections. When a connection is made, the FTP proxy starts a new thread to handle the connection, and the main thread returns to listening for other connections.

The child thread generates an FTP login banner and asks for a user name/password pair. The user name format is proxyuser@server. The password format is proxypass@serverpass, where proxypass is the password for the proxy, and serverpass is the password for the destination FTP server.

The FTP proxy validates the proxyuser name using proxypass as was described previously. The hostname (backend server), given in the USER command after the first @ character, is translated to its IP address(es) using the hostname-to-address translation mechanism configured for and in the context of the FTP proxy. The resulting addresses provide the values to use as matching criteria for the destination addresses in the proxy rules.

The standard proxy rule matching (given above in the section "Policy Rule Matching") is employed. If a match is found, a connection is established to the FTP server of the user-requested destination (if multiple addresses result from the translation of the user-specified backend server, they are each tried in the order yielded by the name translation mechanism (for example, DNS)).

Once a connection to the backend server is established, the proxy attempts to login using the backend username generated during authentication and using serverpass as the password (see "Proxy User Authentication" above). Once the backend user identity is established, commands that are allowed by flags associated with the policy rule in use are relayed, results returned, and files exchanged.

The following example illustrates a session between an FTP connection to a target host (ftp.cdrom.com) using anonymous FTP.


#ftp screen
Connected to screen
220- Proxy: SunScreen FTP Proxy Version 2.0
	:Username to be given as proxy-user@FTP-server
	:Password to be given as proxy-pass@FTP-server-pass
220 Ready
Name (screen:edison): anonymous@ftp.cdrom.com
331-Proxy: Authenticate and connect
331 Password needed to authenticate anonymous.
Password:
	:Authentication mapped anonymous to backend user anonymous
	:Connecting to ftp.cdrom.com (165.113.121.81) - done
Server: 220 wcarchive.cdrom.com FTP server (Version 2.0) ready
Proxy: Login on server as anonymous
Server: 331 Guest login OK, send your email address as password
Proxy: Supplying password to server
230-Server:
230-Welcome to wcarchive - home ftp site for Walnut Creek CD-ROM
230-There are currently 2273 users out of 2750 possible
230 Guest login OK, access restrictions apply

FTP Proxy and Anonymous FTP

The proxy user anonymous is configured during the installation process as an unauthenticated proxy user. As such, any string provided before the first @ in the password is ignored. The password after the first @ in the password sequence (that is, edison@carter.com) is the backend user password, which, for anonymous FTP, is traditionally the users email address.

FTP Proxy Use

To use the proxy and make FTP connections, the user must open an FTP connection to the Screen (as shown in the preceding example) rather than open a direct connection to the end system. The Screens policy rules only allow FTP connections to and from the FTP proxy.

Other FTP Proxy Issues

The FTP proxy does not permit the PASV command (used for third-party transfers).

The FTP proxy employs a 10 minute timeout on the control connection for user requests. Its idle allows backend server responses two minutes to arrive before timing out.

The maximum number of concurrent sessions available in the FTP proxy daemon is configurable through the variable N_Sessions.

It contains the following items:

As initially-installed, a global version of this variable is created that restricts the number of concurrent sessions to 100.

The following is an example of what you type to display this (initial) variable while logged in to the primary Screen:


admin% ssadm -r primary edit Initial
edit> vars print prg=ftpp name=N_Sessions
PRG="ftpp" NAME="N_Sessions" ENABLED VALUE="100" DESCRIPTION="limit # of concurrent sessions, FTP proxy"

You may wish to alter this number of sessions, perhaps to be more restrictive on a particular Screen.

The following is an example of what you type to do this while logged in to the primary Screen:


edit> vars add sys=Screen prg=httpp name=N_Sessions value=66 description="limit # of concurrent sessions on the Screen FTP proxy"
edit> quit

By configuring the FTP proxy on a Screen, the actual FTP service into that system becomes unavailable. To avoid confusion, define the destination address of proxy rules so as to exclude all of your Screen(s) addresses. (You can still FTP out of the Screen, as necessary.)

HTTP Proxy

The HTTP proxy provides a relay capability for HTTP access to the World Wide Web. This relay supports HTTP and the Secure Sockets Layer (SSL). The HTTP proxy allows or denies sessions based on the source and destination addresses. Additionally, the HTTP proxy provides selective filtering of HTTP content, such as Java applets, ActiveX, and cookies, based on the source and destination addresses for sessions. Finally, the HTTP proxy can filter Java applets based on the signatures encapsulated in Java Archive (JAR) files attached to the applet or based on a precomputed hash of valid applets.

To use the HTTP proxy, define the source addresses that should be allowed to access the proxy and the destination addresses of allowed Web servers to be contacted. To create the HTTP proxy rule, use the built-in service www, reference your desired source and destination addresses, and select the PROXY for PROXY_HTTP during rule definition (in the administration GUI) or the PROXY_HTTP keyword (for command-line rule creation).

The HTTP proxy allows further restrictions based on target port numbers. HTTP provides for user-specified references to arbitrary port numbers using the http://host:port/... construction. Because of the way in which the Screen operates, client browsers can be inadvertently allowed to access services that would otherwise be restricted save this feature of HTTP.

The port restriction mechanism for the SunScreen EFS 3.0 HTTP proxy is controlled by the variable TargetSvcs. This variable can either be global or Screen-specific. It contains the following items:

As initially-installed, a global version of this variable is created that restricts such access to port 80 (the www service).

The following is an example of what you type to display this (initial) variable while logged into the primary Screen:


admin% ssadm -r primary edit Initial
edit> vars print prg=httpp name=TargetSvcs
PRG="httpp" NAME="TargetSvcs" ENABLED VALUES={ svc="www" } DESCRIPTION="target TCP ports that the HTTP proxy can get to"

You may wish to be able to access a wider range of ports in their URLs. One such configuration is obtained by configuring a new service object and an added variable (for example, this time, for a particular Screen) Again, the following is an example of what you type while logged in to the primary Screen: 


admin% ssadm -r primary edit Initial
edit> add service www-targets SINGLE FORWARD "tcp" PORT 1024-1520 PORT 1522-3850 PORT 3856-5999 PORT 6064-65545 COMMENT "more TCP port numbers to allow as targets in HTTP proxy URIs"
edit> vars add sys=screen prg=httpp name=TargetSvcs values={ svc=ssl svc=www svc=www-targets } description="target TCP ports that the HTTP proxy can get to"
edit> save
edit> quit

Note -

The above definitions prevent access to ports that are below 1024 except for www and ssl. It also prevents access to port 1521 (SQLNET), ports 3851-3855 (the Screens administrative and SecurID PIN server ports), and ports 6000-6063 (used by X windows). Tailor your restrictions to suit your security needs.

The SunScreen EFS 3.0 HTTP proxy can also be configured to restrict Web content to be allowed through. Content can be blocked or allowed, or it can be configured to verify certain content (Java applets) based on digital signatures or hashes. These content-filtering features are configured as part of the rules employing the HTTP proxy.

HTTP Proxy Operation

When the HTTP proxy starts, it reads its policy files, starts a Java Virtual Machine (JVM) for processing JAR files, and then listens on the standard HTTP port (80) for connections. When a connection is made, the HTTP proxy starts a new thread to handle the connection, and the main thread resumes listening.

The child thread reads the first line of the HTTP header request from the client and parses the actual destination address. It then searches the proxy policy rules for a match on the source and destination addresses.

After all of the data has been passed to the client, the proxy closes the connections to the client and the server and terminates the thread.

SMTP Proxy

The SMTP proxy provides a basic level of control over incoming electronic mail that is based on the Simple Mail Transport Protocol (SMTP). It can be configured to allow or deny such email based on source addresses, the actual server name of the source host, or the server name of the (claimed) originator of a message. It can be further configured to allow or deny relaying of email based on the destined host or server of a message.

SMTP Proxy Operation

When the SMTP proxy starts, it reads its policy files, determines its local server name for use in relay checking, and listens on the standard SMTP port (25) for connections. When a connection is made, the SMTP proxy starts a new thread to handle the connection, and the main thread resumes listening.

The child thread takes control of the connection from the client. It then attempts to reverse-translate the address of the client (from the connection state) to yield a registered name.

If a registered name is discovered, then the suffixes in the mail_spam list are checked against that name. If a suffix matches (the end of) the name of the originating host, the connection is closed with a response (455) refusing reception.

If no name is registered for the address, then the address itself is sought in the mail_spam list (looking for items that contain single or range IP addresses). If a match is found, the connection is closed with a response (455) refusing reception.

Having passed the peer-address check, the proxy thread next attempts the typical proxy rule match steps (given earlier), except that only the source address is checked. For each rule that matches, an SMTP connection is attempted to the MTAs listed as destination for the rule.

Spam Control

Unsolicited electronic mail is colloquially-known as spam. In SunScreen EFS 3.0, the restriction of mail based on originator is known as spam control. The SMTP proxy provides the ability to define a list of one or more restrictors that operate based on either server name (suffix) or non-server (address range) criteria.

Spam restrictors have one of two syntactic forms:

server suffix (suffix in a named host), or

start address [.. end address] (range of one or more IP addresses of unnamed hosts)

server suffix is simply an ASCII character string.

See the section below entitled "SMTP Proxy Operation" for details regarding how these restrictors are used.

Spam restrictors are defined using the command-line interface, and the mail_spam sub-command of ssadm edit in the administration GUI.

The following is an example of what you type to display the current set of spam restrictors while logged in to the primary Screen:


admin% ssadm -r primary edit Initial
edit> mail_spam list
"total-nonsense.org"
"0.0.0.0..255.255.255.255"

The above example listing shows two entries, one to refuse email from the server total-nonsense.org, the other to refuse mail from any host that does not have a registered server name (in a reverse-mapping of IP address to DNS name).

The following is an example of what you type to add an additional restriction while logged in to the primary Screen:


edit> mail_spam add complete-spam.net
edit> quit

The mail_spam restrictors are stored in the database used by the vars variables. It is not necessary to type save before quit like above if only authuser, proxyuser, logmacro, or vars entities have been altered. If you attempt to save without changing entities other than these types, you are reminded by a message:

edit> save

lock not held

failed (status 244)

This is a non-fatal message in this situation; you can simply quit the configuration editor at this point.

Once changes have been made to spam restrictors, the current policy must be (re)activated to install the new objects and to propagate these changes to secondary Screens.

The following is an example of what you type to remove a restriction while logged in to the primary Screen:


edit> mail_spam delete lite-spam.com

From the command line, in addition to controlling incoming spam destined for your site, another important area of control over email is the limitation on accepting email and then relaying it to another location. Relayed mail is responsible for a great deal of the unsolicited email on the Internet. Improper relaying makes spam harder to defeat and leaves the relaying site open to various types of reprisal from the ultimate recipient-victims.

The SMTP proxy allows the configuration of a set of strings that, coupled policy rules, allows you to restrict which destination domains are accepted by the proxy.

Relay restrictions have one of two syntactic forms:

domain suffix (suffix in recipients to allow)

or

!'domain suffix (suffix in recipients to disallow)

domain suffix is simply an ASCII character string.

See the section below entitled "SMTP Proxy Operation" for details regarding how these restrictors are used.

Relay restrictors are defined using the command-line interface, through the mail_relay sub-command of ssadm edit. The following is an example of what you type to display the current set of relay restrictors (while logged into the primary Screen):


admin% ssadm -r master edit Registryedit> mail_relay list"your-domain.com" 

"!private.your-domain.com"

The above (example) listing shows two entries, one to set a base domain to allow in recipients, the other to block a private sub-domain in recipients.

The following is an example of what you type to add an additional restriction (while logged into the primary Screen):


edit> mail_relay add !lists.your-domain.comedit> quit

Note -

The mail_relay restrictors are really stored in the database used by the vars variables. It is not necessary to enter save before quit above if only authuser, proxyuser, logmacro, or vars entities have been altered. If you attempt to save without changing entities other than these types, you will be reminded by a message:


edit> savelock not held

failed (status 244)

This is a non-fatal message in this situation; you can simply quit the configuration editor at this point.

Once changes have been made to relay restrictors, the current policy must be (re)activated to install the new objects and to propagate these changes to secondary Screens.

The following is an example of what you type to remove a restriction (while logged into the primary Screen), type:


edit> mail_relay delete !test.your-domain.com

Note -

If relay checking is enabled (for example, NO_RELAY) and yet no relay restrictors are configured, the SMTP proxy defaults to allow only the domain configured for the Screen itself as the valid domain for inbound mail.

The SMTP proxy rules should use the smtp service, and specify the PROXY to be PROXY_SMTP during rule definition in the administration GUI. (Or the PROXY_SMTP keyword (for command-line rule creation). The RELAY (or NO_RELAY) flag is used to specify whether to perform unrestricted versus restricted relaying of mail (use NO_RELAY in conjunction with the mail_relay restrictors shown above to effect relay control).

The following is an example of what you type, presuming that you already have the following objects defined:


admin% ssadm -r primary edit Initialedit> list address "mta-primary" HOST
1.2.3.4 ...

"mta-secondary" HOST 1.2.3.5 ...

"outside" GROUP { } { inside } ...

The following is an example of what you type to define an address group to contain all inside MTAs:


edit> add address mtas GROUP { mta-primary
mta-secondary } { ...

The following is an example of what you type to define relay restrictors to specify the servers (and perhaps hosts) to be allowed in recipient mailbox names:


edit> mail_relay add prime-server.com
edit> mail_relay add other-server.com
edit> mail_relay add !lists.prime-server.com
edit> mail_relay add !private.other-server.com

The following is an example of what you type to define spam restrictors to deny mail from some mail originators you know to be sources of unsolicited mail:


edit> mail_spam add 0.0.0.0..255.255.255.255
edit> mail_spam add dialups.naughty-isp.net

Finally, the following is an example of what you type to define a rule to cause inbound email to pass through the SMTP proxy:


edit> add rule smtp outside mtas ALLOW PROXY_SMTP NO_RELAY
edit> save
edit> quit

Note -

Because of the way that SunScreen EFS 3.0 represents addresses (in numerical order by IP address), rules that refer to multiple destination addresses give rise to attempting the MTA connection in numerical order. To obtain finer control over MTA connection ordering, use multiple rules.

Once a connection is established to a willing backend MTA, the proxy thread begins watching information passed by the client to the server (ordinarily, the proxy does not talk to the client). The proxy looks for a MAIL FROM: command from the client. (This command gives the name of the user who originated the message. It is often abused by spam message creators, so its use is often untrustworthy.) The mailbox name in this command is compared with the suffixes in the mail_spam list and if found there, the connection is aborted with a response (455) refusing reception.

Next, the proxy thread looks for one or more RCPT TO: commands from the client. (Such commands give one of the destination mailboxes to which the message is directed. Unlike the MAIL FROM: command, this mailbox name is *always* a real recipient.) If the rule specifies NO_RELAY, then the mailbox names in these commands are compared against the mail_relay list. The search can be conceptually thought of as a two-pass search. On the first pass, any denial suffixes (ones beginning with !) are sought and, if matched cause connection abort with a response (454) refusing reception. On the second pass, allowance suffixes are sought (ones not beginning with !); if one matches, the recipient is allowed, if none matches, the connection is aborted with a response (454) refusing reception.

SMTP is designed to allow multiple messages (each with one or more recipients) to pass on a single connection. Barring a refusal of service, once all messages have been passed, the proxy closes the connection to the client and backend server and ends the child thread.

Other Mail Configuration Issues

In addition to specifying SunScreen EFS 3.0 SMTP proxy policy, configuration steps must be taken to cause SMTP-based email to arrive at the proxy for delivery to the servers it is to represent. The typical mechanism is to create MX records in the server Name System for those servers. The procedure for altering DNS configuration is outside the scope of this document but should be very familiar to your DNS administrator.

More than one Screen can be configured to operate in parallel to service incoming mail. The multiple Screen management features of SunScreen EFS 3.0 make doing so a relatively straightforward task. These parallel Screens can then be used within MX records.

By configuring the SMTP proxy on a Screen, the actual SMTP (inbound email) service into that system becomes unavailable. (You can still send email out of the Screen, as necessary.)

SMTP Proxy Rules

After configuring the content filtering, the final step is to create one or more rules that actually allow SMTP-based email to be served. A typical configuration often allows outside email to be filtered through the proxy to one or more inside mail transfer agents (MTAs) such as Solaris mail servers.

The source address for SMTP proxy rules should allow mail from any potential mail-sending address. Restrictions on source addresses in the rule can be useful in blocking entirely-abusive mail-originating sites that are stationary with respect to IP addressing.

The destination address for SMTP proxy rules should contain the addresses of one or more MTAs to which the proxy will connect to actually store and forward the incoming email.

telnet Proxy

The telnet proxy provides a virtual terminal relay. It allows or denies connections based on source and destination addresses. The telnet proxy can ask for user authentication as an additional mechanism for controlling access to sites and commands. The telnet proxy does not support content filtering.

To authenticate users, the telnet proxy can request a user name from a user and, based upon the type of authentication for that user name, request and validate a reusable password or digital token.

telnet Proxy Operation

When the telnet proxy starts, it reads its policy files and listens on the standard telnet port (23) for connections. When a connection is made, the telnet proxy starts a new thread to handle the connection, and the main thread returns to listening.

The child thread generates a proxy login banner and waits to read the user name and password. The format for user names consists of a login ID and a destination host separated by an @ symbol; for example, lionel@manduck.bafb.af.mil. The telnet proxy validates the user name/password. If an invalid user name/password are sent, the telnet proxy sends an error to the user and closes the connection. If the user name/password are valid, then the source and destination addresses are checked against the Screens policy rules. If a match is found, the flags associated with that policy rule are checked. If the connection is permitted, the telnet proxy opens a connection to the actual destination server and relays data between the source host and the destination host.

The hostname (backend server) given in the user prompt, after the @ character, is translated to its IP address(es) using the hostname-to-address translation mechanism configured for and in the context of the telnet proxy. The resulting addresses provide the values to use as matching criteria for the destination addresses in the proxy rules.

The standard proxy rule matching (shown in the section, "Policy Rule Matching") is employed. If a match is found, a connection is established to the telnet server of the user-requested destination (if multiple addresses result from the translation of the user-specified backend server, they are each tried in the order yielded by the name translation mechanism (for example, DNS)). Once a connection to the backend server is established, all data is relayed (uninspected) by the thread in both directions until either end terminates.

Other telnet Proxy Issues

The telnet proxy utilizes TCP keep-alives on the connection to the client. The telnet proxy insists on doing its own echoing during the initial user authentication portion of the session. Some telnet client programs do not obey standard telnet echo negotiation and improperly double-echos username/hostname input and single-echos the password.

Note -

By configuring the telnet proxy on a Screen, the actual telnet service into that system becomes unavailable. To avoid confusion, define the destination address of proxy rules so as to exclude all of your Screen(s) addresses. (You can still use the rlogin protocol to access the Screen, as necessary, as well as being able to telnet out.)

telnet Proxy Use

Before a client can connect to a remote host when the telnet proxy is active, the client must first connect to the telnet proxy. In the following example, the telnet proxy is running on the host Screen, and the user wants to connect to the remote system foo.com.


riyal% telnet Screen
SunScreen telnet Proxy Version: 2.0
Username@Hostname: edison@foo.com

At the password prompt, you type the password for the proxy authentication. The telnet proxy would compare the specified user name and password to the list of valid proxy users and their passwords. If the user name/password are correct and the connection is allowed, the user is presented with a login banner for the machine foo.com.

You can have the Screen decrypt incoming traffic from a client before passing it to the proxy. It requires two rules. The following is an example of using the telnet proxy with SunScreen SKIP:


edit> add rule telnet proxyclient localhost SKIP_VERSION_2 ...edit> add rule telnet proxyclient proxyserver PROXY_TELNET

Likewise, you can have the Screen encrypt the connection from the proxy to the backend server using a similar pair of rules:


edit> add rule telnet localhost proxyserver SKIP_VERSION_2 ...edit> add rule telnet proxyclient proxyserver PROXY_TELNET

User Authentication

SunScreen EFS 3.0 provides the ability to configure user entities. These entities are used to authenticate administrators of Screens and to allow access through the Screen when using proxied services.

Authentication provides the ability to verify the identity of users. The user facilities of SunScreen EFS 3.0 employ both internal and external means of proving user identity. Further, user entities can be configured in various ways depending on the role or roles they are to play with respect to SunScreen EFS 3.0 administration and use.

SunScreen EFS 3.0 proxies provide a means to validate, regulate, and extend the abilities of certain services beyond those afforded by kernel-based stateful packet filtering.

SunScreen EFS 3.0 User Model

The SunScreen EFS 3.0 user model provides two levels of user identification. These are the Authorized User (abbreviated authuser) and the Proxy User (abbreviated proxyuser).

Authorized Users

The Authorized User is represented as a named common object. Each such object is intended to describe an individual human user distinct from all others. The attributes of an Authorized User provide a repository for demographic and authentication data about that individual.

Authorized User objects contain information sufficient to allow authentication of users of SunScreen EFS 3.0. Validation information can either be: (1) simple text password or (2) SecurID(R) token PASSCODE; users can also be configured to have both means of authentication.

Access to and use of the administrative functions of SunScreen EFS 3.0 require the establishment of the Authorized User identity before administration is allowed. Both the Login Screen of the administration GUI and the login sub-command of the ssadm command line facility reference an Authorized User object.

Authorized User authenticity establishes only the identity of a user, but does not itself describe any of the various roles a user can play in use of SunScreen EFS 3.0. Role establishment is afforded in one of two ways: (1) reference within the User field in the administrative access rules of a policy, (2) reference from a packet filtering rule that utilizes user authentication (proxies).

Proxy Users

The Proxy User is a named common object, and is distinct from the Authorized User. Proxy Users are either SIMPLE or GROUP objects. A SIMPLE object is used to provide for and establish an association between an individual human and a role that human plays in usage of the facilities controlled by SunScreen EFS 3.0. GROUP objects are used to allow creation of collections of SIMPLE Proxy Users that share common access to facilities; GROUPs streamline the task of allowing or removing access to established facilities.

Some special Proxy User objects also provide the means to map external collections of users into the access control facilities of SunScreen EFS 3.0. In SunScreen EFS 3.0, external access to SecurID(R) users and RADIUS users is provided. (Access to other external user databases is afforded using RADIUS as an intermediary agent. For example, access to LDAP user databases stored through Sun Directory Services (SDS) are accessible through RADIUS.)

The following diagram summarizes the relationship between Rules, Authorized Users, Proxy Users, and external user databases:

Graphic

The names of Authorized Users and Proxy Users are distinct, and it is perfectly allowable to have objects with identical names in each. You should choose a naming strategy for each set that best reflects the naming systems already employed. For example, you can choose to name Authorized Users by employee identities (distinguished names, employee numbers, etc.) and Proxy Users by names that reflect their normal user login names deployed on server systems (for example: Unix login name). Names cannot contain any of the following characters:

"!", "#", "$", "%", "^", "&", "*", "{", "}", "[", "]", "<", ">", """, "', "?", "`", "/", "@", or NUL characters.

Space, tab, and other whitespace characters are allowed in names, but in doing so you should be prepared to supply quotation marks in some situations in order to protect such whitespace within names.

Note -

In examples, the names of Authorized Users, Proxy Users, and other user naming items are often deliberately chosen to be different for purposes of clarity and illustration.

Authorized User Object Definition

The Authorized User and Proxy User objects can be created and managed by both the administration GUI and the command line interface. The administration GUI pages that manipulate these objects have already been elaborated in the administration GUI chapter. This section describes the attributes of these objects and their manipulation using the command line.

The Authorized User object contains the following items:

The password= and securid= items define authentication methods for the Authorized User.

The password= item has the following sub-items:

"passwd"-- the plain-text password string; should either be empty (for example, "") or contains a one to eight character password; if this field is non-empty, then the next sub-item (crypt_password=) should not occur.

crypt_password="cryptpasswd" -- (optional) the encrypted version of the plain-text password string; if this sub-item is present, then the plain-text password string (above) should be empty enabled | disabled enablement flag for this simple-text password authentication method; if disabled, any password presented for authentication of this user is not compared against this sub-item; the default is enabled.

Note -

The processing of passwd and crypt_password= sub-items is special. When an Authorized User object is first created (or whenever a new password is set for that user), the password can be presented in plain-text using the (non-empty) passwd sub-item. Thereafter (for example, whenever the object is edited), the crypt_passwd= sub-item can be used to retain a password without having to know (or retype) the plain-text form. The encryption method used for these objects is identical to that used by Solaris to encrypt user passwords (those stored in /etc/shadow). This provides the ability to clone encrypted passwords from Solaris to SunScreen EFS 3.0 user descriptions without the SunScreen EFS 3.0 administrator needing to know the users plain-text passwords. This fact also means that the content of the SunScreen EFS 3.0 Authorized User database is maintained with file permissions that prevent access from all but root users of the SunScreen EFS 3.0.

The securid= item has the following sub-items:

"securidname" -- User login name associated with this users SecurID token in the ACE/Server database enabled | disabled enablement flag for this SecurID authentication method; if disabled, any password presented for authentication of this user is not be submitted to the ACE/Server; the default is enabled.

Note -

If both simple-text and SecurID methods exist in a single Authorized User object, the simple-text method should be presented first.

Authorized User Object Creation

The Authorized User object is manipulated using the authuser sub-command of ssadm edit. authuser takes one of the following verbs:

add "name" item... -- creates or overwrites an object; takes a complete description of the object, beginning with its name, followed by desired items and sub-items as defined above.

delete "name"-- deletes a named object

print[,sortopt] ["name"]-- display one or more objects; if an object name is given, then only that objects definition is displayed; otherwise all Authorized User objects are displayed

sortopt can be:

names [,sortopt]-- display the names of all objects sortopt can be:

The following is an example of what you type to display an existing Authorized User object while logged into the primary Screen:


admin% ssadm -r primary edit Initialedit> authuser print jeff.hogg"jeff.hogg" ENABLED
PASSWORD={ "" CRYPT_PASSWORD="s8Q2DZRw4tmGk" ENABLED }
DESCRIPTION="large and in charge" REAL_NAME="Jeff
Hogg"

admin% ssadm -r primary edit Initialedit> authuser print jeff.hogg
"jeff.hogg" ENABLED
PASSWORD={ "" CRYPT_PASSWORD="s8Q2DZRw4tmGk" ENABLED
} DESCRIPTION="large and in charge" REAL_NAME="Jeff
Hogg"

Note -

Although the output produced by print surrounds the value of each item in double quotes, these are only necessary on input to protect embedded spaces within the values of items, or to preserve null items.

Also, although print outputs all tag names in capital letters (for example, REAL_NAME=), these tags are recognized in a case-insensitive manner on input (for example, real_name= and REAL_NAME= are equivalent.)

Note -

Because of the way in which passwords are encrypted, it is unlikely that any add operation will yield a particular crypt_password= encoding of any given plain-text password. In fact, there are 4096 different encryptions of any given plain-text password.

The following is an example of what you type to create the above Authorized User object while logged into the primary Screen:


admin% ssadm -r primary edit Initialedit> authuser add jeff.hogg password={ "4flash" } description="large and in charge" real_name="Jeff Hogg"edit> quit

This shows creation of the object by supplying the simple-text password in the plain-text form.

An alternate means of (re)creating the above Authorized User object, while logged in to the primary Screen:


admin% ssadm -r primary edit Initialedit> authuser add jeff.hogg password={ "" crypt_password="s8Q2DZRw4tmGk" } description="large and in charge" real_name="Jeff Hogg"edit> quit

Note -

This shows creation of the object by supplying the simple-text password in its already encrypted form.

Tip -

It is not necessary to type save before quit above if only authuser, proxyuser, logmacro, or vars entities have been altered.

If you attempt to save without changing entities other than these types, you are reminded by a message:


edit> savelock not held

failed (status 244)

This is a non-fatal message in this situation; you can simply quit the configuration editor at this point.

Note -

See Chapter 3, "Administration Graphical User Interface Reference" for more information regarding which common objects do not require the use of save.

Once changes have been made to Authorized User objects, the system configuration must be (re)activated to install the new objects and to propagate these changes to secondary Screens.

In each of the above add operations, the (two) enablement items have been allowed to default to enabled.

The following is an example of what you type to re-create the above Authorized User object but causing it to be disabled, while logged into the primary Screen:


admin% ssadm -r primary edit Initial
edit> authuser add jeff.hogg disabled password={ "" crypt_password="s8Q2DZRw4tmGk" } description="large and in charge" real_name="Jeff Hogg"

The following is an example of what you type to create an Authorized User object defining a SecurID authentication method, while logged into the primary Screen:


admin% ssadm -r primary edit Initial
edit> authuser add jeff.hogg securid={ "jeffh" } description="large and in charge" real_name="Jeff Hogg"

The following is an example of what you type to create an Authorized User object defining both simple-text password and SecurID authentication methods, while logged into the primary Screen:


admin% ssadm -r primary edit Initialedit> authuser add jeff.hogg password={ "" crypt_password="s8Q2DZRw4tmGk" } securid={ "jeffh" } description="large and in charge" real_name="Jeff Hogg"

The following is an example of what you type to display all Authorized User objects, while logged into the primary Screen:


admin% ssadm -r primary edit Initialedit> authuser print

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

"jeff.hogg" ENABLED SECURID={ "jeffh" ENABLED } DESCRIPTION="large and in charge" REAL_NAME="Jeff Hogg"

The following is an example of what you type to display the names of all Authorized User objects, while logged into the primary Screen:


admin% ssadm -r primary edit Initialedit> authuser names,raw"jeff.hogg"

"admin"

Authorized User Authentication Processing Logic

Authentication processing is performed in the order of authentication methods in the Authorized User object.

First, if the Authorized User object itself is disabled, then, authentication fails.

Second, if the simple-text password method exists and is enabled, then the password supplied is encrypted and compared against the one stored in the method sub-item; if equal, then authentication succeeds.

Third, if the SecurID method exists, is enabled, and the password presented appears to be a possible SecurID PASSCODE (that is, ends in 6 decimal digits), then it is submitted to the ACE/Server along with the securidname for the method; if the ACE/Server indicates success, then authentication succeeds.

If none of the above yields success, then authentication fails.

Proxy User Object Definition

The SIMPLE Proxy User object is used to define associations between user authentication mechanisms and the identity a user assumes when connected to a permitted network resource. This association is loosely dubbed a role.

A SIMPLE Proxy User object can indicate one of three types of authentication be used: (1) none, (2) an Authorized User object, (3) an external authentication mechanism.

The relationship between SIMPLE Proxy Users and authentication mechanism was shown in an illustration previously.

A SIMPLE Proxy User object also indicates the user identity string to be supplied when establishing the user identity on a network resource. This network resource is dubbed the backend server and, by derivation, the identity established on the backend server is defined by the backend_user_name item.

Note -

In SunScreen EFS 3.0, the backend_user_name is only used by the FTP proxy.

A GROUP Proxy User object is a collection of one or more references to other Proxy User objects, either SIMPLE or GROUP.

Any Proxy User object, either SIMPLE or GROUP, contains the following items:

A SIMPLE Proxy User object contains the following items:

User object to be used to authenticate this user role; if absent, and if no SPECIAL item is present, then the Proxy User object requires no authentication:

A GROUP Proxy User object contains zero or more of the following items:

Proxy User Object Creation

The Proxy User Object is manipulated using the proxyuser subcommand of ssadm edit. proxyuser takes one of the following as commands:

sortopt can be:

names [,sortopt] -- display the names of all objects sortopt can be:

The following is an example of what you type to display existing Proxy User objects, while logged into the primary Screen:


admin% ssadm -r primary edit Initialedit> proxyuser print jdh"jdh" ENABLED
SIMPLE AUTH_USER_NAME="jeff.hogg" BACKEND_USER_NAME="jeffh" DESCRIPTION="Jeff
Hogg as self on Solaris"

edit> proxyuser print proxyusers"proxyusers" ENABLED
GROUP MEMBER_NAME="radius" MEMBER_NAME="jdh" DESCRIPTION="users
allowed through FTP and telnet proxies"

The following is an example of what you type to create the above SIMPLE Proxy User object, while logged into the primary Screen:


admin% ssadm -r primary edit Initialedit> proxyuser add jdh auth_user_name=jeff.hogg backend_user_name=jeffh description="Jeff Hogg as self on Solaris"edit> quit

The following is an example of what you type to create the above GROUP Proxy User object, while logged into the primary Screen, first create the initial group with no members:


admin% ssadm -r primary edit Initialedit> proxyuser add proxyusers group description="users allowed through FTP and telnet proxies"

Note -

This above empty group creation demonstrates a case where the GROUP type cannot be deduced from the other tags, since description= is a tag common to all Proxy User object types.

Next, is an example of what you type to add the members of the example GROUP:


edit> proxyuser addmember proxyusers radiusedit> proxyuser addmember proxyusers jdh

Note -

Member names are stored in the order in which you add them to GROUP objects. The order is unimportant to authentication processing. This example also uses a SPECIAL object radius that is defined during initial installation.

Note -

It is not necessary to type save before quit above if only authuser, proxyuser, logmacro, or vars entities have been altered.

If you attempt to save without changing entities other than these types, you are reminded by a message:


edit> savelock not held

failed (status 244)

This is a non-fatal message in this situation; you can simply quit the configuration editor at this point.

Note -

See Chapter 3, "Administration Graphical User Interface Reference" for more information regarding which common objects do not require the use of save.

Once changes have been made to Proxy User objects, the system configuration must be (re)activated to install the new objects and to propagate these changes to secondary Screens.

In each of the above add operations, the enablement items have been allowed to default to enabled.

The following is an example of what you type to remove a member reference from a GROUP Proxy User object, while logged into the primary Screen:


admin% ssadm -r primary edit Initialedit> proxyuser deletemember proxyusers radiusedit> proxyuser print proxyusers "proxyusers" ENABLED GROUP MEMBER_NAME="jdh" DESCRIPTION="users allowed through FTP and telnet proxies"

The following is an example of what you type to display all Proxy User objects, while logged into the primary Screen:


admin% ssadm -r primary edit Initialedit> proxyuser print"admin" ENABLED
SIMPLE AUTH_USER_NAME="admin" DESCRIPTION="initial
SunScreen administrator" 

"admin-group" ENABLED GROUP MEMBER_NAME="admin" DESCRIPTION="SunScreen
administrators" 

"anonymous" ENABLED SIMPLE BACKEND_USER_NAME="anonymous" DESCRIPTION="unauthenticated
user, for anonymous FTP, etc." 

"ftp" ENABLED SIMPLE BACKEND_USER_NAME="anonymous" DESCRIPTION="unauthenticated
user, for anonymous FTP, etc." 

"jdh" ENABLED SIMPLE AUTH_USER_NAME="jeff.hogg" BACKEND_USER_NAME="jeffh"
DESCRIPTION="Jeff Hogg as self on Solaris" 

"proxyusers" ENABLED GROUP MEMBER_NAME="radius" MEMBER_NAME="jdh" DESCRIPTION="users
allowed through FTP and telnet proxies"

"radius" ENABLED SIMPLE RADIUS DESCRIPTION="default, external, non-specific
RADIUS proxy_user" 

"securid" ENABLED SIMPLE SECURID DESCRIPTION="default, external, non-specific
SecurID proxy_user"

The following is an example of what you type to display the names of all Proxy User objects, while logged into the primary Screen:


admin% ssadm -r primary edit Initialedit> proxyuser names,raw"admin"

"admin-group" 

"anonymous"

"ftp"

"radius"

"securid"

"jdh"

"proxyusers"

Proxy User Processing Logic

In earlier sections, the relationship between Authorized User objects and Proxy User objects was described, as well as an introduction of external (SPECIAL) Proxy User authentication methods. This section gives more specifics regarding these objects and mechanisms, and the sequence of steps performed by the processing logic upon them.

There are fundamentally two types of authentication processing performed in SunScreen EFS 3.0. Whenever a user identity is required, authentication processing occurs first, using one of these two processes. After SUCCESS is obtained in the authentication of an identity you supplied, access control matching determines if you are allowed to perform the operation being attempted; authentication FAILURE denies any requested operation. (Access control is described in the section "User Access Control Processing Logic," which follows.)

The first type of processing is the authentication of an Authorized User object directly. This form occurs when authenticating an administrator of SunScreen EFS 3.0, either through the administration GUI Welcome page or by the ssadm login sub-command. In these situations, the user name provided must match an ENABLED Authorized User object. Authentication logic has been previously described (see, "Authorized User Authentication Processing Logic").

The second type of processing is the authentication of a Proxy User object. This form occurs when authenticating a user who desires access through the FTP or telnet proxies.

As previously introduced, authentication of a Proxy User object can take one of three subpaths: (1) null authentication, (2) Authorized User authentication, or (3) SPECIAL external authentication method processing.

Regardless of Proxy User authentication path, only ENABLED objects can be used for authentication. A DISABLED object always results in an authentication FAILURE if attempted.

Null Authentication

Null authentication occurs when a SIMPLE Proxy User object named by the user contains no auth_user_name= item. In this situation, whatever input is given for the password is accepted without any checking. The pre-installed anonymous and ftp Proxy User objects are examples of this type of authentication.

Note -

There is nothing special about the names anonymous and ftp for these pre-installed objects. You can create additional null authentication Proxy User objects and use them in-lieu of or in addition to the pre-installed ones. This allows the creation of null authentication paths that are private to your installation.)

Referenced Authorized User Authentication

Authorized User authentication occurs when an auth_user_name= item is present. In this situation, Authorized User authentication logic is performed on the Authorized User object named in the item (see, "Authorized User Authentication Processing Logic").

SPECIAL External Method Authentication

SPECIAL external authentication method processing occurs when you supply an identity, which is a compound name consisting of a SPECIAL external authentication method and a backend user name.

The syntax of this compound name is:


/extmethodname/backendusername

For example, compound names that use the pre-installed RADIUS and SecurID SPECIAL methods might be:


/radius/jeffh

/securid/jeffh

Note -

There is nothing special about the names radius and securid in these pre-installed SPECIAL objects; they are distinguished by their special radius or securid items. You can create additional SPECIAL authentication methods and use them in-lieu of or in addition to the pre-installed ones. This allows the creation of authentication paths that are private to your installation, perhaps to hide these paths or to abbreviate user input.)

SPECIAL external authentication logic varies depending upon the method in question. More specifics about the two external methods (RADIUS and SecurID) can be found in later sections. Interestingly, note that there are two means for utilizing SecurID tokens for authentication: one within the Authorized User object, the other through SPECIAL external Proxy User object. The reason for this apparent redundancy lies in the level of trustedness of the two mechanisms. When using the Authorized User path, an association is formed between a specific SunScreen EFS 3.0 Authorized User object and a specific SecurID tokenholder. The SPECIAL external authentication mechanism allows, in essence, any user that SecurID authenticates to satisfy its rigor.

Thus, depending upon the security requirements of your site, you can choose the mechanism to employ. Notably, the ability to establish authenticity for purposes of SunScreen EFS 3.0 administration is never available to SPECIAL external authentication.)

User Access Control Processing Logic

As previously referenced, once an identity is supplied, the would-be user is authenticated. It is still required that this (now authentic) user be allowed to perform the operation presently being attempting. The logic that determines the abilities of a user is loosely termed access control.

As with the initial nature of user authentication, there are two contexts within which access control is employed: SunScreen EFS 3.0 administrative activities and usage of network facilities controlled by FTP and telnet proxies.

Access control logic regarding SunScreen EFS 3.0 administration is covered in various other sections of this and other manuals. However, once an administrative user has been authenticated, access to administrative capabilities is controlled by the administrative rules for both remote and local use. Within each such rule, a user name is found. If the Authorized User named within the rule matches the authenticated identity, then access is granted at the level the rule specifies. Alternatively, the rule can reference a Proxy User object; if the authenticated identity is a member of that Proxy User object, then the associated rule-specified access is likewise allowed.

SunScreen EFS 3.0 proxies that perform user authentication do so by requiring a Proxy User object to be referenced by their rules. Once the user-supplied identity has been authenticated, that identity (which is always a Proxy User in this context) is evaluated to see if it is a member of the Proxy User object referenced by the rule; if so, then the associated rule matches. (See below for more details regarding proxy rule matching.)

RADIUS User Authentication Processing Details

The RADIUS protocol provides the ability to centralize user authentication databases for widespread uniform deployment throughout organizations. RADIUS was originally developed for use by terminal-server devices, but its open specification and reference implementation have allowed it to achieve a sort of universal joint interconnection status in the world of external authentication mechanisms. Many forms of external authentication processing, both proprietary and standard, provide the ability to configure a RADIUS agent, or gateway.

Among noteworthy mechanisms so endowed are:

The SDS gateway facility enables SunScreen EFS 3.0 to tap into authentication using LDAP user databases.

With respect to a RADIUS server, the Screen plays the role of a client host or, for our purposes, a RADIUS Requestor.

Note -

The term client is quickly subordinated here, to avoid any confusion with clients of SunScreen EFS 3.0-provided services.)

The RADIUS protocol uses UDP datagrams to perform user authentication. Each RADIUS Requestor is configured with a node secret that is known only to itself and the RADIUS server(s) from which it expects authentication. That node secret is used to encrypt requests and to decrypt and authenticate server responses.

The RADIUS protocol in SunScreen EFS 3.0 comes installed with nearly all parameters prefigured for immediate use. Four remaining configuration elements needing post-installation attention are:

The SunScreen EFS 3.0 RADIUS Requestor can use up to eight different IP addresses for servers to be queried. These can be configured in one or more Address Common Objects with arbitrary names.

Tip -

It is suggested that a single Address group object be defined to collect all RADIUS servers for ease in creating server access rules.

To allow the RADIUS Requestor to function, the Screen must be configured to allow it access to the server(s) through the radius service Common Object, which comes pre-installed.

RADIUS Server Configuration

The RADIUS Requestor learns of its RADIUS servers and node secret from the variables "RADIUSServers" and "RADIUSNodeSecret", respectively.

The "RADIUSServers" variable can either be global or Screen-specific.

It contains the following items:


sys=Screen				(optional)

prg=auth

name=RADIUSServers

values={ host=server ... }		(name(s) of address object(s)

of RADIUS server(s))

description="descriptive text"	(optional)

enabled | disabled			(default is enabled)

For multiple-Screen installations, there are at least two approaches for dealing with the possible need to have Screens use different RADIUS servers. One is to employ the SCREEN attribute on Address objects with the same name, and then use a global "RADIUSServers" variable. Another is to use "avoid SCREEN" attributes on Address objects and instead use the sys= item to create Screen-specific "RADIUSServer" variables. Of course, combinations are also possible. And, naturally, the logic prefers Screen-specific Address objects and variables, over global ones.

The Address object(s) (referenced by server name in the above), can be GROUP, RANGE, or SINGLE. server can also be a dotted-quad IP address; however, avoid such usage unless required. The first eight unique IP addresses produced during processing of the variable are used.

Note -

Due to the way SunScreen EFS 3.0 represents address objects, use of GROUP or RANGE objects results in server usage that is ordered by ascending IP address. The preference order of server use can be controlled precisely by the order of the sub-items in the values={...} of the RADIUSServers variable.

RADIUS Node Secret Configuration

The RADIUSNodeSecret variable specifies a character string to use for security and authenticity when interacting with the configured RADIUS server(s). Because of the way RADIUS operates, only the RADIUS Requestors have node secrets (not the servers).

The same value configured for "RADIUSNodeSecret" must also be introduced into each RADIUS server through its own configuration mechanism. (For obvious reasons, this should be done in an out-of-band fashion.)

The "RADIUSNodeSecret" variable is normally Screen-specific. It contains the following items:


sys=screen				(optional)

prg=auth

name=RADIUSNodeSecret

value="nodesecret"			(node secret string)

description="descriptive text"	(optional)

enabled | disabled			(default is enabled)

In multiple-Screen installations, the sys= item allows you to configure different node secrets for each Screen.

Caution - Caution -

Because short-cuts were taken by some reference implementations, a common deficiency in RADIUS servers is the proper handling of node secrets that are longer than 31 characters. If you intend to use longer values, you should first determine that your server(s) can handle them correctly.

Once Addresses, Rules, and variables have been established, the configuration must be activated to propagate the changes.

Typical RADIUS Configuration

A typical RADIUS configuration scenario has two Screens that each protect a site. la-screen and la-radsvr are a Screen and RADIUS server in the la location, sf-screen and sf-radsvr are a Screen and RADIUS server in the sf location. Each site uses the RADIUS server of the other as a backup.

Note -

Ephemeral IP addresses are shown. Encrypted tunnels, or VPNs, are possible, perhaps likely, in such a configuration, but are not shown for purposes of clarity.

The following is an example of what you type to create address objects, while logged into the primary Screen:


admin% ssadm -r primary edit ConfigNameedit> add address la-radsvr HOST 1.2.3.4 ..edit> add address sf-radsvr HOST 4.3.2.1 ...edit> add address radsvrs GROUP { la-radsvr sf-radsvr } { } ...

The following is an example of what you type to create a rule to allow RADIUS-Requestor-to-server access, while logged into the primary Screen:


edit> add rule radius localhost radsvrs ALLOW

The following is an example of what you type to create RADIUS variables, while logged into the primary Screen:


edit> vars add sys=la-screen prg=auth name=RADIUSServers values={ host=la-radsvr host=sf-radsvr } description="RADIUS servers for la site"edit> vars add sys=sf-screen prg=auth name=RADIUSServers values={ host=sf-radsvr host=la-radsvr } description="RADIUS servers for sf site"

The following is an example of what you type to create RADIUS node secret variables, while logged into the primary Screen:


edit> vars add sys=la-screen prg=auth name=RADIUSNodeSecret value=la--secretedit> vars add sys=sf-screen prg=auth name=RADIUSNodeSecret value=sf--secret

Save and activate the configuration:


edit> saveedit> quitadmin% ssadm -r primary activate configname

For example, given a valid, RADIUS-hosted user gooduse with password goodpass and an invalid user baduser, while logged into the Screen la-screen:


admin% ssadm -r la-screen lib/user_authenticate -v /radius/gooduser goodpassUser  /radius/gooduser
 authenticated and mapped to backend user  gooduser

admin% ssadm -r la-screen lib/user_authenticate -v /radius/gooduseranythingelse

User  /radius/gooduser  failed authentication.

admin% ssadm -r la-screen lib/user_authenticate -v /radius/baduseranything

User  /radius/baduser  failed authentication.

Note -

lib/user_authenticate is a low-level program used internally to perform user authentication; its interface is not supported for general use. It echoes the password as it is typed.

User Databases

User databases are registries for user entities that are private to the SunScreen EFS 3.0 system.

There are two types of entities: Authentic users and Proxy users.

Each type of entity has a string for its name.

The authuser and proxyuser namespaces are distinct entities.

Editing command verbs and item names are case-insensitive; however, documentation generally uses all-CAPS in examples for emphasis.

For example:


edit> authuser add Ron password={
raygun }

is identical to:


edit> authuser add Ron PassWorD={
raygun }

The add verb performs a complete overwrite of the named item, which is important in the case of proxyuser GROUP entities, where the addmember and deletemember verbs have been provided to manipulate member lists.

The output of the print verb is suitable for re-use through add. The print verb outputs a canonical form, including defaults for required items. Here again, you need to address shell escape issues.

Each type of entity has an enablement flag (enabler), while some sub-fields also have enablement flags:

ENABLED

-or-

DISABLED

where the default is ENABLED.

authuser Database

authuser is intended to correspond one-to-one with actual persons. The authuser entity contains parameters that are required to verify the authenticity of a given individual authuser.

Note -

Entities do not reflect user roles; that is what the proxyuser entities are for.

authuser entities allow authentication by simple password or SecurID token PASSCODE (a given authuser can be configured for both types; satisfying either one is sufficient to cause authentication).

authuser entities provide for multiple simple passwords; however, the administration GUI is only prepared to deal with zero or one.

authuser entities have the following required items:

name -- However, to be of any great use, at least one of the following authentication mechanisms must also be given:

PASSWORD={ plain-text [ CRYPT_PASSWORD=crypt-text ] enabler }

SECURID={ securid-name enabler }

If the CRYPT_PASSWORD item is given, the plain-text is given as "" (empty placeholder string).

Any PASSWORD item(s) precedes a SECURID item, and only one SECURID item is allowed or used (ACE/Server contains a mechanism to allow a given user to use multiple token devices).

authuser entities have the following optional items:

The administration GUI only expects zero or one of each of the above, but the command-line tools do not restrict their numbers.

authuser passwords are stored in encrypted form (DES Unix /etc/passwd style, up to eight characters).

When the configuration editor is presented with a plain-text password, it translates it into an encrypted item, because it cannot display plain-text form.

The configuration editor stores the encrypted items directly and uses them during database build operations. When you do not know a user password, they can also be used to paste-in user passwords from /etc/passwd.

authuser example with simple password authentication:


edit> authuser add harry.bovis password={ secret }edit> authuser print harry.bovis "harry.bovis" ENABLED
PASSWORD={ "" CRYPT_PASSWORD="upO7711Q0CRaA" ENABLED }

Output of print is actually a single, long line.

Note -

If you try this example, the password encryption logic will probably generate a different crypt-text string for the password "secret". There are 4096 different possible encryptions for any given plain-text password.

authuser example with SecurID authentication:


edit> authuser add larry.hovis securid={ lhovis }edit> authuser print larry.hovis "hovis" ENABLED SECURID={
"lhovis" ENABLED }

authuser example, with both simple password and SecurID authentication:


edit> authuser add ac-dc password={ rockU } securid={ acdc }
edit> authuser print ac-dc "ac-dc" ENABLED PASSWORD={
"" CRYPT_PASSWORD="fOE25hj8FhvIM" ENABLED } SECURID={ "acdc" ENABLED
}

Output of print is actually a single, long line.

proxyuser is intended to provide the idea of user roles to control the inclusion of users within groups used by Screen rules (through the GROUP entity type); they provide a means of mapping authentic users into their roles (user identities) on backend server systems (through the AUTH_USER_NAME or BACKEND_USER_NAME items); and they provide inclusion of external user authentication means (through the RADIUS item).

proxyuser Database

proxyuser entities have the following required items:

Including two basic types:

SIMPLE or GROUP

Often, you do not have to enter the type specifier, as the configuration editor usually infers the type from the other items presented.

proxyuser items that are allowed in (and imply) SIMPLE:

proxyuser items that are allowed in (and imply) a GROUP:

MEMBER_NAME=proxy_user_name is repeated for each member of a GROUP.

Note -

MEMBER_NAME is not often used directly for the add verb, in favor of the addmember and deletemember verbs.

proxyuser items are allowed in either SIMPLE or GROUP:

DESCRIPTION=desc-string

proxyuser example -- the anonymous entity:


edit> proxyuser add anonymous BACKEND_USER_NAME=anonymous 
edit> proxyuser print anonymous "anonymous" ENABLED SIMPLE
BACKEND_USER_NAME="anonymous"

This entity requires no authentication in any rule where it is included. Access is allowed by mentioning the name anonymous.

Note -

There is nothing special, within the SunScreen EFS 3.0 authentication subsystem at least, about the name anonymous; the FTP protocol assigns special meaning, but the authentication logic is unaware of this.

proxyuser items provide a means by which non-well-known but un-authenticated access can be granted.

For example:


edit> proxyuser add backdoor SIMPLE

By mentioning the user backdoor, access is granted.

proxyuser example, authenticated user entity:


edit> proxyuser add ronco AUTH_USER_NAME=ron.popeiledit> proxyuser print ronco "ronco" ENABLED SIMPLE
AUTH_USER_NAME="ron.popeil"

The BACKEND_USER_NAME defaults to "ronco" when used.

proxyuser example, authenticated user entity with alternate backend name mapping:


edit> proxyuser add msd-root AUTH_USER_NAME=marc.dye BACKEND_USER_NAME=root DESCRIPTION="map msd to root"edit> proxyuser print msd-root "msd-root" ENABLED SIMPLE AUTH_USER_NAME="marc.dye" BACKEND_USER_NAME="root"
DESCRIPTION="map msd to root"

Output of print is actually a single, long line.

The backend server supplies the user name "root" upon connection establishment.

proxyuser example, creation of a GROUP:


edit> proxyuser add crow SIMPLEedit> proxyuser add servo AUTH_USER_NAME=tom.servoedit> proxyuser add inbound-ftp-users GROUP DESCRIPTION="users allowed inbound access as themselves" edit> proxyuser addmember inbound-ftp-users crowedit> proxyuser addmember inbound-ftp-users servoedit> proxyuser print "anonymous" ENABLED SIMPLE
BACKEND_USER_NAME="anonymous" 

"crow" ENABLED SIMPLE 

"inbound-ftp-users" ENABLED GROUP MEMBER_NAME="crow" MEMBER_NAME="servo"
DESCRIPTION="users allowed inbound access as themselves" 

"radius" ENABLED RADIUS SIMPLE 

"servo" ENABLED SIMPLE AUTH_USER_NAME="tom.servo"

An FTP proxy rule, which uses GROUP inbound-ftp-users, allows the user crow without a password, and the user servo with whatever authentication the authuser entity tom.servo specifies. In both instances, the name of the proxyuser entity matched is supplied to the backend FTP server.

proxyuser example, more complete, allowing RADIUS authentication and groups within groups:


edit> authuser add dilbert SECURID={ wiseguy } DESCRIPTION="contract engineer"edit> authuser add dogbert PASSWORD={ trusted } DESCRIPTION="management consultant"edit> authuser print "dilbert" ENABLED SECURID={
"wiseguy" ENABLED } DESCRIPTION="contract engineer" 

"dogbert" ENABLED PASSWORD={ "" CRYPT_PASSWORD="O6JeSCIwq0LvA" ENABLED
} DESCRIPTION="management consultant"

edit> proxyuser add dilbert AUTH_USER_NAME=dilbert BACKEND_USER_NAME=guestengr1 DESCRIPTION="contractor mapped to a guestengr"edit> proxyuser add dogbert AUTH_USER_NAME=dogbertedit> proxyuser add engg GROUPedit> proxyuser addmember engg dilbertedit> proxyuser addmember engg radiusedit> proxyuser add inbound GROUPedit> proxyuser addmember inbound dogbertedit> proxyuser addmember inbound enggedit> proxyuser print "dilbert" ENABLED SIMPLE
AUTH_USER_NAME="dilbert" BACKEND_USER_NAME="guestengr1" DESCRIPTION="contractor
mapped to a guestengr" 

"dogbert" ENABLED SIMPLE AUTH_USER_NAME="dogbert" 

"engg" ENABLED GROUP MEMBER_NAME="dilbert" MEMBER_NAME="radius" 

"inbound" ENABLED GROUP MEMBER_NAME="dogbert" MEMBER_NAME="engg" 

"radius" ENABLED RADIUS SIMPLE

Examine the way in which the FTP proxy allows access for "inbound":

user prompt: dilbert@server user passwd: sidpass@srvpass

Assuming sidpass validates "wiseguy" with SecurID:

Proxy supplies the user "guestengr1" password srvpass

user prompt: /radius/msd@server user passwd: radpass@srvpass

Assuming sidpass validates "msd" with RADIUS:

Proxy supplies the user "msd" password srvpass

user prompt: dogbert@server user passwd: trusted@srvpass

Proxy supplies the user "dogbert" password srvpass

References to non-existent user entities behave as if the entity existed but was DISABLED ( virtual ); DISABLED entities (either real or virtual) always behave so as to cause a non-terminal failure of processing.

For example:

Authentication logic used within the proxies is performed with a three-step check for a given user username and password passstrings:

  1. If username begins with a method prefix (for example. /radius/), then that method is invoked, returning SUCCESS or FAILURE. Otherwise, username is used as the pname sought in the next check (2).

  2. An ENABLED proxyuser pname is sought; if it exists. Then, if that proxyuser contains no AUTH_USER_NAME item, then authentication SUCCEEDS immediately (pass is not checked); otherwise, the value of that item is used as the aname sought in the next check (3), otherwise, pname is used as the aname sought in the next check (3),

  3. An ENABLED authuser aname is sought; if it exists. Then if pass authenticates it, then authentication SUCCEEDS, otherwise authentication FAILS.

Currently, authentication logic used for Screen administrative access control uses only the third (3) stage of the logic given above (that is, no external method nor proxyuser matching is performed).

The user-portion of the rule-matching logic used by the proxies performs the three-step authentication given above. If that authentication fails, no rule match is attempted; otherwise, the is-member portion of the rule match is performed. Each rule references a proxyuser user ruser; ruser can be a GROUP or a SIMPLE user.

If username begins with a method prefix (for example, /radius/), then if ruser has an ENABLED member with method (for example, RADIUS) then is-member SUCCEEDS; otherwise, is-member FAILS. Otherwise, if ruser has an ENABLED member named username, then is-member SUCCEEDS; otherwise, is-member FAILS.

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.