Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
My server was hacked and we found it by noticing large amounts of bandwidth. A user had a common name and easy password. I disabled the user and installed denyhosts. The only item that I couldn't clean up was a cronjob found in the /var/spool/cron/crontabs directory listed as
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (cron.d installed on Wed Dec 8 09:12:22 2010)
# (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
* * * * * /dev/shm/ /.access.log/y2kupdate >/dev/null 2>&1
Could someone tell me where to find this file or what is going on?
Yes, everything is gone in that directory. It looks like the hacker cleaned everything up except the .bash_history of the user they hacked. The computer was rebooted. Is it like the /tmp directory and everything is deleted on shutdown?
Please run '( /bin/ps axfwwwe; lsof -Pwln; netstat -antupe; who )| /tmp/result.log', shut down all 'net-facing services except SSH, make the firewall block IRC traffic, check any 'net-facing users crontab in /var/spool/cron and perform tasks as per the CERT Intruder Detection Checklist: http://web.archive.org/web/200801092...checklist.html ('tis an oldy BTW) and post feedback.
Apart from vulnerabilities exploited in the OS due to lack of updates or severely misconfigured machines the most common infection vector would be in running outdated, vulnerable software in the web stack. While other languages are equally prone to this it's commonly PHP-based software. And while I don't know the exact contents of the kit that contains y2kupdate accounts here and elsewehere suggest it is used to deliver and run an IRC bouncer (usually PsyBNC). So if the application is active you should see any process ("httpd -DSSL"?) making connections to IRC servers.
Originally Posted by unSpawn
check any 'net-facing users crontab in /var/spool/cron
On second thought it would be better to run 'mv -f /etc/cron.deny /etc/cron.deny_; echo root > /etc/cron.allow' as this would only allow the root user to use cron. If you however suspect a root compromise then that's not going to help and you should bring the machine down fast to avoid it being used against other systems. Also note that "fixing" one hole like you did does not automagically mean you should trust the machine: you have to ensure integrity by checking it, not just assume it's "OK".