Firewalls are one of the fastest growing technical tools in the field of information security. However, a firewall is only as secure as the operating system it resides upon. This article will take a step by step look at how you can best armor your Solaris box, both Sparc and x86. These steps can apply to any situation, however I will be using Check Point FireWall-1 on Solaris 2.6 as an example. At the end of this article is a script that you can download that will automate most of the armoring process, to include implementing TCP Wrappers.

Installation
The best place to start in armoring your system is at the beginning, OS installation. Since this is your firewall, you cannot trust any previous installations. You want to start with a clean installation, where you can guarantee the system integrity.

Place your system in an isolated network. At no time do you want to connect your unprotected system to an active network nor the Internet, exposing the system to a possible compromise. I personally witnessed a newly installed system scanned and rooted within 15 minutes of connecting to the Internet. To get critical files and patches later, you will need a second box that acts as a go between. This second box will download files from the Internet, then connect to your isolated, configuration "network" to transfer critical files.

Once you have placed your future firewall box in an isolated network, you are ready to begin. The first telnet. If the connection is rejected by the access control list, then the connection is dropped.

Many of you may be wondering why would a firewall need TCP Wrappers, the firewall does all that for you. The answers are simple. First, in case the firewall is compromised or crashes, TCP Wrappers offer a second layer of defense. Second, and just as important, TCP Wrappers protect against Firewall misconfigurations. I have often seen firewalls misconfigured, especially in VPN situations, allowing unauthorized users access to the firewall. Third, TCP Wrappers add a second layer of logging, verifying other system logs.

You can get TCP Wrappers from Wietse Venema's Website. Once again, be sure to use your go between system to retrieve and compile TCP Wrappers. We do not want any compilers on the Firewall and we want to protect the armored Solaris box within its isolated network. Once downloaded, be sure to review the README file first, it is an excellent introduction to TCP Wrappers. Two options I recommend when compiling TCP Wrappers. First, go with paranoid, as this does a reverse lookup for all connections. Second, use the advance configuration, which is actually quite simple. This con, you wion keeps all the binaries in there original locations, which may be critical for future patches.

Implementing TCP Wrappers will involve editing several files (these examples are based on the advance configuration). First, once compiled, the tcpd binary will be installed in the /usr/local/bin directory. Second, the file /etc/inetd.conf must be configured for which services are to be wrapped (example D). Third, /etc/syslog.conf must be edited for logging tcpd (example E), be sure to touch the file /var/adm/tcpdlog . Last, the access control lists must be created, /etc/hosts.allow and /etc/hosts.deny (example F).

Once all the proper files have been edited and are in place, restart /usr/bin/inetd with kill -HUP. This will restart the daemon with TCP Wrappers in place. Be sure to verify both your ACLs and logging before finishing.

For the Truly Paranoid
I consider the measures discussed above absolutely essential. By following these steps, you have greatly improved your system's security, congratulations! Unfortunately, your system is not 100% secure, nor will it ever be. So, for the truly paranoid, I have added some additional steps you can take.

First we will create the wheel group. The wheel group is a group of select individuals that can execute powerful commands, such as /usr/bin/su. By limiting the people the can access these commands, you enhance the system security. To create the group, vi the file /etc/group, create the group wheel, and add the system admins to the group. Then identify critical system binaries, such as /usr/bin/su. Change the group ownership to wheel, and the permissions to owner and group executable only (be sure to maintain the suid or guid bit for specific binaries). For /usr/bin/su, the commands would be:

/usr/bin/chgrp wheel /usr/bin/su
/usr/bin/chmod 4750 /usr/bin/su

* Note: (Don't forget, for su there is actually another binary in /sbin. For 2.6, this is called /sbin/su.static This is the same thing as /usr/bin/su, however the libaries are statically linked, hence the larger file size. Don't forget to change this file also ).

Second, we will lock down the files .rhosts, .netrc, and /etc/hosts.equiv. The r commands use these files to access systems. To lock them down, touch the files, then change the permissions to zero, locking them down. This way no one can create or alter the files. For example,

/usr/bin/touch /.rhosts /.netrc /etc/hosts.equiv
/usr/bin/chmod 0 /.rhosts /.netrc /etc/hosts.equiv

