ignite without rexec

[Donny Jekels]

Was anyone able to get "Ignite UX" to work without rexec?

[Pete Randall]

Donny,

I assume you're referring to make_net_recovery. Make_tape_recovery seems to work just fine.


Pete

[Donny Jekels]

nope. not even there yet. trying to add a client to our ignite server, so I can push out the new Ignite client software.

#rexec is commented out in /etc/inetd.conf

[Pete Randall]

Donny,

Maybe SEP will pipe in here. He does a lot with Ignite and I know he abhors the "r" commands.


Pete

[Donny Jekels]

Pete thanks, I read some of SEP's threads yes maybe he can help.

[Alzhy]

If Ignite's compnents are configurable.. perhaps it can use SSH to do its thing?...

[Pete Randall]

Donny,

I sent him an e-mail. He's been quiet the last couple of hours but I'm sure he'll jump in when he can.


Pete

[Steven E. Protter · Accepted solution]

Hi,

I was doing some yucky work. Budgets are due today at 5 p.m. Plus trying to spend last years money.

To my knowledge, and I've had a few support calls with HP on this, the Berkley protocols, including rexec are required to run an Ignite/UX server.

I have contacted HP and said that its an important Ignite enhancement to integrate this product with ssh.

How I handle this obvious security problem is as follows:

The Ignite Server has the protocols enabled in inetd.conf. It has no .rhosts file and it has an /etc/hosts.equiv file authorizing Ignite clients by IP address.

This enables make_net_recovery jobs to be run out of cron by my two production servers to the Ignite Server.

Those two servers, Ignite clients have the Berkley r-protocols commented out in inetd.conf. When I need to do DR or push a new image out to those servers, I uncomment the entries save the file and run ientd -c

This is still a problem, I'd rather not run this way. I read the docs on Ignite 4.3 and see no indication that ssh is supported.

SEP

[Donny Jekels]

yuck! Thanks guys.

[Donny Jekels]

quick refresher.

inetd -c does not drop existing connections, or does it?

[Steven E. Protter]

No, existing connections will stay open.

inetd -k will stop new connections, not disrupt existing ones.


SEP

[Donny Jekels]

yet another work around.

Okay thank you.
peace
Donny

[Jeff Schussele]

Hi Guys,

Here we set up /var/adm/inetd.sec to allow access ONLY from the Ignite server(s).
Corp Security has blessed this, but like us, would rather disable r commands altogether.

Rgds,
Jeff

[Donny Jekels]

Jeff,

this sounds like a great idea. send more info please.

Thanks Donny

[Steven E. Protter]

Here is an ientd.sec example.

ftp allow 10.1.* 10.1.11.* prod tzfat hebron
tftp allow 192.168.* 10.1.* jufprod jufdev hebron moriah
login allow 10.1.* 10.85.* 10.1.31.* 10.4* jufprod hebron moriah jufdev
telnet allow 10.1.* 10.85.* 10.1.31.* 10.4* prod hebron moriah

There are few limits on what you can do with this file, it can be very precise and limit the chance that outsiders will get in.


SEP

[Donny Jekels]

does this mean i can add one entry for my ignite server - say

/var/adm/inetd.sec

rexec allow

how does inetd knows to run rexec if it is commented out in inetd.conf?

[Steven E. Protter]

Donny,


There comes a time when you need to try it.

Now may be the time. I tried it and it was accepted when I ran inetd.sec

Also note, you can limit the NFS access that Ignite ALSO requires with /etc/exports.

Here is mine.

/images -anon=2,access=jufprod,access=hebron,access=tzfat

Note the access limits based on hostnames.

NFS is a problem because it transmits disk information unencrypted.

SEP

[Steven E. Protter]

I emailed Berlene Herren on this issue. Seems she read the the thread and she answered as follows(forgive the paraphrase).

There is an enhancement request to the labs for Ignite to work with ssh.

She added our organization to the list of organizations that wants this feature.

In my opinion, the way to make this happen is for customers such as you Donny, to contact HP and make their wishes known.

I imagine based on my Ignite experience its a rather involved upgrade.

SEP

[Jeff Schussele]

Hi Donny,

Sorry for the delayed reply - have been quite busy today.

Anyway as SEP noted you need

tftp deny
tftp allow ignite_server_ip
login deny
login allow ignite_server_ip
exec deny
exec allow ignite_server_ip

on the Ignite client as well as the Ignite server. First entry denies ALL while the second explicitly allows all servers/IPs listed. You don't need to bounce inetd as the .sec file is read at every connection attempt.

HTH,
Jeff

[Donny Jekels]

Sure thing, I can send emails and requests to HP, if I only knew where to send it with our next SD order :-(

[Berlene Herren]

Donny, you can send security issues to mailto:security-alert@hp.com

Regards,
Berlene

[Steven Sim Kok Leong]

Hi,

I agree too that ssh is the way to go. The security risk with rexec is primarily in its cleartext mechanism. Authentication credentials can be sniffed along potential man-in-middle attacks compromising traffic integrity.

Possible mitigating mechanisms include:

1) Having a switched network where the Ignite server and the clients are in neighboring proximity to one another. Unless a switch port is in SPAN mode, authentication credentials cannot be sniffed.

2) If you have a VPN tunnel between the client's switched network and the Ignite server's switched network, then traffic is secured within public network.

3) Implement imperfect security by obscurity by using a high unknown port (e.g. 65432) for both rexecd and rexec. /etc/services has to be modified at both Ignite server and client ends. For someone malicious to sniff the rexec traffic, he needs to perform the extra step of probing and identifying the service running on the obscure port.

Hope this helps. Regards.

Steven Sim Kok Leong.