Date: Mon, 22 Nov 1999 00:47:35 -0500 From: Jonathan Chen <jon@spock.org> To: freebsd-security@FreeBSD.ORG Subject: Re: Disabling FTP (was Re: Why not sandbox BIND?) Message-ID: <D7CF1878D2GZ7J8373.A44257A9835@msidl.d0.localhost> In-Reply-To: <NCBBILEECKNKMONCIAIOKECJCDAA.freebsd@gtonet.net>; from freebsd@gtonet.net on Sun, Nov 21, 1999 at 05:17:54PM -0800 References: <Pine.BSF.4.21.9911211832330.19746-100000@isr4033.urh.uiuc.edu> <NCBBILEECKNKMONCIAIOKECJCDAA.freebsd@gtonet.net>
index | next in thread | previous in thread | raw e-mail
[ random-rant-mode=on]
ftpd and telnetd is just as much a security risk as sshd. Alright, before
everyone starts flaming me for this somewhat exaggerated statement, hear me
out. Here's some reasons I think ftpd/telnetd is not as great a security
hole as some people may be saying and why, IMHO, it should not be disabled
by default.
1) ftpd/telnetd, by themselves, does not give unwanted guests a window of
entry any more than sshd.
2) the code base for ftpd and telnetd combined is smaller than sshd. Plus,
sshd may call external libraries like rasraf. Tell me which one is
easier to audit for buffer overflows.
3) People who have no need to use ftpd (or telnetd) does not use
ftpd/telnetd. Thus, cleartext password is never transmitted over these
protocols.
4) FreeBSD comes with skey. The security conscious may choose to use it.
With PAM this is very easy.
5) The same people who doesn't know about sending plain text passwords is
also more likely to give away that password to someone else using other
means. The solution is education, not disabling services.
6) Instead of disabling the service altogether, it is perhaps better to
simply insert a "220- this protocol transmits password in clear text,
use with caution. consult your sysadmin if you don't know what that
meant" on the ftp greeting message.
7) Picture this scenario: Sysadmin installs freebsd machine. ssh is not
installed for whatever reasons (ie, crypto laws/time/firewall-unable to
grab source). Now this same sysadmin heads over to a near by building
to setup a user machine.
Boss: "I need to transfer this stuff to the new machine, NOW!"
Admin: "no problem. I haven't installed sshd there yet, but I should be
able to ftp the stuff over. Don't worry about the clear text password
going through the network because our internal network is relatively
secure, and I can change the password after I get back to the console
anyway. In the mean time, if someone sniffs the password and tries
it, I should be able to get back to the console in time to detect and
stop this without any damage."
Computer: "ftp: connection refused."
Boss: "What the heck?!?"
Admin: "Donno, let me telnet in and check."
[ logs in to new machine ]
Admin: "Hmm... appears someone changed inetd.conf so ftpd is disable by
default. Now what should I do? Should I run over back to the other
building and make my boss wait 20 minutes, or do I send the clear root
password over the network?"
8) IMHO, ssh gives too many people too much false sense of security. How
many times have you ssh'ed from a Windows (or otherwise unsecure)
machine? How many times have you ssh'ed from a machine that other
people admins? How many times have you blindly pressed "yes" when it
asks you to accept a new host key? If a windows machine with an email
client makes the whole network insecure, then it is also reasonable to
conclude that any ssh client on a windows machine with an email client
may also be trojaned or has a running key capture driver.
9) While in a perfect world every person who sets up a freebsd box would
know how to turn on/off services, that is certainly not true in the
world I live in. Certain users may have certain expectations about what
a machine should be able to do out of the box. Sure you can document it
to your heart's content, but the fact remains that people don't always
RTFM, or may not know where the relevant portions of the FM is.
10) Whatever happened to "Unix was not designed to stop people from doing
stupid things"? ;) (can't remember who that quote was from)
[ quasi-fair-mode=on, rant-mode=stuck ]
So there'll always be those people who have the "if it ain't broke, don't
fix it" attitude and go on using telnet/ftp. Disabling these services by
default may make some of them use ssh or other more secure protocols, but
it might just make some others turn it back on or switch to another OS.
Disabling ftpd/telnetd also has other effects like making the host less
appealing to someone doing a port scan.
While I'm sure many of you will have different opinions on this matter, I
think I is not unreasonable to have an extension to sysinstall that let
people turn on/off inetd services, much like daemons started at boot time.
Users setting up freebsd would get this menu and thus be able to select
whatever choices they want.
Just my $0.002 on this whole issue.
--
(o_ 1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2 _o)
\\\_\ Jonathan Chen jon@spock.org /_///
<____) The surest protection against temptation is cowardice. --MT (____>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D7CF1878D2GZ7J8373.A44257A9835>