Also, we want to set the TCP initial sequence number generation parameters. By truly randomizing the initial sequence number of all TCP connections, we protect the system against session hijacking and ip spoofing. This is done by setting TCP_STRONG_ISS=2 in the file /etc/default/inetinit (example G). By default, the system installs with a setting of 1, which is not as secure.

To protect against possible buffer overflow (or stack smashing) attacks, add the following to lines to /etc/system.

set noexec_user_stack=1
set noexec_user_stack_log=1

Next, we make some modifications to the IP module. Add these commands to one of your start up scripts. For detailed information on ndd and tuneing ip modules for security, check out Network Settings for Security.

### Set kernel parameters for /dev/ip
ndd -set /dev/ip ip_respond_to_echo_broadcast 0
ndd -set /dev/ip ip_forward_directed_broadcasts 0
ndd -set /dev/ip ip_respond_to_timestamp 0
ndd -set /dev/ip ip_respond_to_timestamp_broadcast 0
ndd -set /dev/ip ip_forward_src_routed 0
ndd -set /dev/ip ip_ignore_redirect 1

Last thing I like to do is eliminate as many suid root binaries as possible. suid root binaries pose a high risk, as vulnerable versions can be used to gain root. Since this is a dedicated system with few accounts, most of the suid binaries can be disabled or removed. To find all suid root binaries, run the following command on your system.

find / -type f -perm -4000 -exec ls -lL {} \; | tee -a /var/tmp/suid.txt

Once you have identifed all of the suid root binaries, you can remove most of them by changing the permissions to '555', or deleting the binaries entirely. For example, I eliminated the suid bit on the following binaries from a Core installation of Solaris 2.7.

Conclusion
We have covered some of the more basic steps involved in armoring a Solaris box. The key to a secure system is having the minimal software installed, with protection in layers, such as TCP Wrappers. There are many additional steps that can be taken, such as sudo (allows a system administrator to give limited root privileges to user and log their activities), tripwire (monitor changes in system binaries), and swatch (automated log monitoring and alerts). Remember, no system is truly 100% secure. However, with the steps outlined above, you greatly reduce the security risks.

For more information on how to better armor your Solaris system, check out Sun Microsystems Security blueprint pages located at http://www.sun.com/security/blueprints. There are also a variety of tools you can use to automate the armoring of your system, including Brad Powell's armoring script Titan, Sun Microsystems's JASS , and YASSP, Yet Another Security Solaris Package.

Downloads.
To save you the time and trouble, I have created a script file that will do everything we have discussed in this article. The script file will go through your Solaris system and make all the above changes, first backing up any changed files. The script will also implement TCP wrappers for you. This script detects what processor you are using (Sparc or x86) and what version (2.5.1, 2.6, 2.7, and 2.8) and makes the proper changes. I recommend this script for new installs only. Send comments or recommendations to lance@honeynet.org

Download armor-1.3.1.tar.Z

I used compress instead of gzip, since uncompress come with the Solaris distribution.
MD5 Checksum for armor-1.3.1.tar.Z = 45009a639877c7c4015564be97af74fa

Author's bio
Lance Spitzner is currently an active member of the Honeynet Project. He enjoys learning by blowing up systems in his home lab. Before this, he was an Tanker in the Rapid Deployment Force, where he blew up things of a different nature. You can reach him at lance@honeynet.org .

Implementing TCP Wrappers will involve editing several files (these examples are based on the advance configuration). First, once compiled, the tcpd binary will be installed in the /usr/local/bin directory. Second, the file /etc/inetd.conf must be configured for which services are to be wrapped (example D). Third, /etc/syslog.conf must be edited for logging tcpd (example E), be sure to touch the file /var/adm/tcpdlog . Last, the access control lists must be created, /etc/hosts.allow and /etc/hosts.deny (example F).

Once all the proper files have been edited and are in place, restart /usr/bin/inetd with kill -HUP. This will restart the daemon with TCP Wrappers in place. Be sure to verify both your ACLs and logging before finishing.

For the Truly Paranoid
I consider the measures discussed above absolutely essential. By following these steps, you have greatly improved your system's security, congratulations! Unfortunately, your system is not 100% secure, nor will it ever be. So, for the truly paranoid, I have added some additional steps you can take.

