Need info: converting to trusted system, shadowed passwords, FTP

[Roderick Derks]

Hello,
A Unix server here is also used for FTP. The problem is that the passwd file in the FTP directory is a security threat. The solution I found is that I have to convert to a trusted system and then activate shadowed passwords.

Is this correct? Am I missing something?

Are there any risk converting to a trusted system? I'm not using NIS or NIS+.

This is the system:
HP-UX ezhlims1 B.11.11 U 9000/800 1775977681 unlimited-user license

Thanks!

[Bill Hassell]

There are several ways to limit ftp's vuew of your filesystems. Take a look at: man ftpaccess. The shadow password system is not the same as Trusted. Shadow passwords are simply kept in a separate file with root-only access. A Trusted system also removes the encrypted passwords from /etc/passwd but stores them in individual files in a root-only filesystem: /tcb. A Trusted system is always recommended for any production system.

Converting to Trusted is simple--use SAM for simplicity. Note that if anyone is typing more than 8 characters for their password, your current system ignores characters 9 and above. But in a Trusted system, an exact match is required (and users can create much longer passwords if desired). There is no risk to converting..it improves the security a lot more than shadow passwords. If you're running some strange application that tries to manipulate the passwd file, it may fail with a Trusted system, but I would not trust such software anyway. Since Trusted systems have been available on HP-UX for a decade, anything that fails is obviously poorly supported.

[Chris Vail]

Here's a paragraph from a recent memo I wrote:
In most versions of Unix, user information (including passwords) are kept in a simple text file called /etc/passwd. The passwords themselves are hashed (a form of encryption). There are many good reasons to keep the /etc/password file world readable. Therefore, it is also possible for a malicious user to make a private copy of this file, and make a "dictionary attack" against it. This attack takes a large number of words (a "dictionary") and runs them through this hashing process, and compares the result with the contents of the private copy of /etc/passwd. This can pretty quickly detect weak or improper passwords, with the resultant security threat. Such dictionary programs are widely available.

One of the ways to deal with this threat is to remove the password hashes from the /etc/passwd file and into a "trusted computing base" (TCB). This is basically a small and secure database. This protects the passwords themselves from being copied, but the other data in /etc/passwd remains available.

Converting to TCB is a no-brainer. AFAIC, this should be the default installation.

Chris

[Steven E. Protter]

ftp is going to transmit password to and from the user in clear text whether your system is trusted or not.

I recall an excerize in Internet security class where we used Kerebos to secure ftp and telnet, but I don't know whether that woulc be compatible with your users and clients.

Same issue with Secure Shell, available at software.hp.com which has a program called sftp which autenticates in a secure fashion.

Going trusted system is not risky at all. Its our standard now. The biggest risk is the security audit files filling up the root directory. Best to redirect them to a larger filesystem.

So if you want the security of trusted system or shadow passwords(shadow password is a separate product that converts you to a Linux like /etc/shadow file). Go ahead with that.

The ftp issue needs to be worked out based on the needs of the ftp client. Never, ever give ftp access to root. Because of the default ftp authentication your root password travels across the network. I can tell you how to sniff a password if you need that concept proven to managment.

SEP

[Roderick Derks]

Thanks you all, you are helping me a lot.

I'd like to have that method to sniff the passwords on the network!

The server is an application server for laboratory software: not many customers. This software has very little security itself. It uses ftp and telnet from the client to the server and vica versa. The supplier has to change it's code to use sftp. I'm the first who is complaining about the security, the other custumers not seem to care much. So there is not enough pressure to increase the security level of the application.

I installed SSH so we can use this for remote support. Is this safe enough?

I'm going to prevent root from logging in directly via telnet and ssh.

I'm going to convert to a trusted system and enable the shadow passwords (the latter needs the trusted system).

Got any more suggestions?

Thanks!

[Chris Vail]

Additional suggestions: stop the telnet and FTP services completely. Remove .rhosts files. Ssh replaces almost all remote services, and does so securly.

This document will tell you how to set up secure shell so that it authenticates nicely and transparently between systems.

I can't believe I beat Steve Protter in posting my document!

[Roderick Derks]

I had to let telnet and ftp run be used by the application software.

Converting to a secure system and installing SSH and sudo (so I can give normal users acces to certain root commands) helped me.

Thanks all!