From owner-freebsd-security Sun Nov 21 21:47:46 1999 Delivered-To: freebsd-security@freebsd.org Received: from spock.org (cm-24-25-148-191.nycap.rr.com [24.25.148.191]) by hub.freebsd.org (Postfix) with ESMTP id E6AC514F6C for ; Sun, 21 Nov 1999 21:47:36 -0800 (PST) (envelope-from jon@spock.org) Received: (from jon@localhost) by spock.org serial EF600Q3T-B7F8823AAA53941F7T for freebsd-security@FreeBSD.ORG; Mon, 22 Nov 1999 00:47:35 -0500 (EST) (envelope-from jon) Date: Mon, 22 Nov 1999 00:47:35 -0500 From: Jonathan Chen To: freebsd-security@FreeBSD.ORG Subject: Re: Disabling FTP (was Re: Why not sandbox BIND?) Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: telnet In-Reply-To: ; from freebsd@gtonet.net on Sun, Nov 21, 1999 at 05:17:54PM -0800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [ 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