OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: IDS: intruder clues
From: Philippe Bourgeois (Philippe.Bourgeoiscnes.fr)
Date: Tue Apr 25 2000 - 05:06:35 CDT

Archive: http://msgs.securepoint.com/ids
FAQ: http://www.ticm.com/kb/faq/idsfaq.html
IDS: http://www-rnks.informatik.tu-cottbus.de/~sobirey/ids.html
HELP: Having problems... email questions to ids-owneruow.edu.au
NOTE: Remove this section from reply msgs otherwise the msg will bounce.
SPAM: DO NOT send unsolicted mail to this list.
UNSUBSCRIBE: email "unsubscribe ids" to majordomouow.edu.au
-----------------------------------------------------------------------------
Some more details about investigating a compromised Unix platform.
I fully agree with "flynngnjmu.edu" overall process, but I
want to give you further details.

1.first of all, make a raw image of the disks before you
  erase "volatile" traces (such as file time stamps) using a
  "dd" command.
  A "tar" copy of some important files (logs and configuration
  files) could be usefull (easier to read back than a "dd"
  image).
2.double-check "/etc/passwd" to find unknown accounts (created
  by the intuder). If you are lucky you will find a login
  added by the hacker. Search that login in "sulog" and "wtmp"
  to establish a time frame for the hacker activity.
3.could be interesting to run a port scanner (such as
  Nmap) to search for unknown open ports (e.g. back-doors
  or sniffer). Compare scan result with "netstat" to know if
  a rootkit has been installed (hiding some network services).
4.install a sane copy of the binaries and the librairies you
  will use to investigate the compromised system.
  NB: That doesn't protect you against corrupted kernels
      (such as a result of a malicious loadable kernel module)
5.search for regular files in "/dev" (could be rootkit configs
  files), strange directory names (e.g. "..." or ".. ")
6.Review the log files. The overall process here is to discard
  all the lines that are looking as regular to finally spots the
  strange entries.
7.If you can establish a time frame
  ( [intrusion-time, incident-detection] ), reviewing
  access/modification time is very usefull to track hacker
  activity.
8.If you dont have Tripwire running on that system, you
  can use "md5" to check system binaries. For that you
  need a sane copy of your system on an other platform
  (could be a restore of a backup of the intruded system).
  Build the MD5 signatures for binaries on that other
  platform and compare the result with the MD5 signatures
  of the intruded system.

Philippe Bourgeois

==================================================================================

flynngnjmu.edu wrote:
>
> [...]
>
> In rough order of effectiveness:
>
> 1. File fingerprints from previously stored tripwire or RPM comparisons.
> 2. Careful examination of critical configuration files
> (inetd.conf, inittab, rc, crontab, profiles, auditing, tcpwrappers, other
> access controls, etc.)
> 3. Network access logs.
> 4. External system logs.
>
> Everything below this point is iffy on a compromised system. Anything,
> including
> the tools you use to inspect the system may be compromised. Its best to mount
> the disk read-only on a known good "inspection system".
>
> 5. Onboard logs
> 6. File modification times.
> 7. Unexpected files and directories.