How do I determine if my Linux box has been infiltrated?

I recently read an article about analyzing malicious SSH login attempts. This got me thinking, are the SSH username, password combinations on my Debian box that uncommon? Had I been targeted by a brute force dictionary attack? Let's take a look at /var/log/auth.log.0:

Sep 23 07:42:04 SLUG sshd[8303]: Invalid user tyjuan from 210.168.200.190
Sep 23 07:42:09 SLUG sshd[8305]: Invalid user tykeedra from 210.168.200.190
Sep 23 07:42:14 SLUG sshd[8307]: Invalid user tykeem from 210.168.200.190
Sep 23 07:42:19 SLUG sshd[8309]: Invalid user tykeshia from 210.168.200.190
Sep 23 07:42:25 SLUG sshd[8311]: Invalid user tyla from 210.168.200.190
Sep 23 07:42:30 SLUG sshd[8313]: Invalid user tylan from 210.168.200.190
Sep 23 07:42:35 SLUG sshd[8315]: Invalid user tylar from 210.168.200.190
Sep 23 07:42:40 SLUG sshd[8317]: Invalid user tyler from 210.168.200.190
Sep 23 07:42:45 SLUG sshd[8319]: Invalid user tylerfrank from 210.168.200.190
Sep 23 07:42:50 SLUG sshd[8321]: Invalid user tyliah from 210.168.200.190
Sep 23 07:42:55 SLUG sshd[8323]: Invalid user tylor from 210.168.200.190

So that doesn't look good. Now that I know I've been targeted by an attack and that some of my username, password combinations are weak, I'd like to know how can I...

• ... determine if my Linux box has been infiltrated?
• ... undo any of the damage left by the perpetrators?
• ... prevent this from happening in the future?

UPDATE

Any advice on undo any of the damage left by the perpetrators?

Solution 1:

A lot of people seem to suggest DenyHosts, but I've seen a lot of success with Fail2Ban on my systems. It watches for a (configurable) number of failures, and then performs an action - on my servers, that action is to use iptables to drop all traffic from the host. After 10 login failures, they get banned and that's the end of it.

I use that in combination with Logcheck, so that I always know what's going on on my servers.

If you have any evidence that someone has actually broken into your systems (the logs you have posted are not evidence of this), then your only solution is to back up all the data you need to keep, wipe the machine, reinstall, and restore from backups. Otherwise, there's no way to be sure.

Solution 2:

Valid login attempts are logged in as well, so if you see a brute force attempt followed by a success, that's a good indication something bad has happened.

I use DenyHosts to monitor my logs for suspicious SSH traffic, and I have it configured to automatically firewall off hosts at a certain point.

Note there are a variety of other ways you'd want to monitor your machine to see if it's compromised, including load patterns, login activity, periodic traffic sniffing, monitoring running processes and open ports, and ensuring file integrity with a tool like tripwire.

If you're only going to do one, monitoring system load is a very effective way of detecting compromise, because most machines when compromised are used to do things like send massive amounts of spam or otherwise receive a lot of traffic. Perhaps not useful if you're a high-value target and people may be trying to specifically break into you for reasons other than to turn your host into a zombie, but valuable nonetheless. Plus monitoring load is needed for profiling and to figure out when you need to invest in more hardware or better software.

You should also do comprehensive log analysis, looking at auth.log and others for things that are unexpected. Log file analysis is a competitive market and the problem isn't yet solved, but there are free tools like logwatch which can be configured to send you summaries daily.

Security through layers!

Solution 3:

Forget Tripwire, its quite expensive. Use AIDE instead. Its free, easy to setup (though it takes a little while to decide which temp directories to exclude, and otherwise configure).

you run it, it builds a database of all files. Run it again and it'll tell you which files have changed.

One other thing to do is install CSF, which has a denyhost type blocker, as people fail repeatedly to login, it'll add them to your firewall rules. You can also require SSH logins to have a public key as well, the script kiddies can attempt as many logins as they like then.