Review: Sunscreen EFS v3.2 Firewall

Checking out Sun's Firewall in Stealth mode

By Seán Boran

While the Sunscreen Securenet 3 (also called EFS 3) does have a few quirks, it is a powerful, flexible and interesting firewall, especially if you like using the command line (CLI). The stealth mode is a unique feature that makes it more difficult to attack than traditional firewalls. The High Availability and Centralised management features are also useful. The bundling of a 'lite' version with Solaris 8 and a full version (v3.2) with Solaris 9 make this technology available for free for both host and network protection.

This article presents the results of practical tests with the Sunscreen EFS v3.0b / v3.1 and especially v3.2 on SPARC and assumes a working knowledge of firewalls.

The Sunscreen can operated in two modes "routing mode" (classical mode where two subnets are joined) or "stealth mode" (an intelligent "bridge mode" packet filter, like the Sunscreen 100 or 200). The focus of this article is on using the stealth mode, since it is what sets the Sunscreen apart from most other firewalls.

  1. Introduction & Overview
  2. Firewall Architectures
  3. Installation: Admin | Screen | Configuring Admin | High Availability (HA)
  4. Patches
  5. Configuration
  6. Analysis
  7. Recommendations
  8. Reader Tips / Feedback
  9. References

1. Introduction to the Sunscreen

The SunScreen is a firewall from Sun [1] which can be operated in two modes:

  1. "Stealth mode" allows packet filtering (state based) and transparent switching between several interfaces. It does not route packets (because it does not understand RIP, have a routing table and is not visible to IP hosts). It functions like an Ethernet switch and needs to know what IP addresses to expect on which interface. It splits an existing subnet, rather than connecting two subnets.
    The original Sunscreen SPF 100 was sold as a "black box" with Windows-based GUI for configuration. This progressed to the Sunscreen SPF 200 being sold as software that could be installed on most Sun SPARCs and had a Motif & Web based admin GUI. The Sunscreen EFS3 was basically a marriage of the Sunscreen 200 with the EFS (see below) with a few improvements thrown in. V3.2 is bundled with Solaris 9 and includes for instance IPsec and IKE.
  2. "Routing mode" is what is expected of most firewalls. The EFS was the first routing mode firewall available from Sun, although Sun also resold Checkpoint's Firewall-1 for many years.
    Packets are routed from the inside interface to the outside (or vice-versa). Depending on rules, they may be passed via a proxy, dropped, logged, en/decrypted etc. Since the firewall actually routes, it must connect two distinct subnets and have IP addresses assigned to each interface.
    HTTP, ftp, telnet and email proxies are also included in Routing mode. Ftp and telnet proxies can make use of authentication (username/password or SecurID), content filtering and anti-spam (email proxy).

Key features:

The SunScreen 3.0 (rev B), v3.1 and v3.2 were tested for this article on SPARC hosts in stealth mode. Routing mode (and hence proxies) filtering, NAT and high availability options have not been tested. The author has been administering Sunscreen's for several years.


Firewall Architectures

The Stealth mode Sunscreen is a special beast that doesn't fit into a network the way that most firewalls do (which tend to check and route packets between an inside and outside interface). The Stealth mode is more like a switch, working on layer 2. It examines all packets on (say) the ethernet layer, and can take actions based on ethernet, ip or tcp/udp headers. It requires a clear definition of which IP address are to be expected on which interface, so it knows which outgoing interface to switch packets to, and to provide 'anti-spoofing'. Since the Sunscreen doesn't route, it can cut a subnet in two, but does not replace a router.

Two examples are presented, the second is  also discussed in the configuration section below. Note that non-routable private network addresses are used.

Figure 1: A simple network with Sunscreen
example1.jpg (27207 bytes)


Figure 2: A more complex two stage firewall with DMZ

This two stage firewall protects the DMZ zone typically ensures that all traffic transits through application layer proxies in the dmz, and protects the dmz from both Internal and External attacks. In this example DMZ contains an email server and http proxy, typically DNS servers, authentication server and other proxy types would also be needed.
Routing: Since there are no routers in the DMZ, the DMZ bastion hosts need static routes pointing (inside) to the router and the default route pointing to The routers must also contain relevant static routes.
A sunscreen with a quad ether interface is shown, with one port free (which could be used for another dmz).

example2.gif (8825 bytes)

Policy: Normally the rules will only allow traffic to and from the dmz, but not directly from the Inside to the Outside and certainly not in the other direction. Possible except are allowing traceroute and ping from the Inside to both dmz and the Outside.

Sunscreen administration: The admin interface (e.g. le0, not show above) could be connected via a dedicated network to an Internal host, or they could be managed by serial lines or terminals attached to the Sunscreen console ports (if SPARC rather than x86 machines are used).


