« Rolling back a zone... | Main | Solving the dual-boo... »

20060831 Thursday August 31, 2006

Securing a zone using the Solaris Security Toolkit

Yep. Still looking over my shoulder. Until recently, I was using a script I wrote to customize a zone. I had two reasons in mind. The first was to disable unnecessary services to conserve RAM, the second to secure the server. However, there is a better way. I've recently adopted the Solaris Security Toolkit (SST) thanks in part to Glenn.

The Solaris Security Toolkit is a configurable tool to harden a system. While best applied during a jumpstart (secure early & repeatably), it can also be applied to a newly installed system. Of course, a newly created zone is a great target for SST. My first application of the SST was to a zone created specifically for the purpose of understanding what the SST does to a host/zone. I have the ability to customize the SST via a driver file to enable or disable the hardening of various OS functions. In fact, while learning about the SST, I was rolling back the zone to repeatedly test out my customizations.

What is equally nice about the SST is that it not only hardens a system, it also enables the administrator to run an audit to detect modifications that stray from the SST hardening. There is one modification I would like, and that is for the SST to be zone aware. What I mean by that is the ability to run the SST from the global zone, and have the SST harden a specified list of non-global zones as well as the global zone. Right now, I have to install the SST into each and every local zone of interest. I'd like to leverage potential the economy of scale of the zones model. Then again, I want to get a bit smarter on "secure by default" to see how it plays with the SST.

If you are serious about security, consider utilizing SST.
(2006-08-31 07:53:21.0) Permalink Comments [10]

Comments:

I've gone through the same process on an X2100 this week. I guess when you say "install" SST into each NGZ you mean apply - it gets installed once into the global zone (/opt/SUNWjass).

One quirk I found yesterday however, the 'secure' driver disables mdmonitor, which depends on rpc/bind and friends - all disabled. This lack seems to send my SVM mirrors into maintenance mode on every reboot (or so I think; I know I've found them in that state several times since applying SST). So I have re-enabled these services on the global zone and will use ipfilter to hide them from outside.

Did you get ipfilter working? I've had no luck with even the simplest configurations.

Posted by Toby on August 31, 2006 at 09:02 AM PDT #

Toby, you are correct on the "install". It's the centralized hardening & auditing I am looking for (zlogin via the finish scripts).

I have gotten ipf to work without any issue. Keep in mind that ipf will not enforce its rules for inter-zone communication, only for traffic that goes out on the wire.

Also, make sure you have nge added to /etc/ipf/pfile.ap as follows for the nge interface, and bge uncommented for the bge interface: nge -1 0 pfil bge -1 0 pfil

Let me know if this helps.

Posted by John Clingan on August 31, 2006 at 09:25 AM PDT #

Toby - retry on /etc/ipf/pfil.ap (typo in last comment):

bge     -1      0       pfil
nge     -1      0       pfil

In addition, after modifying /etc/ipf/ipf.conf, I run "ipf -Fa; ipf -Af /etc/ipf/ipf.conf". That's rather brute-force but I'm not smart enough with ipf yet to do anything else :)

Posted by John Clingan on August 31, 2006 at 09:29 AM PDT #

We looked at that feature for a little, and decided against it. We would have to do zlogin's to enter each zone, since you can't safely access them from the global zone. Then it got a bit more complicated. We can put it on the list to take another look at. SST should not explicitly disable mdmonitor, so it's probably just getting offlined, not disabled. Or it's just not enabled by default. You could remove the disable-rpc script and possibly tweak JASS_SVCS_DISABLE to help there. You need patch 122608-02 for ipfilter with SST, we had some silly bugs that were preventing it from working correctly with SST.

Posted by David Finberg on August 31, 2006 at 10:30 AM PDT #

I don't need any kind of filtering between zones, and I don't even need filtering on the NGZones. I want filtering on the global zone only (and only because I must now have sendmail, rpc/bind and friends running). (How DOES one get sendmail's submission daemon to bind to localhost only??!!)

I know I should RTFM, but what is the difference between offlining and disabling in this case? I was seeing mirrors in maintenance mode, is this the cause? If so, it has to be ONLINE (and hence the need for filtering).

Are they the silly ipfilter bugs that I've been wrestling with for days??? The sort of bugs that lead one to question one's sanity a little?? :)

My system is, I thought, fully patched but 'showrev -a |grep 122608' comes up emptyhanded. Thanks.

Posted by Toby on August 31, 2006 at 02:28 PM PDT #

I don't have that patch installed either, although I don't have the SST installed in the global zone (yet).

Disabled means you do not want the service to run, period. Offline means one of the service's dependencies have not been met, and it won't start until the dependency is met. Once all of it's dependent services are running, then mdmonitor will automatically be started.

Run "svcs -x mdmonitor", and that will tell you more.

Note, "svcs -D mdmonitor" will show what services mdmonitor depends on. "svcs -d mdmonitor" will show what processes depend on mdmonitor".

svcs -x will show all potential "service" errors or misconfigurations on the system.

Posted by John Clingan on August 31, 2006 at 02:41 PM PDT #

Dagnabit, I got my -D and -d reversed. Swap the two, and all the verbage falls correctly into place :)

Posted by John Clingan on August 31, 2006 at 02:44 PM PDT #

OK, after patching and re-applying the secure profile, ipfilter seems to be behaving much better. Thanks again, the machine's now ready to go into colo in 2 hours' time :)

Posted by Toby on August 31, 2006 at 03:33 PM PDT #

Yes, mdmonitor may have been 'offline' because rpc/bind was disabled - I am familiar enough with SMF to have figured that much out :-) - but I think SST actually disabled it.

In either case, it wasn't running, and I did want to confirm that this was actually causing the mirrors to go into maintenance mode (still not sure). I re-enabled rpc/bind and the other dependencies, and mdmonitor is running normally. I've metasync'd the 2 mirrors to clear the maintenance condition, we'll see what happens.

Posted by Toby on August 31, 2006 at 03:37 PM PDT #

Toby, great to hear.

Posted by John Clingan on August 31, 2006 at 03:43 PM PDT #

Post a Comment:

Comments are closed for this entry.