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:
- [Fwd: [Fwd: Fwd: Emergency...Pls Forward This To Everyone You Know]] madhurs () mahindrabt com (Apr 12)
- Re: [Fwd: [Fwd: Fwd: Emergency...Pls Forward This To Everyone You Know]] walter sulym (Apr 12)
- Re: [Fwd: [Fwd: Fwd: Emergency...Pls Forward This To Everyone You Know]] Ki.Ki.Ki...Kiran (Apr 23)
- IDS Focus Area at SecurityFocus.com Jensenne Roculan (Apr 24)
- intruder clues Meritt, Jim (Apr 24)
- Re: intruder clues flynngn () jmu edu (Apr 24)
- Re: intruder clues Philippe Bourgeois (Apr 25)
- Re: intruder clues Lance Spitzner (Apr 25)
- Scanning on tcp port 27374 Benninghoff, John (Apr 26)
- Re: Scanning on tcp port 27374 Gary Flynn (Apr 27)
- Re: Scanning on tcp port 27374 DPG (Apr 27)
- Re: Part 2 Scanning on tcp port 27374 DPG (Apr 27)
- strings in backdoor binaries Meritt, Jim (Apr 27)
- Re: strings in backdoor binaries Anton Chuvakin (Apr 28)
- Re: strings in backdoor binaries Gary Flynn (Apr 28)
- Re: strings in backdoor binaries DPG (Apr 28)
- Re: strings in backdoor binaries Jonas Eriksson (Apr 29)
- Re: intruder clues flynngn () jmu edu (Apr 24)
