Locking down your Solaris system
Over the years I've worked on numerous sites running SunOS 3,x, SunOS 4.x, Solaris 1.x 2.x upto and including Solaris 10 being the latter! I've been involved on many sites, and on many requests and configuration changes to bolt down certain areas of Solaris depending on the project involved;
I've covered the basics by simply disabling certain services, inetd processes, certain network ports. It goes beyond the scope of installing tcp wrappers, and even on certain sites, the installation of Trusted Solaris ...
[Hmmm! those grey cells are working overtime and beginning to fail me but I still remember those days! Stop! Stop! Stop! lets get back on track.]
At a current contracted site, I was tasked with a small project to investigate different ways to lock down the a Solaris systems. Here I share my findings.
Firstly, I would recommend that you perform a reinstallation of the Solaris system where possible. You may ask why do this, but if we can start from scratch the easier it is! Starting from a fresh install, we only (in most situations) need to select the 'Solaris Core' (SUNWCreq) install cluster; In most cases that's all that's needed for a system; At a later date if desktop or developer environments are required, you can simply added these features via the pkgadd command.
With later releases of Solaris, if you want to, you can manually lock down your system using the svcs and svcadm commands. Useful utilities like netstat, nmap, and lsof are your friends, but at the end of the day of you want to manually want to lock down a system you really need to know what you are doing. However, there is a far simpler way to do this and that is to use the Solaris Security Toolkit (SUNWjass). This is a very powerful (and extremely well documented) utility that is pretty easy to use, to very good effect. It is also free.
All you need to do is run one simple command (there are 16 variations to choose from depending on paranoid you are) and the SST will do the rest — disabling all the appropriate services, setting file permissions, creating hosts.allow and hosts.deny files and even invalidating non-root user passwords in certain cases. So be sure that you have console access to your system before you run it.
You can even run it again in analyse mode to ensure that the system is still locked down the same degree as it was when you first ran it (although I have not tested this).