drears@pilot.njin.net (Dennis G. Rears) (12/09/89)
I just want to get some info before I do this ......
I thinking of changing the ftp servers on systems that I have
control over so that the behaviour mimics rlogin/rsh. Example:
ftp -l drears caesar
will allow me to access ftp without a password if .rhosts or
hosts.equiv allows access. Also if I do :
(815) ac4> ftp caesar
Connected to caesar.
220 caesar FTP server (SunOS 4.0) ready.
Name (caesar:drears): drears
230 User drears logged in.
ftp>
Is there any reason why I shouldn't do this?
Dennisbarmar@Think.COM (12/09/89)
In article <Dec.8.16.10.03.1989.20166@pilot.njin.net> drears@pilot.njin.net (Dennis G. Rears) writes: > I thinking of changing the ftp servers on systems that I have >control over so that the behaviour mimics rlogin/rsh. >Is there any reason why I shouldn't do this? It seems like a reasonable thing, but there are a number of things you'll have to watch out for when you do it. For security, ftp should use a privileged port to connect to the daemon, and ftpd should check that the foreign port is privileged. This prevents users from spoofing with "telnet <host> 20". However, this means that you'll have to make ftp setuid root. But much of the program probably assumes that it is running under the invoker's userid. It should change its effective userid to its real userid except when it is opening the port. Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
dougm@ico.isc.com (Doug McCallum) (12/11/89)
In article <Dec.8.16.10.03.1989.20166@pilot.njin.net> drears@pilot.njin.net (Dennis G. Rears) writes: > I thinking of changing the ftp servers on systems that I have >control over so that the behaviour mimics rlogin/rsh. >Is there any reason why I shouldn't do this? It seems like a reasonable thing, but there are a number of things you'll have to watch out for when you do it. It isn't a safe thing to do for the reasons you outline below. For security, ftp should use a privileged port to connect to the daemon, and ftpd should check that the foreign port is privileged. This prevents users from spoofing with "telnet <host> 20". You don't even need telnet <host> 20, all you need is ftp and do the login by hand. However, this means that you'll have to make ftp setuid root. But much of the program probably assumes that it is running under the invoker's userid. It should change its effective userid to its real userid except when it is opening the port. Non-UNIX systems don't have the priviledged port mechanism. It would be quite simple to spoof the FTP daemon even with the mechanism you suggest. It would be much better to add something like the Kerberos authentication system and forget the priviledged port business.
barmar@Think.COM (12/13/89)
In article <DOUGM.89Dec10124339@queso.ico.isc.com> dougm@ico.isc.com (Doug McCallum) writes: >Non-UNIX systems don't have the priviledged port mechanism. It would >be quite simple to spoof the FTP daemon even with the mechanism you >suggest. It would be much better to add something like the Kerberos >authentication system and forget the priviledged port business. The original poster was only looking for a mechanism as secure as rsh, which uses privileged ports and the hosts.equiv file to implement its security. If a site is concerned about spoofing, it should only put Unix systems in its hosts.equiv file. Password-less access would always be rejected from hosts not in this file; for hosts in the file ("trusted" hosts), password-less access would be permitted only from privileged ports. Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
guy@auspex.UUCP (Guy Harris) (12/16/89)
>For security, ftp should use a privileged port to connect to the daemon, >and ftpd should check that the foreign port is privileged. This prevents >users from spoofing with "telnet <host> 20". Well, some users, anyway. Not all OSes in the known universe prevent non-privileged users from using certain port numbers (and some of those that don't may even have TCP/IP and TELNET implementations).