Enterprise Software

Lock IT Down: Getting started with Solaris: Security out of the box

Learn how to perform some basic lock-down procedures on a Solaris system.


Solaris 8.0 comes with a wealth of features, but before you take your brand-spanking-new install and connect it to the Internet, you may want to look at what is enabled and lock things down a bit.

In this Daily Drill Down, I will show you a Solaris administrator’s best-laid plans to lock down just the right windows.

Keeping abreast
According to Sun, Solaris meets the criteria set forth by the Department of Defense Orange Book for level C2 computer security systems. That doesn't mean you are completely safe. Computer security requires more than just buying an OS and installing it. Security is an ongoing process of understanding your system and what's running on it. As an administrator, you need to proactively seek out vulnerabilities as they are exposed and apply patches or upgrades to defend against them.

Sun has a patch mailing list for registered users that will keep you abreast of the latest patches. The patch list is also accessible from the SunSolve site. CERT, the computer security coordination center, is where you want to go to keep abreast of security exploits on Solaris and any other OSs you may be running. CERT also offers amailing listthat you can subscribe to if you want regular updates.

Our test bed
For this discussion, I've done a fresh install of Solaris 8, and the box is up and running and sitting on my network. I selected the Solaris default installation, as well as had the IP address assigned via DHCP from my main server. I also gave nameserver entries for /etc/resolve.conf but have not adjusted the routing table yet to gateway through my firewall machine to the Internet. I gave a root password and logged in and added one user, "stew." At the moment, the machine has just been booted and is sitting at the graphical login screen for X. Let's try to telnet into the machine from elsewhere on the network:
[stew@omnibook stew]$ telnet curly-joe
Trying 192.168.192.24...
Connected to curly-joe.
Escape character is '^]'.

SunOS 5.8

login: root
Password:
Not on system console
Connection closed by foreign host.


Well, at least root can't telnet in; that's good. This is controlled in the file /etc/default/login by setting the CONSOLE variable in the script entry:
CONSOLE=/dev/console

ssh
If CONSOLE is set, then network root logins are disabled, but telnet for users is enabled. Many operating systems now ship with telnet and ftp disabled, and with ssh and scp in place to replace them. Ssh and scp encrypt the connection, so no clear text usernames or passwords are visible, should prying eyes be trying to sniff their way into your system. You might want to consider doing the same and disabling telnet and ftp and grabbing ssh. Check out this version of Openssh for Solaris 8.

You will also need to download and install openssl from the same site. If you are running Solaris 7, you'll need gzip and zlib. Put the files in a temporary work directory (like /tmp/packages) and run this (as root):

 

Note
I'm using the 32-bit versions on a Sparc20.

You should end up with two directories, openssh and openssl. Now you can install the packages:
pkgadd -d. openssl
pkgadd -d. openssh


Notice the period (.) after –d; it's important. You'll be notified about attribute changes on /usr/local/bin and /usr/local/man. You can respond with n to these changes and continue the install with y. For openssh, you'll see the same notice, as well as a warning that ssh will be installed suid root, which I opted to override, and another warning that scripts will be run as root as part of the install.

The package contents will reside in /usr/local. The first thing you need to do to set up sshd as a server is to generate the host keys:

There are two keys, one for ssh1 and one for ssh2.

I’ve covered the most basic part of the configuration. The file /usr/local/etc/ssd_config has additional options for the server, and /usr/local/etc/ssh_config has client options.

To start the server, run:
/usr/local/bin/sshd

You should now be able to ssh in from another machine on the network. You can use the -v option on the client machine to enable verbose output, should you need to debug things. The typical ssh login will run something like this:

I found one caveat with scp and this setup. The package was installed in /usr/local/bin. When running scp from another machine, it spawned scp on the Solaris box without the full path, and I got an error. The easiest fix is probably a symbolic link in /usr/bin:
cd /usr/bin
ln -s /usr/local/bin/scp scp


You’ll probably also want to set up the sshd daemon to run at boot time. We can create a file in /etc/rc2.d called S78sshd:
#!/sbin/sh
case "$1" in
'start')
        /usr/local/bin/sshd
        ;;
'stop')
        /usr/bin/pkill -x -u 0 -P 1 sshd
        ;;
*)
        echo "Usage: $0 { start | stop }"
        exit 1
        ;;
esac
exit 0


