CentOS(Linux) VPS 防暴力登录账户和密码

声明：本文针对CenOS6.x VPS，对其它Linux VPS也有参考价值，内容仅供个人收藏参考，有耐心的朋友也可以看一下

本文内容转自一个讲解使用denyhosts软件防CentOS VPS被暴力攻击的老外网站，denyhosts有适和其它linux的版本，因此也适用于其它linux VPS。

网站链接http://centoshelp.org/security/securing-sshd/

虽是英文，但都比较简单，故不在翻译。

对于linux新手可能会用到以下内容(针对CentOS)

/article/9076752.html

如果CentOS 上直接yum install denyhosts无效，可执行以下命令更新源，然后再安装,以下提供的源可能在未来的某个时间失效，可在网上找其它denyhosts源

参考https://www.digitalocean.com/community/articles/how-to-install-denyhosts-on-centos-6

#sudo rpm -Uvh http://mirror.metrocast.net/fedora/epel/6/i386/epel-release-6-8.noarch.rpm #sudo yum install denyhosts

内容如下：

Securing sshd

This howto outlines a few extra steps that can be taken to further secure a SSH server, chiefly from the constant onslaught of automated brute-force password attacks.

Applicable to Centos Versions:

Centos 5.x
Centos 6.x

Requirements

An SSH server should already be installed and running. If it is not, do the following:

yum install openssh-server
service sshd start

Doing the Work

Most of the steps below involve editing the global SSH server configuration file located at /etc/ssh/sshd_config, and the access control tcpwrapper configuration files /etc/hosts.allow and /etc/hosts.deny. Use your favorite editor to modify these files
as root.

Summary of Steps:

Some or all of the following steps may be taken to secure your SSH server. The steps are sorted roughly in order of entirely sensible precaution to completely paranoid:

Choose a strong password
Install “DenyHosts” to auto-block bad clients
Change the default port
Disable insecure Protocol 1; allowing only Protocol 2
Disable root login
Reduce MaxStartups
Reduce LoginGraceTime
Allow only specific users or groups to connect
Allow only specific IP addresses to connect
Allow only users with keys to connect; no passwords allowed
Bind the ssh server to a specific network interface

Steps Explained:

If you do nothing else, it is of utmost importance to choose strong passwords for all accounts, especially root, since it is the #1 attacked account. It is very enlightening to see the accounts on your system that attackers have been targeting lately; to
do this either use the lastb command to quickly see recent failed logins of all types, or, better, parse/var/log/secure to get stats only for failed ssh logins. Three examples:

[root@nano ~]# ### top 5 most recently attacked accounts

[root@nano ~]# lastb | awk '{print $1}' | sort | uniq -c | sort -rn | head -5
29 root
24 admin
16 sales
14 test
14 staff

[root@nano ~]# ### top 5 most attacked accounts

[root@nano ~]# awk 'gsub(".*sshd.*Failed password for (invalid user )?", "") {print $1}' /var/log/secure* | sort | uniq -c | sort -rn | head -5
723 root
66 admin
45 test
39 ftpuser
34 mysql

[root@nano ~]# ### top 5 attacker IP addresses (obscured for privacy)

[root@nano ~]# awk 'gsub(".*sshd.*Failed password for (invalid user )?", "") {print $3}' /var/log/secure* | sort | uniq -c | sort -rn | head -5
1042 193.251.XXX.XXX
556 85.21.XXX.XXX
373 218.189.XXX.XXX
284 121.156.XX.XXX
228 121.140.XX.XXX

Centos uses pam_cracklib.so to force normal users to choose semi-strong passwords of 6 characters or more whenchanging their passwd, but rootcan still choose weak passwords anytime he wants (but will be warned). Also note that the first
user account added to the system after an installation (using firstboot) is allowed to be weak if you ignore the warning.

You may want to use a utility called “john the ripper” to audit the strength of passwords on your system – if it cracks any too quickly, they’re too weak.

Install
Denyhosts which watches the /var/log/secure logfile for invalid ssh login attempts, and if a configurable threshold is crossed, they are automatically blocked by being added to /etc/hosts.deny. Install Denyhosts, and optionally edit the good default configuration
in /etc/denyhosts.conf:

