3 ms·

Simply logging into your server once a day and typing "top" is a good start. You can usually spot suspicious processes associated with these spamkits. Also, che

Simply logging into your server once a day and typing "top" is a good start. You can usually spot suspicious processes associated with these spamkits. Also, check /var/log/messages, and check root's email. Also if you run anything like phpbb or wordpress, make sure you keep it updated. I also like to disable Apache's suexec (as I once had a rootkit that exploited it, and I don't require it for my systems), limit inbound connections with iptables, and limit ssh access to certain ip addresses. Also, get rid of or disable access to any services you don't really need (like ftp, bind, etc). It's also very important to check all your php/perl scripts for file/sql injection vulnerabilities, as that is one of the most common methods of infiltration.

dTal 12y ago
I'd like to add that it's a good idea to routinely check /var/log/auth.log for successful SSH logins. If you find that onerous because of the volume of breakin attempts, that's a good sign you need something like fail2ban. Fail2ban isn't foolproof, incidentally. I once nearly caught a worm despite a limit of 6 login attempts per IP, because I had created an account with username and password both "test" that I had since forgotten about, well before I exposed that particular machine to the internet. Oops! An automated script managed to guess that in well under 6 attempts! Fortunately I was physically present at the time and noticed the abnormal load within a few minutes, and killed the offending process (doubtless a local password cracker for privilege escalation) before it could do any damage. Lesson learned there, and it also taught me the value of knowing your machine well enough to sniff when it's not behaving right. On a Windows machine I would have written off the abnormal load, as abnormal load is normal on Windows.
- LukeShu 12y ago
  I'd like to add that in my experience simply moving SSH to a port other than 22 reduces the volume of breaking attempts low enough that it's viable to see things in the log.
raziel2p 12y ago
Adding to this, I've found `lsof -i` more useful for spotting suspicious activity - it shows processes listening on ports as well as established connections. Enabling and checking cronjob logs is also something I wasn't doing before.

dTal 12y ago

I'd like to add that it's a good idea to routinely check /var/log/auth.log for successful SSH logins. If you find that onerous because of the volume of breakin attempts, that's a good sign you need something like fail2ban. Fail2ban isn't foolproof, incidentally. I once nearly caught a worm despite a limit of 6 login attempts per IP, because I had created an account with username and password both "test" that I had since forgotten about, well before I exposed that particular machine to the internet. Oops! An automated script managed to guess that in well under 6 attempts! Fortunately I was physically present at the time and noticed the abnormal load within a few minutes, and killed the offending process (doubtless a local password cracker for privilege escalation) before it could do any damage. Lesson learned there, and it also taught me the value of knowing your machine well enough to sniff when it's not behaving right. On a Windows machine I would have written off the abnormal load, as abnormal load is normal on Windows.

LukeShu 12y ago
I'd like to add that in my experience simply moving SSH to a port other than 22 reduces the volume of breaking attempts low enough that it's viable to see things in the log.

raziel2p 12y ago

Adding to this, I've found `lsof -i` more useful for spotting suspicious activity - it shows processes listening on ports as well as established connections. Enabling and checking cronjob logs is also something I wasn't doing before.