Beginner's guide to armoring Solaris

From: Subject: Beginner's guide to armoring Solaris Date: Sun, 17 Jun 2001 12:27:00 +0900 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Location: http://www.enteract.com/~lspitz/armoring.html X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Beginner's guide to armoring Solaris Armoring = Solaris=20
Preparing solaris for a firewall=20

Lance=20 Spitzner
http://www.enteract.com/~lspitz<= /A>=20
Last Modified: 22 October, 2000

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

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

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

Once you have placed your future firewall box in an isolated network, = you are=20 ready to begin. The first step is selecting what OS package to = load. The=20 idea is to load the minimum installation, while maintaining maximum = efficiency.=20 The less software that resides on the box, the fewer potential security = exploits=20 or holes. I recommend Core installation. I prefer Core = because this=20 is the absolute miminum installation, creating a more secure operating=20 system. For the truly paranoid, I have created three checklists on = how to=20 modify the Core installation. One checklist for Solaris 2.6 and FW-1 = 4.0,=20 the second checklist for Solaris 2.7 and FW-1 = 4.1,=20 and the third checklist Solaris 8 and FW-1 = 4.1. The=20 third checklist is still in beta, as Solaris 8 is not supported by = CheckPoint.=20 If you require a GUI, need additional functionality, or are new to = Solaris, then=20 you may want to consider the End User installation. Anything above the = End User=20 package, such as Developer, is adding useless but potentially = exploitable=20 software. Be sure to add the "On-Line Manual Pages" during = the=20 install process. I find these extremelly usefull, while adding = little risk=20 to your system. For more information on building a minimal = installation,=20 check out Solaris=20 Minimization for Security.=20

During the installation process, you will be asked to partition your=20 system. I've never really understood Sun's love for making = various=20 partitions. You always end up making the partitions to small and running = out of=20 room later. I always like to make root as big as possible and just = throw=20 everything in there, then you do not run out of room. However, we do = need=20 several partitions to protect the root drive. If we were to fill the = root=20 partition with data, such as logging or email, we would cause a denial = of=20 service, potentially crashing the system.=20

Therefore, I always recommend a separate partition for /var, this is = where=20 all the system logging and email goes. By isolating the /var = partition,=20 you protect your root partition from overfilling. I've found = 400 MB=20 to be more then enough for /var. You may also consider making a = separate=20 partition for the firewall logging and /usr. If you create a seperate = partition=20 for /usr, you can mount it read only, protecting the binaries from = modification.=20 For Checkpoint Firewall 1, all logging by default happens in /etc/fw/log = (/var/opt/CKPfw/log for ver 4.0). Many Solaris systems have two or = more=20 drives, such as the Ultra 10 or 2 IDE drives for an x86. If you = are not=20 mirroring the second drive, make it the partition for all the firewall=20 logging. Once again, this protects all the other partitions in = case the=20 firewall logging floods the drive. With such a setup, your partitions = would look=20 as follows:=20

/          &n= bsp;   =20 - everything else
/var          = ; -=20 400 MB
swap          = ; -=20 256 MB (or normally 2x amount of RAM)
/etc/fw/log        &nbs= p;   =20 - 2nd drive (for CP FW-1 ver 3.0x)
/var/opt/CKPfw/log      - 2nd drive = (for CP=20 FW-1 ver 4.0x)
/var/opt/CPfw1-41/log   - 2nd drive (for CP FW-1 ver = 4.1x)=20

Once the system has rebooted after the installation, be sure to = install the=20 recommended=20 patch cluster from Sun. Be sure to use your go between box to get = the=20 patches, the firewall box should always remain on an isolated network. = Patches=20 are CRITICAL to maintaining a secure firewall and should be = updated at=20 least once a week. BUGTRAQ is=20 an excellent source for following the latest bugs and exploits. =
=20

Eliminating=20 Services
Once you have loaded the installation = package,=20 patches, and rebooted, we are now ready to armor the operating system. = Armoring=20 consists mainly of turning off services, adding logging, tweaking = several files,=20 and TCP Wrappers. First we will begin with turning off services.=20

By default, Solaris is a powerful operating system that executes many = useful=20 services. However, most of these services are unneeded and pose a = potential=20 security risk for a firewall. The first place to start is = /etc/inetd.conf. This=20 file specifies which services the /usr/sbin/inetd daemon will listen = for. By=20 default, /etc/inetd.conf is configured for 35 services, you only need = two, ftp=20 and telnet. You eliminate the remaining unnecessary services by = commenting them=20 out (example).&nbs= p; This=20 is critical, as many of the services run by inetd pose serious security = threats,=20 such as rexd. Confirm what you have commented out with the = following=20 command (this will show you all the services that were left uncommented) =

#grep -v = "^#"=20 /etc/inetd.conf=20

The next place to start is /etc/rc2.d and /etc/rc3.d. Here you will = find=20 startup scripts launched by the init process. Many of these are not = needed. To=20 stop a script from starting during the boot process, replace the capital = S with=20 a small s. That way you can easily start the script again just by = replacing the=20 small s with a capital S. The following scripts are not needed and pose = serious=20 security threats to your system.=20

