1.  Apache

Apache viene con un más que decente fichero de configuración pero todavía necesitamos mejorar algunas cosas, como enlazar Apache a una dirección y prevenir fugas de información. A continuación se describen las opciones que debería aplicar en el fichero de configuración:

Si usted no deshabilita ssl en su /etc/make.conf antes de instalar Apache, debería tener habilitado el acceso al servidor mediante ssl. Dentro de /etc/apache2/vhosts.d podemos encontrar archivos con ejemplos de configuración. Estos son ejemplos funcionales y es mejor verificarlos o deshabilitarlos.

Es importante definir en el archivo de configuració que se escuche a una dirección IP en particular (en vez de todas las direcciones IP de su sistema). Por ejemplo, en el archivo 00_default_vhost.conf:

# Make it listen on your ip
Listen 127.0.0.1

También recomendamos que deshabilite el despliegue de información sobre la instalación Apache al resto del mundo. Por defecto, la configuración agregará la versión del servidor y nombre del anfitrión virtual a las páginas generadas por el servidor. Para desactivar esta característica, cambie la variable ServerSignature a Off:

ServerSignature Off

Apache está compilado con --enable-shared=max y --enable-module=all. Esto activará por defecto todos los módulos, así que puede "comentar" todos los módulos en la sección LoadModule (LoadModule y AddModule) que no use en el archivo principal de configuración /etc/apache2/httpd.conf. Reinicie el servicio ejecutando /etc/init.d/apache restart.

Puede encontrar más información en http://www.apache.org.

1.  Bind

Puede encontrar información en Internet Software Consortium. El Manual de referencia del administrador en BIND 9 lo puede encontrar también en doc/arm.

Los nuevos "ebuilds" de BIND soportan el chrooting fuera del entorno. Después de instalar (emerge) bind siga estos sencillos pasos:

# emerge --config bind
(Antes de ejecutar el comando anterior debe tratar de cambiar)
(el directorio de chroot en /etc/conf.d/named.)
(En caso contrario será usado /chroot/dns.)

1.  Djbdns

Djbdns es una implementación de DNS en cuya seguridad su autor está dispuesto a apostar dinero. Trabaja de forma muy diferente a Bind 9 pero vale la pena probarlo. Puede obtener más información en http://www.djbdns.org.

1.  FTP

Generalmente, usar FTP (File Transfer Protocol) es una mala idea. Porque no cifra los datos (por ejemplo, las contraseñas circulan en texto claro), escucha en dos puertos (normalmente el 20 y el 21), y los atacantes buscan frecuentemente accesos anónimos para intercambiar warez. Puesto que protocolo FTP tiene varios problemas de seguridad, debería utilizar en su lugar sftp o HTTP . Si no lo hace, asegure tan bien como pueda sus servicios y prepárese.

1.  Mysql

Si sólo necesita que las aplicaciones locales accedan a la base de datos mysql "descomente" la siguiente línea en /etc/mysql/my.cnf.

skip-networking

Luego, deshabilitemos el uso del comando LOAD DATA LOCAL INFILE.Lo que nos prevendrá contra la lectura no autorizada de ficheros locales. Esto toma relevancia cuando se encuentran nuevas vulnerabilidades de Inyección SQL en PHP.

set-variable=local-infile=0

A continuación, vamos a borrar la base de datos de ejemplo (test) y todas las cuentas excepto la cuenta local de root.

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;

1.  Proftpd

Proftpd ha tenido bastantes problemas de seguridad, pero parece que se han resuelto muchos de ellos. Aún así, es buena idea aplicar algunas mejoras:

ServerName "My ftp daemon"
# No muestre la identidad del servidor
ServerIdent on "Go away"

# Hace más fácil crear usuarios virtuales
RequireValidShell off

# Use unos ficheros de contraseñas y grupos alternativos (passwd usa cifrado)
AuthUserFile "/etc/proftpd/passwd"
AuthGroupFile "/etc/proftpd/group"

# Permisos
Umask 077

# Timeouts y limitaciones
MaxInstances 30
MaxClients 10 "Only 10 connections allowed"
MaxClientsPerHost 1 "You have already logged on once"
MaxClientsPerUser 1 "You have already logged on once"
TimeoutStalled 10
TimeoutNoTransfer 20
TimeoutLogin 20

# Chroot todo el mundo
DefaultRoot ~

# No lo ejecute como root
User  nobody
Group nogroup

# Registre cada transacción
TransferLog /var/log/transferlog

# Problemas con globbing
DenyFilter \*.*/

Puede encontrar más documentación en http://www.proftpd.org.

1.  Pure-ftpd

Pure-ftpd es una variante del trollftpd original, modificado por Frank Dennis por razones de seguridad y funcionalidad.

