[762] in Intrusion Detection Systems
Re: Audit trails
daemon@ATHENA.MIT.EDU (Alexander O. Yuriev)
Sat Nov 23 15:06:02 1996
To: ids@uow.edu.au
In-Reply-To: Your message of "Mon, 18 Nov 1996 03:33:37 CST."
<Pine.LNX.3.93.961118030315.8457B-100000@underground.error.net>
Date: Wed, 20 Nov 1996 12:00:24 -0500
From: "Alexander O. Yuriev" <alex@bach.cis.temple.edu>
Reply-To: ids@uow.edu.au
> Let me begin by saying that UNIX "audit trails" suck.
UNIX does not have audit trails. It is just not there. Some people consider
that wtmp/utmp and process accounting records are audit trails but that is
defenetly not the case. The audit trail should answer at least the following
questions for every single operation:
* What was done to a system
* When was it done to a system
* Where did the request come from
* What was the status of the operation ( success or failure )
Even audit substems of DEC Unix or Solaris that log every call do not
provide all this information.
> My name is Michael Hampton, and my site was hacked two weeks ago. Though I
> watch my system logs fairly carefully, I never noticed the breakin, until the
> administrator of another local site informed me of the details of the breakin
> at his site. Only then did I notice that my /bin/login had been replaced, an
> d
> only then did I whip up a "raw" utmp viewer, and notice that someone had done
> a
> not-so-great job of editing my wtmp file.
One of the easiest ways to 'secure' system is to make sure that clean,
non-compromised binaries are stored on write-protected media. There is
absolutely no reason on earth to modify programs located in /usr when system
is up in a multiuser mode.
ObUtmp editors: Zappers that are used in kits to automatically remove
entries from ump/wtmp/lastlog files usually use something like lseek() and
bzero() functions to overwrite particular parts of utmp/wtmp with zeros,
which generates empty records. Under normal conditions this does not happen,
therefore presence of empty records can be used to detect usage of a zapper.
> One idea is this: use the syslog facility for what it was intended: logging
> !
> I notice that /bin/login and friends don't talk to syslog unless there is a
> problem. I believe that they should log everything that's going on, so that
> discrepancies (which mean possible intrusions) are easier to discover. Yes,
> I'm aware there are modified programs out there that do such logging, though
> they may be slightly incompatible with my system or someone else's system.
Pick up a modified login.c for SunOS from
ftp://bach.cis.temple.edu/pub/Security/SunOS. The modification is trivial
and can be added to any other login program.
Best wishes,
Alex
