vvmarko at gmail.com
Wed Jan 26 01:59:53 UTC 2011
On Tuesday 25 January 2011 22:34:16 Wolfgang S. Rupprecht wrote:
> Once again I find myself trying to help someone piece together how an
> intruder managed to get into their system. The system was way out of
> date (FC6) so it is no surprise that they got compromised. What I can
> tell, the intruder managed to get root which allowed them to remove the
> iptables file and lower the protection on ssh to allow unix passwords.
> The attacker then installed an ssh-probing client that was installed in
> /root. That lowered ssh security allowed a second intrusion at user
> level (probably by password guessing) where an IRC bot was installed and
> run from cron with normal user permissions.
Shouldn't this be the other way around? I mean, ordinary user gets compromized
first, and then root gets compromized later?
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
> The real issue is that there isn't a good activity log. While I can
> install tripwire to watch for changed files, it probably won't tell me
> how they got in. Is there something that addresses that problem? Some
> poor sucker always has to be the first victim of a new attack. It would
> be nice to know which service to disable or reconfigure until a fix is
> distributed. Is there some way to track intruders that I'm missing?
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.
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.
If you are into intrusion detection research, you can set up a honeypot
machine, make an exact cloned copy of the hard disk, log all activity to
another server, monitor all network traffic with a transparent machine-in-the-
middle, and then sit and wait for the machine to get hacked. Then take it off
the net, do a diff of the entire hard disk against the initial copy, analyze
logs and network traffic, etc. Those are the "laboratory conditions" in which
you can do proper forensics.
Other than that, the only thing that can give you a trustworthy clue what
happened is the remote log server, if you have one set up. If you don't, well,
the only thing you can do is to keep guessing what happened... ;-)
More information about the users