Is it normal to get hundreds of break-in attempts per day?

Question

I just checked my server's /var/log/auth.log and found that I'm getting over 500 failed password/break-in attempt notifications per day! My site is small, and its URL is obscure. Is this normal? Should I be taking any measures?

Answer 1

In today's internet this is quite normal sadly. There are hordes of botnets trying to login to each server they find in whole IP networks. Typically, they use simple dictionary attacks on well-known accounts (like root or certain applications accounts).

The attack targets are not found via Google or DNS entries, but the attackers just try every IP address in a certain subnet (e.g. of known root-server hosting companies). So it doesn't matter that your URL (hence the DNS entry) is rather obscure.

That's why it is so important to:

• disallow root-login in SSH (howto)
• use strong passwords everywhere (also in your web applications)
• for SSH, use public-key authentication if possible and disable password-auth completely (howto)

Additionally, you can install fail2ban which will scan the authlog and if it finds a certain amount of failed login attempts from an IP, it will proceed to add that IP to /etc/hosts.deny or iptables/netfilter in order to lock out the attacker for a few minutes.

In addition to the SSH attacks, it is also becoming common to scan your webserver for vulnerable web-applications (some blogging apps, CMSs, phpmyadmin, etc.). So make sure to keep those up-to-date and securely configured too!

Answer 2

A few 100 is just fine... Last month I found one of my servers had 40k failed attempts. I went trough the trouble of plotting them: Map

Once I changed the ssh port and implemented Port Knocking, the number dropped to 0 :-)

Answer 3

I for one use a "tarpit" in addition to only allowing public key authentication and disallowing root logins.

In netfilter there is a recent module, which you can use with (INPUT chain):

iptables -A INPUT -i if0 -p tcp --dport 22 -m state --state NEW -m recent --set --name tarpit --rsource
iptables -A INPUT -i if0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 180 --hitcount 6 --name tarpit --rsource -j DROP
iptables -A INPUT -i if0 -p tcp --dport 22 -j ACCEPT

