CXL - Securing your mid-range systems.

unix, os400 vms security reviews
OS/400 security reviews
Oracle security reviews
unix, os400 vms security reviews
Purchase azscan
unix, os400 vms security reviews
Unix security reviews
 
unix, os400 vms security reviews
AZScan users
unix, os400 vms security reviews
 
VMS reviews security
 
unix, os400 vms security reviews
unix, os400 vms security reviews
 
 

Unix Security with Solaris 2.6/7


As in any security venture, the place to begin securing a UNIX system (Solaris, in this case) is prior to and during installation. Waiting until after a machine has been in the field to address its security presents a huge number of problems.

Before installing the system, spend a moment to think about exactly what this machine's role will serve. Is it a mail server? If so, there are certain services it needs to run...and certain services it does not. Is it a workstation? Does it need to be accessible remotely? These are the kinds of things that should be considered before the machine is even installed. Next, you should select the most recent version of the operating system. The current stable version of Solaris is Solaris 7; Solaris 2.6 is on many machines, though, and as I have more experience with it, I'm going to have to stick with that for this write-up. So make sure you have your operating system software ready. From a computer that is already secure and connected to the network, go to http://sunsolve.sun.com/ and click on the 'Patches' link on the left. Navigate through and download all the patches you'll need for the new system. Alternately, ftp://online.sunsolve.sun.co.uk/pub/patches/ also has patches -- look for the Patch Reports at the bottom of the page.

Once you have the OS ready and the patches downloaded, you're ready to start installing. Begin by selecting End User with On-line manual pages. This will give you the basic components you need without adding unnecessary, potentially vulnerable software. If there are packages that need to be added later, that isn't a problem. Make a note of the packages that will need to be added after installation is complete, look into the security issues of each package, and install the package once all other security patches have been put into place. Once you've finished the installation and the system has rebooted, put the server on an isolated network with the other secure machine that you used for downloading the patches earlier. Download the patches from the secure host to the new machine and install them.

When you've got the operating system and all patches installed, it's time to start fine-tuning the system. Remember -- when making changes to system-dependent files such as the ones discussed here, it's best to get into the habit of always making a backup copy of the file you're editing prior to modification. This way, if there's a problem, restoration is simple. To make a backup, use the format 'cp filename date-filename', where 'filename' is the name of the file you're editing and 'date' is the current date. The place to start, as with any UNIX-based system, is /etc/inetd.conf. By prepending the line with a # symbol, comment out anything you don't absolutely need -- if the server you've built isn't designed for mail, it probably doesn't need pop turned on. It's a good bet that rexd won't be utilized, and the rlogin/rsh services should never be enabled. Be aware of what you have turned on and what it does. As with anything, if you aren't certain if it needs to be there, comment it out. You can always go back and turn something on later. To see what's actually running, type 'grep -v "^#" /etc/inetd.conf' -- that will show you all lines that are not commented out. Ideally, comment out ftp, tftp, systat, rexd, ypupdated, netstat, rstatd, rusersd, sprayd, walld, exec, talk, comsat, rquotad, name, uucp, sadmind, login, finger, chargen, echo, time, daytime, discard, telnet, imap, pop3, dtspc, fs, kcms, and all rpc services. The best thing to do, generally, is to comment out every line in /etc/inetd.conf initially, and then turn things back on later if they're needed. As a note -- if you comment out the line for telnet and you still want to access the machine remotely, make sure you install Secure Shell or OpenSSH, or you won't be able to get in. xinetd is a secure replacement for inetd, and can be found at http://www.synack.net/xinetd or http://sources.isc.org/network/daemon. Remember, just because it's more secure doesn't mean you can be sloppy in configuring it.

Now kill -HUP /etc/inetd.conf, and grep -v "^#" /etc/inetd.conf again to make sure you've got everything.

