Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Possible Duplicates:
Is it normal to get hundreds of break-in attempts per day?
What should I do if I find someone is brute forcing my server password?

I have an Ubuntu 10.04 VPS box. It's been installed for a couple of days and only has ssh, postfix/dovecot running. The server is intended to be used for my personal needs like e-mail and RoR development. My /var/log/auth.log is already roughly 300k and is full of messages like these:

Jul  4 03:18:36 artemis sshd[360]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=66.96.201.81  user=root
Jul  4 03:18:38 artemis sshd[360]: Failed password for root from 66.96.201.81 port 58040 ssh2
Jul  4 03:18:39 artemis sshd[362]: reverse mapping checking getaddrinfo for 66-96-201-81.static.hostnoc.net [66.96.201.81] failed - POSSIBLE BREAK-IN ATTEMPT!

There are other random users, which they tried to log in with, such as user, testftp, ftp, samba, postgres, admin, alex and so on. I randomly did whois on some of the IP addresses and they seem to belong to China, Uruguay, Ecuador and some other countries. How common are such brute force break-in attempts? Do I need to worry? Should I install firewall or take any other security measures?

share|improve this question

marked as duplicate by Iain, wolfgangsz, splattne Jul 4 '11 at 15:11

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

    
After only a couple of days?! –  pavium Jul 4 '11 at 13:48
    
Yes, I've set up this server 3 days ago. –  Artem Pakk Jul 4 '11 at 13:50
    
It looks like the 'duplicate' post would be worth reading. –  pavium Jul 4 '11 at 13:52

3 Answers 3

up vote 1 down vote accepted

You shouldn't worry at those attempts as they are very common, what you can (and have to IMHO) do to reduce the risk of your server being compromised is the following:

  • Use your firewall, if you can you should only allow your IP(s) to connect to non-public services, whatever they are. Anyway set up your firewall to block the most common rogue/strange packets (ICMP redirect, bogus ip ranges...) and allow connections only on ports and protocols you need.

  • Use ssh to your advantage, use ssh keys as your only authentication method and password-protect your private key, this way dictionary/bruteforce attacks doesn't stand a chance anymore. If you can't use keys, use the "Match" directive with "Address" to further restrict which account can log from public IPs.

  • Have a look at fail2ban, this tool can dynamically change firewall rules to block too many attempts from the same IP, beware you can be your own victim :)
    More infos on fail2ban here

share|improve this answer
1  
I'd also suggest Denyhosts. Simple to install and configure. Blocks out attempts to break into SSHD, and it can be configured to download IP's from other denyhost installs so you get sites blocked that are attempting to hit other systems. –  Bart Silverstrim Jul 4 '11 at 14:20

What you're noticing is very common - As long as you have server on the public-facing internet, people will try to break in. Therefore, keeping your code and software packages up to date is a must! And yes, using a good firewall is important too.

I use a program called Config Server Security (CSF). It's good because it will automatically log these things, and you can configure it to permanently block a certain IP address after so-many failed SSH attempts.

Another practice I do is reduce the amount of "Maximum Failed Attempts" in the sshd_config file.

share|improve this answer

I had the same problem as you. Multiple SSH attacks, and dictionary attacks. I would suggest using an IPTables approach - either with manually created rules or using a package such as fail2ban or denyhosts. Something similar is pam_shield but it is a bit more limited in its uses.

I would suggest a non-password based SSH login (i.e. certificate/key based), as well as restricting the addresses from which SSH logins can be made.

An example of some IPTables rules that can be used for this purpose can be found at: http://www.thatsgeeky.com/2011/01/limiting-brute-force-attacks-with-iptables/

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.