Solaris 11 is the latest Operating System in the Solaris server OS range from Oracle, previously Sun Microsystems. It incorporates many features from Solaris 10 such as the Service Management Framework, but also pulls a lot from the now defunct OpenSolaris project including a new packaging system and a whole new suite of *adm administrative commands to configure the operating system.

This article will cover security configuration of the OS after a standard text-based installation. I’m using Solaris 11.1 x86_64 running as a VMware Fusion guest, but almost all of the steps will be applicable for the SPARC architecture too.

Only core security concepts will be covered. For full details, review the appropriate CISecurity.org benchmark for Solaris 11.1, as well as the comprehensive documentation on the operating system available from the Oracle site. I’ll be working along with those benchmarks and covering only the main points (the full benchmark is 94 pages).

Operating system hardening is good practice, and will assist in a defense-in-depth architecture by adding another layer of security along with firewalls, well-written code, secure application servers, and so on. It is also a requirement of several financial accreditation standards such as PCI-DSS.

This article presumes the reader is proficient at administering the Solaris 11 operating system.

Pre-hardening Considerations

Ensure that the system is fully patched prior to starting hardening. This will ensure that all of the latest security errata have been applied. The latest patch cluster can be downloaded and applied to the system, or you can use pkg update. For more information on patching Solaris 11, consult the following article (http://www.oracle.com/technetwork/articles/servers-storage-admin/o11-018-howto-update-s11-1572261.html).

Prior to starting the hardening procedure it is recommended that an alternate boot environment be created for backup purposes.

Now, should it be required, the pre-hardening boot environment can be selected from the GRUB menu at boot. Issuing the beadm activate pre-hardening command will activate the environment for future reboots.

We can now begin hardening the OS. You may find that some of the hardening is not applicable for your environment - e.g. you cannot disable RPC keyserv if using Secure RPC - so make sure you fit these guidelines around your real-world platform and application requirements.

Disable Services

It is always desirable to run a minimal service set so as to limit avenues of potential exploit. Solaris 11 uses a Secure By Default approach. For example, there is no GUI by default, only a limited set of system services are set to start, Sendmail is configured to listen locally only, and so on.

You can check whether the graphical login manager is running by issuing the following command:

If you see no output, then try the following:

This indicates that the service isn’t fully installed so there’s nothing to worry about. If there is output, and it isn’t “disabled“, issue the following command to disable GDM if you’re not planning on using a GUI:

Sendmail will be configured to listen locally by default. If you have no need to forward/receive mail, then that configuration is fine and secure. If Sendmail is listening on other interfaces and you don’t need it to be you should set the config/local_only property to true. You can verify with the following command (note the use of ggrep - GNU grep):

And verify the SMF configuration for the Sendmail service directly:

Again, with the mindset of “minimal service exposure means less attack vectors which means more secure”, verify that the RPC keyserv service is disabled if you don’t have a requirement for it - if you’re using secure RPC for things like Secure NFS then you will need to leave this enabled.

Likewise, NIS should be disabled if you’re not using it:

We see here that the appropriate package for the NIS server isn’t even installed in a default Solaris 11 installation. We also check that nis/domain is disabled as LDAP is not in use.

We will also check that the NIS client is disabled:

If any of these services are enabled, issue the svcadm disable <service_fmri> command to disable it.

If Kerberos has not been configured on the system, then check that any Kerberos-related services are disabled as they are not required. Check that the ktkt_warn service, which warns users when their Kerberos tickets are about to expire, is disabled:

Out-of-the-box it’s online and enabled. Let’s disable it:

The GSS API is only required in Kerberos environments and other edge cases, so you should disable it if you don’t need it:

The next set of services we need to disable are to prevent users from mounting and accessing data on removable media. This would allow for the physical introduction of malice, both via incoming means as well as outgoing (stealing sensitive data, perhaps).

With these services disabled, we can also disable automount (svc:/system/filesystem/autofs) if it isn’t required. It’s most often employed to automatically mount NFS file systems from remote file servers when needed, as well as loopback filesystems (user home directories, etc.). If you don’t need it, disable it.

Check that the bundled Apache 2.2 service is disabled:

Configure TCP Wrappers

TCP Wrappers allows access to various network daemons that support it via administrator-controlled ACLs based upon remote IP addresses. Therefore, we can use this as another layer of security along with network and host-based firewalls – if one layer is compromised there are still other ACL points. It may mean slightly more administration, but it’s a good pay off in terms of security. It also performs syslog logging regarding successful and unsuccessful connection attempts - information that would be vital in determining the source IP address.

By default, tcp_wrappers is disabled:

The default can be overridden by individual inetadm enabled services. The following command will display a report of the tcp_wrappers variable of each service. These are all set to FALSE by default:

TCP Wrappers for the RPC portmapping service are also disabled by default:

To implement TCP Wrappers, you’ll need to create two files: /etc/hosts.allow and /etc/hosts.deny. Configure ACLs in /etc/hosts.allow as appropriate for your needs. The version of SSH that ships with Solaris 11 supports TCP Wrappers too if these files exist, so ensure you have a rule for sshd: <network>/<mask> in /etc/hosts.allow.

And implement a default deny-any policy:

To enable TCP Wrappers for all services started by inetd, issue the following command and verify the results:

Finally, enable TCP wrappers for the RPC portmapping service, remembering to refresh the rpc/bind service:

A final check that telnet is disabled, and we’re done configuring services.

Kernel Tuning

Core dumps of processes may contain sensitive information and as such the OS must be correctly configured to handle them.

First, verify the OOTB configuration:

We can always configure the OS, via coreadm, to dump to this directory - however it’s always a safer bet to just disable core dumps altogether if they’re not going to be utilised.

Stack protection helps protect against certain types of buffer overflow attacks. Whilst it doesn’t protect against all types of buffer overflow, it is still a significant security feature and it should be implemented. To check that it is enabled, look for the following:

If this isn’t returned, add the appropriate entries to /etc/system and reboot.

The TCP_STRONG_ISS variable sets the TCP initial sequence number generation parameters. By default, it’s set to 1 (Improved sequential generation, with random variance in increment), but for a hardened server this should be set to 2 (RFC 1948 compliant number generation). This will make remote session-hijacking attempts more difficult as well as any attack that relies upon predictable sequence number generation.

Verify the running system:

Let’s change it on the fly:

Verify that the host isn’t configured to route packets by checking the following properties:

If it is enabled, and is not required, disable it with ipadm set-prop as appropriate. There are a myriad of other variables that can be tuned depending upon your needs. A value of 0 is disabled, 1 is enabled. The _forward_directed_broadcasts property in the ip protocol should be set to 0 to prevent denial-of-service attacks. You should set _respond_to_timestamp in the ip protocol to 0 to hamper host discovery, as well as _respond_to_timestamp_broadcast in protocol ip. To Other variables to check the documentation for are _respond_to_address_mask_broadcast, _respond_to_echo_broadcast, _respond_to_echo_multicast, _ignore_redirect, and more. Note that not all of these variables may be present on your system. ipadm can also be set to restrict the maximum number of incoming connections for the tcp protocol with:

If this value is to be configured you must take great care in ensuring there are enough connections to comfortably serve the application to the users.

Disable Routing

If you don’t have a need for the Routing Internet Protocol (RIP) then you should ensure it is disabled. Again, this provides one less thing to be exploited on the system, and one less thing to administer.

If any routing is enabled, disable it with

SSH Configuration

X11Forwarding via SSH should be disabled if you do not have a need for it. Verify with the following command:

By default, it’s enabled. Disable it:

Restart sshd for the change to take effect:

The MaxAuthTries parameter in /etc/ssh/sshd_config should be set to an appropriately low value for your needs - between 3 and 6 normally suffices. This setting controls how many times a user can enter incorrect credentials before being forced to reconnect. This can stop many types of brute force attack by disconnecting a malicious login exchange.

By default, root is disallowed direct login via sshd which is something we wish to maintain:

Neither are empty passwords:

Retry Limit

As MaxAuthTries does for sshd, the RETRIES parameter can be set at the OS-level in /etc/default/login. There also is configuration available to enforce account locking after a certain number of retries which may be something your site needs - read /etc/security/policy.conf for further documentation.

Access to at/cron

Access to the at and cron commands should be limited to authorised users only. Scheduling jobs should be performed at the discretion of the System Administrator, and perhaps a few delegates and service accounts. If not, appropriate monitoring of user crontab files should be performed to check for errant jobs that could compromise system security or stability.

The /etc/cron.d/at.{allow,deny} and /etc/cron.d/cron.{allow,deny} files control this behaviour. The default configuration is as follows:

It is recommended to perform the following remediation:

Any other users that require at/cron access can be added to the appropriate files.

Console Access

Direct root login should only be permitted from the system console. To configure this, ensure that the CONSOLE variable is set in /etc/default/login as follows:

All other access must be made via unprivileged user accounts, and then escalated to root via sudo or su.

User Accounts

Solaris has a great number of tunable parameters relating to user accounts, password expiration, password creation policies, and so on.

The logins -ox command displays user and system login information in a parse-able format. For example:

Here we use the passwd command to force password changes every ten weeks (70 days) and prevent password changes for one week thereafter. Warnings will start to be sent to the user 2 weeks before their password expires. Obviously, you will need to change these parameters as per the security policy at your site:

Checking logins -ox once again:

The last three fields have updated appropriately. You’ll need to do this for all active users except the root account and any accounts with NL or LK in the fifth-to-last field as they represent non-login and locked accounts respectively. If you have more than a handful of accounts you’d be best to script this operation.

Update /etc/default/password:

There are a variety of variables in /etc/default/passwd that can be used to set up a strong password creation policy. Every site will have different needs, but here are the NSA/DISA compliant complexity rules:

If these are too restrictive, you can tune them appropriately. Check man -s 1 passwd for more information on these options, although the variable names are fairly self-descriptive.

The default umask for users is 0022 which leads to files being created with 0644 permissions. It is more desirable to have the default umask set to 0027 so that “other” do not have access. To do this, modify /etc/default/login:

You can be even more restrictive and set the default umask to 077 if need be. You’ll also need to change “umask 022” to “umask <your_desired_umask>” in /etc/profile. Ensure that you don’t break things by being too restrictive either.

Warning Banners

Displaying a warning banner may be a legal requirement at your site. It is also good to ward off potential attackers and let them know that their activity on the system may/will be monitored.

Update /etc/motd, and replace its contents with the following:

Add the same to /etc/issue. We can now have the SSH service display this warning banner by including the following in /etc/ssh/sshd_config:

and restarting sshd:

User checks

Check that only one user exists with UID 0 - i.e. root:

If any other lines are returned, you should investigate immediately, as some other account has root privileges on the server. Even if it is legitimate, it is poor practice.

The logins command has a couple of options for searching for bad logins. For example, the -d option selects logins with duplicate UIDs and the -p option selects logins with no passwords.

Checking for World-Writable Files

A find command should be regularly run across all filesystems to check for world-writable files that are unexpected. For example, the following is seen on a fresh installation of Solaris 11.1:

This list should be retained and regularly compared to ensure that new world-writable files and directories are not created without careful consideration. Any world-writable directories that must exist (/tmp and /var/tmp, for example) should have their sticky-bit set to prevent file deletion by non-owners. World-writable files and directories are a quick target for denial-of-service attacks, as any user could potentially fill the filesystem on which the directory or file resides.

You should also check for SETUID and SETGID files with the following commands:

Retain the file listings taken after a fresh installation of Solaris 11.1 has been performed, and regularly check the live system against these original lists and investigate any changes. There should only be use of SETUID and SETGID binaries where strictly necessary.

Check for unowned files, i.e. those being files owned by a numeric UID and GID where no corresponding user or group entries exist on the current system.

These should be investigated as a new user may inherit a UID (or group a GID) and unintentionally get access to data.

Solaris Zones

Solaris zones are an operating system-level virtualisation technology. Using zones, it is possible to cordon off applications into their own containers, thus minimising any damage an exploited application will do. Solaris Zones provide an easy way to either provide a sparse chroot-like environment so that applications can run in an environment that will not be detrimental to global system resources, or a full branded environment (running a Solaris 10 branded zone, for example). Zones provide an excellent way to split a system into several logical units, each with their own filesystem resources, system resources and management. The “physical” host (which in our case is actually a VMware VM) is known as the global zone in Solaris zone nomenclature.

Before creating a zone, I’ll create a new dataset and zfs filesystem to hold the zone root - this is an optional step but will have the benefit of further isolating the zones. I have two disks in the system, with only one (c8t0d0) in use:

I format and label the additional disk:

Next, create a zpool on the new device:

Verify the result:

Create a ZFS filesystem that will form the root of the zonepaths:

Using zonecfg, we can now begin creating a zone. Zones are tightly integrated with ZFS and a new ZFS filesystem will be created for each new zone created. Create the zone:

You’ll notice that the zone has now been configured:

Install the zone. This will take some time as the packages are downloaded and installed. For larger installations you’ll need to look at configuring your own package repositories and/or cloning zones to save time for future zone provisioning. We could also specify the -c option here and pass a system configuration template generated with sysconfig create-profile to skip the post-installation screens after zone creation.

Verify the zone has been created:

You can see that the status of testzone has changed from configured to installed. Boot the zone:

dladm show-link will now show a new VNIC created for the zone:

During the boot up of the zone you may see the following on the zone console if you’re running your zones on a virtualised global zone (i.e. the VMware VM):

To fix this, place the global zone’s physical interface in promiscuous mode.

You can use dladm show-link to identify the correct physical interface to place into promiscuous mode.

Connect to the zone console with zlogin:

Start working through the post-installation dialogs. You will need to enter system identification information such as hostname, networking configuration, location and root password - much the same as during the configuration stages of a fresh Solaris 11 installation. Disconnect from the zone console with the hash-dot (#.) break sequence we specified with the -e option to zlogin. Once the zone is booted, you should be able to log in normally via zlogin:

You can also try ssh-ing to the zone once you’ve created a user:

Isolated services can now be deployed to the zone. Zones are a complex topic and this has only scratched the surface. There are many more features of zones, such as resource controls, that should be investigated when deploying zones. If full-root rather than sparse-root zones are used then there will be some additional hardening that will need to take place within the zone as well as within the global zone.

You can view a full article on the configuration of Solaris 11 zones here.

Testing the Hardening

You can now run network security tools such as nmap and Nessus against the host and any zones created. You can install nmap under Solaris 11 as follows:

You can then scan your global zone and any child zones.

By default, nmap will perform a SYN stealth scan:

Performing a TCP connect() scan yields:

Other Considerations

Depending on the needs at your site, you may wish to look at the Solaris audit service which is enabled by default on Solaris 11. The CIS Benchmark contains full details on how to configure the service as per recommendation.

Role-Based Access Control is also an option, and allows tasks that would normally be restricted to the root role to be delegated to other users. The Oracle documentation covers RBAC in great detail (http://docs.oracle.com/cd/E23824_01/html/821-1456/rbac-1.html).

ZFS also includes encryption capabilities which you can read more about here.

Conclusion

This article has covered the main aspects of securing the Oracle Solaris 11 operating system. Where it has not been possible to cover hardening in full detail (around the TCP/IP stack for example) due to the sheer number of tunable parameters, the reader is advised to consult the relevant CIS benchmark for the OS, as well as the Oracle documentation which can be considered authoritative.

This article was previously published in Pentest Magazine.