I'm using Ubuntu 10.04. An unknown person has logged in several times through SSH using postgres user account.

I'm having a hard time finding logs with any related acitivty, probably because such logs are being cleaned??

I need help logging the person's activity, so I can understand what this person did or is doing?

Help would be awesome, thanks.


Are there any traps I could set for the next login this person makes? I don't mind leaving the server as is, just to find out what this person's activities are.

Any ideas? =)

  • 2
    at this point you should be assuming the box is rooted, and any investigation beyond this point is strictly evidence gathering / research, yes ? – Sirex Aug 31 '10 at 14:34
  • And the next question from RadiantHex will be "how do i lock down my server to prevent attack?" – Chris Aug 31 '10 at 14:52
  • @Chris: Bingo! Oh well, it's always good to get some expert's advice. – RadiantHex Aug 31 '10 at 15:00
  • Can you post the log fragment or whatever you are seeing that is making you suspect there is a this breach? Sometimes cronjobs can do things that may look unusual if you don't know about them. – Zoredache Aug 31 '10 at 20:02

Step one: take the server offline, shut it down, and make a clone of the hard drive. When doing your forensic work, use only this clone drive, leaving the original untouched.

You should be able to throw the clone drive into another system, mount it, and start poking around to see what the user did. The first thing I'd check is the user's ~/.bash_history, if there is one. Most smart hackers will delete this file when they're done with their work, but there's a chance it may still be around. If that doesn't work, then all you really have to go by are log messages in /var/log. You may try running rkhunter over the system, but IMO, it's not worth it, as you already know that this system is compromised. Depending on how savvy this user was, you may never know what they actually did.

If I were you, I'd do a full re-install of the system and restore from a known-good backup. That's the only way you'll be able to be certain the system isn't compromised. Additionally, when you bring the new system up, do yourself a favor, and turn off PasswordAuthentication in your /etc/ssh/sshd_config file and use key auth instead. By doing this, you'll be much safer from this sort of malicious activity.

  • thanks for your awesome reply, postgres currently has no folder. Any idea where the .bash_history file would be? – RadiantHex Aug 31 '10 at 14:46
  • 1
    Oh, and also - go back to your previous questions and mark answers as "accepted". That would a polite, courteous, and respectful way to thank the community for the information and advice they've given you. – EEAA Aug 31 '10 at 14:48
  • 2
    Sorry, but I'm not going to put a whole lot more effort into this answer. See my above comment. – EEAA Aug 31 '10 at 14:49
  • I did so, after Chris S wrote his comment. I don't use ServerFault often, I am not sure how come I forgot to tick the answers. – RadiantHex Aug 31 '10 at 14:52

Part One (what to do): As per what ErikA wrote. You are sure that the system is compromised, so the right thing to do is to take it off-line.

Part Two (setting traps): There isn't much you can sensibly do on the host, as doing anything on the host may alert the person(s) that compromised the server. Since you're using SSH, it's also not trivial to packet-sniff upstream to recover the session from there. I'd, personally, ignore that and go with what ErikA wrote (take the server down; clone the disk; if a forensic investigation is needed, use the cloned data; install a new server; secure the new server; recover data from known-good backup).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.