## Review: Sunscreen EFS v3.2 Firewall

#### Checking out Sun's Firewall in Stealth mode

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

• Price for v3.1 is about $4500 for Workgroup,$15K for Unlimited version and free for "local" use (EFS lite).
V3.2 is free with Solaris 9.
• High Availability clustering is available whereby passive screens monitor an active screen and take over if the active fails (V3.0b or later is needed for Stealth mode HA).
• VPN: The Sunscreen can be used to setup VPNs (virtual private networks) using the SKIP protocol. EFS runs SKIP V1 and V2, whereas the older Sunscreen 100 & EFS only support SKIP V1.  V3.2 can also speak IPsec and IKE. The VPN can run in two modes:
• In end-point to Gateway (Sunscreen) mode the Sunscreen needs certificates for each end point and rules can be added to only allow certain services (encrypted) to certain target IP addresses.
• In end-point to end-point  mode, the Sunscreen simply lets SKIP (IP protocol 79 for SKIP V1 and protocol 57 for SKIP V2) pass or not, individual services cannot be passed or stopped since the packet is not decrypted by the Sunscreen.
• Centralised Screen Management of configuration objects such as address, interfaces, service & rules.
• Network Address translation
• The intelligent packet filter includes engines for ethernet, realaudio, rsh, sqlnet, ftp, tcp, udp, dns, ip, ping, nfs, nis, ntp, iptunnel and ipmobile. Based on these engines, about 125 services are predefined in V3.0b.
• V3.1 adds support for ATM CIP mode (the ATM logical interface is not supported), Gigabit Ethernet and SNMP status reporting.
• When running in stealth mode, Sunscreen can filter Ethernet packets that are not IP-based (e.g. Novell IPX, AppleTalk, DECNet). To filter these, define a new service using the ether state engine, and specify the exact Ethernet frame types.
• OS support: V3.0b runs on Solaris 2.6 or 2.7. EFS lite and v3.1 runs on Solaris 8 and Trusted Solaris 7. V3.2 runs on Solaris 2.6 and later and Trusted Solaris 8.
• Hardware support:
• V3.2 is not available for Intel.
• Any Solaris SPARC or Intel machine (on the hardware compatibility list) that runs Solaris 2.6, 7 or 8.
Note: with V3.0a it was restricted to a subset of SPARCs. V3.2 runs ONLY on sparc.
• SBUS Network cards: Fast ethernet (X1059A), quad ethernet, quad fast (qfe 1.0 and 2.0 - X1049A).
ATM, FDDI and Token Ring are supported in Routing, but not Stealth mode.
• PCI Network cards: Fast ethernet (X1032A, X1033), quad ethernet, quad fast (X1034A).
ATM, FDDI and Token Ring are supported in Routing, but not Stealth mode.

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 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 176.17.16.0 (inside) to the 176.17.17.2 router and the default route pointing to 176.17.17.1. 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).

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

#### Installation

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?

• I prefer the command line since:
- the java GUI was really slow on my aging admin station
- the installation can occur on a pre-hardened host, with weak services such as RPC and inetd disabled.
- you can save a (text) log of the installation to a file, to document your work and re-use it for later installations.
• Sun recommend you use the GUI for installation.

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

• Install Solaris (e.g. Solaris 9 with User Bundle  see also [2])
• Download the Sunscreen software (or mount the CD-ROM)
• Install the Sunscreen software via pkgadd (See Sunscreen 3.2 Installation guide, Appendix A),   Older versions: Packages for v3.1:  2-5, 8-9, 12, 17-21  v3.1 and earlier: Make the sunscreen binaries accessible to the root account. For example, add the following to /.cshrc:    setenv PATH ${PATH}:/opt/SUNWicg/SunScreen/bin or .bashrc  PATH=${PATH}:/opt/SUNWicg/SunScreen/bin

for example with v3.2:
pkgadd -d . 1-6, 10-27 