yum install denyhosts
chkconfig denyhosts on
service denyhosts start

The vast majority of ssh attacks are directed by compromised zombie machines against ssh servers listening on the default port of “22″. By changing this port to something else you greatly reduce the risk of an automated break-in. Edit /etc/ssh/sshd_config
and change the line which reads “Port 22″ to “Port 2222″, or any other unused port of your choosing, preferably above 1024. A line preceded by a ‘#’ is the commented outdefault value.

#Port 22
Port 2222

SSH speaks two protocols: The old and insecure Protocol 1, and the newer Protocol 2. Almost all SSH clients now speak Protocol 2, so it is best to disable the older one. Edit sshd_config to include only Protocol 2, and not both:

#Protocol 2,1
Protocol 2

Note: This should be unnecessary as only Protocol 2 is enabled by default.

There is no good reason for root to be allowed to interactively login directly; after connecting as a normal user, you can still“su -” to root. edit sshd_config:

#PermitRootLogin yes
PermitRootLogin no

If root login is required – e.g. for remote system backups – you may alternatively permit root to login, butonly if using ssh keys, not interactive password entry:

PermitRootLogin without-password

Finally, it’s also possible to limit root access to only be able to run specific commands, such as backup scripts (beyond the scope of this article):

PermitRootLogin forced-commands-only

Limit the maximum number of unauthenticated connections that the ssh server will handle at the same time. The smaller this is, the harder it is for script kiddies to make parallel, coordinated cracking attempts with multiple connections. edit sshd_config
and change MaxStartups from the default of “10″ to “3:50:10″. The colon separated values tells the ssh server to, “allow 3 users to attempt logging in at the same time, and to randomly and increasingly drop connection attempts between 3 and the maximum
of 10″. Note: this should be increased on servers with substantial numbers of valid ssh users logging in.

#MaxStartups 10
MaxStartups 3:50:10>

Reduce the maximum amount of time allowed to successfully login before disconnecting. The default of 2 minutes is too much time to hold open an unauthenticated connection attempt (see above); 30 seconds is more than enough time to log in:

#LoginGraceTime 2m
LoginGraceTime 30

By default, all valid users on the system are allowed to log in. A more secure policy is to only allow a whitelist of users or groups to log in. For example, to allow only the users “john”, “mary”, “joeblow”, “joeschmoe”, “joejoe”, and any username that
starts with “joe” to login, add the following line to sshd_config:

AllowUsers john mary joe*

Alternatively, you may instead allow only users who are members of certain groups to login. For example, to allow only the members of the “sshusers” group to connect, first make sure the group exists (groupadd sshusers) and add your users to it (usermod
-a -G sshusers username), then add the following line to sshd_config:

AllowGroups sshusers

Allow only users from certain IP addresses to connect. Before allowing specific IPs, the default policy must first be set to DENY to be effective. edit /etc/hosts.deny and add the following line:

sshd: ALL

Next add to /etc/hosts.allow the networks you want to allow. For example, to allow all 254 hosts on the class C network “192.168.1.*”, all 16million hosts from the class A network “10.0.0.0″, and the lonely IP 24.42.69.101, you would add the following to
/etc/hosts.allow:

sshd: 192.168.1.0/255.255.255.0
sshd: 10.0.0.0/255.0.0.0
sshd: 24.42.69.101

You may also allow/deny connections via a firewall, but to maintain sanity it’s best to stick to one method or the other.

To remove the possibility of anybody ever guessing a user’s password, disable password authentication completely, and require that public/private key pairs be used instead. While much more secure than passwords, a user’s private key can still be compromised,
especially if not protected by a passphrase. To disable password logins, add the following to sshd_config:

PasswordAuthentication no

By default, the ssh server listens for connections on ALL interfaces (0.0.0.0). If a ssh server is to only be accessible internally, bind it to a LAN IP. For example: edit sshd_config:

ListenAddress 192.168.1.10

Troubleshooting / How To Test

If your changes don’t seem to be working, remember to restart the sshd server, butDO NOT CLOSE THE ACTIVE SSH CONNECTION in case something goes wrong; attempt to make a new connection first, and undo any changes if necessary, or you may
find that you’ve remotely locked yourself out of the system.

/etc/init.d/sshd restart