We need to also make a shutdown script when the system goes down to runlevel 0 and 1:
cp S78sshd ../rc1.d/K78sshd
cp S78sshd ../rc0.d/K78sshd


That's it for a basic setup. There is much more information on ssh in the man pages and at the openssh site.

Disabling telnet and ftp
Disabling telnet and ftp is easy; the file we want to edit is inetd.conf. In Solaris 8, the file in /etc is a symlink to /etc/inet/inetd.conf. The file is also read-only, so we'll need to change the permissions (as root):
chmod u+w /etc/inet/inetd.conf
vi /etc/inet/inetd.conf


Then, you just need to edit two lines, adding # at the beginning to comment them out (see sidebar).

Any time you make changes to inetd.conf, you'll need to stop and restart the inetd daemon:
/etc/rc2.d/S72inetsvc stop
/etc/rc2.d/S72inetsvc start


Note
The above two lines are scripts on my system; yours may vary. Most system daemons are started and stopped through these scripts. The "S" scripts start the daemons when the system comes up, in order of the number after the "S." The "K" scripts shut down the services at system shutdown or a change in runlevel. The "rc2.d" refers to services started at runlevel 2.

Prodding and probing: What’s running
So what else is running? We can get a quick look at the network services running with netstat. Netstat will give you a list of your currently active network connections, plus a list of potential ways to access your box. Some are benign, but if we're going to lock things down as tightly as possible, then the thing to do is shut down everything we don't absolutely need. To see which services are running, type this text.

This is an edited list; yours should be much longer. Each one of these named services and ports is a potential avenue to access your machine through its network connection. I edited it out, but you'll also see a subset of this list listed under IPv6, which is the new Internet delivery protocol. So what is all this stuff, and why do we have it running?

Let’s look at some of the named services we should be concerned with:
  • ·        sunrpc: Sun's Remote Procedure Call (RPC) forms the basis of many UNIX services, especially Network File System (NFS). However, RPC can be extremely dangerous when left exposed to the Internet.
  • ·        echo, discard, daytime, and chargen: These are primarily used for network testing.
  • ·        lockd: This is used in conjunction with NFS to maintain file locks on shared files.
  • ·        shell, login, and exec: These are the "r" services: rshelld, rlogind, and rexecd. Much like telnet, they allow users on other machines on the network to remotely log in or run commands on your machine, provided they have a user account. Many administrators shut these down. With ssh/scp in place, we can turn these off too.
  • ·        finger: Finger allows you to look up user information. Many administrators disable it, because any piece of user information a cracker can get makes his job that much easier. Once he/she probes with finger and finds a valid username, only the password is needed for entry.
  • ·        dtspc: This is the "CDE Subprocess Control daemon." Like the "r" programs, it allows you to run a remote xterm from another machine. It apparently uses a different authorization scheme than rsh and family, from what I saw searching on the Net. This looks like another candidate to disable.
  • ·        smtp: This is the "Simple Mail Transfer Protocol," used to transfer e-mail between systems. Solaris uses sendmail, historically a source of a number of system exploits. The version in Solaris 8 is Sendmail 8.9.3 with Sun patches. The easiest way to find your sendmail version is to telnet to port 25 (provided telnet is enabled) (see sidebar).

If you stay on top of security advisories and upgrades to sendmail, you should not have too much trouble. Although it has been a source of problems in the past, it has had a lot of improvements.

Let's also use ps to see what is currently running on the system:
$ps -ae

PID TTY      TIME CMD
0   ?        0:01 sched
1   ?        0:00 init
2   ?        0:00 pageout
3   ?        0:08 fsflush
285 ?        0:00 sac


Again, this is an edited list, and my actual list had about 30 entries, which is quite a bit for a machine with one person on it. Let's run down some of the potential problem programs in this list.
  • ·        rpcbind: A server that facilitates mapping of ports to services.
  • ·        inetd: Inetd is the Internet services daemon. It watches for activity on a port and launches the appropriate program, based on entries in /etc/services and /etc/inetd.conf.
  • ·        statd: Network status monitor, part of NFS.
  • ·        cimomboot: Part of Solaris Web Based Enterprise Management.
  • ·        snmpXdmi: Part of the Desktop Management Interface.
  • ·        dwhttpd: This is a Web server. Sun, like many vendors, provides documentation in HTML. This server is for accessing that information; by default, it is on port 8888.
  • ·        snmpdx: Solstice Enterprise Master Agent.
  • ·        dmispd: DMI Service Provider. Another part of Solaris Enterprise Management. This process is the core of DMI.

