Home / server / Questions / 27351
Accepted
Mark Roddy
Asked: 2009-06-18 07:19:17 +0800 CST

Diagnosing Possible Intrusion

  • 772

I noticed a number of directories on my home server that I haven't touched in have had their modification time changed, though none of the files contained in these directories report a change in time.

I run an IDS (fcheck), and it did not report anything on the date of the directories' modification time. This is not surprising since the directories in question are in my home directory (which my IDS does not scan). I have grepped through auth.log and did not find any unauthorized access on the date in question and checked most configurations in /etc appear to be the same. How should I proceed next to determine if in fact my machine has been compromised?

linux ubuntu security

4 Answers

  1. Best Answer

    Checking your logs is the first thing to do. That should let you know if someone has entered your system via any open door (e.g., sshd, do you see login times that don't correspond to times at which you logged in?)

    Checking /etc is a fine idea, but that will only tell you if someone tried to modify your configuration, not whether or not someone actually penetrated your system just for the fun of it.

    Also, have you applied all current security patches for your platform? If not, do that immediately.

    If you determine that your system was penetrated, you'll have to figure out what vector they used. You say it's a home server: does that mean someone has cracked your wifi password, and attacked from the LAN—which is often a trusted network—or that someone got past your router from the WAN side?

    PS I forgot to include the possibility that a script (that you ran on purpose) may have touched files in ~/ for some totally legitimate reason. That's something to look at as well, before getting too worried about having been hacked.

    • 1

  2. I attended a pretty fantastic talk last night about basic computer forensics. Here's a link to his slides. http://greenfly.org/talks/security/forensics.html He ended with a demonstration of Superslueth which would require you pulling the plug on your system, booting a rescue CD that does not automatically mount the hard drive, then mounting read only, making an image of the harddrive or partition you're interested in, and then loading that into SUperslueth on a separate machine. It's a fair amount of work, but using the machine while running and mounted read/write is going to destroy a lot of data.

    In regards to pulling the plug he suggests that because halting a machines can cause a lot of housecleaning on the way down that will make seeing actually changes in file or MAC times harder.

    • 1

  3. The modification time is not a reliable source of information, since it can change quite frequently (specially on a home directory). This is what the manual says:

     st_mtim     Time when file data was last modified.  Changed by the
             truncate(2), utimes(2), and write(2) system calls.  For di-
             rectories, changed by any system call that alters which files
             are in the directory, such as the unlink(2), rename(2),
             mkdir(2), and symlink(2) system calls.

 st_ctime    Time when file status was last changed (inode data modifica-
             tion).  Changed by the chmod(2), chown(2), link(2),
             rename(2), unlink(2), utimes(2), and write(2) system calls.

    So, if you ran a backup, did a chmod * by mistake or something like that, the change/modification time may have changed.

    Now, on the topic of intrusions, after the fact checks will only work if you had the security measures BEFORE in place. If you are not securely storing your logs on a central repository, looking for them on the target machine is useless (any attacker will delete/modify them). My suggestion:

    • Look for open ports (netstat)
    • Look for processes running (lsof, ps aux)
    • Enable a firewall, install an IDS (OSSEC is a good one) and keep a look at the box
    • Maybe run a rootkit detector (rootcheck is good: http://www.ossec.net/en/rootcheck.html )
    • 1

  4. Do not trust any tool running on the suspect host. If you log in and start poking files you can either taint the evidence and let the intruder guess that you spot him/her out. Try monitoring closely the network traffic of the host by running a traffic capture externally. Look for any suspect or unusual connection. If you don't spot out anything, take a full snapshot of the harddrives during a short downtime. Don't go through the normal shutdown process, hard reset it. While analyzing the disk image you can keep the system running and keep monitoring its network flows.

    • 0