Despite the previous efforts I've still got some issues with the BBS
user, thats used to ssh to TLP. Somehow they're able to exploit the account to insert a crontab. I've subsequently taken write perms off
#0 0 */3 * * /dev/shm/.lwp/.rsync/a/upd>/dev/null 2>&1
#5 8 * * 0 /dev/shm/.lwp/.rsync/b/sync>/dev/null 2>&1
#@reboot /dev/shm/.lwp/.rsync/b/sync>/dev/null 2>&1
#0 0 */3 * * /dev/shm/.lwp/.rsync/c/aptitude>/dev/null 2>&1
Despite the previous efforts I've still got some issues with the BBS
user, thats used to ssh to TLP. Somehow they're able to exploit the account to insert a crontab. I've subsequently taken write perms off
the users home directory, and innoculated the user crontab and then
locked it by removing write permissions....
Have to say I don't quite know what the result is, but the injection is,
# (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $) #0 0 */3 * * /dev/shm/.lwp/.rsync/a/upd>/dev/null 2>&1
#5 8 * * 0 /dev/shm/.lwp/.rsync/b/sync>/dev/null 2>&1
#@reboot /dev/shm/.lwp/.rsync/b/sync>/dev/null 2>&1
#0 0 */3 * * /dev/shm/.lwp/.rsync/c/aptitude>/dev/null 2>&1
Its rsyncing to something? and it also tries to install something? I haven't looked at these in a terminal removing the /dev/null at this point, I s'pose I should look at the files its calling. The result is a rogue ./cron task, and a load average that shoots through the roof, on
the octo core its out past 18 so it uses everything it can.
Try adding the BBS user to a line in /etc/cron.deny, that should take care of any attempts of adding to the user's crontab (unless they got root
on the machine of course). Also don't forget to clear the BBS user's crontab completely so that it is clean after locking it down.
I'm not sure if this prevents any /etc/cron.d/ cron jobs (for that user) from running, though... I think anything that you (as root) add to
the user's crontab, and any /etc/cron.d/ jobs for that user, will
work as usual, it is just the "crontab -e" (editing/adding
etc.) for that user which will be "locked".
software. The dot directories to hide everything and the names probably just an attempt to masquerade all of it in case you would notice
the files.
You might want to check the .ssh directory of the BBS user (e.g. ~bbs/.ssh/) to see if they have added SSH keys to it -- that way they could SSH to the machine and perhaps execute commands that way, e.g.
What's likely going on is that the user has managed to get access
to a shell on your system. Do you have something installed
that lets them run an editor or pager or something along those
lines? Those are common vectors for getting to a shell.
It is likely that once they get access to the shell, they leverage
that to install a crontab file, possibly via the `crontab` command. Setting permissions on the tab file and changing the permissions
of the home directory are unlikely to help much here.
programs, which are in odd directories (/dev/shm/.lwp/.rsync and the subdirectories underneath that). I'd imagine these are probably
shell scripts; I'd take a look at them to see what they do.
At this point, it seems likely that you've had a root compromise.
Sysop: | echicken |
---|---|
Location: | Toronto, Ontario |
Users: | 2,224 |
Nodes: | 6 (0 / 6) |
Uptime: | 212:53:58 |
Calls: | 14,143 |
Calls today: | 1 |
Files: | 295 |
Messages: | 551,114 |