How to Protect your servers from bruteforceattacks

Note : all blogs post will be moved to http://blog.cybergen.in/protect-your-server-by-securing-ssh/

Attackers try acessing servers all the time this is done generally by BruteForce where they would try random combination of passwords till they get access to your server .This is not generally done at a stretch but distributed over a period of time to prevent suspiscion.

in linux distributions you can find this log in /var/log/secure

Dec 22 08:43:25 your_server sshd[7207]: Failed password for root from (attackers ip) port 2867 ssh2
Dec 22 08:43:25 your_server sshd[7208]: Disconnecting: Too many authentication failures for root
Dec 22 08:43:27 your_server sshd[7209]: Failed password for root from (attackers ip) port 1598 ssh2
Dec 22 08:43:27 your_server sshd[7209]: Failed password for root from (attackers ip) port 1598 ssh2
Dec 22 08:43:27 your_server sshd[7209]: Failed password for root from (attackers ip) port 1598 ssh2
Dec 22 08:43:28 your_server sshd[7209]: Failed password for root from (attackers ip) port 1598 ssh2
Dec 22 08:43:28 your_server sshd[7209]: Failed password for root from (attackers ip) port 1598 ssh2
Dec 22 08:43:28 your_server sshd[7209]: Failed password for root from (attackers ip) port 1598 ssh2

you can see this log if in your /etc/ssh/sshd_config
LogLevel is set to INFO

other options for Log Level

LogLevel
      Gives the verbosity level that is used when logging messages from
      sshd.  The possible values are: QUIET, FATAL, ERROR, INFO, VER-
      BOSE, DEBUG, DEBUG1, DEBUG2 and DEBUG3.  The default is INFO.
      DEBUG and DEBUG1 are equivalent.  DEBUG2 and DEBUG3 each specify
      higher levels of debugging output.  Logging with a DEBUG level
      violates the privacy of users and is not recommended.

Solutions

1. Check existing firewall rules and remove rules for machines that do not need SSH open to the internet - This is particularly important when decommissioning machines. Compromises often occur when an IP address is re-used and a firewall rule for SSH still exists for the old machine. If the new machine has an out-of-the-box configuration that includes weak username/password combinations, it is likely to get compromised before long.
2. Use a single, secure host for SSH access into your network - Instead of opening multiple firewall holes for every host that someone might need SSH access to, require users to SSH to one particular host, from which they can then SSH to other hosts which are not directly exposed to the internet. The exposed host can have more hardening measures applied, which may not be necessary on the others.
3. Run SSH on a non-default port - Since nearly all 'random' attacks are targeted at the default port 22, changing the listening port for sshd is an effective way of avoiding them. In OpenSSH, this can be done by editing the line "Port 22" in /etc/ssh/sshd_config. It is probably wise to avoid obvious alternate ports such as 222 and 2222, as scans for these ports are sometimes seen. Any connecting clients will need to specify the new port.
4. Disallow root logins via SSH - This should be the default setting anyway. Older versions that allow root logins by default should be updated. If you require root access via SSH, don't enable root logins, instead you should log in as a user that can 'su' to root.
5. Allow only SSH protocol version 2 - Again this should be the default.  SSHv1 is insecure and may make brute force attacks easier.  The relevant line in /etc/ssh/sshd_config should read "Protocol 2".
6. Avoid using easily guessable names for accounts - Unless the attackers can obtain usernames from another source (e.g. a website), they are just guessing them. Avoid usernames such as manager, admin, sysadmin, webmaster, guest, test, temp, as these are seen in brute force attempts. Users' first names are also used, so initial and lastname is a better choice.
7. Apply a password policy - Setting length and complexity requirements will greatly decrease the chances of a successful brute force attack.
8. Use key-based authentication - It is possible to disable password-based authentication altogether and use key-based authentication. This can have its own security issues. If your machine with the SSH keys is compromised, the attacker can log on to remote systems using your keys. So, if you use SSH keys, you should protect the private key with a passphrase which must be typed when the key is used. However, it might not be possible to force users to set a passphrase for their keys.
9. Block brute force attacks - Although sshd itself provides no effective way to limit brute force attacks, it is possible to use methods that use log files and firewall rules to impose a ban on IP addresses that attempt too many connections. An example is Fail2ban.