Intrusion Detection Systems mailing list archives

Re: intruder clues


From: Philippe.Bourgeois () cnes fr (Philippe Bourgeois)
Date: Tue, 25 Apr 2000 12:06:35 +0200


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
UNSUBSCRIBE: email "unsubscribe ids" to majordomo () uow edu au
Some more details about investigating a compromised Unix platform.
I fully agree with "flynngn () jmu 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

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

flynngn () jmu 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.


Current thread: