Tips on basic Linux server security
by George Rushmore - for Help Net Security
Bookmark and Share
If you just put your Apache web server online, and are thinking into making the first step in your system security, this brief article will help you do that. By having your own server, you must understand the responsibility behind it. While the web server itself (Apache in this example) is not a big security problem (at least not the software package itself), there are a few things you should take care on your system.


I presume you know that having a password like 'Mom' or 'girlfriend' is not a good start for securing your system. I usually prefer passwords with both numerican and alphatbetical characters, plus some extra symbols. This is a good password: ILik3-PeN_gu1nS. Passwords should be complicated as there are a lot of ways someone can get your encrypted password. When we are talking about Linux systems with a webserver, the first thing that comes to my mind are all those numerous buggy CGI scripts that make you get /etc/passwd file from the attacked system. When that is done, a copy of Crack or John The Ripper can be used for cracking the password. Always remember: a good password is harder to crack. If you use some basic word for a password, a good wordlist will make the cracker software spit your en-encrypted password on the screen in no-time.

File transfer and remote logins

Think what software packages should run on your system, and remove the ones that you don't need. If you are thinking about transfering files from and to your system shut the FTPd down. There is far more secure way that does the same - SCP. By quickly checking the man pages for SCP, we get: "scp copies files between hosts on a network. It uses ssh for data transfer, and uses the same authentication and provides the same security as ssh. Unlike rcp, scp will ask for passwords or passphrases if they are needed for authentication."

SCP clients don't have that much good looking GUI frontends, but you can do it all from the shell by using the syntax:

scp Localfile Username@RemoteServer:RemoteFolder

I hope you don't use the Telnet Deamon which usually sits on the port 23. If you do, remove it as SSH is a far better way of remotely doing a login into your system. The big difference between telnet and SSH, is that SSH provides significantly enhanced security for your login situations.It provides an encrypted communications path between two untrusted hosts over a potentially insecure network and thus prevents user's passwords and other sensitive data from being transmitted across the network in clear-text form.

Access forbidden

There is no point of not using the hosts.deny and hosts.allow files for blacklisting some people, and giving others the right to connect to the system. The hosts.allow file (located at /etc/hosts.allow) describes the names of the hosts which are allowed to use the local INET services, as decided by the '/usr/sbin/tcpd' server (for instajnce telnet, finger, ftp, exec, rsh, ssh, tftp, talk...). The hosts.deny file is doing just the opposite thing and is self explanatory. In most of the books I read about security on Linux systems, authors have this proposition regarding usage of mentioned hosts.* files.

First add all:all into your host.deny list, which doesn't allow anyone to connect to your INET services, and then edit hosts.allow with all the hostnames which should be able to connect. This is the bottom line what should be done on the Linux system that is connected to the Internet, but let's say Murphy's Law strikes - When you add all:all to host.deny list and save the configuration, your Internet connection just crashes and you are not able to connect to the system which is physically thousands of miles from your home. Because of this I prefer first editing hosts.allow and then the hosts.deny list.

Checking the integrity


Attackers use reflection techniques for larger DDoS attacks

Posted on 17 April 2014.  |  Instead of using a network of zombie computers, newer DDoS toolkits abuse Internet protocols that are available on open or vulnerable servers and devices. This approach can lead to the Internet becoming a ready-to-use botnet for malicious actors.

Weekly newsletter

Reading our newsletter every Monday will keep you up-to-date with security news.

Daily digest

Receive a daily digest of the latest security news.


Fri, Apr 18th