/etc/rc2.d=20
S73nfs.client -=20 used for NFS mounting a system. A firewall should never = mount=20 another file system.
S74autofs     - used = for=20 automounting, once again, a firewall should never mount another file = system.=20
S80lp         - = used for printing, your firewall should never need to = print.=20
S88sendmail   - listens for = incoming=20 email. Your system can still send mail (such as alerts) with = this=20 disabled.
S71rpc        -=20 portmapper daemon, a highly insecure service (required if = you are=20 running CDE).
S99dtlogin    - CDE = daemon, starts=20 CDE by default=20

/etc/rc3.d=20
S15nfs.server -=20 used to share file systems, a bad idea for firewalls. =
S76snmpdx - snmp = daemon=20

Running any GUI (CDE or OpenWindows) is not a good idea. Only = run a GUI=20 when it is absolutely required. You can disable CDE, the default GUI in = Solaris=20 2.6, with the S99dtlogin startup script (replace the = capital S with=20 a small s). To get an idea of how many ports and services CDE = requires,=20 type the following command when it is running.=20

ps -aef | wc - = l=20

Once you are done with the installation and have turned off = S99dtlogin and=20 S71rpc (required to run CDE), type the command again and compare how the = number=20 of services have decreased. The fewer services running, the = better. For=20 those of you who installed the Core installation, this is not an issue, = as the=20 GUI is not installed.=20

Logging and=20 Tweaking
Once you have eliminated as many services = as=20 possible, we want to enable logging. Most system logging occurs in = /var/adm. We=20 want to add two additional log files there, sulog and loginlog. = /var/adm/sulog=20 logs all su attempts, both successful and failed. This allows you to = monitor who=20 is attempting to gain root access on your system. = /var/adm/loginlog logs=20 consecutive failed login attempts. When a user attempts to login 5 = times, and=20 all 5 attempts fail, this is logged. To enable the files, just touch the = files=20 /var/adm/loginlog and /var/adm/sulog. Ensure both files are chmod 640, = as they=20 contain sensitive information.=20

Next comes tweaking. This involves various file administration. The = first=20 thing we want to do is create the file /etc/issue. This file is an ASCII = text=20 banner that appears for all telnet logins (example A). = This legal=20 warning will appear whenever someone attempts to login to your system.=20

We also want to create the file /etc/ftpusers (example B). = Any=20 account listed in this file cannot ftp to the system. This restricts = common=20 system accounts, such as root or bin, from attempting ftp sessions. The = easiest=20 way to create this file is the command=20

cat /etc/passwd | = cut -f1 -d:=20 > /etc/ftpusers=20

Ensure that any accounts that need to ftp to the firewall are NOT in = the file=20 /etc/ftpusers.=20

Also, ensure that root cannot telnet to the system. This forces users = to=20 login to the system as themselves and then su to root. This is a system = default,=20 but always confirm this in the file /etc/default/login, where console is = left=20 uncommented (example=20 C).=20

Last, I like to eliminate the telnet OS banner and create a = seperate=20 banner for ftp. For telnet, this is easily done by creating the = file=20 /etc/default/telnetd and adding the statement
BANNER=3D"" &nbs= p; = ; =20 # Eliminates the "SunOS 5.6" banner for Telnet=20

For ftp, this is easily done by creating the file /etc/default/ftpd = and=20 adding the statement
BANNER=3D"WARNING:Authorized use = only" #=20 Warning banner for ftp.
=20

Connecting to the=20 Firewall
It is critical that you develop a = secured,=20 controlled way to connect to the firewall. Often, you need remote = access=20 to your firewall for administration or the uploading of files, these=20 communications need to be secured I will discuss two options here, = ssh and=20 TCP Wrappers.=20

I prefer ssh, as it encrypts all communication between you and the=20 firewall. TCP Wrappers will NOT protect your network traffic from=20 sniffing. Users can still capture all of your keystrokes&nb= sp;=20 (including passwords) on the network. If you are concerned about = users=20 capturing communications to your firewall, I recommend you replace = telnet/ftp=20 with ssh. ssh will encrypt all communications to your firewall, = allowing=20 you both to upload files and administer the firewall in a secure = manner. =20 ssh is similar to TCP wrappers in that it has its own layer of logging, = and can=20 limit what systems can connect to it. For more information on ssh, = you can=20 find ssh here. = including source=20 for both ssh clients and server daemon. I recommend you use ssh = version=20 1.2.7, as version 2.x has a limiting license. For 95/NT users, I highly=20 recommend SecureCRT as a=20 ssh client.=20

TCP Wrappers, while it does not encrypt, it does log and control who = can=20 access your system. It is a binary that wraps itself around inetd=20 services, such as telnet or ftp. With TCP Wrappers, the system launches = the=20 wrapper for inetd connections, logs all attempts and then verifies the = attempt=20 against a access control list. If the connection is permitted, TCP = Wrappers=20 hands the connection to the proper binary, such as telnet. If the = connection is=20 rejected by the access control list, then the connection is dropped.=20

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

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

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

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

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

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

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

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

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

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

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

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

set=20 noexec_user_stack=3D1
set noexec_user_stack_log=3D1=20

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

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

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

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

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

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

For more information on how to better armor your Solaris system, = check out=20 Sun Microsystems blueprint pages, specifically Solaris = Security=20

For the truly secure, I HIGHLY recommend you check out Brad Powell's = armoring=20 script Titan. This professional tool is far more powerful and = modular=20 then what I have presented here and documents security in far greater = detail.=20 Also, you may want to check out YASSP, Yet Another Security = Solaris=20 Package.
=20

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

Download armor-1.3.1.ta= r.Z=20

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

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

Whitepapers=20 =