October 25, 1999. This article presents a concise step-by-step approach to securely installing Solaris for use in a firewall DMZ, or other sensitive environment. There are many books and web articles on general hardening, but deciding exactly how to do it for your Solaris system can be tricky.

The focus in this article is on preparing the Operating System to securely run services, rather than the setup of the services themselves. Firewall engines like Raptor, Firewall-1, Sunscreen etc. are not examined here.

This article is specific to Solaris 2.7, other versions are similar, but will have some differences in startup file names, kernel parameters etc. 
This article has been updated since the original release, see the Additional Notes section.

We welcome your feedback on this article.

---

We divide up the process into the following steps:

1. Preparation
2. Initial OS installation
3. Stripping/configuring OS: 1st pass
4. Connect to test network
5. Installing tools & sysadmin software
6. Stripping/configuring OS: 2nd pass
7. Create Tripwire image, backup, test
8. Install, test, harden applications.
9. Install on live network, test

Additional Notes
References

---

1. Preparation

• Keep things simple: it is expected that only one or two services will run on a host. Use several machines, rather than one superserver that does everything. It's easier to isolate applications, harden and troubleshoot. Be minimalist, only run what is absolutely necessary.
• Hardware: Consider installation via the serial port console, get rid of the keyboard, screen and framebuffer. i.e. avoid using X11 and get to know the command line. Have an isolated, trusted network available for testing.
• Know exactly what the system is supposed to do, what it's hardware configuration will be etc. hardening is generic and make break certain functions. e.g. If you like to use CDE/OpenWindows or Disksuite, it needs RPC to run but you really don't want RPC running on a firewall host, if at all possible (for instance I prefer manual mirroring with a cpio script for warm standbys, rather than Disksuite).
• It's important to understand how the applications work (how they use ports, files), to judge what hardening is possible and to assess the risk posed.

---

2. Initial OS installation

