Secure my web and FTP server

Q I am responsible for a web and FTP server running Red Hat Enterprise Linux 4. I have been administering the server and recently configured Logwatch to send me reports. I found entries in the reports that worry me, mainly authentication failures and invalid users. I get these entries every single day, but the IP address and number of attempts change each time. It seems to me that these are attempts to log in to my system using different combinations of usernames and password. Is there anyway to stop these annoying attacks on my server? What actions would you recommend to secure my server?

A You are right! The entries you see in Logwatch are automated break-in attempts that try to find a valid user name/password on your server in order to gain local access. There are numerous security configurations that you can use to harden your sshd server. The configuration file of the OpenSSH server is /etc/ssh/sshd_config. Let's take a look at it. While you could set the AllowUsers parameter to allow only a limited number of users to log in, this is hard to manage when you have lots of users on your system, as is the case with a typical FTP server. Attackers can still try to guess the password for any users that are allowed to log in, but if using this option on your server is feasible, then I recommend you do use it. Also, you can disable root logins via ssh by using the option:

PermitRootLogin no

Use strong passwords, and to prevent passwords being guessed I'd recommend not using password authentication at all. You can generate private/public keys for your system users using ssh-keygen; manage keys with ssh-agent/ssh-add and disable password authentication. There are other configurations; you can, for example, reduce the number of connections your sshd server gets by changing the default port. Most automated attacks will only check port 22, so changing to a different port will decrease the number of hits you get on the Logwatch report - try Port 222 in the config file. You should only allow version 2 of the SSH protocol: version 1 has known vulnerabilities and should not be used. And make sure that no one can log in using an empty password, by amending the file to 'PermitEmptyPasswords no'.

After you've saved changes to the sshd configuration file, the sshd server needs to be restarted for the settings to take effect. These suggestions will thwart most attacks. However, they are static rules that do not adapt to the changing nature of the attack. Also, there might be specific reasons that prevent you from using public key cryptography. There are numerous open source solutions (Sshdfilter, Blockhosts and so on) for this problem, using different tools to do the job: PortSentry, Iptables, Tcpwrappers etc. I will focus on DenyHosts ( since it uses Tcpwrappers, which is available in most Unix systems. In order to use Tcpwrappers, sshd needs to be compiled with libwrap support. Almost all sshd servers deployed are compiled this way but you can verify your specific version using a command like

# ldd /usr/sbin/sshd | grep libwrap => /usr/lib/ (0x00140000)

DenyHosts is written in Python, so you will need the Python interpreter installed on your system. In Red Hat you can accomplish this by running

# up2date -i python

Now you should download the actual DenyHosts package. Since you are running RHEL 4, you can install the RPM version with

rpm -ivh

DenyHosts comes with a simple configuration file (/usr/share/denyhosts/denyhosts.cfg-dist), which you can use as a template for your system. By default, it is properly configured for Red Hat-based systems. The relevant options you may want to edit are:


Specifies how old blocked entries need to be when DenyHosts is invoked with the --purge flag.


Number of failed login attempts for invalid users to trigger blocked connections.


Number of failed login attempts for valid users to trigger blocked connections If you want to be notified by email of new blocked hosts, you can specify your address in the ADMIN_EMAIL =' line The configuration file is extremely well documented and is not hard to interpret. Once you have decided on your particular options, copy this file to /etc/denyhosts.cfg. Now we need to edit the init script (/usr/share/denyhosts/daemon-control-dist) to reflect our system settings. In this case we just need to indicate which configuration file to use:

DENYHOSTS_CFG = "/etc/denyhosts.cfg"

And install the init script with

# cp /usr/share/denyhosts/daemon-control-dist /etc/init.d/denyhost
# chmod +x /etc/init.d/denyhost
# chkconfig denyhost on

Now it is just a matter of running the DenyHosts daemon with

# /etc/init.d/denyhost start &

If you have any break-in attempts on your current /var/log/secure log file, DenyHosts will populate /etc/hosts.deny accordingly, blocking out the offending IP addresses!

#tail -n3 /etc/hosts.deny
sshd: 220.1  17.241.3
sshd: 218.85.1   19.83

A notification email will also be sent to the ADMIN_EMAIL that you specified above. Server security, and sshd security in particular, is widely dealt with online and you may want to do a web search on "defending against brute force ssh attacks" for extra information.

Follow us on or Twitter

Username:   Password: