From owner-freebsd-isp Tue Jul 17 5:27:29 2001 Delivered-To: freebsd-isp@freebsd.org Received: from bilver.wjv.com (dhcp-1-72.n01.orldfl01.us.ra.verio.net [157.238.210.72]) by hub.freebsd.org (Postfix) with ESMTP id 59E4C37B401 for ; Tue, 17 Jul 2001 05:27:18 -0700 (PDT) (envelope-from bill@bilver.wjv.com) Received: (from bill@localhost) by bilver.wjv.com (8.11.1/8.11.1) id f6HCC2982439; Tue, 17 Jul 2001 08:12:02 -0400 (EDT) (envelope-from bill) Date: Tue, 17 Jul 2001 08:10:26 -0400 From: Bill Vermillion To: Paul Robinson Cc: Bart Silverstrim , freebsd-isp@FreeBSD.ORG Subject: Re: gcc on production server Message-ID: <20010717081025.A82350@wjv.com> Reply-To: bv@wjv.com References: <20010711170336.B84178@krijt.livens.net> <20010711123133.A21587@pitr.tuxinternet.com> <20010712123523.G53408@jake.akitanet.co.uk> <007c01c10b14$5462d820$0100a8c0@sosbbs.com> <20010713122500.A23202@jake.akitanet.co.uk> <010c01c10bdb$a8f11600$0100a8c0@sosbbs.com> <20010716103740.C37477@jake.akitanet.co.uk> <00a701c10e42$2075b560$0100a8c0@sosbbs.com> <20010717121913.J27087@jake.akitanet.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010717121913.J27087@jake.akitanet.co.uk>; from paul@akita.co.uk on Tue, Jul 17, 2001 at 12:19:13PM +0100 Organization: W.J.Vermillion / Orlando - Winter Park Sender: owner-freebsd-isp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Jul 17, 2001 at 12:19:13PM +0100, Paul Robinson thus sprach: > On Jul 16, Bart Silverstrim wrote: [just one or two minor comments here] > > People who work for companies that are big enough to have admins > > that can, as part of daily routine, monitor security lists for > > every bit of software that they're running and can take the time > > to do patches as needed are indeed fortunate. Some of us have to > > make due with limited resources and I've heard people mutter about trying to keep up with all the security lists, and then I point them to SANS. www.sans.org. Subscribe to their lists and you'll have 95+% of your security monitoring done for you. Sort of a one-stop place. I've had peopel thank me for pointing them out. > Build it Once and Walk Away. You should put the time and effort in > at the design stage to try and get things to work well. If we could get more people to believe in 'design' or even just a bit of planning!. > The point about all these measures is that you are supposed to > be able to detect a compromise. Not prevent it. Being able to > detect but not prevent is FAR more useful than thinking you can > prevent (which you can never do) but are never able to detect. > You're assuming an implicit trust in a piece of software on the > IDE controller that says "no, I think I'm read only". I'd surely not trust software for that. I try not to work in IDE mode and a great many SCSI devices have pins to make the device read only in HW. > > If the system WAS compromised, the "safe admin" wouldn't > > consider anything "probably uncompromised" in terms of binaries > > being replaced. They got in to the system somehow, and you never > > know if the bugger that got in is doing something you didn't > > expect or think of to compromise you again or leave back doors. > The point about using MD5, signed executables, etc. is to detect > compromise. The idea of being able to *very* quickly patch your > daemons is about prevention. > > How common is using the MD5-executable only method of setting up > > a machine? Is there a HOWTO on it? How many FreeBSD people on > > the list are using this technique? I missed part of this thread, and I'm not sure exactly what this paragraph refers to explicitly, but one way to do this is to get TCT. TCT - The Coroners Toolkit - written by Weistse Venema and Dan Farmer. Turn it loose and after it's done you'll have a complete set of MD5's for everthing on your system. Put that away somewhere OFF the machine and you'll have a way to check what has been compromised. A decent over-view but I'd really have like to seen the slides that went with the text. From the README. ---- ------------------ NOTE: If you've just been broken into and are desperate for help, read the "help-when-broken-into" file. The Coroner's Toolkit (TCT) - a Brief Introduction TCT is a collection of tools - some large, some small, some in perl, some in C - that are all either oriented towards gathering or analyzing forensic data on a Unix system. There is no single task or ultimate goal that they are directed to, but if there was a theme it'd be an effort towards the reconstruction of the past - determining as much as possible what happened with a static snapshot of a system. Most of the tools are oriented towards data collection rather than analysis - a good use of the toolkit could be for a relative neophyte in Unix forensic security to send the data to someone who does know something and can further analyze the output. (Do NOT send it to us, however! ;-)) Note that by default we don't gather *ALL* data - unallocated blocks of disks (let alone the entire contents of your media!) and raw memory are not touched by default... where would you put the results, for starters? So, as a general overview: A quick start for the impatient may be found in the "quickstart" file. The most current version of TCT may be found at both: http://www.fish.com/forensics/ http://www.porcupine.org/forensics/ To install TCT read the "INSTALL" file. A list of the contents of TCT may be found in the "MANIFEST" file. A copyright notice is in the "COPYRIGHT" file; additional copyrights might be included in individual source code files (especially look at the C source code files, which are mostly covered by IBM's open source license, in the file "LICENSE".) A general overview of the toolkit may be found in the "README" file in the "docs" subdirectory. More about TCT's design methodology and philosophy can be found in the "design-notes" file in the same directory. We hope that you enjoy this and find our work useful to you! Dan Farmer & Wietse Venema August 1st, 2000 p.s. There's a mailing list (with on-line archive) for sharing experiences. To subscribe, send a message to majordomo@porcupine.org with body (not subject): subscribe tct-users. The list will reject mail from non-members so it is unlikely to catch UCE. To unsubscribe, send mail with as body (not subject): unsubscribe tct-users. p.p.s. Some unpolished, unfinished, and perhaps not very useful tools and notes are in the "extras" subdirectory; feel free to check them out, but caveat emptor. -------------------- It's worth a look at as a minimum. I found it's quite interesting and was surprise at how much erased data could actually be recovered. Once you see that you really want to have a system that zeroes all blocks when you rm a file. Bill -- Bill Vermillion - bv @ wjv . com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isp" in the body of the message