Date: Tue, 28 Jul 1998 08:48:05 -0400 (EDT) From: Robert Watson <robert@cyrus.watson.org> To: Brett Glass <brett@lariat.org> Cc: "Jan B. Koum " <jkb@best.com>, chat@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: FreeBSD Security How-To (Was: QPopper exploit) Message-ID: <Pine.BSF.3.96.980728083352.12263A-100000@fledge.watson.org> In-Reply-To: <199807272354.RAA01585@lariat.lariat.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 27 Jul 1998, Brett Glass wrote: > I'd like to commend Jan on this effort. Yes, I think this is a great thing :) > I do think that the section on eliminating inetd needs some fleshing out, > though. Some servers, such as all of the POP3 daemons I've tried, don't > seem to admit themselves to being run except from inetd. Also, the section > should discuss the dangers of having a server die without any automatic > means to resuscitate it. For example, the docs for identd warn against > running it without inetd, since if it quits it will not be restarted. > Perhaps a utility that checks for the presence of servers and restarts them > if they've died could be developed as part of this effort and perhaps added > to the FreeBSD distribution. I agree with limiting/replacing this inetd, but I am actually not sure I agree with just removing inetd. inetd provides a number of useful services under BSD: 1. Single location to configure the majority of IP services (i.e., a single point of configuration that is easy to maintain and monitor) 2. Single location to install IP wrappers and IP-based access control 3. Single location to monitor for potential denial of service attacks These are all important, I feel. Inetd provides a simple way to monitor which daemons you are running, and disable them easily. Rather than having to modify umpteen rc.* scripts in many directories, I can modify a single file. Simplifying the policy control mechanism is not bad, and it makes it easy for new users of BSD to disable services. Now, instead of finding references in many scripts and config files, I can in 20 seconds comment out all the lines but telnet, ftp, etc. This is not bad. And the format of the inetd configuration file is certainly not bad -- attempting to stuff the same degree of control into rc.conf is only asking for trouble :). With a single HUP, I can enact the new policy, rather than tracking down dozens of processes hanging around. Also, let's not forget the reason for inetd in the first place -- if you have a number of infrequently used TCP services, you experience far lower load and resource consumption via inetd. You are less susceptible to memory leaks (or even just fragmentation), swap space consumption, etc. Most long-lasting heavily hit services regularly kill their component processes to try and address this (for example, many web servers only use particular server processes 64 times before killing them in an effort ot reduce fragmentation and memory leak issues). I would rather reduce the number of long-running daemons and have a centralized point of control. But there are more sides to this (points 2 + 3 of above). inetd allows the use of TCP wrappers via a central administration point. Rather than building by-IP access control into each and every daemon running on the system, using a central TCP wrappers config file makes far more sense. It also means that I can apply varying access control mechanisms to binary-only daemons I may have (commercially available daemons). It also means I don't have to sit there and patch a ported daemon like crazy to use my access control. An example: suppose I have an IPsec FreeBSD router. The FreeBSD router needs to be configured remotely by a mobile host so that we can have mobile IP. I want the machine to allow connections to the telnet, etc, daemons only if it is a secured connection with the correct keying material/etc. Rather than build this into each daemon, I'd really prfer to have it live in TCP wrappers. When the connection comes in, the TCP wrapper makes an authorization decision based on knowing about IPsec, and then if desired, forwards the connection to the telnet daemon. Similarly, wrappers provide a central logging facility. Rather than rely on the far larger and more complex telnetd that is probably more susceptible to programming errors, I want wrappers to securely log the event, and then allow the connection to telnetd. Perhaps also, one might want to run inetd itself chroot, and have all daemons inherit that aspect? The third point is denial of service. With a dozen daemons running independantly, written by a variety of vendors, it might be quite hard to monitor denial of service attacks. With a single daemon multiplexing connections in userland, I can far more easily install a filter watching for application-based denial of service, or resource consumption. I feel that inetd provides a degree of centralization for configuration and security that is more of a benefit than a liability. Certainly, in an environment where *no* daemons are running, inetd is probably a bad idea. The same for high volume daemons like httpd. On the other hand, wouldn't you rather have a small daemon (finger) run as nobody via the benefits of inetd changing the uid, than running fingerd as root so that it can bind the port? > Also, the section on ssh suggests running it without telling the user where > to find client software. Any recommendation for a secure service should > include information on how to obtain clients for all of the usual client > platforms (including -- yes -- Microsoft OSes). I heard there was a free Windows ssh client these days -- I haven't used it as (oops) I don't run any Microsoft operating systems :). SSH is a great tool and we should encourage its use. There are some caveats involving automatic X forwarding (etc) that should be raised. There are already papers on this around so perhaps point to existing documents for details? Robert N Watson Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.980728083352.12263A-100000>