Date: Tue, 17 Jul 2001 08:10:26 -0400 From: Bill Vermillion <bill@wjv.com> To: Paul Robinson <paul@akita.co.uk> Cc: Bart Silverstrim <bsilver@sosbbs.com>, freebsd-isp@FreeBSD.ORG Subject: Re: gcc on production server Message-ID: <20010717081025.A82350@wjv.com> In-Reply-To: <20010717121913.J27087@jake.akitanet.co.uk>; from paul@akita.co.uk on Tue, Jul 17, 2001 at 12:19:13PM %2B0100 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jul 17, 2001 at 12:19:13PM +0100, Paul Robinson thus sprach:
> On Jul 16, Bart Silverstrim <bsilver@sosbbs.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010717081025.A82350>