Although a quick overview of the installation is provided here, it is recommended to read the installation guide, make notes, and be prepared to do a few dummy installations.

Install via the GUI or command line?

In the following scenario, we install two Sunscreens, one which is used for administration. We not install a dedicated "Administration Station" itself (which would have IPsec configured, but no Sunscreen Firewall), since it is important to protect the Administration Inself by a  (local) Firewall itself. i.e. by installing Sunscreen Firewall on the Admin Station we can then use it to restrict access to the Admin Station by other hosts. Since Sunscreen 3.2 is free, there is no additional license required either.

Install the Administration Screen

Installing the Sunscreen

Configuring the Admin station

Assuming that the Admin station and at least one Screen have been installed as noted in the two previous sections, we can now configure the Admin station's SKIP to allow communication with the screen.
Either start the GUI to show/add/manage SKIP on interface le0 (it may have several interfaces):
  skiptool le0 

Or do it on the command line:

After installing the Screen with as above, a skiphost command is provided to run on the Admin station, which adds the Screen's cert to the skip ACL. If your Admin station has more than one interface, add "-i le0" or what ever the interface name, is to the front of the skiphost command; e.g.

skiphost -i le0 -a MyScreen -r 8 -R 0x98765fe7218d87654e543e3de202bab2 -s 8 -S 0x4fd3a1eec3a345e987654fb3a1a65457 -k DES-CBC -t RC4-40 -m MD5

Save the skip settings:
skipif -i all -s
Check that the Sunscreen is properly listed on the Admin station ACL:
skiphost -i le0 -V

Finally, check out the communication from Administration to Screen. If the communication fails, see the troubleshooting section.


High Availability (HA)

The Sunscreen includes HA option for failover to a redundant system. The documentation covers both GUI and CLI installation of HA, here we provide a brief CLI summary.

The sunscreens need to have similar hardware, and identical interface names. A separate interface for the HA "heartbeat" is needed, and must be configured on the Solaris level with a  valid IP address (/etc/hostname.interface). A crossover Ethernet cable is the easiest way to connect the two redundant Screens. Verify that the two systems can ping each other via the HA interface before installing the Sunscreen software.

 The Sunscreen software as installed in standard fashion as above on both Screens, with remote administration enabled.

On the primary, configure the Sunscreen create and test a policy as usual. Then create a HA cluster and indicate that this machine is the master (assuming the HA interface is eri1)

ssadm ha init_primary eri1

