Date: Sat, 23 Sep 2000 08:22:17 -0700 From: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca> To: Drew Derbyshire <ahd@kew.com> Cc: freebsd-security@FreeBSD.ORG Subject: Re: rsh/rlogin (was Re: sysinstall DOESN'T ASK, dangerous defaults!) Message-ID: <200009231522.e8NFMn964757@cwsys.cwsent.com> In-Reply-To: Your message of "Sat, 23 Sep 2000 08:13:10 EDT." <39CC9E56.EC4FDD44@kew.com>
index | next in thread | previous in thread | raw e-mail
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
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200009231522.e8NFMn964757>