From owner-freebsd-security Sat Sep 23 8:24:26 2000 Delivered-To: freebsd-security@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 3393B37B422 for ; Sat, 23 Sep 2000 08:24:21 -0700 (PDT) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id IAA12527; Sat, 23 Sep 2000 08:23:31 -0700 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda12525; Sat Sep 23 08:23:18 2000 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.9.3/8.9.1) id IAA52938; Sat, 23 Sep 2000 08:23:18 -0700 (PDT) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdg52936; Sat Sep 23 08:22:50 2000 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.0/8.9.1) id e8NFMn964757; Sat, 23 Sep 2000 08:22:49 -0700 (PDT) Message-Id: <200009231522.e8NFMn964757@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdp64751; Sat Sep 23 15:22:20 2000 X-Mailer: exmh version 2.1.1 10/15/1999 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 4.1-RELEASE X-Sender: cy To: Drew Derbyshire Cc: freebsd-security@FreeBSD.ORG Subject: Re: rsh/rlogin (was Re: sysinstall DOESN'T ASK, dangerous defaults!) In-reply-to: Your message of "Sat, 23 Sep 2000 08:13:10 EDT." <39CC9E56.EC4FDD44@kew.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 23 Sep 2000 08:22:17 -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <39CC9E56.EC4FDD44@kew.com>, Drew Derbyshire writes: > > Warner> That assumes that your firewall is good and that it can't > > Warner> be breached. > > Working Assumption: Some day, some how, the firewall *will* get breached. Agreed. That's why you use an onion ring approach to firewalls. You have firewalls protecting rings which contain machines with increasingly more sensitive data. > > > Correct. But that's true for a lot more than just rsh. > > Good practice dictates security in depth. If for example, ssh is as easy > for the end-user to use as rsh (if for example installed as a straight > replacement), it reduces your number of holes. I fought for the banishment of insecure protocols ("r" commands, telnet, and ftp) along with Will Andrews in -arch. However it was pointed out that most FreeBSD users use FreeBSD along side of vendor equipment that does not support SSH out of the box. I think that a broader, meaning larger than FreeBSD, solution, at least in my case, is what is required. An application that will disable certain services on a generic UNIX system and install SSH if not already there. Having said that and taking my security officer hat off and putting my manager hat on. Most organisations that use SSH are using it illegally. With recent licensing changes and the fact that OpenSSH doesn't install all that cleanly on non-BSD platforms, e.g. no /dev/random, compile errors, and my customers report that OpenSSH sometimes hangs on Solaris 2.6 systems (probably related to the entropy gathering daemon that substitutes /dev/random on non-BSD systems), the quick and dirty solutions are: 1. Run the "r" commands behind a firewall on a network of closely related systems, or 2. Use Kerberos -- less secure than SSH IMO but better than "r" commands but still not firewall friendly when accessing a secured network from a management workstation on the outside of the firewll. Thinking about this whole issue further is to give the FreeBSD installer the options at installation or mergemaster time of: 1. An open (insecure) or closed (secure) inetd.conf. 2. NFS or no NFS. 3. Sendmail or no sendmail. 4. An open or closed firewall. 5. IPFW or IPF. 6. Turning off or turning on of setuid bits of most setuid apps. Instead of 64 questions we can have five questions or one question, which will choose the more secure or less secure of the above options. Alternatively all of this could be put into a port, when installed would make the necessary changes to secure a system. If the FreeBSD specific parts of the port are separate from the generic UNIX parts of the port, the generic pieces could be run on non-FreeBSD systems to affect the same changes there as well. The short of it is that the issues discussed here don't just affect FreeBSD. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/DEC Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message