The Yin and Yang of Ignite vs Security

[Terrence]

I'm setting up an ignite server, and installing fresh new copies of ignite on all my clients. However Ignite is opening all kinds of services that my paranoid security efforts are seeking to shut down. I realize I need the tftp entry in inetd.conf for clients, but do I need this other entry for the clients, or just on the ignite server?

instl_boots dgram udp wait root /opt/ignite/lbin/instl_bootd instl_bootd

What about this line? Is it needed for ignite?

bootps dgram udp wait root /usr/lbin/bootpd bootpd

Finally I know I need nfs for make net recoveries but normally I'm going to keep it off. Is it enough to turn it off in just nfsconf? My security cookbooks recommend renaming /sbin/rc3.d/S100nfs.server and /sbin/rc2.d/S430nfsclient to disable them as well.

My plan is to keep everything off, and then script it so that it all gets turned on when ignite is creating net or tape recoveries, and then turned off again when done. Opinions? Specifics? Examples of what you are doing?

[Steven E. Protter]

Ignite servers build in some security problems, as you have found out.

On my Ignite Server which is used to push or pull Golden images, I disabled all the r protocols in /etc/inetd.conf and built the image that way.

I commented them because in order to start a push, you need remesh enabled. So after pushing the image to the client, if I need to push a revised image all I have to do is:

vi /etc/inetd.conf

uncomment the r- procols

inetd -c

All on the target Ignite Client.

Your plan is solid. If you need no NFS services running on the Ignite server, you can disable all the NFS servcies and fire them up right before you start using the Ignite server.

NFS though isn't the real problem. Its been made pretty fast and pretty secure. Its the Berkely protocols (rcp remesh et al) that present the biggest security issues.

Even a Bastille Security Hardening Install won't disable NFS because its pretty basic to many OS functionaility.

Bastille Info:
Bastille Security hardening
http://www.software.hp.com/cgi-bin/swdepot_parser.cgi/cgi/displayProductInfo.pl?productNumber=B6849AA

Perl which the above needs.
http://www.software.hp.com/cgi-bin/swdepot_parser.cgi/cgi/displayProductInfo.pl?productNumber=PERL

As I said, you plan is solid just be prepared to put things back with regards to NFS just in case other functionality is needed.

SEP

[Tim Sanko]

I manually turn on NFS as I need it. When we do our make_net_recovery and if our NFS is down we get an email message telling us that we failed our make_net_recovery.

We use cron on most of our enterprise servers to kick it off at 05:00 A.M. By the time I wander in at 7:30-7:45 it is done...

I merely stop the nfsd using a /sbin/init.d/nfs.server stop. I don't bother renaming the client on our boxes, because there is no client behind the firewall to connect to.

All of my NFS exports are as follows
/d140 -anon=65534,root=131.184.4.101:131.184.64.10

This allows root mounting for /d140 to two interfaces on one machine. The real trick is for my /var/opt/ignite/clients subdirectory, which has a long pained list. It allows me control and flexibility, but gives grief in complexity... We ignite a half dozen boxes with two interfaces to each of our two ignite servers.

[David Lodge]

>NFS though isn't the real problem. Its been made pretty fast and pretty secure.

I would strongly disagree with that statement. Even though the r-commands aren't the most secure and are ussually exploited; I would say the NFS is *worse*.

The protocol is pretty insecure by definition - and the HP implementation makes it particulary easy to break. Essentially because the NFS daemon only uses a shared secret to perform authentication - and these accesses aren't logged; then this means that it is easy to bypass mountd (which does IP validation) and guess the NFS file handle. The HP file handle is pretty predictable and has very little entropy. Also it is susceptible to sniffing on the network.

In this respect remsh may actually be *more* secure than NFS - as remsh doesn't *need* a shared secret which can be guessed - or sniffed - its susceptibility is limited to IP spoofing...

The best solution would be for HP to rewrite it using some secure form of authentication - eg using RSA certificates...

dave

[Bill McNAMARA_1]

you can also use ftp to push the image across.

[Bernhard Mueller]

Terrence,

if you want to have security and not spend a lot of time writing scripts to undermine security temporarily, why don't you use local tape drives in the first place.

for the tape change labor, if you need the local drives for some other backups you have that anyway, if not you just leave the tapes in place.

Of course you may have to invest in tape drives and possily HBAs, however, if security is only temporary, how do you rate that?

Additionally, you might consider to compromise
security only occasionally at randomly choosen times, to have a fallback on an ignite server, if your tape recovery does not work.

If you have hundreds of workstations without a tape drive I would make sure they are very very similar so that you could use practically any recovery tape to restore them.

Just my 0.02$

Regards,
Bernhard