[ << ]
[ < ]
[ Home ]
[ > ]
[ >> ]
10. Securing Services
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
If you did not disable ssl in your /etc/make.conf before
installing Apache, you should have access to an ssl enabled server. Inside
/etc/apache2/vhosts.d 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 00_default_vhost.conf file:
Code Listing 1.1: /etc/apache2/vhosts.d/00_default_vhost.conf
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 Off:
Code Listing 1.2: /etc/apache2/modules.d/00_default_settings.conf
Apache is compiled with --enable-shared=max and
--enable-module=all. 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
/etc/apache2/httpd.conf configuration file. Restart the
service by executing /etc/init.d/apache2 restart.
Documentation is available at http://www.apache.org.
One can find documentation at the Internet Software
Consortium. The BIND 9 Administrator Reference Manual is also in
The newer BIND ebuilds support chrooting out of the box. After emerging
bind follow these simple instructions:
Code Listing 2.1: Chrooting BIND
# emerge --config bind
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.
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 sftp or HTTP. If this is not possible, secure your
services as well as you can and prepare yourself.
If you only need local applications to access the mysql database,
uncomment the following line in /etc/mysql/my.cnf.
Code Listing 5.1: 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.
Code Listing 5.2: 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.
Code Listing 5.3: Removing sample database and all unnecessary users
mysql> drop database test;
mysql> use mysql;
mysql> delete from db;
mysql> delete from user where not (host="localhost" and user="root");
mysql> flush privileges;
Be careful with the above if you have already configured user accounts.
If you have been changing passwords from the MySQL prompt, you should always
clean out ~/.mysql_history and
/var/log/mysql/mysql.log as they store the executed SQL commands
with passwords in clear text.
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:
Code Listing 6.1: /etc/proftpd/proftpd.conf
ServerName "My ftp daemon"
#Don't show the ident of the server
ServerIdent on "Go away"
#Makes it easier to create virtual users
#Use alternative password and group file (passwd uses crypt format)
# Timeouts and limitations
MaxClients 10 "Only 10 connections allowed"
MaxClientsPerHost 1 "You have already logged on once"
MaxClientsPerUser 1 "You have already logged on once"
#don't run as root
#Log every transfer
#Problems with globbing
One can find documentation at http://www.proftpd.org.
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 -lpuredb:/etc/pureftpd.pdb and create your users by using
Code Listing 7.1: /etc/conf.d/pure-ftpd
## Misc. Others ##
MISC_OTHER="-A -E -X -U 177:077 -d -4 -L100:5 -I 15"
Configure your MISC_OTHER setting to deny anonymous logins (-E),
chroot everyone (-A), prevent users from reading or writing to files
beginning with a . (dot) (-X), max idle time (-I), limit recursion
(-L), and a reasonable umask.
Do not use the -w or -W options! If you want to have a
warez site, stop reading this guide!
One can find documentation at http://www.pureftpd.org.
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.
Code Listing 8.1: /etc/vsftpd
#enable logging of transfers
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 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 emerge netqmail and go
Samba is a protocol to share files with Microsoft/Novell networks and it
should not be used over the Internet. Nonetheless, it still needs
Code Listing 10.1: /etc/samba/smb.conf
#Bind to an interface
interfaces = eth0 10.0.0.1/32
#Make sure to use encrypted password
encrypt passwords = yes
directory security mask = 0700
#allow traffic from 10.0.0.*
hosts allow = 10.0.0.
#Enables user authentication
#(don't use the share mode)
security = user
#Disallow privileged accounts
invalid users = root @wheel
#Maximum size smb shows for a share (not a limit)
max disk size = 102400
#Uphold the password policy
min password length = 8
null passwords = no
#Use PAM (if added support)
obey pam restrictions = yes
pam password change = yes
Make sure that permissions are set correct on every share and remember to read
Now restart the server and add the users who should have access to this
service. This is done though the command /usr/bin/smbpasswd with
the parameter -a.
The only securing that OpenSSH needs is turning on a stronger authentication
based on public key encryption. Too many sites (like
http://www.sourceforge.net, http://www.php.net and
http://www.apache.org) have suffered unauthorized intrusion
due to password leaks or bad passwords.
Code Listing 11.1: /etc/ssh/sshd_config
#Only enable version 2
#Disable root login. Users have to su to root
#Turn on Public key authentication
#Disable .rhost and normal password authentication
#Only allow userin the wheel or admin group to login
AllowGroups wheel admin
#In those groups only allow the following users
#The @<domainname> is optional but replaces the
#older AllowHosts directive
AllowUsers email@example.com firstname.lastname@example.org
Also verify that you don't have UsePAM yes 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
Now all that your users have to do is create a key (on the machine
they want to login from) with the following command:
Code Listing 11.2: Create a DSA keypair
# /usr/bin/ssh-keygen -t dsa
And type in a pass phrase.
Code Listing 11.3: Output of ssh-keygen
Generating public/private dsa key pair.
Enter file in which to save the key (/home/kn/.ssh/id_dsa):[Press enter]
Created directory '/home/kn/.ssh'.
Enter passphrase (empty for no passphrase): [Enter passphrase]
Enter same passphrase again: [Enter passphrase again]
Your identification has been saved in /home/kn/.ssh/id_dsa.
Your public key has been saved in /home/kn/.ssh/id_dsa.pub.
The key fingerprint is:
This will add two files in your ~/.ssh/ directory called
id_dsa and id_dsa.pub. The file called
id_dsa is your private key and should be kept from other people
than yourself. The other file id_dsa.pub is to be distributed to
every server that you have access to. Add the key to the users home directory
in ~/.ssh/authorized_keys and the user should be able to login:
Code Listing 11.4: Adding the id_dsa.pub file to the authorized_keys file
$ scp id_dsa.pub other-host:/var/tmp/currenthostname.pub
$ ssh other-host
$ cat /var/tmp/currenthostname.pub >> ~/.ssh/authorized_keys
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.
10.l. Using xinetd
xinetd is a replacement for inetd (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 xinetd 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:
Code Listing 12.1: Install xinetd
# emerge xinetd tcp-wrappers
And edit the configuration file:
Code Listing 12.2: /etc/xinetd.conf
only_from = localhost
instances = 10
log_type = SYSLOG authpriv info
log_on_success = HOST PID
log_on_failure = HOST
cps = 25 30
# This will setup pserver (cvs) via xinetd with the following settings:
# max 10 instances (10 connections at a time)
# limit the pserver to tcp only
# use the user cvs to run this service
# bind the interfaces to only 1 ip
# allow access from 10.0.0.*
# limit the time developers can use cvs from 8am to 5pm
# use tpcd wrappers (access control controlled in
# /etc/hosts.allow and /etc/hosts.deny)
# max_load on the machine set to 1.0
# The disable flag is per default set to no but I like having
# it in case of it should be disabled
socket_type = stream
protocol = tcp
instances = 10
protocol = tcp
wait = no
user = cvs
bind = 10.0.0.2
only_from = 10.0.0.0
access_times = 8:00-17:00
server = /usr/sbin/tcpd
server_args = /usr/bin/cvs --allow-root=/mnt/cvsdisk/cvsroot pserver
max_load = 1.0
log_on_failure += RECORD
disable = no
For more information read man 5 xinetd.conf.
By default Xorg is configured to act as an Xserver. This can be dangerous since
X uses unencrypted TCP connections and listens for xclients.
If you do not need this service disable it!
But if you depend on using your workstation as a Xserver use the
/usr/X11R6/bin/xhost 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 /usr/X11R6/bin/xhost +hostname
Do not ever use the xhost + feature! This will allow any client to
connect and take control of your X. If an attacker can get access to your X,
he can log your keystrokes and take control over your desktop. If you have to
use it always remember to specify a host.
A more secure solution is to disable this feature completely by starting X with
startx -- -nolisten tcp or disable it permanently in the configuration.
Code Listing 13.1: /usr/X11R6/bin/startx
To make sure that startx does not get overwritten when emerging a
new version of Xorg you must protect it. Add the following line to
Code Listing 13.2: /etc/make.conf
If you use a graphical login manager you need a different approach.
For gdm (Gnome Display Manager)
Code Listing 13.3: /etc/X11/gdm/gdm.conf
command=/usr/X11R6/bin/X -nolisten tcp
For xdm (X Display Manager) and kdm (Kde Display Manager)
Code Listing 13.4: /etc/X11/xdm/Xservers
:0 local /usr/bin/X11/X -nolisten tcp
[ << ]
[ < ]
[ Home ]
[ > ]
[ >> ]
The contents of this document, unless otherwise expressly stated, are licensed under the CC-BY-SA-2.5 license. The Gentoo Name and Logo Usage Guidelines apply.