Cover V11, I13

Article

SolarisTM 9 Operating Environment Security Tips

Mark Thacker

The launch of Solaris 9TM Operating Environment (OE) brings a new level of default security to Sun systems administrators. In this article, I will explore a few of these new features with the goal of helping you create a more secured system as soon as possible. Because the features covered here are part of the standard Solaris distribution, they are fully supported and will be enhanced over time. The reference material provided in this article has been borrowed heavily from the existing Solaris 9 OE System Administration documentation as well as public whitepapers and BluePrints to which you can refer for more in-depth information.

Network Security

The following technologies will help protect your system from network-based attacks. This list is certainly not exhaustive, but it is a beginning.

The SolarisTM Secure Shell Software

The Solaris 9 OE includes a full implementation of the Solaris Secure Shell remote access protocol that is integrated with kernel (Basic Security Module -- BSM) auditing, internationalization, pluggable authentication modules (PAM), and TCP Wrappers. Secure Shell provides encryption, privacy and public key authentication of hosts and userid as a replacement for the less secure commands, such as telnet, rsh, rcp, etc. Sun's product is based on OpenSSH, but all updates and patches will be released by Sun.

So, how do you use Secure Shell software in the Solaris 9 OE? Many of the basics are already done for you. For example, the /etc/rc2.d/S89sshd creates host key for you automatically, and 128-bit encryption is already built-in using the AES, 3DES, and Blowfish cryptography algorithms. Essentially, all you need to do is to generate your own personal keys and start using the /usr/bin/ssh command. Here are some commands:

1. Generate your own public/private key pair and hit <return> to save the key into a file: 

myLocalHost% ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key(/home/johndoe/.ssh/id_rsa):
2. Enter a password that you want to use to lock this key: 

Enter passphrase(empty for no passphrase): <pass phrase and return>
Enter same passphrase again: <pass phrase and return>
3. The keys are saved for future use: 

Your identification has been saved in /home/johndoe/.ssh/id_rsa.
Your public key has been saved in /home/johndoe/.ssh/id_rsa.pub.
The key fingerprint is:
0e:fb:3d:57:71:73:bf:58:b8:eb:f3:a3:aa:df:e0:d1
johndoe@myLocalHost
4. You are now ready to open an encrypted shell session on a remote server. Use the ssh command to start the session and choose to accept the first-time question about accepting the remote server's public key. 

myLocalHost% ssh myRemoteHost
The authenticity of host 'myRemoteHost' can't be established.
RSA key fingerprint in md5 is: 04:9f:bd:fc:3d:3e:d2:e7:49:fd:6e:18:4f:9c:26
Are you sure you want to continue connecting(yes/no)? yes <return>
5. Enter the password for your public/private key (as in step 2): 

Enter passphrase for key '/home/johndoe/.ssh/id_rsa': <return>
johndoe@myRemoteHost's password: <return>
Last login: Fri Jul 20 14:24:10 2001 from myLocalHost
myRemoteHost%
6. You are done! You have an encrypted, secured remote session on the remote server.

Look for Sun to provide patches and enhancements to Solaris Secure Shell software and please review the Solaris 9 OE documentation for information on system-wide defaults (/etc/ssh/ssh_config and /etc/ssh/sshd_config) in Secure Shell.

TCP Wrappers

The Solaris 9 OE also includes the TCP Wrappers program, which provides a way of restricting access to TCP-based services started by the inetd process based on hostname, wildcards, and reverse DNS resolution. This is an easy way to restrict in-bound connections to your server to be from particular domains. For example, limiting FTP access to only those machines in the "foo.com" domain is done by adding an entry to the /etc/hosts.allow file. TCP Wrappers does not limit out-bound connections from your server.

In the Solaris 9 OE, all services in /etc/inet.conf are already linked to libwrap.so and ready for use. To begin, enable it in the inetd configuration file and restart the inetd process:

1. Edit /etc/default/inetd and change ENABLE_TCPWRAPPERS to be YES and uncomment the line: 

ENABLE_TCPWRAPPERS=YES
2. Kill and restart the inetd process: 

% pkill inetd
% /etc/rc2.d/S79inetsvc start
Next, configure the access control files, /etc/hosts.deny and /etc/hosts.allow. For more information on the format of these files, refer to the hosts_access(4) man page located in the new /usr/sfw/share/man directory tree (i.e., set your MANPATH to include this directory). Here is an example of limiting access to the tftpd (Trivial FTP -- used by JumpStart clients) to just the local network, while denying access to all other TCP/UDP services started by inetd: 