As you can see, there are a number of Solaris/Solstice enterprise management tools running that we may want to consider disabling.

nessus
A useful tool for peeking into the vulnerability of your machine, if you have another machine to access it through the network, is nessus. Nessus is a remote security scanner that will audit a given network machine and determine whether the machine may be broken into or misused in some way. The package has a nice GUI, and you can run all 500 or so scans, or pick and choose as needed.

After building nessus, I ran a full attack and scan on the Solaris machine. These are the results.

The nessus report continues, giving details on each hole and warning, referencing CERT advisories, and suggesting steps to address the issue. It looks like we've got some work to do. The Solaris/Solstice Enterprise Management tools are part of our problem, starting with SNMP. The process is easy enough to stop by running:
/etc/rc3.d/S76snmpdx stop

To keep it from starting again on the next boot, we just need to rename the file:
mv /etc/rc3.d/S76snmpdx /etc/rc3.d/no-S76snmpdx

This change dropped the nessus scan to two holes and 14 warnings when I reran it.

The next warning mentions walld. Walld is a program that an administrator can use to send messages to all users in the event of a system shutdown or other event. As nessus mentions, crackers can also use it to trick users into revealing passwords or other sensitive information. It is easy to disable. While we're at it, let's cover echo, daytime, and chargen too. Again, we'll be commenting out lines in inetd.conf, like we did with ftp and telnet. Don't forget to stop and start inetd when you are done. The lines we want are here.

This drops the nessus scan to two holes and 10 warnings.

Now go back and comment out the rest of the known dangerous services in /etc/inet/inetd.conf, including sadmind, rquotad, rstatd, ruserd, sprayd, cmsd, finger, rsh, rlogin, rexec, and tooltalk. Don't forget to stop and start inetd. According to the CERT page, Sun released patches for the tooltalk issue in 1998, but again, if you don't need it, don't run it. These changes bring our nessus scan down to zero holes and five warnings.

If you don't feel you need a Web server running, stop it and change the start scripts for it too. Even if a service wasn't mentioned in your scan, if you don't feel you need it, don't run it. You can always turn it back on. Below are some examples that highlight how to shut these services off:

Keeping the Answerbook Web server off:
/etc/rc2.d/S96ab2mgr stop
mv /etc/rc2.d/S96ab2mgr /etc/rc2.d/no-S96ab2mgr


Keeping other Solaris Management tools off:
/etc/rc3.d/S77dmi stop
mv /etc/rc3.d/S77dmi stop /etc/rc3.d/no-S77dmi
/etc/rc2.d/S90wbem stop
mv /etc/rc2.d/S90wbem /etc/rc2.d/no-S90wbem


If you are not using nfs, you can also disable the nfs client tools, statd and lockd, which generate two of the nessus warnings.

If you were to rerun netstat and ps now, you would see that the lists have shortened considerably.

The remaining three warnings are all low-risk factor. The nonrandom IP ID suggests a patch from your vendor, which I did not find at Sun's site. The other two suggest ICMP packet filtering, which can be accomplished with a TCP/IP packet-filter product. IP Filter seems to be fairly popular on Solaris machines.

I was unable to find binaries and don't yet have gcc and family set up on this machine, so building and installing IP Filter will have to wait for another article. Essentially, once the program is up and running, you would add a ruleset to block icmp packets of the specified type:
block in proto icmp "packet-type"

Or you can block everything and then selectively allow packet types that you want (to allow ping, for example) (see sidebar).

If you find you need to turn on the nfs client or some of the other services we disabled, having the packet filter in place should give you some protection against vulnerabilities.

Conclusion
Security is an ongoing process. You need to know your system and which processes are running on it, and what you need the system to do. Disabling unnecessary processes will not only close off possible security threats but will also free up system resources for the tasks that you do want to run. Stay on top of patches from the vendor and follow security announcements from CERT. Monitor log files for unusual activity and get to know your process table and what you expect to be running. Replace telnet and ftp with secure versions, if possible, and encourage users to use nontrivial passwords. This is no guarantee that you won't be cracked, but you'll make things a bit harder for the crackers.

Editor's Picks

Free Newsletters, In your Inbox