On the secondary, indicate the name of the primary and initialise as a HA slave (assuming the HA interface is eri1 and HA IP address of the primary is

ssadm ha init_secondary eri1

On the primary, not add the secondary to the cluster, and synchronise the current policy to the secondary (assume secondary IP address is

ssadm ha add_secondary

This may take some time, after which the new policy is enable on both machines, but only one is active. Troubleshooting: The HA traffic is on port 3853, so snooping the HA interface can confirm that this traffic is being exchanged.

Check the status of the HA cluster (in the following example the secondardy was powered on first, then the primary. As a result the primary, fw1, is "passive"):

ssadm ha status
HA configuration is enabled and contains no errors.
This host is in ACTIVE mode.
The HA daemon is running with pid 238: HA is on.
fw1b is a secondary node

ssadm ha status -Z
HA configuration is enabled and contains no errors.

Now we log onto the primary, fw1, and make it the active screen (perhaps we want to do maintenance on the secondary):
root@fw1:~[3]$ ssadm ha active_mode
root@fw1:~[4]$ ssadm ha status -Z
HA configuration is enabled and contains no errors.

Now we shutdown the primary (which is active), and log into the secondary to make sure it has become active:
root@fw1b:~[3]$ ssadm ha status -Z
HA configuration is enabled and contains no errors.


Troubleshooting a Cluster installation:

If you reconfigure an existing Sunscreen and try to make it a secondary, you may find it simply does not work. So wipe the sunscreen software, reinstall and reinit as a secondary:

\rm -rf /etc/sunscreen /etc/skip /var/sunscreen
init 6
(when rebooting make sure there are no traces of sunscreen)

Add packages & reboot:
cd /opt/install/SunScreen_3.2/sparc/
pkgadd -d .                    
[Select "1-6, 10-27"]
ssadm ha init_secondary eri1  (IP of primary)
init 6

On the primary, Setup the Firewall as usual, test, activate policy. Then setup the cluster:

ssadm ha init_primary eri1             (HA interface)
ssadm ha add_secondary
    (IP of secondary, HA interface)
ssadm activate MyPolicy


The SunScreen has been stable in my experience, but like all software, bugs are found and patches released. The latest patches should be installed when a new sunscreen is setup.

An example list of patches on Sunsolve's "Security & Recommended Patch list" is as follows, note that there is one patch for each Sunscreen version/architecture.

106718-01 SunScreen SKIP for Solaris 1.1.1: patch for /etc mode in packaging
106718-01 SunScreen SKIP for Solaris 1.1.1: patch for /etc mode in packaging
106719-01 SunScreen SKIP for Solaris 1.1.1: x86 patch for /etc mode in packaging

105237-09 SunScreen EFS 1.1: miscellaneous fixes including NAT
106881-03 SunScreen EFS 2.0: NAT, MP, and FW-1 conversion fixes

108156-15 SunScreen 3.0b (Sparc)
108157-15 SunScreen 3.0b (Intel)

109734-07 SunScreen 3.1 (Sparc)    - Feb 2002
109735-07 SunScreen 3.1 (Intel)
109736-07 SunScreen 3.1 LITE (Sparc) 
109737-07 SunScreen 3.1 LITE (Intel)
112613-03 SunScreen 3.2 (Sparc) - Aug 2003

See also

The current Sunscreen patchlevel install can be checked with commands such as:

showrev -p | grep icg
ssadm patch list

The patches are typically installed by downloading to the Sunscreen and Administration station, extracting them to a directory, changing into that directory and running:

patchadd .

Changes in patches should be checked for and installed at regular intervals.

Note: If your Sunscreen filters IPsec traffic, install the latest patch as the EFS 3.0b has a problems with IPsec fragments.


Initial Policy

The first thing to do after installation, is to setup an new Policy and change the admin password. Rather than creating a virgin policy, copy the default 'Initial' configuration (so that remote administration continues working as expected).

  1. Via the GUI: Start Hotjava to connect to the Sunscreen and show the Sunscreen configuration GUI.
      hotjava http://myscreen:3852
    Select Policy Edit->Type->Admin User->Search, select Results->Administrator, select Edit and change Password in the authorised dialog, Save Changes, Activate.
  2. Via the command line (the new Policy will be called 'test', the network we are splitting is (see Example above) and we limit logs to 1GB). Note that 'myscreen' and 'CERTNAME' should be replaced by the output of the ADMIN_CERTIFICATE displayed in the 'list screen' command.

ssadm policy -c Initial test
ssadm edit test

edit> list screen
edit> add screen myscreen SPF ADMIN_CERTIFICATE "CERTNAME.admin" LOGSIZE 1000 COMMENT "DMZ Firewall"
edit> add authuser admin ENABLED PASSWORD={ "SomePassword" ENABLED } REAL_NAME="Sunscreen SysAdmin" CONTACT_INFO="Bob or Alice"
edit> save

ssadm activate test

1. the spaces before and after the password quotes are needed to avoid a core dump!
2. A 'screen' must be defined before you can save changes to the admin user.
3. If "add authuser" is done on it's own, save will report an error about a lock not being set. Discard this, the change has been made (exit and edit again to confirm).
4. Don't use "$" in passwords, they won't work.
5. LOGSIZE: We limit the log size above to 1GB. Set it to a limit that corresponds to your /var free disk space.

If remote communication fails, reactivate 'Initial' (see the troubleshooting section).

Environment - to ensure that the GUI and commandline run smoothly, add a few lines to your administration station .cshrc (if you use C-Shell):

setenv PATH ${PATH}:/opt/SUNWicg/SunScreen/bin:/opt/SUNWicg/SunScreen/lib
setenv MANPATH ${MANPATH}:/opt/SUNWicg/SunScreen/man
alias hotjava '/usr/dt/bin/hotjava http://myscreen:3852/'
alias screen1 'ssadm -r myscreen edit dmz'

setenv SSADM_TICKET_FILE $HOME/.ssadmticket

Note: if more than one screen is managed, then either:
a) Only log into one screen at a time (ssadm login/logout)
b) Specify separate a SSADM_TICKET_FILE for each screen, not a common one.

Configuring Policies

The Sunscreen can be configured locally (via the console/serial line) or remotely (via web GUI or commandline from the Administration station). The focus here is on the local command line, since
- SKIP can be troublesome
- the GUI is slow, and
- using the command line allows you to clearly plan and document changes.

  1. GUI Tips
  2. Command line Tips
  3. Things to watch out for
Troubleshooting SKIP
Log analysis & Troubleshooting

Once the firewall has been configured and activated, analysis of the logs is essential to find configuration errors, monitor sunscreen errors and monitor intrusion attempts.

