By Seán Boran
www.boran.com/security/sp/SunscreenEFS.html
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.
The SunScreen is a firewall from Sun [1] which can be operated in two modes:
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.
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.
|
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).
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.
| 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: |
for example with v3.2:
pkgadd -d .
1-6, 10-27
/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
| 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: /usr/lib/makewhatis /opt/SUNWicg/SunScreen/man |
For v3.2, install packages 1-6 10-27
/usr/lib/makewhatis /usr/man;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.ssadm configure options can also be given on the command line (see the -h option), for
example:ssadm configure -i eri0 -t STEALTHvi /usr/lib/sunscreen/lib/ss_bootssadm debug_level 1001
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:
Finally, check out the communication from Administration to Screen.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
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
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.207This 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 ACTIVENow 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 PASSIVENow 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
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:
/usr/lib/sunscreen/lib/remove-efs(when rebooting make sure there are no traces of sunscreen)
\rm -rf /etc/sunscreen /etc/skip /var/sunscreen
init 6
Add packages & reboot:
cd /opt/install/SunScreen_3.2/sparc/[Select "1-6, 10-27"]
pkgadd -d .
ssadm ha init_secondary eri1 172.17.17.211(IP of primary)
init 6On the primary, Setup the Firewall as usual, test, activate policy. Then setup the cluster:
ssadm ha init_primary eri1(HA interface)(IP of secondary, HA interface)
ssadm ha add_secondary 172.17.17.207
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 packaging105237-09 SunScreen EFS 1.1: miscellaneous fixes including NAT
106881-03 SunScreen EFS 2.0: NAT, MP, and FW-1 conversion fixes108156-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 2003See also
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.
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).
ssadm policy -c Initial test
ssadm edit test
edit>list screenedit>
...
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 testNotes:
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_FILENote: 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.
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.
ssadm edit test
edit>
# Addresses:
add address router1 HOST 176.17.17.1
add address router2 HOST 176.17.17.2
add address http_prox HOST 176.17.17.3
add address mailgate HOST 176.17.17.4
add address dmz RANGE 176.17.17.3 176.17.17.255
add address Inside RANGE 176.17.16.0 176.17.16.255
add address Outside GROUP {"*"} {dmz Inside}
add address qe1 GROUP {Outside} {}
add address qe0 GROUP {dmz} {}
add address qe2 GROUP {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.
ssadm edit test <<EOF > test_policy.txt
list accesslocal
list accessremote
list screen
list interface
list rule
list address
list service
EOFadd service "remote administration" GROUP ss_admin ping
sshadd service ss_admin SINGLE FORWARD tcp PORT 3852-3854
add service "remote administration" GROUP ss_admin ping
ssh
ssadm debug_level 1001
Current debug level is: 00001001<ERROR,DEFAULT_DROP>
ssadm debug_level ?ssadm debug_level 00182421
ifconfig eri0 modlist
0 arp
1 ip
2 efs
ssadm lib/statetables -f| 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: |
| 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 |
/var/log/skipd.log on both Screen and Admin station. 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.
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).
Download, empty the log and view:
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
#!/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.".
#!/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
find /var/opt/SUNWicg/SunScreen/logs -xdev -type f -mtime +400 -exec
rm {} \;find /var/opt/SUNWicg/SunScreen/logs -xdev -mtime +400 -lsreferlist address 176.17.17.2
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
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).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.
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
mv /opt/SUNWicg/SunScreen/lib/run_httpd /opt/SUNWicg/SunScreen/lib/run_httpd.STOPPED
mv /etc/rc2.d/S95http /etc/rc2.d/_S95httpThe 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:
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:"secondary" ADMIN_CERTIFICATE "secondary.admin" KEY "DES-CBC" DATA
"RC4-40" MAC "MD5" COMPRESSION "NONE" MASTER "master" CDP ROUTING NIS
ADMIN_IP 10.0.0.2If 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.
[1] SunScreen Securenet www.sun.com/software/securenet/index.html
Download Sunscreen EFS lite www.sun.com/software/securenet/lite
Sunscreen V3.0 Online docs
Admin Guide
Installation Guide
Reference Manual
Release NotesSunscreen V3.1 Online docs
Admin Guide
Installation Guide
Reference Manual
Release NotesSunScreen 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
www.itsec.gov.uk
www.itsec.gov.uk/cgi-bin/prodlist.pl?prodarea=Networking
[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.htmlSunscreen Lite install documentation is now available online
docs.sun.com:80/ab2/coll.557.2/SSCRNLITEINSTProtect yourself with SunScreen Lite - Mark Thacker
www.elementkjournals.com/sun/0105/sun0151.htm
Further reading:
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@.ee88caeCommand-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
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 |