Re: IDS: intruder clues

[flynngn@jmu.edu]

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-owner@uow.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 majordomo@uow.edu.au
-----------------------------------------------------------------------------
Meritt, Jim wrote:
> 
> If a corporation/organization/whatever has NOT implemented an IDS, what do
> you (the reader specifically) look for/at during after-the-event intrusion
> detection?
> 
> I'm looking for individual responses other than real-time clues (the system
> isn't even connected to the network any more) and the multitude of log files
> (a system may, or may not, have varied logging enabled)

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.