Utilice usuarios virtuales (nunca cuentas del sistema) habilitando la opción AUTH. Configure esto con -lpuredb:/etc/pureftpd.pdb y cree sus usuarios mediante /usr/bin/pure-pw.

AUTH="-lpuredb:/etc/pureftpd.pdb"

## Misc. Others ##
MISC_OTHER="-A -E -X -U 177:077 -d -4 -L100:5 -I 15"

Configure la opción MISC_OTHER para no permitir accesos anónimos (-E), hacer chroot para todos (-A), para que los usuarios no puedan leer o escribir en los archivos que empiezan por . (punto) (-X), el tiempo máximo 'idle' (-I), el límite de recursión (-L), y una razonable umask.

Puede encontrar más documentación en http://www.pureftpd.org.

1.  Vsftpd

Vsftpd (siglas de "very secure ftp", ftp realmente seguro) es un pequeño demonio ftp que se ejecuta con una razonable configuración por defecto. Es sencillo y no tiene algunas de las características de pureftp o proftp.

anonymous_enable=NO
local_enable=YES

#sólo escritura
write_enable=NO

#permite el registro de transacciones
xferlog_std_format=YES

idle_session_timeout=20
data_connection_timeout=20
nopriv_user=nobody

chroot_list_enable=YES
chroot_list_file=/etc/vsftpd/chrootlist

ls_recurse_enable=NO

Como puede ver, no hay forma en este servicio de tener permisos individuales, pero cuando se prepara con una configuración anónima es bastante bueno. Algunas veces es bueno tener un ftp anónimo (para compartir programas de código abierto) y entonces vsftpd hace muy buen papel.

1.  Netqmail

Netqmail está frecuentemente considerado como un servidor de correo muy seguro. Está escrito pensando en la seguridad (y en la paranoia). Por defecto no permite el reenvío y no ha tenido un sólo agujero de seguridad desde 1996. ¡Simplemente instálelo con emerge netqmail y configúrelo!

1.  Samba

Samba es un protocolo para compartir ficheros con redes Microsoft y Novell y no debería usarse a través de Internet. Aún así, continua necesitando ser asegurado.

[global]
  #Enlace a una interface
  interfaces = eth0 10.0.0.1/32

  #Indica el uso de contraseñas cifradas
  encrypt passwords = yes
  directory security mask = 0700

  #Permite el tráfico desde 10.0.0.*
  hosts allow = 10.0.0.

  #Habilita el modo de autentificación por usuario
  #(no use el modo compartido)
  security = user

  #Deshabilita las cuentas con privilegios
  invalid users = root @wheel

  #Tamaño máximo que smb muestra para un recurso compartido
  #(no es un límite)
  max disk size = 102400

  #Política de contraseñas
  min password length = 8
  null passwords = no

  #Uso de PAM (si se ha añadido su soporte)
  obey pam restrictions = yes
  pam password change = yes

Asegúrese que los permisos están correctamente establecidos en cada recurso compartido y recuerde leer la documentación.

Ahora reinicie el servidor y añada los usuarios que deban tener acceso a este servicio. Esto se hace mediante el comando /usr/bin/smbpasswd con el parámetro -a.

1.  ssh

