Security Handbook/Securing services

Ensuring daemons are secure.

Apache
Apache comes with a pretty decent configuration file but again, we need to improve some things, like binding Apache to one address and preventing it from leaking information. Below are the options that you should apply the configuration file.

If you did not disable the  USE flag in  before installing Apache, you should have access to an ssl enabled server. Inside example configuration files can be found. These are working examples and it is best to verify those or disable them.

It is important to define your configuration(s) to listen to a particular IP address (rather than all available IP addresses on your system). For instance, for the file:

We also recommend you to disable showing any information about your Apache installation to the world. By default, the configuration will add server version and virtual host name to server-generated pages. To disable this, change the ServerSignature variable to :

Apache is compiled with  and. This will by default enable all modules, so you should comment out all modules in the LoadModule section (LoadModule and AddModule) that you do not use in the main configuration file. When using OpenRC, restart the service by executing.

Documentation is available at http://www.apache.org.

Bind
One can find Bind documentation at the Internet Software Consortium. The BIND 9 Administrator Reference Manual is also in the doc/arm.

The newer BIND ebuilds support chrooting out of the box. After emerging follow these simple instructions:

Djbdns
Djbdns is a DNS implementation on the security of which its author is willing to bet money. It is very different from how Bind 9 works but worth a try. More information can be obtained from http://www.djbdns.org.

FTP
Generally, using FTP (File Transfer Protocol) is a bad idea. It uses unencrypted data (ie. passwords are sent in clear text), listens on 2 ports (normally port 20 and 21), and attackers are frequently looking for anonymous logins for trading warez. Since the FTP protocol contains several security problems you should instead use or HTTP. If this is not possible, secure your services as well as you can and prepare yourself.

MySQL
If you only need local applications to access the mysql database, uncomment the following line in.

Disable network access:

Then we disable the use of the LOAD DATA LOCAL INFILE command. This is to prevent against unauthorized reading from local files. This is relevant when new SQL Injection vulnerabilities in PHP applications are found.

Disable LOAD DATA LOCAL INFILE in the [mysqld] section:

Next, we must remove the sample database (test) and all accounts except the local root account.

Removing sample database and all unnecessary users:

Proftpd
Proftpd has had several security problems, but most of them seem to have been fixed. Nonetheless, it is a good idea to apply some enhancements:

One can find documentation at http://www.proftpd.org.

Pure-ftpd
Pure-ftpd is an branch of the original trollftpd, modified for security reasons and functionality by Frank Dennis.

Use virtual users (never system accounts) by enabling the AUTH option. Set this to  and create your users by using.

Configure your MISC_OTHER setting to deny anonymous logins, chroot everyone , prevent users from reading or writing to files beginning with a. (dot), max idle time , limit recursion , and a reasonable umask value.

Warning: Do not use the  or   options! If you want to have a warez site, stop reading this guide!

One can find documentation at http://www.pureftpd.org.

Vsftpd
Vsftpd (short for very secure ftp) is a small ftp daemon running a reasonably default configuration. It is simple and does not have as many features as pureftp and proftp.

As you can see, there is no way for this service to have individual permissions, but when it comes to anonymous settings it is quite good. Sometimes it can be nice to have an anonymous ftp server (for sharing open source), and vsftpd does a really good job at this.

Netqmail
Netqmail is often considered to be a very secure mail server. It is written with security (and paranoia) in mind. It does not allow relaying by default and has not had a security hole since 1996. Simply and go configure!

Samba
Samba is a protocol to share files with Microsoft/Novell networks and it should not be used over the Internet. Nonetheless, it still needs securing.

Make sure that permissions are set correct on every share and remember to read the documentation.

Now restart the server and add the users who should have access to this service. This is done though the command with the parameter.

ssh
The most important securing that OpenSSH needs is turning on a stronger authentication based on public key encryption. Too many sites (like Sourceforge, PHP and Apache) have suffered unauthorized intrusion due to password leaks or bad passwords.

Also verify that you don't have  in your configuration file as it overrides the public key authentication mechanism, or you can disable either PasswordAuthentication or ChallengeResponseAuthentication. More information about these options can be found in the sshd_config manual page.

Now all that your users have to do is create a key (on the machine they want to login from) and type in a passphrase with the following command:

This will add two files in your directory called  and. The file called is your private key and should be kept from other people than yourself. The other file is to be distributed to every server that you have access to. Add the key to the users home directory in and the user should be able to login:

View password:

Now your users should guard this private key well. Put it on a media that they always carry with them or keep it on their workstation (put this in the password policy).

For more information go to the OpenSSH web site.

Using xinetd
xinetd is a replacement for (which Gentoo does not have), the Internet services daemon. It supports access control based on the address of the remote host and the time of access. It also provide extensive logging capabilities, including server start time, remote host address, remote user name, server run time, and actions requested.

As with all other services it is important to have a good default configuration. But since is run as root and supports protocols that you might not know how they work, we recommend not to use it. But if you want to use it anyway, here is how you can add some security to it:

And edit the configuration file:

For more information read.

X
By default Xorg is configured to act as an Xserver. This can be dangerous since X uses unencrypted TCP connections and listens for xclients.

But if you depend on using your workstation as a Xserver use the command with caution. This command allows clients from other hosts to connect and use your display. This can become handy if you need an X application from a different machine and the only way is through the network, but it can also be exploited by an attacker. The syntax of this command is

A more secure solution is to disable this feature completely by starting X with or disable it permanently in the configuration.

To make sure that does not get overwritten when emerging a new version of Xorg you must protect it. Add the following line to :

If you use a graphical login manager you need a different approach.

For gdm (Gnome Display Manager):

For xdm (X Display Manager) and kdm (KDE Display Manager):