• Update the man page indices (this is missing from the official doc):
/usr/lib/makewhatis /usr/man
• Install self generated or issued Administration Station SKIP certificates and activate SKIP  (see Installation Guide, Chapter 5).
On the Admin station, there is initial work to be done the first time SKIP is used, and hence a connection is made to a Sunscreen (see EFS3 Installation guide, Appendix A).

Reboot:
sync; init 6

#### Installing the Sunscreen

• Install Solaris:
• Install Solaris with the User Bundle  see also [2]. With the Solaris User bundle, you may need the packages SUNWsprot and SUNWeuluf (which can be found on the Solaris CD).
• Disk layout:
- The Screen will need lots of logging space in /var/opt/SUNWicg/SunScreen/logs, consider creating  a separate large partition for /var.
- /var and /tmp can be mounted nosuid.
- /usr needs about 250mb for the end user bundle and can be mounted read-only.
- /tmp is mounted in swap and it's maximum size should be restricted, e.g. 'size=2000m'
• Download the Sunscreen software (or mount the CD-ROM)
• Install via 'pkgadd -d .'  (See the Sunscreen Installation guide, Appendix A).  Older versions: For v3.0b, install packages 1-2 7-16 For v3.1, install 2-5 10-22 V3.1 and earlier: Make the sunscreen binaries and manual pages accessible to the root account. For example, add the following to /.cshrc:    setenv PATH ${PATH}:/opt/SUNWicg/SunScreen/bin setenv MANPATH$MANPATH:/opt/SUNWicg/SunScreen/man or .bashrc   PATH=${PATH}:/opt/SUNWicg/SunScreen/bin MANPATH=$MANPATH:/opt/SUNWicg/SunScreen/man  /usr/lib/makewhatis /opt/SUNWicg/SunScreen/man

For v3.2, install packages 1-6 10-27

• Ensure man page indices are updated:
  /usr/lib/makewhatis /usr/man;
• Run ssadm configure (v3.1:  ss_install) and document the options chosen (perhaps by saving the install session to a file with the script command - see [4]). Sample settings: Stealth, Remote Admin, Self issues certs. It will ask for the Admin station ID, you can get this by running skipstat -a on the Admin station.
The ssadm configure options can also be given on the command line (see the -h option), for example:
ssadm configure -i eri0 -t STEALTH

Finally, allow the Solaris OS to be hardened.
• Install the latest patch and reboot.
• Optional: Stop the remote GUI  HTTP daemon, if you intend to administer via the CLI, run the command 'htserver disable efshttpd' and:
vi /usr/lib/sunscreen/lib/ss_boot
[comment the line "#$LIB_DIR/run_httpd start"] • Optional: Enable logging of error and default drops to syslog (only do this if you have enough disk): ssadm debug_level 1001 #### 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. • GUI: Start Hotjava to connect to the Sunscreen and show the Sunscreen configuration GUI. hotjava http://myscreen:3852 • Command line: Login, list active configuration, logout ssadm -r myscreen login admin admin ALL access <3CE6C04BA23BF9D5> ssadm -r myscreen active Active configuration: myscreen default Initial.2 Activated by root on Fri Mar 03 11:16:13 2000 ssadm -r myscreen logout 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 172.17.17.211). ssadm ha init_secondary eri1 172.17.17.211 On the primary, not add the secondary to the cluster, and synchronise the current policy to the secondary (assume secondary IP address is 172.17.17.207). ssadm ha add_secondary 172.17.17.207 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. HA_STATUS ON HA_MODE PASSIVE HA_DAEMON ON PRIMARY_HOST fw1 fw1 PASSIVE fw1b ACTIVE 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. HA_STATUS ON HA_MODE ACTIVE HA_DAEMON ON PRIMARY_HOST fw1 fw1 ACTIVE fw1b PASSIVE 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.
HA_STATUS ON
HA_MODE ACTIVE
HA_DAEMON ON
PRIMARY_HOST fw1

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:

