From owner-freebsd-questions Tue Jun 15 0:31:38 1999 Delivered-To: freebsd-questions@freebsd.org Received: from phoenix (phoenix.aye.net [198.7.192.5]) by hub.freebsd.org (Postfix) with SMTP id 23E9615598 for ; Tue, 15 Jun 1999 00:31:27 -0700 (PDT) (envelope-from barrett@phoenix.aye.net) Received: (qmail 7067 invoked by uid 1000); 15 Jun 1999 07:31:00 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 15 Jun 1999 07:31:00 -0000 Date: Tue, 15 Jun 1999 03:31:00 -0400 (EDT) From: Barrett Richardson To: Scott Benjamin Cc: freebsd-questions@freebsd.org Subject: Re: Security Docs? Help? In-Reply-To: <1D7D0A00F0E8D111A26600104B873E4C01783DAB@exchange.quests.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 14 Jun 1999, Scott Benjamin wrote: > Could someone point me in the right direction for securing a FreeBSD box? > I'm looking for some documentation and such in helping me make sure I hit > all of the angles so that someone else doesn't =). > Practical fundamentals can be found at http://www.freebsd.org/~jkb/howto.html I've done some other things that give me an extra level of comfort. I've hacked the kernel sources to require a flag settable only by root for a binary executable to run. Not as perfect as it seems at first glance but it keeps the Linux kidz from hammering away with whatever goods they find on places like rootshell.com (not criticizing rootshell). I've ported the stackguard compiler and I've compiled apache, qmail and ssh with it. Protects against buffer overruns that target the return address on the stack (doesn't give that protection in library functions -- just functions in the source dist of what you are compiling). Doesn't protect against buffer overruns that target things like functions pointers and variables. I've eliminated system setuid binaries except ones that are absolutely necessary and I've compiled those with stackguard (like su, passwd, df). I've done the same with network daemons that I use (timed for example). I am currently working on a chroot'd environment for interactive logins. I've hacked login, ftpd and sshd to look for a "/./" embedded in a users home dir in the passwd file and do a chroot to that dir (before the "/./"). For telnet and ssh users directories etc, bin, sbin, usr/bin, usr/lib, usr/sbin need to be setup with various things like shared libs, termcap, passwd files -- what ever I want the user to be able to use (no setuid binaries at the moment but I may have to buckle on a couple). The idea is to have all the customers login to the chroot'd environment (we are an ISP) and disable passwords for our staff effectively disableing ftp and telnet, which would force them to use ssh (I've been unable to wean the staff off of telnet and ftp completely so I'll probably end up using Skey -- I'll still see them telnet in and do the old "su - root"). When I get it all in place knowing my root password should be useless information to a cracker (provided I'm not doing something stupid with ssh, apache or something) makeing it unappealing to gain entry. There is a more substantial effort along the chroot line in -current. I'll have the patches and some details available on an ftp server within a couple of weeks (migrating all my patches from 2.2.8 to 3.2). Send me an email if your interested and I'll send you the site. -- Barrett Richardson barrett@phoenix.aye.net > thanks in advance, > > Scott > > ---- > "Any sufficiently advanced bug is indistinguishable from a feature" > -- Rich Kulawiec > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message