Security Incidents mailing list archives

Re: RedHat compromise


From: Daniel Martin <dtmartin24 () HOME COM>
Date: Wed, 21 Feb 2001 15:19:44 -0500

Jim Roland <jroland () ROLAND NET> writes:

Thanks to everyone for their input.  One last question, what's the best way
to find out his IP address without running his trojans and waiting for him
to connect?  Based on the "allow" IP list, I know he's coming from 24.*

Get a dd of the disk that had the log files on it and run strings on
the diskimage (and put it to some file).  Then, grep the resulting
file for lines from various logfiles.  (For example, you might grep
for "named" or "ftpd" - your attacker most likely did not succeed on
his first try and some of the earlier attempts may have left evidence
in the logfiles which they later had to wipe out)

This at least works on the base images the honeynet project had out
for their forensic challenge.  It depends on the logfile wiping
program to not do the modification in-place, but it's worth a shot.

Oh, and if his trojans are running on a specific port (I forget what
portnumbers you mentioned in your initial post) you can simply
log all connection attempts to that port number with a:

# Assuming that your IP address is 12.34.56.78 and that
# his trojan ran on port 5309
# And yes, assuming kernel 2.2.*, but I think that's a safe assumption
# right now.

/sbin/ipchains -A input -j DENY -i eth0 -p tcp -s 0.0.0.0/0 \
               -d 12.34.56.78/32 5309 -l

The key to getting it logged is the "-l" part.  It'll then get logged
wherever it is that your syslog puts kernel messages.  (DENY means to
blackhole those packets; REJECT would mean to send back the standard
"port closed" response (RST); ACCEPT would mean that the packets
travel to userland and generate a SYN+ACK or RST packet based on
whether or not any processes are listening for a connection.)  You
could, I suppose, also run tcpdump to capture and log incoming
connection requests, but you're unlikely to get any more information
out of a TCP SYN packet via tcpdump than you already get from the
kernel's ipchains log.


Current thread: