How to secure HP-UX 11.0 to prevent people from getting off of it?

[John Jeffrey]

We need to grant outside contractors shell-level access to some of our HP-UX servers. This can be controlled by the VPN group, such that the outside contractors can connect to specific servers only.

However, once on the server, they can easily telnet off of it and communicate with other servers they are not supposed to have access to. How do I prevent this?

The contractors will be administering the Oracle instance. The Oracle binaries and data are located off of root (/), so a chroot environment will not work unless I move all the Oracle files. And Im not sure that would work anyway. As DBAs they need considerable access to the box.

I thought of locally restricting /usr/bin/telnet, /usr/bin/ftp, etc., using file level permissions. But I cannot restrict ftpd, as the contractor will need to ftp files TO the server, and it is trivial for them to ftp up their own copy of telnet.

any suggestions?

[Steven E. Protter · Accepted solution]

You can place limits on who can log in from what segment of your netwwork with the /var/adm/inetd.sec file


I'm attaching mine. This will require your contractors to first log into your network to connect, preventing the idle internet predator.

See attached example.

SEP

[James Specht]

It doesn't help you now, but we use Symark's Power Broker. It gives us the ability to control their access through a separate account but let them run oracle processes as needed. Or even in the worst case I can give them full access to oracle but record everything they do. The cool part is I can watch them live if I don't trust them. I highly recommend it if you have "outsiders" on your boxes regularly.

Hopefully someone has a quick solution to your current problem.

--Jim

[Mark Greene_1]

All the Oracle files should be owned by oracele:dba , not root. Also, you should put them in their own file system, as the system will hang or crash if they are simply in a directory off of / and a run-away query eats the disk. This setup is also what Oracle recommends, in case anyone gives you grief for bringing it up.

The other issue is that if any of the data is sensative, you'll not want to use ftp, as that is all tranmitted in the clear. Have you considered OpenSSH?

HTH
mark

[Wodisch]

Hi,

if I understand you correctly, then the oracle codefiles are located in your root-FS.
Well, then a "chroot(1M)" jail is even easier to build, as you can hard-link all "they" need into their jail. Omtting "telnet", "ssh" and such, of course...

FWIW,
Wodisch

[Keith Buck]

ipfilter can be used to block outgoing connections. (normally, it is used to keep people out, but in this case it would be used to keep people in).

This assumes:

1. the contractors do not have root access to the box
2. none of the outbound protocols required by your application allow access to unauthorized internal data/systems. You shouldn't have to allow ftp/telnet, etc.

You could also spring for a hardware firewall and put this box in a DMZ/isolated network segment. It's the same basic idea, just a cost vs. risk tradeoff.

I also recommend switching to ssh/scp over telnet/ftp, but I'm not sure if it solves your current problem.

Hope that helps

-Keith

[Steven Sim Kok Leong]

Hi,

> You mentioned:
> However, once on the server, they can easily telnet off of it and communicate with other servers they are not supposed to have access to. How do I prevent this?

Since these contractors are not authorized for access on other servers, then don't create accounts for them on these servers.

Unless you are providing them with the Oracle user account which has the same userid/password authentication credentials across all your other servers, restricting access should be as straightforward as simply NOT having any account rights provided to them. A chroot cage is an overkill and not cost-effective in my opinion.

You will need to restrict access at the database level as well if Oracle client access exists. Otherwise, they can still sqlplus to the other servers and run shell commands.

Hope this helps. Regards.

Steven Sim Kok Leong

[Elmar P. Kolkman]

Best way will be using different passwords for the accounts they need on the box they get to, so that even if they have an telnet client, they don't have passwords for accounts on other servers.
It will mean you have to remember passwords are different on that server, but at least you keep them off your other servers.

Also using auditing and monitoring the shell history on the system could help you track down malicious use of their rights, so you can take repercusions if they do things they are not allowed to do.