Marko Vojinovic <vvmarko(a)gmail.com> writes:
Shouldn't this be the other way around? I mean, ordinary user
gets compromized
first, and then root gets compromized later?
Oh, I'm sure there was an initial user-level attack that I haven't found
yet and probably won't. Apache will all that dynamic stuff run from the
web server scares me. I don't think the guys running the system
appreciated how much of a security vulnarability that is.
If the intruder has root access, he has absolutely no need to
brute-force the user passwords through ssh. It is enough to change the
password interactively or by modifying /etc/shadow. That is, unless
the intruder is just plain stupid. ;-)
It was most likely a double infection with the second intruder just
taking advantage of the now lower security.
The only safe way to track and analyze intrusion details of a live
system is to have the machine log all activities to another machine on
the net. That way the logs are physically append-only, and even after
the intrusion happens, the intruder has no way of deleting the logs
and otherwise covering up how the machine got compromized.
Agreed.
I was just wondering if there is a package that already does that or
something close.
Other than that, once the intruder becomes root, all bets are off,
there is no safe way to know anything about the intrusion and what
exactly happened. The only thing you can do is wipe the hard disk and
reinstall the system from scratch. Forensic research of a rooted
system is (a) very painful and tough job (even for experts) and (b)
almost impossible, in most cases.
I'll certainy take a snapshot of the disk and pick at it as inspiration
strikes. If it was a server attack (apache? dovecot?), there might be
probes in log file. They might have been lazy and not deleted the log
entries.
-wolfgang
--
Wolfgang S. Rupprecht
http://www.wsrcc.com/wolfgang/ (IPv6-only)