On Thu, 2006-11-30 at 22:12 -0800, John R Pierce wrote: > Alfred von Campe wrote: > > My home system has been hacked. It's running CentOS 4.4, and I > > recently added an account to play around with Samba shares to back up > > PCs here at home. I had set a weak password for that account and > > forgot to disable it after my testing. I could hear the disk being > > accessed constantly, so I knew something was up. I disabled the port > > forwarding to my CentOS box on my Linksys router (only ports 22 and 80 > > were being forwarded). > > if for sure only 22 and 80 were forwarded, then it wasn't Samba. > Right ... however, if a weak account/passwd was created in useradd (for backups) and if something was not done to prevent ssh logins for that user, then someone may have logged into ssh via that account and port 22. In this case (if the user you created for samba shares was "backup") then this is what happened. There are many ways to combat this specific issue (use key only logins to ssh, etc.). But the simplest way I have found (if you want password access) is to use the AllowGroups option in /etc/ssh/sshd_config. AllowGroups sshusers That will make it so only people in the group sshusers can ssh in. If you do that, create the group sshusers, and add only those accounts that you want to have ssh access to the sshusers group you will make it so any new test accounts you create do not allow ssh login by default (only if you also add them to the sshusers group). I would also highly recommend that you do not use port 22 for ssh from the outside ... pick a non standard port (like 3333 or 22222, etc.) and add this option as well to sshd_config port 22 port 3333 You can then port forward port 3333 from linksys to 3333 on your centos machine ... you can ssh in via that port from outside and still use port 22 from inside your firewall (via other machines inside your firewall). (you will also need to open up port 3333 tcp on iptables if you have iptables on). > There's no default account I see here on my 4.4 boxes named backup, was > that something you'd created? some package you'd installed? > > what was on your website? any canned php scripting or whatever? > That is also a possibility. Many php CMSs are horrible and allow access to many issue by default. SELinux can be your friend if properly configured ... as well, a program called mod_security can be affective. If backup was the sambe user, then this was probably not the entry point in this case. > > re: cleanup... look very carefully for directories in odd places with > . names > > I'd run rkhunter to see if tehre's any other well known root kits on > your system. rkhunter and / or chkrootkit ... both good things. Another thing to worry about is that once a user is logged in on that machine and in, they may try to use a local use exploit to gain root privileges. So, you need to proceed assuming that they logged in as backup ... and exploited to get a root shell ... and had access to everything. That would mean that you need to either reinstall or do: rpm -V -qa and figure out everything that is different and verify that you do not have binary files for things like top, ps that have been modified to hide certain things. Reinstall, that is my advise. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.centos.org/pipermail/centos/attachments/20061201/6e18599d/attachment-0005.sig>