What that does is, that every attempt to connect to port 22 is listed by the recent module with IP and some other stuff under the name "tarpit" (if you're curious, look at /proc/net/xt_recent/tarpit). Obviously you can use other names.

To list or delist IPs use:

echo "+123.123.123.123" > /proc/net/xt_recent/tarpit
echo "-123.123.123.123" > /proc/net/xt_recent/tarpit

This rate-limits the attempts to 5 in 300 seconds. Please note that users with an existing connection are not bothered by that limit, because they already have an established connection and are allowed to create more (even above the rate limit).

Adjust the rules to your liking but make sure that they be added in that order (i.e. when adding then use them in this order, when inserting then in the reverse order).

This cuts down the noise immensely. It also provides actual security (against brute-forcing) unlike the perceived security of changing the port. However, I'd still recommend changing the port if it's feasible in your environment. It will cut down the noise level a lot as well ...

You can still combine this with fail2ban, although I've been running just fine without it and only the above rules.

EDIT:

It is possible to lock your self out doing this, so you can add something like the following that lets you clear you ban by knocking on a particular port:

iptables -A INPUT -i if0 -p tcp --dport <knockport> -m state --state NEW -m recent --name tarpit --remove

Answer 4

You could implement fail2ban, or similar methods like locking SSH to your IP. Sadly bots attempt to bruteforce access all the time so it is quite normal, you need to make sure you have a good password.

Answer 5

Yes. It's quite normal nowadays.

Please use only public key authentication for administrative purposes if possible. Generate a private key on you workstation:

$ ssh-keygen -t dsa

Copypaste the contents of ~/.ssh/id_dsa.pub to you servers ~/.ssh/authorized_keys (and /root/.ssh/authorized_keys, should you require direct root login).

Configure your servers /etc/ssh/sshd_config to only accept public key authentication:

PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin without-password

If you have too many servers, you can use Puppet to run public keys and configurations to them.

Look into Denyhosts and fail2ban to block repeated SSH login attempts and see Snort if you require full IDS/IPS.

Answer 6

use http://denyhosts.sourceforge.net/

and yes, you should use public-key authentication and disable password auth.

Answer 7

The attempts are mechanized, so the numbers seem OK (yes they are high compared to some sites and the low compared to others). You should take the steps you normally have to: You consider your sites as attack targets every day, even when you do not detect an attack; not detecting an attack, does not mean it does not exist.

Answer 8

I'd say only getting only 500 is kind of low.

At a previous employer, one of the computer security researchers called the constant stream of break-in attempts the "internet equivalent of cosmic noise". He described it as a normal, continuous flow of malicious traffic that was searching for systems on the internet and automatically exploit scripts to attempt to hijack the system. Bot-nets and other malicious systems would perpetually scan and rescan the internet for vulnerable systems much like SETI.

Answer 9

Yes,

this is common, but that doesn't mean you shouldn't fight the good fight. Here are some steps on how you can make your server more secure.

Avoid DNS associated IP addresses

You can greatly reduce this number in shared or colocation environments by disabling SSH access on any IP addresses associated with domain names. Unlisted non-domain IP addresses will receive less of this type of traffic, so buy an unlisted IP and only use this IP for SSH access.

Use a VPN for all SSH access

If you are in an environment in which you can implement IPsec/VPN to a private network within your server environment, this is ideal. Disable all SSH Internet access, make sure you have an integrated lights out solution. Setup your VPN, and only allow SSH access from your VPN.

Implement IP address rules for SSH access

If the VLAN isn't an option configure your router, or firewall rules to only allow SSH connections from a known IP address range.

If you follow these steps you will sleep much easier in the night knowing someone would have to compromise your hosting companies network to gain access to the server through SSH.

Answer 10

Pretty normal to see hundreds of failed SSH connections.

If you have the option, I simply change my SSH port to something non-standard. It doesn't necessarily make your server any more secure, but it sure cleans up the logs (and lets you see anyone deliberately trying to break in!)

Answer 11

In addition to using an automated lockout mechanism like fail2ban you have one more option: actually contact the abuse address ISP of the attacker. It may seem completely futile but in the case of the script-kiddie their ISP is more than willing to take action on them.

To find the abuse address, start with arin.net and lookup the IP address using whois. You may be redirected to another regional registry but eventually you can find the responsible ISP for the IP block which contains the address. Look for the abuse@ address or just mail the technical contact.

Send them a polite message with the relevant log file entries (make sure to remove any private information) and ask them to take action against the offending host.

Answer 12

I would recommend not using fail2ban but running SSH (and others) on a non-standard port. I don't believe in security by obscurity but I think that this is an excellent way to reduce the noise in your logs.

Failed logins on non-standard ports will be few and far between and can also indicate more targeted attacks.

You could even go a step further an install a SSH honeypot such as Kippo to 'let in' the bruteforcers and see what they would do given the chance.

Answer 13

Yes, it's normal. What I tell clients in your situation with small websites.

Always be prepared to be hacked.

Have a copy of your website on a dev server. This can be your Windows desktop using XAMPP which you can get for free.

ALWAYS make changes to your dev server then upload them to your live website. If it is a CMS like Wordpress, make your posts on the dev server then copy and paste them into the live server.

NEVER download anything from your live website to your dev server.

Monitor your webpages regularly for any changes that you did not do. Specifically, hidden links to drugs or 'enhancement' products. You can find lots of browser add ins and programs that will do this for you.

If you are compromised. Notify your host, delete everything, change all passwords and upload your clean dev server to the now empty webserver. Work with your host to prevent a recurrence.

You should not need a security team for a small site. That is what your host is supposed to provide. If they do not, then get another host which is much easier to do when you have a dev server rather than trying to move the live server.

Hope this helps.

Answer 14

Another way of stopping it (as I personally don't like to move the SSH port): decide if you are able to list all networks from which you'll ever want to login, then only allow these to access your SSH port.

WHOIS entries of local ISPs helped me to reduce attacks to 1-2 login attempts a month (back then it was about 1k/day). I detected those by still using denyhosts.

Answer 15

In addition to the other excellent suggestions you've already received, I also like to use the AllowUsers directive if appropriate for the given server. This allows only specified users to login via SSH which greatly reduces the possibility of gaining access through an insecurely configured guest/service/system account.

Example:

AllowUsers admin jsmith jdoe

The option AllowUsers specifies and controls which users can access ssh services. Multiple users can be specified, separated by spaces.

Answer 16

Yes, it is normal. You can :

• Reduce the opportunity for attack by using fwknop

Fwknop is the one of the better port knock implementations because it is not spoofable and actually authenticates as opposed to just authorizing a connection.

• You can change the port that Openssh uses but you are not really improving security.

• Fortify ssh authentication using Google-authenticator or wikid

This will protect password based attacks and the possibility of a determined attacker / targeted attack compromising your admin machine and stealing your ssh-key & password combo.

Just look at the latest pwn2own comp to see how easy it is for a skilled attacker to compromise your fully patched admin box.

Answer 17

Sadly this is quite normal. You should consider adding something like fail2ban to your system to automatically detect and ban the attackers. If you don't already do so you should also consider only using ssh with public keys and don't allow root login over ssh. If use ftp to transfer files to the system, consider using scp/sftp instead.

Answer 18

I implemented port knocking, and have a few probes per day. They don't get a connection, so they go away. I log and report all access to the ports involved.

I have also run fail2ban with Shorewall as a firewall to temporarily blacklist persistent attackers.

If you don't need Internet access to SSH disable it. If you have a few known addresses which need remote access, limit access to those addresses.

Limiting access to authorized-keys can also be helpful.

Answer 19

I use pam_abl to temporarily blacklist brute forcers, and it works great. I think it feels better to have authorization in PAM using its own database rather than depend on hosts.deny or iptables.

Another plus is that pam_abl does not depend on scanning log files.

Answer 20

It's completely normal these days.
You can set up "burst" limit on firewall for incoming new connections on the SSH port,
or install one of many log parsers a'la fail2ban or change the SSH port ;).

The last one is the easiest one. On heavy loaded machines such break-in attempts can heavy really bad influence to whole system.

--
Regards,
Robert

Answer 21

Yes it's normal.

I just changed the ssh port away from the standard 22. My server, my rules :) just edit /etc/ssh/sshd_config, change the port and restart the service. The only down side is that you must remember to add that port to configuration to every ssh client you use.

Answer 22

• Disable root login (In every linux system root user exist so bots can easily guess the user name).After logging in as normal user you can switch to root either by su or sudo.

• change default port from 22

• Allow ssh access from known ip's only

• Use a strong alpha-numeric-password for the user with ssh access