Next, go to /etc/rc2.d and /etc/rc3.d and go through a similar process with startup scripts. All you need to do to stop a script from running is to type './script stop' (where 'script' is the name of the script you're trying to stop). Then replace the 'S' at the start of its name with a lower-case 's' by typing 'mv Sscript sscript'. Again, make a backup of any file you are going to edit before altering it, be aware of what all these scripts actually do, and run only those you feel need to be running. Make sure to disable /etc/rc2.d/S71rpc, /etc/rc2.d/S76snmpdx, /etc/rc2.d/S77dmi, /etc/rc2.d/S99dtlogin, and /etc/rc2.d/S74autofs. You can actually still send mail without sendmail running as a daemon (i.e., listening on a port). First do '/etc/rc2.d/S88sendmail stop', then edit /etc/rc2.d/S88sendmail. Find the line that reads '/usr/lib/sendmail -bd -q15m'. Change that to '/usr/lib/sendmail -q15m'. Note -- the number (15m) may be different, but it doesn't matter; what you're doing is removing the '-bd' from the line.

Next, tighten down various other potential problems.

Be sure root has a umask setting of 077 or 027, so any file created by root is, by default, not readable or writable by others.

Be sure root has a safe search path, as in /usr/bin:/sbin:/usr/sbin.

Go into etc/default/login and make certain root can't log in remotely, and make certain root is in /etc/ftpusers.

Edit /etc/shadow and * out the accounts for 'uucp', 'nuucp', 'listen', 'ftp' and 'sys' -- and any other unnecessary accounts that might be in there.

Remove group write permission (chmod -R g-w /etc) of the /etc directory; unless you're using the wheel group and extending permissions that way, the files in /etc don't need to be group writable.

If the host is going to have more than one interface, don't let it route -- touch /etc/notrouter, which will create a file telling the system it isn't allowed to route.

Don't use in.routed and in.rdisc; use static routes if routing is necessary.

Disable the automounter (remove all /etc/auto_* files, and disable /etc/rc2.d/S74autofs if you haven't already stopped that script previously). If not absolutely necessary, there's no need to use NFS; rename etc/rc3.d/S15nfs.server and etc/rc2.d/S73nfs.client (to etc/rc3.d/s15nfs.server and etc/rc2.d/s73nfs.client). If you haven't already, make sure to rename /etc/rc2.d/S71rpc -- don't use the rpc services or NIS if you can avoid it. Weitse Venema has written a secure replacement for rpcbind (ftp://ftp.porcupine.org/pub/security/index.html). If you -must- use NFS, make sure you've replaced rpcbind and bear in mind that all NFS traffic flows in clear text, thus is not secure. Also, use fsirand to randomize inode numbers on NFS servers. Lastly, try to prevent buffer overflows in the stack (this may break certain things, so be careful) by adding set noexec_user_stack=1 and set noexec_user_stack_log =1 to /etc/system.

The next thing you'll want to do is set up TCP Wrappers. TCP Wrappers can be downloaded from ftp://coast.cs.purdue.edu/pub/tools/unix/tcp_wrappers/ or from Wietse Venema's site -- this should be downloaded to the host that downloaded your patch files earlier, and then the new Solaris box should download from the secure box. Install TCP Wrappers, and configure the services you'd left turned on in /etc/inetd.conf to be protected by TCP Wrappers.

There are other options to make a Solaris box even more secure, such as creating the wheel group (so only those users in the wheel group can execute commands such as su), locking down files such as /etc/hosts.equiv such that no one can alter the files, going into /etc/default/inetinit and altering the parameters for TCP initial sequence number generation by setting TCP_STRONG_ISS=2, using xntp instead of ntp, disabling IP forwarding and source routing` in etc/init.d/inetinit, logging to a remote log host, making /noshell the default shell for all accounts except root and access, removing extraneous files from /etc/init.d, locating all suid and sgid files (by doing 'find / -type f -perm -4000 -print' for suid files and 'find / -type f -perm -200 -print' for sgid files) and removing the suid and/or sgid bit from those that aren't needed (using 'chmod u-s file' or chmod g-s file'), and so on.

Once you have the system basically set up, and before you hook it to a live network, reboot and run tripwire. Make a database of checksums on a secure remote server or on tape or floppy. Optimally, get the commercial version of tripwire, as it can sign the database, to guard against tampering. Run tripwire regularly at random, frequent intervals -- one idea is to run tripwire before the nightly backup, -and- at some random time during the day.


Credits:

Lance Spitzner's whitepaper Solaris Security FAQ


Patches:

Sun's Solaris Patch Site

Alternate Solaris Patch Site

OSA
 
www.cxlsecure.com