La única seguridad que OpenSSH necesita es habilitar la autentificación fuerte basada en cifrado de clave pública. Demasiados sitios (como http://www.sourceforge.net, http://www.php.net yhttp://www.apache.org) han sufrido accesos no autorizados debidos a filtraciones de contraseñas o a malas contraseñas.

#Sólo habilitar la versión 2
Protocol 2

#No permitir el acceso directo a root
PermitRootLogin no

#Habilitar la autentificación de clave pública
PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys

#Deshabilitar los ficheros .rhost y la autentificación normal con contraseña
HostbasedAuthentication no
PasswordAuthentication no
PermitEmptyPasswords no

#Sólo los usuarios en los grupos wheel o admin pueden obtener acceso
AllowGroups wheel admin

#En dichos grupos sólo permite el acceso de los siguienes usuarios
#El @<nombre_de_dominio> es opcional, pero reemplaza la
#anterior directiva AllowHosts
AllowUsers kn@gentoo.org bs@gentoo.org

#Añadir registro de actividad
SyslogFacility AUTH
LogLevel INFO

(Cambie esto con su dirección)
ListenAddress 127.0.0.1

Verifique también que no tiene UsePAM yes en su fichero de configuración porque sobreescribe el mecanismo de autentificación de clave pública, o sino desactive PasswordAuthentication o ChallengeResponseAuthentication. Más información acerca de estas opciones puede encontrarse en la página man de sshd_config.

Ahora todo lo que sus usuarios tienen que hacer es crear una clave (en el ordenador desde el que se van a conectar) usando el comando siguiente:

# /usr/bin/ssh-keygen -t dsa

Y teclear una contraseña-frase (passphrase).

Generating public/private dsa key pair.
Enter file in which to save the key (/home/kn/.ssh/id_dsa):[Pulse enter]
Created directory '/home/kn/.ssh'.
Enter passphrase (empty for no passphrase): [Escriba la frase de paso]
Enter same passphrase again: [Vuelva a escribir la frase de paso]
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:
07:24:a9:12:7f:83:7e:af:b8:1f:89:a3:48:29:e2:a4 kn@knielsen

Esto añadirá dos archivos a su directorio ~/.ssh/, llamados id_dsa y id_dsa.pub. El archivo id_dsa es su clave privada y debe ser accesible sólo por usted. El otro fichero id_dsa.pub debe ser distribuido en cada servidor al cual tenga acceso. Añada la clave en el directorio home del usuario en ~/.ssh/authorized_keys y el usuario debería ser capaz de hacer login:

$ scp id_dsa.pub other-host:/var/tmp/currenthostname.pub
$ ssh other-host
password:
$ cat /var/tmp/currenthostname.pub >> ~/.ssh/authorized_keys
 

Ahora, sus usuarios deberían salvaguardar su clave privada convenientemente. Poniéndola en un dispositivo que ellos lleven siempre encima o dejarla en su estación de trabajo (añada esto a las políticas de (Contraseñas)).

Para más información visite la página web de OpenSSH.

1.  Uso de xinetd

xinetd es un sustituto de inetd (del cual no dispone Gentoo), el demonio de servicios de Internet. Soporta control de acceso basado en la dirección del host remoto y el tiempo de acceso. También proporciona extensas posibilidades de log, incluyendo una hora de arranque del servidor, dirección de host remoto, nombre de usuario remoto, tiempo de ejecución del servidor, y acciones solicitadas.

Como en todos los demás servicios es importante tener una buena configuración por defecto. Pero desde el momento que xinetd se ejecuta como root y soporta protocolos que puede que usted no conozca como funcionan, le recomendamos que no lo utilice. Pero si a pesar de todo lo quiere utilizar, aquí le explicamos como puede añadirle algo de seguridad:

# emerge xinetd tcp-wrappers

Y edite el fichero de configuración:

defaults
{
 only_from      = localhost
 instances      = 10
 log_type       = SYSLOG authpriv info
 log_on_success = HOST PID
 log_on_failure = HOST
 cps    = 25 30
}

# Esto configurará pserver (cvs) via xinetd con los siguientes parámetros:
# un máximo de 10 instancias (10 conexiones simultáneas)
# limita pserver a conexiones tcp solamente
# utiliza el usuario cvs para ejecutar este servicio
# enlaza una sola dirección IP en las interfaces de red
# permite el acceso desde 10.0.0.*
# limita el tiempo que los desarrolladores pueden usar cvs: desde 8am a 5pm
# usa tcpd wrappers (control de acceso especificado en
# /etc/hosts.allow y /etc/hosts.deny)
# la carga máxima del sistema se establece a 1.0
# el disable flag está a no por defecto, pero preferimos tenerlo
# en caso de querer desactivarlo
service cvspserver
{
 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
}

Para más información consulte man 5 xinetd.conf.

1.  X

Por defecto Xorg está configurado para actuar como un servidor X. Esto puede resultar peligroso puesto que X usa conexiones TCP no cifradas y está a la escucha para clientes X.

Pero si piensa usar su estación de trabajo como servidor X use el comando /usr/X11R6/bin/xhost con precaución. Este comando permite a clientes desde otros hosts conectarse y usar su pantalla. Lo que puede ser práctico si usted necesita una aplicación X de un equipo diferente y la única manera de utilizarla es a través de la red, pero lo que también puede permitir ser aprovechado por un atacante. La sintaxis es /usr/X11R6/bin/xhost +nombre_de_host

Un solución más segura es deshabilitar completamente esta característica arrancando X con startx -- -nolisten tcp o deshabilitándola permanentemente en la configuración.

defaultserverargs="-nolisten tcp"

Para asegurarse de que startx no será sobreescrito al 'emerger' una nueva versión de Xorg debe protegerlo. Añada la siguiente línea a /etc/make.conf:

CONFIG_PROTECT_MASK="/usr/X11R6/bin/startx"

Si usted usa un gestor gráfico de login necesitará cambiar otros archivos.

Para gdm (Gnome Display Manager):

[server-Standard]
command=/usr/X11R6/bin/X -nolisten tcp

Para xdm (X Display Manager) y kdm (Kde Display Manager):

:0 local /usr/bin/X11/X -nolisten tcp