Re: ssh with diskless machines

On Tue, Mar 18, 2003 at 09:48:52AM +0100, Peter wrote:
> Hello,

That's one way. The other and slightly more difficult thing to do is a man-in-the-middle and intercept messages while the machine is still up.

If you don't use hostkey authentication, what kind of authentication will you use to authenticate the remote host? The r-commands use IP address. Obviously, in the attack outline you give, its even easier for the e\/1L black hat to spoof the remote server for r-commands. He can follow the same process but skip the step where he steals the key.

The point is, if there is not some secret stored on the remote machines, there is no way to do authentication. If the black hat knows everything about the remote machine or can get all of the info about it, he can spoof that machine by building a replica, under his control of course, to whatever precision is necessary.

> > NFS (heck, might as well give them all the same set of keys) just to

We all know what NFS _really_ stands for, No F*cking Security, right? If the keys are handed out via NFS, the black hat can steal one set just as easily as any other. So you need to weigh two facts:

• Using one key may make the potential black hat's life _slightly_ easier. An analogy might be, you have glass case containing the keys to every office in the lobby versus a glass case with one master key.
• Using one key makes maintaining your PKI a helluva lot easier.

Also, using one key may server to continually remind you that the keys are pretty much a formality to keep SSH happy and are not providing any real security.

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related securityfocus.com Links bugtraq certification focus-bsd focus-ids focus-ih focus-linux focus-ms focus-sun focus-unix-other focus-virus forensics incidents libnet linux-secnews ms-secnews pen-test secpapers secprog sectools secureshell security-basics securityjobs sf-news vuln-dev webappsec Request more information about Pantek

> > make SSH happy seems like your only option. This is OK as long as you

You still have the same problems with LDAP and sftp. It all flows back to the problem of not being able to store a secret on the workstations. How can the diskless workstations authenticate themeselve to the LDAP server or sftp server if they can't store a secret? That is, how can you prevent the black hat from relpicating the process the workstations use to fetch the keys if the black hat knows everything that the workstation does?

I think what you need to do is build your security policy around the fact that the workstations can never be trusted. Assume that they can be compromise, or worse, completely spoofed. For example, you should never use the same password to log into one of these things that you use on the servers, use host-based authentication or "throw-away" passwords (e.g. some root password shared by all of the workstations). It sounds backwards, but if someone can spoof it, you don't want to be typing your password into it and giving it to the black hat.

I should point out that there are ways to get that secret onto the remote machine, but I haven't mentioned it because it is somewhat harder to do. What you can do is wait until the remote user logs into the machine to setup the operating system. The remote user's authentication secrets become the means to secure the communications. There is still a risk that the remote workstation was trojaned before the user authenticated, but this attack is more difficult than the others discussed above.

-- 
Crist J. Clark                     |     cjclark@alum.mit.edu
                                   |     cjclark@jhu.edu
http://people.freebsd.org/~cjc/    |     
cjc(at)freebsd.org