Connect the serial console, switch on, halt to the OK prompt by sending a Stop-A (~#, ~%b, or F5 depending on whether you use tip, cu or a vt100 terminal), then start the installation procedure -
"boot cdrom - install".

Install the minimum end user bundle (unless you really need the additional server/developer tools), set hostname, terminal, IP parameters, timezone, etc. Don't enable NIS or NFS. Don't enable power management.

Choose manual disk partitioning: Keep /usr and /opt separate from root, so that they can be later mounted read-only (see below). Consider a separate, large /var filesystem for syslog/web/news/proxy servers. Servers containing lots of data (web, ftp) should use a separate disk for their data.
If you don't wish to mount partitions read-only, then put the whole boot disk under root.
Suggestion for a 2GB disk: 200MB / (+var), 200MB swap,  600MB /usr and 1GB on /opt.
Suggestion for a 1GB disk: 300MB / (+var+opt), 200MB swap,  500MB /usr.

Set a strong password (7 or 8 chars with numbers, letters and punctuation) for root, then reboot.

Install the recommended & security patches from Sun. Typically a separate CD is provided with a patch bundle. Reboot and logon again as root. The list of patches installed can be listed with showrev -p .

---

3. Stripping/configuring OS: 1st pass

Disk mounting: To reduce the risk of trojan horses and unauthorised modifications, in /etc/vfstab, mount / with options "remount,nosuid", /var with "nosuid", /tmp with "size=100m,nosuid" (allow /tmp to only use 100MB of swap space and disallow execution of SUID programs).

The following commands assume you use the C-Shell.

Disable NFS :

rm /etc/rc2.d/{S73nfs.client,K28nfs.server} /etc/rc3.d/S15nfs.server /etc/dfs/dfstab

Disable Sendmail daemon. Although sendmail is not running as a daemon, the binary is still present and email can be sent from (but not received by) the host. The only host that needs to receive email, the mail gateway, should use smap or an equivalent to minimise sendmail risks.

rm /etc/rc2.d/S88sendmail
And add a root cron entry to process the mail queue hourly:
0 * * * * /usr/lib/sendmail -q

Disable more services (automounter, power mgt., serial protocols, caching fs, etc.):

rm /etc/rc2.d/{S74autofs,S30sysid.net,S71sysid.sys,S72autoinstall}
rm /etc/rc2.d/{S93cacheos.finish,S73cachefs.daemon,S80PRESERVE}
rm /etc/rc2.d/{S85power,K07dmi}
rm /etc/rc3.d/S77dmi
If you have server/developer packages:
rm /etc/rc2.d/{S47asppp,S89bdconfig,S70uucp}

Disable RPC: This is highly desirable, but will break some programs like CDE or Disksuite. If you don't disable RPC, then a packet filter that blocks it is an absolute must.

rm /etc/rc2.d/S71rpc

Disable printing (unless there's a local printer attached):

rm /etc/rc2.d/{S80lp,S80spc}

Disable the naming Services Caching Daemon: I've had problems with nscd and don't like daemons running that I don't trust. It might offer performance advantages however.

mv /etc/rc2.d/S76nscd /etc/rc2.d/.S76nscd

Disable CDE: unless you insisted on a graphical console?

rm /etc/rc2.d/S99dtlogin

Disable NTP - Network Time Protocol. (NTP is accurate but complex, uses bandwidth and is an additional security worry. I prefer to use rdate to one central host, which then uses NTP to get accurate time). See also the additional notes below. To disable it:

rm /etc/rc2.d/S74xntpd

Disable SNMP, unless you do really need to use HP Openview or whatever. I prefer simple ping/traceroute scripts. If SNMP is switched on, only allow read (not write) access and change the community string.

rm /etc/rc2.d/K07snmpdx /etc/rc3.d/S76snmpdx

Inetinit: Disable ip forwarding, source routing (if there is more than one network interface), and avoid echo broadcasts.  Add the following to the end of /etc/init.d/inetinit:

## hardening
ndd -set /dev/ip ip_forward_directed_broadcasts 0
ndd -set /dev/ip ip_forward_src_routed 0
ndd -set /dev/ip ip_forwarding 0
ndd -set /dev/ip ip_respond_to_echo_broadcast 0
ndd -set /dev/ip ip_strict_dst_multihoming 1

And in /etc/default/inetinit, prevent TCP sequence prediction (IP spoofing) attacks, by generating initial sequence numbers as suggested in RFC 1948.

TCP_STRONG_ISS=2

Prevent some buffer-overflow attacks by adding the following lines to /etc/system. This protects against forms of attack where the code to be executed lives on the stack. The OS won't allow the code to be executed, but it requires hardware support (it's only effective on sun4u/sun4d/sun4m systems).

set noexec_user_stack=1
set noexec_user_stack_log=1

Use default routes: add the IP address of the router to /etc/defaultrouter, or create a startup file in /etc/rc2.d/S99static_routes using the "route" command. To disable dynamic routing:
        touch /etc/notrouter

/etc/init.d/inetsvc: Disable multicasting by commenting the lines around "route add 224.0.0.0.".
Enable logging of all INETD connections: Add add "-t" to the inetd startup line at the bottom, it should read:  /usr/sbin/inetd -s -t

Configure /etc/hosts with a list of critical machines (which you don't want resolved via DNS).

/etc/inetd.conf:

• Disable everything.
• If you don't use SSH, you might need ftp/telnet. RPC programs like Disksuite will insist on having a few entries enabled, but as noted previously we want to avoid RPC.
• If you really want to use inetd services, then use them with the FWTK netacl or tcp wrappers to allow a minimal IP address based access control and decent logging.
• To list the actived inetd entries, and make sure that the correct lines
  are disabled, try this:
  egrep -v '^#' /etc/inetd.conf
• Tell inetd to re-read the configuration file:
  kill -1 `pgrep inetd`

---

4. Connect to test network

The system has now gone through a first hardening phase and should be still working! Connect it to a secure, isolated network where standard tools/software can be downloaded. Boot and log in on the console again as root. Check for error messages on the console during boot, fix if necessary.

Tools are typically copied down with ftp. Avoid using the root account on the target server and change the password to a temporary one during the downloads, change back afterwards.

---

5. Installing tools & sysadmin software

At this stage standard tools/utilities are installed, the most important being SSH. These tools should already have been compiled and tested extensively on another machine. They are typically transferred as tar files by CD or FTP. 

• Environment:

  DNS client (avoid if not needed): add domain name & DNS servers to /etc/resolv.conf. Add a DNS entry for "hosts" in /etc/nsswitch.conf.

  Email: If hosts are not supposed to send email outside the subnet, don't configure the mailhost alias. Otherwise:
  edit /etc/mail/aliases (at least point root to a real address), set mailhost in /etc/hosts, in /etc/mail/sendmail.cf uncomment the Dj line and set it to Dj$w.YOURDOMAIN.COM.
  If DNS is not configured, add a hostname.YOURDOMAIN.COM alias for this machine in /etc/hosts.
       Send a test email with: mailx -v -s test_email root </dev/null

  /.cshrc /.profile: set aliases, variables (such as VISUAL, EDITOR and PATH don't include "." ! ). Set umask to 077, or 027.

• Install SSH for login access. Configure the ssh daemon (/etc/sshd_config) so that access is restricted to named hosts with known public keys (/etc/ssh_known_hosts) and rhosts authentication is disabled. Use .shosts rather than .rhosts, if remote admin is needed.
  If telnetd/ftpd was still enabled, disable it in /etc/inetd.conf, once you have tested SSH.
• Install other necessary tools: gzip, traceroute and maybe top (without SUID) or lsof.
• Perl 5, for scripting - install & create a link to /bin/perl.
• Install security scripts in /secure, for example those used below: rotate_cron, rotate_log, wtrim.pl, rdistd. Protect /secure:  
     chmod -R 700 /secure; chown -R root /secure

---

6. Stripping/configuring OS: 2nd pass

More OS patches: The Patch CD above won't be quite up to date. Get the Patchdiag tool from Sunsolve and run it to see what recommended and security patches are needed, then download & install the missing ones.

Configure logging:

Enable SU logging to console in /etc/default/su.

Enable logging of failed attempts to login:
touch /var/log/loginlog; chmod 600 /var/log/loginlog; chgrp sys /var/log/loginlog

Syslog logging: Split up log analysis according to the example syslog.conf which enables more logging than the default and splits up services into separate logfiles. Designate one machine as the loghost (in /etc/hosts) or log locally.

Syslog "loghost"

Give the loghost a whopping great disk for logs.
Create empty logs & set permissions:
   cd /var/log; touch daemonlog authlog kernlog userlog maillog lprlog cronlog newslog locallog alertlog;
   chmod 600 daemonlog authlog kernlog userlog maillog lprlog cronlog newslog locallog alertlog;
   kill -1 `pgrep syslogd`

Use rotate_log to prune & compress logs, add the root cron entries:
## Prune syslog logs weekly, keeping the last 6 months or so:
55 23 * * 6 /secure/rotate_log -n 40 alertlog
55 23 * * 6 /secure/rotate_log -n 40 authlog
55 23 * * 6 /secure/rotate_log -n 20 cronlog
55 23 * * 6 /secure/rotate_log -n 40 daemonlog
55 23 * * 6 /secure/rotate_log -n 40 kernlog
55 23 * * 6 /secure/rotate_log -n 40 locallog
55 23 * * 6 /secure/rotate_log -n 20 newslog
55 23 * * 6 /secure/rotate_log -n 40 userlog
55 23 * * 6 /secure/rotate_log -n 10 lprlog
55 23 * * 6 /secure/rotate_log -n 20 maillog

Disable the Solaris log pruning (& other) lines in the root cron, since you're doing it yourself:

#10 3 * * 0,4 /etc/cron.d/logchecker
#10 3 * * 0 /usr/lib/newsyslog 
#15 3 * * 0 /usr/lib/fs/nfs/nfsfind
#1 2 * * * [ -x /usr/sbin/rtc ] && /usr/sbin/rtc -c > /dev/null 2>&1
#30 3 * * * [ -x /usr/lib/gss/gsscred_clean ] && /usr/lib/gss/gsscred_clean

Pruning of login & other logs:

## Empty login/logout records at year end
0 0 31 12 * /secure/wtrim.pl wtmp 20
0 0 31 12 * /secure/wtrim.pl wtmpx 20
# Solaris 2.x logs:
0 4 * * 6 /secure/rotate_log -L /var/adm -n 30 loginlog
0 4 * * 6 /secure/rotate_log -L /var/adm -n 30 sulog
0 4 * * 6 /secure/rotate_log -L /var/adm -n 2 vold.log
0 4 * * 6 /secure/rotate_cron

Crons

Remove unnecessary crons: rm /var/spool/cron/crontabs/{lp,sys,adm}
Don't delete the adm cron if you want sar performance collection or accounting .

Root cron entries:

Set date once a day with a reliable source using rdate (you may prefer NTP, it's more accurate, but complex, uses bandwidth and is an additional security worry):

## Synchronise the time:
0 * * * * /usr/bin/rdate YOURTIMEHOST  >/dev/null 2>&1

File permissions: tighten basic permissions, and restrict certain tools to root or disable:

chmod 0500 /usr/sbin/snoop /usr/sbin/devinfo
chmod o-r /var/spool/cron/crontabs/*
chmod 000 /bin/rdist
chmod o-rx /etc/security
chmod og-rwx /var/adm/vold.log
chmod u-s /usr/lib/sendmail                 #Except for mailgateways or multi-user hosts
chmod 400 /.shosts /etc/sshd_config /etc/ssh_known_hosts

Then download, compile and run Casper Dik's script ftp://ftp.fwi.uva.nl/pub/solaris/fix-modes.tar.gz for improving file and directory permissions (runs on Solaris 2.2-2.7).

Documentation:

Document configuration changes in a text file such as /etc/mods, update after each change, with date, author, files affected, description.
cat > /etc/mods <<EOF
15.11.99  sb  New install of Solaris2.7 & tools according to hardening guidelines V1.03
EOF

Set login banners to warn users about unauthorised access (you'll need this if you want to prosecute intruders). For Telnet and SSH, use /etc/issue (for pre-login) /etc/motd (for post-login), containing, for example:

ATTENTION: You have logged onto a secured XXXX Corporation server.
Access by non YYYY administrators is forbidden.
For info contact YYYY@XXX.com

Reboot, login via SSH.

Now, ps -e should show a small process list:
   PID TTY TIME CMD
   0 ? 0:00 sched
   1 ? 0:00 init
   2 ? 0:00 pageout
   3 ? 0:09 fsflush
   156 ? 0:00 ttymon
   152 ? 0:00 sac
   447 ? 0:06 sshd
   88 ? 0:00 inetd
   98 ? 0:00 cron
   136 ? 0:00 utmpd
   605 ? 0:00 syslogd
   175 console 0:00 ttymon
   469 pts/1 0:00 csh
   466 ? 0:01 sshd
   625 pts/1 0:00 ps

and netstat -a should show a minimum of network connections (e.g. only SSH).

UDP
Local Address Remote Address State
-------------------- -------------------- -------
*.syslog Idle
*.* Unbound

TCP
Local Address Remote Address Swind Send-Q Rwind Recv-Q State
-------------------- -------------------- ----- ------ ----- ------ -------
*.* *.* 0 0 0 0 IDLE
*.22 *.* 0 0 0 0 LISTEN
*.* *.* 0 0 0 0 IDLE

---

7. Create Tripwire image, backup, test

• Test - Do SSH and the standard tools work? Check log entries, check console messages. Does the system behave as expected?
• When all is working fine, freeze /usr and if possible /opt:

Mount /usr and /opt read-only (in /etc/vfstab with "ro" option). This reduces the risk of trojan horses and unauthorised modifications.
Mount other partitions nosuid (SUID programs cannot assume other identities).
Reboot.
Run the mount command to check that filesystems options are effective.

• If CD-ROMS are not needed for production, disable the volume manager (one less daemon, one less security worry). It can always be re-enabled if needed later:
      mv /etc/rc2.d/S92volmgt /etc/rc2.d/.S92volmgt
  
• At this stage install tripwire (or some other filechecker that uses secure hashing algorithms), initialise it's database and run regular checks to monitor for changes. If possible keep the tripwire master database on another machine or write-once media. Even better, copy tripwire & it's database and run it remotely at regular intervals using SSH. This makes it difficult for an attacker to know that tripwire is being used to check the system. See the sample script for running tripwire, trip_host.sh.

---

8. Install, test, harden applications

Consider installing applications on a separate partition or /opt. If /opt is used, it will have to be mounted read-write during installation and testing, and switched back to read-only afterwards.

Depending on the function of the server, applications such as ftpd, BIND, proxies, etc. are installed at this point. Web servers and firewall engines in particular, are complex and require careful configuration. The following is a general checklist that servers/applications should conform to:

• Is the umask set restrictively (e.g. 022) by or before the application starts?
• Does it run as a non root user with minimum privileges? Is it's password "blocked" and shell set to a dummy value such as /bin/false? If the password is really needed, is it set to min 8 chars with numbers, letters and punctuation?
• If it runs as root, to bind to a low port, does it immediately fork to a non privileged user to minimise risks?
• Are file permissions set so that only the application user can read/write files are there are no world read/writeable files?
• Does the application write log permissions securely? Does it write passwords in the install log (don't laugh - it's common!).

A few tips for well known services

1. FTP server (ftpd):

• If you use Washington University wu-ftpd (for it's better logging, access control and other features), be wary. It has a history of bugs (e.g. see CERT advisories CA-93:06, CA-94:07, CA-95:16 and Auscert AA-97.03 and AA-1999.02). Use at least V2.6.0 or later.
• Configure /etc/ftpusers to list system accounts, so they cannot not be used for ftp e.g. disable use of ftp by root, add "root" to /etc/ftpusers.
  One way of doing this for all system accounts on your fresh new system is:
    awk -F: '{print $1}' /etc/passwd > /etc/ftpusers
• FTP can be selectively enabled per user via /etc/ftpusers or by using the following trick: For users who shouldn't have ftp access to this machine, give their accounts a non-standard shell (such as bash or tcsh) and don't enter this new shell into /etc/shells. FTP access will be denied. Conversely, if a non-standard shell is required, it must appear in /etc/shells for FTP to work correctly.
• Enable logging: adding the "-l" option in /etc/inetd.conf (the additional -d option adds debug output).
• FTP can be restricted on an IP address or hostname basis with the tcp wrappers.
• For anonymous ftp, be VERY careful. A chroot environment is a MUST. See the in.ftpd man page which includes a script. Avoid allowing uploads. If uploads are necessary, don't allow downloads of uploaded files, hide uploaded file names and don't allow them to be overwritten (otherwise you may end up as an illegal software repository).
• For normal "user ftp", chroot is also recommended.
• Put the ftp data area on a separate disk partition and mount it nosuid.

2. DNS servers:

• Use the latest BIND (Berkeley Internet Name Server) rather than Sun's named. BIND has more features, is easier to debug (with dig) and is updated quickly when security problems are found.  See  www.isc.org/products/BIND
• Use 8.2.2-P5 or later (which includes security fixes).
• Restrict zone transfers to the IP address of secondaries (in /etc/named.conf)
• A great tool for testing active domains is www.uniplus.ch/direct/testtool/dnstest.html
• Troubleshooting:
  • Use nslookup or dig to check server results.
  • Client: Check /etc/nsswitch.conf and /etc/resolv.conf if you're having DNS client side problems. Start nslookup with the "-d2" option to get buckets of debugging info. Try killing the nscd daemon.
  • Server: Use spaces and not tabs in Sun's old /etc/named.boot (bind uses named.conf). Start named with the debug option "-d" and read the console & logs. Typically logs are found in the syslog "daemon" section.
  • See www.ebsinc.com/solaris/dns.html
  • To get statistics from the name server, do the following
         kill -ABRT `cat /etc/named.pid`
    This puts the statistics into the file /usr/tmp/named.stats.
  • Send a HUP signal to named, to reread the config file after changes.
        kill -HUP `cat /etc/named.pid`

3. A good article on general chroot environments, also called "padded cells" can be read at Sunworld www.sunworld.com/swol-01-1999/swol-01-security.html

4. HTTP servers:

• If content doesn't change often, store it on CD-ROM, it simplifies change control and provides greater resilience to the hackers favourite of "site defacing". The HTTPD server will cache pages, ensuring that access speed does not depend on CD-ROM speed.
• Separate "simple read-only" content servers from E-commerce servers.
• Check out the CIAC Bulletin J-042 which describes best practices for Internet web servers.

Preparing to go live

You probably won't need CR-ROMs or floppies anymore, so disable the volume manager:
    mv /etc/rc2.d/S92volmgt /etc/rc2.d/.S92volmgt

Consider installing a script to check that important daemons are running. Install monitor_processes.pl and add a root cron entry:
## Check that important processes are running during office hours:
## [If you run 7x24 modify accordingly]
0,30 8-19 * * 1-5 /secure/monitor_processes.pl inetd sshd httpd

If partitions such as /opt or /usr had to be mounted read-write during the application install/testing, mount them read-only now.

Reinitialise tripwire (or equivalent integrity checker).

Run a network scan on the system, to ensure that only expected services are visible. A commercial tool such as ISS or a free one like Nessus, nmap or Satan should do the job. Print out the results and archive.

If possible, have additional people do the final testing, just in case something was forgotten.

Test in detail - What works? What is forbidden? Check console/log entries. Does the system behave as expected? Watch the logs very frequently during the first few days of production.

---

9. Install on live network, test

Test in detail. Check log entries. Does the system behave as expected?

Have applications been tested in detail, by different people with different points of view, from different access points on the network?

---

10. Regular maintenance

The following activities should take place hourly, daily, weekly or monthly, depending on how critical the system is:

• Check the status of patches with Sun's Patchdiag, update as needed. Be very wary of kernel patches (test on a non-production machine).
• Check all logs for errors and unusual activity: syslog (/var/adm/messages or /var/log/*, depending on syslog.conf), /var/cron/log, last, /var/adm/sulog, /var/adm/loginlog, application/server logs.
• Write scripts to report if critical daemons die, or if important systems cannot be pinged.
• Run tripwire (or equivalent integrity checker).
• Be regularly informed of new vulnerabilities and security issues, either by subscribing directly to CERT, CIAC and the vendor security lists (Sun, Microsoft, etc.) and/or, subscribing to SecurityPortal's weekly letter or the SANS monthly letter.

---

Additional Notes

This article has been very specific, in the interest of making it practical. However, each security administrator has his own methods and each site has different requirements.

• For increased security: don't just remove startup files, but also program binaries.
• use Jumpstart: for installing large numbers of hosts, or to be able to quickly produce a new hardened host (perhaps after a failure). Jumpstart is not trivial to setup, but worthwhile when installations are frequent.
• Versioning: Use RCS or CVS to manage versions of configuration files. This is especially important when several administrators manage a host, changes are frequent, etc. Versioning should also be used with Jumpstart scripts & config files.
  An alternative is to make a copy of each config file BEFORE making changes. Append a date to the file, e.g. /etc/syslog.conf.19991023.
• Time Synchronisation: If you think you might have to produce evidence in court, use NTP to synchronise time, not rdate. Prosecutions have failed because, on busy servers, a few seconds difference could be used to insist that there is a doubt about the identity of a session. (This happened to a bank in Australia trying to prosecute an Internal Attacker).
  If using NTP, either get a (cheap) radio clock (if you are near an appropriate transmitter - e.g. the Stuttgart transmitter in Germany), or setup a dedicated bastion host as a 2nd stratum NTP server, which uses 3 1st stratum sources. Setup the firewall filter to allow only NTP from the bastion to the three 1st stratums and allow Intranet hosts to query the bastion.
  NTP can also be setup for higher security by configuring DES+MD5 authentication keys on server and client, see man xntpd.
• Logging: in addition to centralised syslogs, you might like to keep an additional local copy - in case the syslog server goes down or is subjected to a denial of service attack. Make sure /var is a separate filesystem if you use local logging, to avoid root being filled and the system stopping.
• Integrity checking:
  • Tripwire (see below):
    I use the free version, but it can be tricky to get working correctly and has a few bugs. Source code is provided.
    The commercial version is a bit pricey, reports are too verbose, more configuration examples should be provided, documentation has no index, it's slow, but it is more stable than the free version, runs on NT also and offers enhanced security by cryptographic signing of policy and configuration files.
  • PGP can also be used by signing files to be protected (creating lots of signature files), then writing a script to check the validity of signatures. This will not catch permission, link, inode or modify date changes though.
  • MD5 signatures could also be used in a similar way, but the list of MD5 signatures should not be stored on the system being monitored, unless it is PGP signed or encrypted.
• Last Update to this document: V1.04/November 17th, 1999.
  Thanks to the following people for providing feedback and suggestions after the initial publication: Glenn Brunette, Andrew van der Stock, Darrel Goeddel and Kamal Kantawala.

---

References

1. Free Tools

   Top, gzip, lsof, traceroute, perl: www.sunfreeware.com
   SSH notes: www.boran.com/security/ssh_stuff.html
   TCP Wrappers www.cert.org/ftp/tools/tcp_wrappers
   SMAP & FWTK www.fwtk.org
   Rdist www.magnicomp.com/rdist/rdist.shtml
   Network weaknesses scanners: Nessus, Satan, Nmap.
   Sample tools for analysing logs:
      Logcheck www.psionic.com/abacus/logcheck
      [See also my improved version of logcheck.sh]
      Swatch  ftp://ftp.stanford.edu/general/security-tools/swatch

2. Security Portal Research Centre:
   Firewall products www.securityportal.com/research/research.firewalls.html
   Firewall white papers www.securityportal.com/research/research.whitefaqfire.html
3. Tripwire:
   • Free version V1.2 www.cert.org/ftp/tools/tripwire (last updated in 1994).
   • Commercial Version www.tripwiresecurity.com (starts at $495.-/server) also runs on NT.
4. Sunworld security columns www.sunworld.com/sunworldonline/common/swol-backissues-columns.html
   Solaris Security FAQ www.sunworld.com/common/security-faq.html
   Padded Cells: www.sunworld.com/swol-01-1999/swol-01-security.html
5. Education: A good reference for any security issue is the SANS Security Roadmap.
   Visiting the SANS security conferences is also worthwhile, they have a workshop on Hardening Solaris, among many other interesting courses.
6. CERT Advisories: www.cert.org