/etc/hosts.allow
in.tftpd: LOCAL, .my.domain.com
/etc/hosts.deny
ALL: ALL
Initial TCP Header Sequence Randomization
Each TCP-based connection to a server can result in a return packet with a unique number, known as a sequence number, which helps both the client and the server track the state of the connection. If a cracker could predict what the next sequence number of a packet should be, he/she could use IP spoofing techniques and send rouge packets in place of the true client or server. Obviously, this could lead to data corruption and other problems. Solaris has long had the ability to randomize the initial sequence number, and in Solaris 9 OE, this has been improved with the addition of even more randomization. The Internet standard for this technique is known as RFC 1948, and to activate the new, improved version in the Solaris 9 OE is very simple -- simply uncomment and change the value of the TCP_STRONG_ISS to in the /etc/default/inetinit file: 

TCP_STRONG_ISS = 2
Platform Security

The following tools can help increase the base level of security of your Solaris platform. Again, this is not an exhaustive list, and I recommend checking the references at the end of this article for additional information before configuring anything on your production systems.

Role-Based Access Control (RBAC)

Solaris OE RBAC is derived from the industrial-strength Trusted Solaris platform, proven in the government, finance, and high-security sector for many years. It is a way of providing non-privileged users with just the power they need to get their jobs done. There are three primary distinctions between Solaris OE RBAC and other technologies, such as sudo. These include the ability to run any command as any effective or real UID and/or GID, an exposed API for checking user authorizations, and the storage of role information in the naming service (files, NIS, NIS+ and LDAP), which allows roles to follow users in the network. Additionally, RBAC is fully integrated into Solaris auditing systems, so all commands executed while a user is in a specific role are logged against that user's real userid and role name in the BSM audit system. RBAC was first introduced in the Solaris 8 OE and is more fully explained in the "RBAC in Solaris OE" whitepaper in the Solaris Whitepaper references.

To understand RBAC, you need to understand a few terms first. A role in the Solaris OE is just like a normal userid, except that it cannot be logged into anonymously; users must log in as a known user first, then assume a role through the su command or through an application that uses the RBAC API. The definition of roles is site specific and typically consists of a role name, a list of usernames assigned to that role, optional authorizations, and one or more execution profiles. A profile consists of a set of execution attributes (command name, what UID/GID to run as, etc.) and an optional set of authorizations that are checked by certain programs. Authorizations are simply a "right" that user has that can be queried by an application. For example, a user may have the authorization to create new users on the system, and that authorization will be checked by the Solaris Management Console. Finally, all of the Solaris OE RBAC information can be stored on the local server and in the naming services of NIS, NIS+, or LDAP.

Here is a quick example of what one can do with RBAC. At the very least, you will want to ensure that the "root" account cannot be logged into anonymously, even if someone were to make a mistake and allow root in via the /etc/ftpd/ftpusers file (which controls which users cannot FTP into a machine). Simply set up the root account as a role and assign it to a real user's account. For root in particular, make sure to assign this role to a userid that is located in /etc/passwd on the machine, just in case your naming service is unavailable. In an emergency, the root role can be logged into directly only in single-user mode on the physical console device.

The following files have been modified to make "root" a role, allow the local user of "thacker" to assume the root role, and to allow the user "saunders" to be the printer administrator and run printer commands without assuming a specific role. 

/etc/passwd
   root:x:0:1:Super-User:/:/usr/bin/pfsh
   saunders:x:1000:10:G Saunders:/export/home/saunders:/usr/bin/sh
   thacker:x:1001:10:Mark Thacker:/export/home/thacker:/usr/bin/sh

/etc/user_attr
   root::::type=role;auths=solaris.*,solaris.grant;profiles=All
   saunders::::type=normal;profiles=Printer Management
   thacker::::type=normal;roles=root;profiles=Basic Solaris User

/etc/security/exec_attr   (Entries already present and abbreviated here for space)
   Printer Management:suser:cmd:::/usr/sbin/accept:euid=lp
   Printer Management:suser:cmd:::/usr/ucb/lpq:euid=0
   Printer Management:suser:cmd:::/etc/init.d/lp:euid=0
   Printer Management:suser:cmd:::/usr/bin/lpstat:euid=0
   Printer Management:suser:cmd:::/usr/lib/lp/lpsched:uid=0
   (and so forth...)
This is just scratching the surface of what the Solaris OE RBAC can do to help systema administrators. RBAC is more fully explained in the whitepaper referenced at the end of this article, in the rbac(5) man page, and in the System Administration Guide: Advanced System Administration documentation, on http://docs.sun.com.