/usr/lib/sunscreen/lib/remove-efs \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 172.17.17.211  (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 172.17.17.207     (IP of secondary, HA interface)
ssadm activate MyPolicy

#### Patches

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

sunsolve.sun.com
ch.sunsolve.sun.com/pub-cgi/show.pl?target=patchpage
sunsolve.sun.ch/pub-cgi/show.pl

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.

#### Configuration

##### 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 176.17.17.0 (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 176.17.17.0 255.255.255.0 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

Notes:
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 touch $SSADM_TICKET_FILE; chmod go=$SSADM_TICKET_FILE

Note: if more than one screen is managed, then either:
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
• Netscape will not run as well as HotJava. Stick to Hotjava.
• Connect to the sunscreen:
hotjava http://myscreen:3852
• When the Sunscreen <=> Admin communication doesn't work, hotjava just says there was a timeout. That is when the fun starts. See the troubleshooting section.
2. Command line Tips
• ssadm is the main command line interface, that can be used locally or remotely, some of the interesting man pages in section 1m are:
• Using the example in Figure2, we could setup the sunscreen as follows, assuming we want the Inside network to access the outside network via DMZ proxies (email and http), and allowing direct ping & traceroute.
ssadm edit test
edit>
add address Outside  GROUP {"*"} {dmz  Inside}
# Network Interfaces
add interface qe2 SPF qe2 ICMP PORT_UNREACHABLE LOG SUMMARY
add interface qe0 SPF qe0 ICMP PORT_UNREACHABLE LOG DETAIL
add interface qe1 SPF qe1 ICMP PORT_UNREACHABLE LOG SUMMARY
# Rules - email
add rule ALLOW smtp         Inside            mailgate LOG NONE
add rule ALLOW smtp         mailgate          Outside LOG  NONE
add rule ALLOW smtp         Outside           mailgate LOG NONE
add rule ALLOW dns           mailgate         Outside LOG NONE
# Rules - general
add rule ALLOW ping          dmz              Outside LOG NONE
add rule ALLOW traceroute dmz        Outside LOG NONE
add rule ALLOW ping          Inside           dmz      LOG NONE
add rule ALLOW ping          Inside           Outside LOG NONE
add rule ALLOW traceroute    Inside           Outside LOG NONE
# Rules - http proxy
add rule ALLOW http          Inside           http_prox  LOG NONE
add rule ALLOW http          http_prox        Outside    LOG NONE
add rule ALLOW dns           http_prox        Outside    LOG NONE
edit> save

ssadm activate test 

Note:
1. These rules are simple, in the real world the http proxy may need access to servers on non standard ports such as 8080, 8081, 8888, etc. No provision for HTTP over SSL is listed either.
2. "LOG NONE" is not needed in the rules above as it is the default, being explicit doesn't harm however.

• Documenting an existing policy: first find out what the active policy is with the command ssadm active, then, assuming test1 is the active policy:
 ssadm edit test <<EOF > test_policy.txt list accesslocal list accessremote list screen list interface list rule list address list service EOF
A more complete script is available too: get_policy.
3. Things to watch out for
• The Administration Station cannot ping the screen, since only the web-based remote administration communication is allowed by default. To allow a ping from Admin station to screen add "ping" to the Remote Administration service group.
On v3.1 and earlier:
add service "remote administration" GROUP ss_admin ping ssh
On v3.2:
add service ss_admin SINGLE FORWARD tcp PORT 3852-3854  add service "remote administration" GROUP ss_admin ping ssh
• Copy exiting policies rather than create new ones, otherwise once you activate the new policy, the administration host will no longer be able to communicate with the Screen (SKIP ID and remote access rules are not configured on new policies).
• Be careful, changing an address object (for example) on one policy changes all others on that Screen (including 'Initial').
• The order of rules is important, rule are interpreted in strict numerical order. Example: if a pass rules matches traffic, and a matching deny rule follows, it will have no effect. The first matching rule is applied, so put all deny rules at the top of the rule list.
(On the command line, use "replace rule 1" to insure that a rule is inserted as the first, but this will remove existing rule 1. One could also "insert rule 1" to ensure that existing rule 1 is not overwritten, but then duplicates can be inserted. Your choice.)
• When saving a policy, if the error "lock not held" occurs, a write lock is held, to display the current lock for policy 'Initial': ssadm edit Initial -c lock_status
or ask for a lock: ssadm lock -w Initial
or reset the lock for policy 'Initial':  ssadm lock -c Initial
• To log packets that are dropped to syslog (kernel facility), because they have not matched a rule, a debug flag can be set as follows:
 ssadm debug_level 1001 Current debug level is: 00001001<ERROR,DEFAULT_DROP>
The default level is 1 (Errors only). Switching on such additional logging can generate huge logs and will affect performance. The use of this debug option is poorly documented. See Appendix B of the Reference manual.  See also  ssadm debug_level ?
Another example:
ssadm debug_level 00182421
Current debug level is: 00182421<ERROR,STATE,SKIP,SKIP_TEST,SPF,HALB>
• If you want to block all rpc services, you need to block "rpc all", "rpc tcp all", port 111/tcp, port 111/udp.
• Many services are defined, but many more are missing. A list of additional services definitions that you may find useful is listed in services_list.txt
• To check that the Sunscreen is actually active on a particular interface, ifconfig can help:
 ifconfig eri0 modlist 0 arp 1 ip 2 efs
• When sunscreen rules are changed and then activated, the existing network connections are not stopped and re-checked against the rules. So if the new rules you added are intended to actually block current sessions (as opposed to new ones), the connection tables need to be flushed:
ssadm lib/statetables -f
Warning: this will reset ALL existing connections (e.g. ftp transfers)
##### Troubleshooting SKIP
• Check that the time/date is synchronized between sunscreen and Admin station.
• If the Admin Station can no longer contact the Screen, try logging in locally and activating the 'Initial' policy - if communication works now, the problem is in the certificate/user configuration of the policy that was active beforehand.
• Tools like "ping" cannot be used to check Sunscreen <=> Admin station connectivity, only the EFS Administration protocols are allowed (unless you change the rules).
• Run a snoop on the Sunscreen (on the admin interface), although the SKIP protocol is not understood it will show what IP handshaking is taking place. "snoop -v ADM_STATION" shows IP and TCP/UDP port numbers. If you see several UDP packets from the Admin to the Sunscreen and then the Admin sends an ARP request for the Sunscreen's address, it probably means the Admin is sending SKIP packets to the Sunscreen and the Sunscreen is silently dropping them. Snoop shows SKIP packets as IP port 57.
• When booting either Admin or Sunscreen, watch the console messages carefully.
• Rebooting either Admin or Sunscreen may help.
• Admin Station: Run skiptool (or skiptool INTERFACE if there are several network interfaces) and/or command line tools such as the following:
 skiphost -h -i le0 Show packet stats for interface le0 skiphost -i le0 -V List current ACL on le0 (or check /etc/skip/acl.le0) If the screen is not listed, it will need to be added with a command like: skiphost -i le0 -a SCREEN_NAME -v 2 -k DES-CBC -t RC4-40 -m MD5 -r 8 -R SCREEN_KEY -s 8 -S ADMIN_KEY  - Replace SCREEN_NAME with the host name, SCREEN_KEY with the mkid value from the command "skiplocal -l -v" run on the screen, and - ADMIN_KEY with the nsid value listed at the bottom of the command "skipstat -a" on the admin station. - Make sure the keys are prefixed with a "0x".I've also had problems with the ACL being reset after a reboot. If this happens, add the commands you used above to add ACL entries, to /etc/skip/acl.le0 (or /etc/skip/acl.hme0 depending on your configuration), or manually save the skip settings: skipif -i all -s skiphost -i le0 -P List current ACL on le0, script format skipstat SKIP stats skipstat -a Detailed stats, plus local key id. skiphost -i le0 -a host1 Enable clear-text communication with machine "host1" skiphost -i le0 -d host1 Disable host1 - remove from access control list skiphost -i le0 -o on Switch on SKIP skiphost -i le0 -o off Switch off SKIP skipd_restart Restart the skip daemons
• Sunscreen commands for checking skip:
skipstat                                                  SKIP stats
skipstat -a                                              Detailed stats, plus local key id.
skiplocal -l                                               List local certs
skiplocal -x                                              Print out all you need to add SKIP key to peer.
skipdb -l

On the Sunscreen management interface, check certificates:
list certificate
• Try logging in manually from the Admin to Screen:

and watching snoop on the Screen at the same time, and/or checking the log  /var/log/skipd.log on both Screen and Admin station.
• If SKIP really won't work at all for you, and you need to urgently transfer files for example, then SKIP and the firewall on the management interface can be disabled:

On the SunScreen, remove the Sunscreen from the stack on the management interface (le0 in this example):
 % /sbin/ifconfig eri0 modlist 0 arp 1 ip 2 efs 3 eri % /sbin/ifconfig   eri0 modremove efs@2

On the Administration station, remove the SKIP ACL entry for the sunscreen (assume sunscreen has address 176.17.17.4 and the Administration station uses interface eri0 to talk to the sunscreen):
% skiphost -i eri -d 176.17.17.4

Now you can freely use ping, or SSH (if SSH is installed as a daemon on the Sunscreen), or whatever services are open in either direction.

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

• Example commands:

 ssadm log -U "Sean: emptied log" get_and_clear | ssadm logdump -i - -D -t a | more

Download and empty the log for later processing:
 ssadm log -U "Sean: emptied log" get_and_clear > /tmp/log.date +%y%m%d.date +%H%M;

Dump the log in verbose summary mode, show all entries for host 176.17.17.4:
 ssadm log get | ssadm logdump -i - -D -t a -V host 176.17.17.4 | more

Viewing the logs almost real-time, on a machine with little traffic (5 second refresh).....
[using the
sh or ksh shells]
while true; do sleep 5; ssadm log get_and_clear | ssadm logdump -i - -ta


• Scripts to manipulate log locally on screen:

#!/bin/sh ## Get Sunscreen log, empty, and make text reports. ## Save logs with date.time prefix now=date +%y%m%d.date +%H%M; ignore='not 179.1.1.1..179.1.2.255 not 10.10.10.144' echo "Get log..\c" ssadm log -U "get & empty log on uname -n" get_and_clear > log.$now echo "make summary..\c" ssadm logdump -i - -D -t a -V$ignore < log.$now > summ.$now echo "make detail.." ssadm logdump -i - -D -t a -v $ignore < log.$now > detail.$now compress log.$now ls -l *.$now* echo "done.". • Analyse a previously compressed log, ignore specific hosts and services and print the remaining entries to stdout (give the log name as first parameter): #!/bin/sh /usr/local/bin/zcat$1 | ssadm logdump -i - -D -t a -V not 176.17.17.255 and not broadcast and not port route and not port 164 and not host alice_pc and not host bob_pc

• A more complex script to manage several screens, check the current policy, get packet statistics, get and clear the log remotely via the Admin Station, archive and deliver a compressed analysis by email is sslog.
• It can happen that logs fill up the disks;
- Emptying the log with "ssadm log clear" doesn't help. the disk space remains full.
- What does work is to delete old logs and then reboot.
- To delete logs older than 400 days:
find /var/opt/SUNWicg/SunScreen/logs -xdev -type f -mtime +400 -exec rm {} \;
- To list files older than 400 days:
find /var/opt/SUNWicg/SunScreen/logs -xdev -mtime +400 -ls
- Another place where files can accumulate over the years is the configurations in /etc/opt/SUNWicg/SunScreen/configs/default
- Set the LOGSIZE parameter appropriately, which limits the maximum size that logs can have.
• On a large firewall, the logs can be gigantic, and thus too big to analyse.
• Use LOG NONE for most rules
• If you don't rely on the screen logs for intrusion detection, use LOG NONE for the noisy interfaces.
• Use LOG SUMMARY or LOG SESSION for rules where auditing is needed or when testing new rules
• Use specific DENY rules to avoid logging (e.g. many users have badly configured PCs that attempt to mount SMB shares on the Internet, but this isn't allowed by policy. Explicitly DENY this service with LOG NONE, so it doesn't appear in your logs.
If host or network addresses have changed, but constant attempts to connect to the old addresses are made, add specific DENY rules.
Create an address group for attacker hosts, with all traffic denied. Add hosts to this group that are constantly scanning and probing your firewall.
• If logs are very big, analyse the Inside interface first, there may be less noise and problems can be more quickly detected.
• Download, clear, compress and archive logs regularly, to keep log size small (easier to analyse) and keep disk space free on the screen.
• Troubleshooting rules: It may not be obvious whether packets are being blocked due to firewall rules, anti-spoofing, network routing problems etc.  Some tips:
• Check the that the address of the target (e.g. 176.17.17.2) is in the address groups and rules that you expect
referlist address 176.17.17.2
• Empty logs and setup snoops on the filtered interfaced of the Sunscreen (yes, the Sunscreen allows you to snoop traffic on the interface before the firewall engine gets it - a brilliant feature for CLI fans). Some examples:
snoop -d qe0 host 176.17.17.2 and host 176.17.2.1 snoop -d qe1 host 176.17.17.2 or host 176.17.2.1
##### Availability & backups
• High Availability mechanisms are available in both routing and stealth mode (V3.0b or later).
• Full redundancy: One reader with a large firewall suggests using Linkproof from Radware for complete redundancy and true load balancing. This solution was far superior to BGP4 and autonomous systems.
• Policy backups
• ssadm backup and  ssadm restore can be used to save all objects including private keys (be careful who has access to these backups, since they can compromise the encrypted channels).
• All (non-rule) default objects, common to all policies are stored in /etc/opt/SUNWicg/SunScreen/configs/default/Registry. In particular interface definitions, SKIP certificates etc. are defined. Don't change it, but you can back it up.
• Specific Policies are stored on the Screen in /etc/opt/SUNWicg/SunScreen/configs/default/POLICY in readable text files. Don't change them, but you can back them up. These policies include a reference to the Registry file above and then specify their own objects.
• Assuming you have one spare screen for a number of active screens, and are not using HA, a simple Warm Standby can be configured: Configure a spare screen, ready, but with no policy installed. When an active screen fails, install the appropriate policy from the command line (using your manual configuration text file), activate and plug in the interfaces. Check the logs to ensure that all is working as expected. Depending on how fast the problem is detected, the switch-over can happen in, say, 10 minutes.
• Adding UPS, raid disks, redundant power supplies etc. can all reduce downtime, without requiring special software. Likewise, choose new(ish), proven hardware, but not so old as to have an increased probability of failure.

#### Analysis

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?
• Transparency (in Stealth mode): it acts like a bridge and has no IP address, making it difficult to attack. This advantage is not to be underestimated. In large firewalls, to increase "diversity of defence" a stealth firewall can be used on the "outside" interface of a DMZ and a routing firewall on the "inside" interface of the DMZ.
• The Sunscreen has both a GUI and command line, that work in harmony. (The lack of harmony is what I dislike most about the Firewall-1.)
• The powerful command line, that allows automatic scripting, can be used locally (e.g. via serial console line) or remotely. Few firewalls can claim this.
• Sun's proven SKIP encryption is used.
• Solaris can be (optionally) hardened at the end of installation.
• Works on both the Intel and many SPARC hardware (with Solaris), allowing the hardware speed and cost to be adapted to budget or network speed.
• Performance: One reader reports running a Sunscreen on a 3 CPU E450 to filter 34Mbits/s, I've used a SPARC 5 and Ultra1 for 2Mb traffic.
• It is robust and reliable.
• The filters are stateful and filter most TCP/IP protocols and services. Non IP protocols (such as IPX) can be filtered by Ethernet packet type. New user defined services (based on port ranges) may also be filtered.
• Rules can be active only at certain times of day and have a comment field.
• NAT (Network Address Translation).
• Each time a change is made to the policy and activated, the policy number is incremented and the previous policy is stored and can be reactivated later, if needed. This provides and excellent method of backing out policy changes that have caused problems.
• Rule can be time based, only active at certain times/days. For example:

add time weekdays8-21 MONDAY{8:00 21:00} TUESDAY{8:00 21:00} WEDNESDAY{8:00 21:00} THURSDAY{8:00 21:00} FRIDAY{8:00 21:00}
add rule ALLOW ftp server1 Internet LOG NONE TIME weekdays8-21

• Mixed mode: The EFS can do both routing and stealth on the same box at the same time (on different interfaces of course), the catch is that traffic can't be exchanged between stealth and routing interfaces.
• Sun bundle "EFS lite v3.1" with Solaris 8 6/00 (or later) and provide it as a free download on the web. EFS Lite only runs in routing mode, no HA, can be a CMG member (but not admin), has limited NAT (max. 10 addresses with 2 translation rules) and supports two interfaces.
It is interesting for protection of network communication on the host level, or for a small SOHO network.
• Price:
• For years, the Screen was reserved for large corporate firewalls. V3.0 has now a cheap-ish workgroup version.
• Sun bundle EFS lite with the current Solaris 8 (see above), although a cut down version, it is nevertheless useful.
• The full version 3.2 is to be bundled for free with Solaris 9!
##### Problems: What needs to be improved?
• Documentation (v3.0) is good, but could be much better. Detailed example architectures and configurations are missing. The configuration and administration guides overlap. Sun promise that the EFS 3.1 docs have much better examples. Sun also have a series of 'cookbook' articles for setting up HA, proxies, migrating from SPF200 etc. (so ask your Sun contact for these docs if you're having difficulty).
• Security
• The "ssadm -r SCREEN login" command forces the use to enter the password in clear text, and it will be visible in the process list and shell history. It should be possible to enter the password interactively and not echo to the terminal.
• The OS Hardening carried out by the installation script could be better.
• The International version has a very weak 40bit encryption level.
• VPN
• SKIP is dated and needs to be replaced with an accepted standard such as IPsec. Apparently IPSec is included in version 3.2, but badly documented and very difficult to use.
• Snoop does not understand SKIP packets.
• SKIP is difficult to troubleshoot, and if you have it wrongly configured, the Screen GUI and command-line won't help you at all.
• No support for IPsec or SSH.
• Ease of use
• Command line interface (CLI):
• The command line log tool allows filtering by log severity and service, but this made little difference on the test system (with a 5MB log), for example:
- if logsev info is used, only authentication packets are shown (other levels show nothing).
- if logapp edit is used, nothing is shown (whereas one would expect an ssadm-edit session to have been logged and be filtered in this way).
The logged reason for a packet which has no rule, or one which is dropped because of a deny rule is the same.
• ssadm-edit command line:
- Commands are not logged. With Version 3.1 or later, ssadm edit (and the GUI) logs when changes are saved to a policy or the common objects.
- Ranges of rules cannot be deleted, only specific rule numbers.
• When using ssadm remotely, one must first login with ssadm -r screen login admin password, the environment variable SSADM_TICKET_FILE must point to a file where an authentication 'ticket' is written.
Problem: if more than one screen is managed, then either:
a) Only into one screen at a time (ssadm login/logout)
b) Specify separate a SSADM_TICKET_FILE for each screen, not a common one.  Painful. The ticket-file should store multiple tickets.
• The GUI is primitive. While better than the Sunscreen 100 and 200, it can be painfully slow and quirky.
• Searching the logs in a important function, the log viewer is not polished enough and better documentation is needed (note: at least the command line allows writing of useful scripts).
• It would be useful if the rule number (where relevant) was listed in the log.
• Setting up a new firewall policy can difficult and error-prone. In particular, the administration certificates need to be manually attached to a policy before it is activated, otherwise the Administration Station will no longer be able to communicate with the Sunscreen (and you can go very grey fixing this).
Workaround: copy the Initial policy and add objects/rules, don't create "new" policies.
• The Sunscreen 100 and 200 were very easy to install: put in the CD and configuration floppy, switch off and on and a voice message would tell you that it was running after 40 minutes or so. This "appliance" like simplicity has been lost with the added functionality and increased hardware support of the EFS3.
• Functionality
• The log browser GUI needs improvement.
• There are no engines for Microsoft protocols/applications, such as Exchange, SMB file shares, printer shares, domain authentication etc.
• Rules don't have an "expiry date".
• The user cannot define new state engines.
• The length of lines added to the ssadm command line are limited, e.g. long lists of hosts cause problems.
• Assurance
• It is not ITSEC approved (see [3]). Apparently the old EFS 1.1 was ICSA certified, but ITSEC is really the certification level to aim for.
• Source code is not provided.
• Stability: The Screen is very stable (the author has used the 100 & 200 also for years), but:
• It happened a few times that the Admin Station could not contact the screen, during initial configuration. Rebooting the screen helped. This seems to be a SKIP problem.
• The Admin station crashed several times when giving incorrect parameters to "ssadm -r log" (during script testing).
• I've heard one report of HA clustered sunscreens hanging so badly that they have to be switched on/off.

#### Recommendations

##### General
• If you're not a firewall expert, follow a course with Sun, or give yourself time to read the entire documentation [1] (especially the release notes) and test several configurations. Few firewalls (if any) are trivial to setup, the Screen is no exception.
• Document your architecture and policy first, then install.
• Install a fresh copy of Solaris and harden it, before installing the Sunscreen Software (see also [2])
• Install on an isolated, or well protected subnet.
• Operate a private, non routed network between the Administration Station and the Screens, rather than relying on SKIP to protect administration traffic (this is also called out-of-band management). i.e. install an additional interface on the Admin Station for this private network.
• Copy the initial configuration for new policies, rather than creating new (empty) policies.
• Test your configuration with tools such as  nmap, rpcinfo, nbtstat, telnet, ftp, ping, traceroute etc.
• Use the command-line, not the GUI for administration. To disable the web interface:
 mv /opt/SUNWicg/SunScreen/lib/run_httpd /opt/SUNWicg/SunScreen/lib/run_httpd.STOPPED mv /etc/rc2.d/S95http /etc/rc2.d/_S95http
##### 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:

• Use a separate private network (rather than your Intranet for example) for administration. If a connection between this network and the Intranet is needed, install a second interface in the Administration station.
• Use a dedicated Administration Station, not a server. Only the administrator may have a user account on this host.
• Harden the Administration Station as if it was a bastion host (see [2]). Do not allow non administrative accounts, or weak services like RPC, NFS, telnet etc. Use SSH (not rlogin/rsh/telnet). Run minimal services only.
• Monitor the syslog, last log (with a tool such as logcheck or swatch) and system files (via an integrity checker such as tripwire), at least daily.
• If "ssadm -r " is used to manage screen, remember that once logged in, the Screen trusts the Admin station completely. So always do an "ssadm -r MyScreen logout" when you are finished.
• Disable saving of history commands in your shell.

#### 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: java.io.IOException: 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:

"RC4-40" MAC "MD5" COMPRESSION "NONE" MASTER "master" CDP ROUTING NIS

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:

/etc/opt/SUNWicg/SunScreen/.master_ticket

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

#### References

[1] SunScreen Securenet www.sun.com/software/securenet/index.html

[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
www.sun.com/blueprints/0901/sunscreenlite.html

Sunscreen Lite install documentation is now available online
docs.sun.com:80/ab2/coll.557.2/SSCRNLITEINST

Protect yourself with SunScreen Lite - Mark Thacker
www.elementkjournals.com/sun/0105/sun0151.htm

Sun www.sun.com   docs.sun.com
SKIP www.skip.org
Sunsolve sunsolve.sun.com
Sunscreen Discussion forum
supportforum.sun.com/cgi-bin/WebX.cgi?13@79.Ms77aI8ZfRM%5e0@.ee88cae

Command-line Interface, by Philip Brown www.bolthole.com/solaris/sunscreen.html

Notes by Vu Pham pluto.sivell.com/~vu/solaris/sunscreen_doc.html

29.Mar'00  Links to docs.sun.com  Dok ID 1885, securityportal.com/articles/sunscreen20000403.html
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