Note that logs are stored in /var/sunscreen/logs (or for V3.1 or earlier /var/opt/SUNWicg/SunScreen/logs).

Availability & backups


Performance:  No hard measurements have been made, but an old Sparc5 with 32MB of memory did not log a few packets on a pretty active 10MB network, an 167MHz Ultra-1 had no log failures. Switching on debug logging does seem to drastically reduce performance, so use with care.
The EFS is multi-threaded and can also take advantage of extra processors, if available.

Advantages: What's good about the EFS3?
Problems: What needs to be improved?


Administration Station Security

The remote administration station(s) are practical for operating the Sunscreens, but the remote administration also presents risks. The paranoid may consider only configuring Sunscreens via the console and avoid a network connection on the administrative port. For those needing remote administration, the following tips should reduce the risk posed:

Reader Tips / Feedback

Tip from Paul Phillips/Todd Janson:

When attempting to activate a configuration in a CMG environment, the
following error can occur:

  master# ssadm activate Initial
  ssadm: Can't run command: Error from remote server:
  You must log in before using the activate command.
  ssadm activate: Couldn't verify configuration on screen "secondary".

Two reasons why one might get this error message are:
1.  The definition of the screen object for the SECONDARY is not complete.
On the secondary screen itself, the definition of the screen object should have the MASTER parameter set, among other things.  For example, a complete definition of a secondary screen object would look like this:

  "secondary" ADMIN_CERTIFICATE "secondary.admin" KEY "DES-CBC" DATA

If the MASTER parameter is not set correctly, the master will not have  permission to install a policy.  Once you verify that all the parameters are properly defined in the screen objects on both systems (as per the example above), reactivate the policy on the secondary, then try to activate the policy from the primary.

2.  There is stagnant information on the secondary from a previous master. If the secondary was previously managed by another system, then the CMG secret between the master and secondary needs to be reinitialized.  On the secondary remove the following file:


Install the policy from the master.  The CMG secret will automatically be
reinitialized and the policy should be successfully activated on the




[1] SunScreen Securenet
     Download Sunscreen EFS lite

Sunscreen V3.0 Online docs
  Admin Guide
  Installation Guide
  Reference Manual
  Release Notes

Sunscreen V3.1 Online docs
  Admin Guide
  Installation Guide
  Reference Manual
  Release Notes

SunScreen 3.2 Documentation
SunScreen 3.2 Configuration Examples

[2] Hardening Solaris:

Sean's Solaris Hardening Guidelines (the Guidelines for hardening with Jass are what I currently use). Tips on using Sunscreen lite are also included.

[3] ITSEC Approved Firewalls  

[4] Configuration examples

Additional service definitions which may be useful services_list.txt
A snapshot for the default "Initial" configuration ss_Initial.txt
Log of an instillation: ss_install.txt

[5] Sunscreen Lite

Sun Blueprint on the Sunscreen lite v3.1  

Sunscreen Lite install documentation is now available online

Protect yourself with SunScreen Lite - Mark Thacker

Further reading:

Sunscreen Discussion forum 

Command-line Interface, by Philip Brown 

Notes by Vu Pham 

Changes to this article

29.Mar'00  Links to  Dok ID 1885,
03.Apr.'00 First Publication
17.Apr'00  Update summary and notes on EFS lite.
16.May'00 Update: install/troubleshooting (minor)
10.Jul'00   Update: Log analysis and troubleshooting (snoop tips) and Troubleshooting SKIP. EFS lite link
30.Aug'00 Update: Troubleshooting SKIP
02.Mar'01 Update: Install/troubleshooting (minor), Line length problem, Redundancy/performance notes from Alain Sabban.
14.Apr'01 New: Patch section, time based example. Updated: logs filling disks.
31.May'01 Sync published version.
05.Oct'01 Update for v3.1. Add Sunscreen lite links. Tip on opening up admin interface if SKIP drives you nuts. Problem with v3.1 to v3.0 communications.
09.Jan'02 Updated: statetables/rule activation note
08.Feb'02 Fonts
09.Apr'02 Minor fix to logging. Add get_policy script.
08.May'02 EFS 3.2 notes.
??.Sep.02 v3.2 installed on many systems, using IPsec for management. Remove SKIP from this document and create a link to the previous v3.1 document (which uses SKIP extensively).
15.Oct'02 Update
logs filling disks.
23.Oct'03 Update for v3.2, HA.
25.Mar'04 Added Cluster Troubleshooting

22.Jun'04 Added Reader Tips / Feedback

Seán Boran is an IT security consultant based in Switzerland and the author of the online IT Security Cookbook.             

© Copyright 2004, Seán Boran. Last Update: 22 Juni, 2004