Minimized Packaging

In the Solaris 9 OE, many of the networking services that were previously considered part of the "core" operating system are now in separate client and server packages and can be selectively removed from the system. This allows you to create a smaller, more customized, and less exposed install of the Solaris OE. Previously, functions such as the Telnet client and server could be disabled, but not cleanly removed from the Solaris OE. Maximum use of this facility comes when doing JumpStart installations or through the use of the SolarisTM Security Toolkit software. Management of these new packages is done through the normal Solaris pkgadd and pkgrm commands. When a network package such as the telnet server is modified on the system, entries in /etc/inetd.conf are also automatically updated as well.

Here is an example of removing the telnet server components while leaving the telnet client on the systems. Effectively, users may telnet out of a server, but no one can telnet in:

1. List the packages related to the telnet services: 

% pkginfo | grep -i telnet
system     SUNWtnetc      Telnet Command (client)
system     SUNWtnetd      Telnet Server Daemon (Usr)
system     SUNWtnetr      Telnet Server Daemon (Root)
2. Second, remove the two server components: 

% pkgrm SUNWtnetd SUNWtnetr
3. Try starting a telnet session to the host you are on to verify that the telnet client program is still available (no "bad command" errors), and that the telnet server is no longer running on your server: 

% telnet localhost
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused
To restore the telnet server to the system, you will need to pkgadd the two server packages from the Solaris 9 OE media or from another distribution source (e.g., JumpStart server). Updated versions of the Solaris Security Toolkit software will take advantage of this new package granularity.

Stack Buffer Overflow Protection Per File

Buffer overflows are a far too common occurrence in the security vulnerability world, and there are ways to limit the scope of these threats. Starting with the Solaris 2.6 OE, Sun made available an option that would disable the ability of a program to execute code placed on that program's stack. This is known as a stack buffer overflow vulnerability. Execution of this code is one way crackers can gain access to processes running as root. In the Solaris 9 OE, this capability is extended to individual processes and can be compiled into the programs so that they are protected against stack buffer overflow vulnerabilities even if the system-wide switch is not turned on. Most of the core setuid-enabled applications in the Solaris 9 OE have been compiled with this feature turned on. You can also compile your own applications with this protection enabled.

To protect the entire system against stack buffer overflow conditions, edit the /etc/system file and add the following line: 

set noexec_user_stack=1
The change will take effect at the next reboot.

Any program that attempts to execute code on the stack will be sent a signal and will exit, also causing the system to log the event via syslog. There is the possibility that some older, 32-bit applications may try to execute code on the stack, thus this feature is not enabled by default.

To compile your own applications to have stack buffer overflow protection enabled, simply add a linker map file during your compile or link process: 

% cc -M /usr/lib/ld/map.noexstk myprogram.c
Conclusion

With the Solaris 9 OE, Sun has added features to help administrators create a more secured system, and I've tried to provide an overview of some of them. Certainly this article is not a comprehensive review of Solaris security, and some significant items were not discussed, such as: SunScreen 3.2, IPsec/IKE for IPv4, IPsec for IPv6, secured LDAP naming services, the SunTM Open Net Environment (Sun ONE) Directory Server 5.1 software, the SunTM Crypto Accelerator 1000 software, the Solaris Security Toolkit, Web server security, and many more. If you have yet to deploy Solaris 9 in your environment, I encourage you to try the Free Binary License for a 1 CPU system. It's a great way to test these new security tools. Also, please use the References section to get a more complete explanation of the Solaris 9 OE and Sun's security technologies.

References

Sun Security: http://www.sun.com/security/

Trusted Solaris: http://www.sun.com/trustedsolaris/

Security Whitepapers: http://www.sun.com/software/solaris/whitepapers.html

Security Services documentation: http://docs.sun.com

Solaris Security Toolkit: http://www.sun.com/blueprints/

Enterprise Security: Solaris Operating Enviornment Security Journal, Solaris OE Versions 2.5.1, 2.6, 7, 8 by Alex Noordergraaf, et al.; ISBN# 0-13-100092-6

Mark Thacker is the Product Line Manager for Solaris Security and is responsible for ensuring that customer's needs for security are met in the Solaris Operating Environment. Mark has many previous years of multi-platform system administration and Internet services administration experience.

Sun, Sun Microsystems, the Sun Logo, Solaris, and Sun ONE Directory Server are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.

 
© 2002 CMP Media LLC. All Rights Reserved.
www.sysadminmag.com