First we will create the wheel group. The wheel group is a group of select individuals that can execute powerful commands, such as /usr/bin/su. By limiting the people the can access these commands, you enhance the system security. To create the group, vi the file /etc/group, create the group wheel, and add the system admins to the group. Then identify critical system binaries, such as /usr/bin/su. Change the group ownership to wheel, and the permissions to owner and group executable only (be sure to maintain the suid or guid bit for specific binaries). For /usr/bin/su, the commands would be:

/usr/bin/chgrp wheel /usr/bin/su
/usr/bin/chmod 4750 /usr/bin/su

* Note: (Don't forget, for su there is actually another binary in /sbin. For 2.6, this is called /sbin/su.static This is the same thing as /usr/bin/su, however the libaries are statically linked, hence the larger file size. Don't forget to change this file also ).

Second, we will lock down the files .rhosts, .netrc, and /etc/hosts.equiv. The r commands use these files to access systems. To lock them down, touch the files, then change the permissions to zero, locking them down. This way no one can create or alter the files. For example,

/usr/bin/touch /.rhosts /.netrc /etc/hosts.equiv
/usr/bin/chmod 0 /.rhosts /.netrc /etc/hosts.equiv

Also, we want to set the TCP initial sequence number generation parameters. By truly randomizing the initial sequence number of all TCP connections, we protect the system against session hijacking and ip spoofing. This is done by setting TCP_STRONG_ISS=2 in the file /etc/default/inetinit (example G). By default, the system installs with a setting of 1, which is not as secure.

To protect against possible buffer overflow (or stack smashing) attacks, add the following to lines to /etc/system.

set noexec_user_stack=1
set noexec_user_stack_log=1

Next, we make some modifications to the IP module. Add these commands to one of your start up scripts. For detailed information on ndd and tuneing ip modules for security, check out Network Settings for Security.

### Set kernel parameters for /dev/ip
ndd -set /dev/ip ip_respond_to_echo_broadcast 0
ndd -set /dev/ip ip_forward_directed_broadcasts 0
ndd -set /dev/ip ip_respond_to_timestamp 0
ndd -set /dev/ip ip_respond_to_timestamp_broadcast 0
ndd -set /dev/ip ip_forward_src_routed 0
ndd -set /dev/ip ip_ignore_redirect 1

Last thing I like to do is eliminate as many suid root binaries as possible. suid root binaries pose a high risk, as vulnerable versions can be used to gain root. Since this is a dedicated system with few accounts, most of the suid binaries can be disabled or removed. To find all suid root binaries, run the following command on your system.

find / -type f -perm -4000 -exec ls -lL {} \; | tee -a /var/tmp/suid.txt

Once you have identifed all of the suid root binaries, you can remove most of them by changing the permissions to '555', or deleting the binaries entirely. For example, I eliminated the suid bit on the following binaries from a Core installation of Solaris 2.7.

Conclusion
We have covered some of the more basic steps involved in armoring a Solaris box. The key to a secure system is having the minimal software installed, with protection in layers, such as TCP Wrappers. There are many additional steps that can be taken, such as sudo (allows a system administrator to give limited root privileges to user and log their activities), tripwire (monitor changes in system binaries), and swatch (automated log monitoring and alerts). Remember, no system is truly 100% secure. However, with the steps outlined above, you greatly reduce the security risks.

For more information on how to better armor your Solaris system, check out Sun Microsystems Security blueprint pages located at http://www.sun.com/security/blueprints. There are also a variety of tools you can use to automate the armoring of your system, including Brad Powell's armoring script Titan, Sun Microsystems's JASS , and YASSP, Yet Another Security Solaris Package.

Downloads.
To save you the time and trouble, I have created a script file that will do everything we have discussed in this article. The script file will go through your Solaris system and make all the above changes, first backing up any changed files. The script will also implement TCP wrappers for you. This script detects what processor you are using (Sparc or x86) and what version (2.5.1, 2.6, 2.7, and 2.8) and makes the proper changes. I recommend this script for new installs only. Send comments or recommendations to lance@honeynet.org

Download armor-1.3.1.tar.Z

I used compress instead of gzip, since uncompress come with the Solaris distribution.
MD5 Checksum for armor-1.3.1.tar.Z = 45009a639877c7c4015564be97af74fa

Author's bio
Lance Spitzner is currently an active member of the Honeynet Project. He enjoys learning by blowing up systems in his home lab. Before this, he was an Tanker in the Rapid Deployment Force, where he blew up things of a different nature. You can reach him at lance@honeynet.org .