Product SiteDocumentation Site

Capítulo 5. Asegurando los servicios que se ejecutan en su sistema

5.1. Asegurando ssh
5.1.1. Chrooting ssh
5.1.2. Ssh clients
5.1.3. Disallowing file transfers
5.1.4. Restricing access to file transfer only
5.2. Asegurando Squid
5.3. Asegurando FTP
5.4. Asegurando el acceso al sistema X Window
5.4.1. Revisar su administrador visual
5.5. Seguridad en el acceso de impresión (El asunto de lpd y lprng)
5.6. Reforzando el servidor de correo
5.6.1. Configuring a Nullmailer
5.6.2. Providing secure access to mailboxes
5.6.3. Recibiendo Correo de forma segura
5.7. Asegurando BIND
5.7.1. Bind configuration to avoid misuse
5.7.2. Changing BIND's user
5.7.3. Chrooting the name server
5.8. Asegurando Apache
5.8.1. Disabling users from publishing web contents
5.8.2. Permisos para el archivo de registro
5.8.3. Published web files
5.9. Asegurando finger
5.10. Cambio general de directorio raíz y paranoia suid
5.10.1. Making chrooted environments automatically
5.11. Texto claro general con el password paranoia
5.12. Incapacitar NIS
5.13. Securing RPC services
5.13.1. Desactivar los servicios RPC
5.13.2. Limites al acceso de servicios RPC
5.14. Añadir capacidades al cortafuegos
5.14.1. El sistema local corta fuegos
5.14.2. Usar otros corta fuegos para proteger otros sistemas
5.14.3. Configurando un cortafuegos
Los servicios que corren en su sistema pueden ser asegurados de dos maneras:
  • Haciéndolos accequibles dentro de los puntos (interfaces) en los que tienen que estar.
  • Configurándolos de una manera apropiada para que puedan ser debidamente usados por los usuarios legítimos de una manera autorizada.
Restringir los servicios de modo que solamente puedan ser accedidos desde un lugar dado puede ser hecho restringiendo el acceso al nivel del kernel (i.e. cortafuego), configúrelos sólo para escuchar en un interfaz dada (algunos servicios no pueden suministrar ésta característica) o usando otros métodos, por ejemplo el parche linux vserver (para 2.4.16) puede ser usado para forzar procesos de forma que usen solo una interfaz.
Regarding the services running from inetd (telnet, ftp, finger, pop3...) it is worth noting that inetd can be configured so that services only listen on a given interface (using service@ip syntax) but that's an undocumented feature. One of its substitutes, the xinetd meta-daemon includes a bind option just for this matter. See ixnetd.conf(5) manual page.
service nntp
{
 socket_type = stream
 protocol = tcp
 wait = no
 user = news
 group = news
 server = /usr/bin/env
 server_args = POSTING_OK=1 PATH=/usr/sbin/:/usr/bin:/sbin/:/bin
+/usr/sbin/snntpd logger -p news.info
 bind = 127.0.0.1
}
Laa siguientes secciones detallan como cada servicio determinado puede ser configurado debidamente dependiendo de los usos que se quieran dar.

5.1. Asegurando ssh

Si aún está usando telnet en vez de ssh, debe detener la lectura de este manual y cambiar esto. Ssh debería ser usado para todas las entradas remotas en vez de telnet. En una época donde es fácil husmear el tráfico de internet y obtener contraseñas en texto plano, debe usar sólo protocólos que usen criptografía. De una vez, ejecute un apt-get install ssh en su sistema.
Anime a todos los usuarios de su sistema para usar ssh en vez de telnet, o mejor aún, desinstale telnet/telnetd. Además, debe evitar las entradas al sistema usando ssh como root y use métodos alternativos en vez de root, como su o sudo. Finalmente, el archivo sshd_config, dentro de /etc/ssh, debe ser modificado para aumentar la seguridad así:
  • Haga que ssh escuche solo la interfaz dada, sólo en un caso de que haya más de uno (y no necesite un ssh disponible sobre éste) o que en un futuro agrege una nueva tarjeta de red (y no necesite una conexión desde ssh en ésta).
  • Intente no permitir al Root entrar tanto como sea posible. Si alguien quiere volverse root por vía ssh, dos logins serán necesarios y la contraseña root no puede ser obtenida a fuerza bruta por vía SSH.
  • Port 666 or ListenAddress 192.168.0.1:666 Change the listen port, so the intruder cannot be completely sure whether a sshd daemon runs (be forewarned, this is security by obscurity).
  • PermitEmptyPasswords no Empty passwords make a mockery of system security.
  • AllowUsers alex ref me@somewhere Allow only certain users to have access via ssh to this machine. user@host can also be used to restrict a given user from accessing only at a given host.
  • Permita que solamente los miembros de ciertos grupos tengan acceso vía a ssh a esta máquina. AllowGroups y AllowUsers tienen directivas equivalentes para denegar el acceso a una máquina. Predeciblemente se llaman "DenyUsers" y "DenyGroups".
  • Queda completamente a su elección lo que usted quiera hacer. Es más seguro permitir el acceso a la máquina solamente a usuarios con llaves ssh en el archivo ~/.ssh/authorized_keys. Si es lo que quiere déle el valor "no".
  • Disable any form of authentication you do not really need, if you do not use, for example RhostsRSAAuthentication, HostbasedAuthentication, KerberosAuthentication or RhostsAuthentication you should disable them, even if they are already by default (see the manpage sshd_config(5) manual page).
  • Protocol 2 Disable the protocol version 1, since it has some design flaws that make it easier to crack passwords. For more information read http://earthops.net/ssh-timing.pdf or the http://xforce.iss.net/static/6449.php.
  • Banner /etc/some_file Add a banner (it will be retrieved from the file) to users connecting to the ssh server. In some countries sending a warning before access to a given system about unauthorized access or user monitoring should be added to have legal protection.
You can also restrict access to the ssh server using pam_listfile or pam_wheel in the PAM control file. For example, you could keep anyone not listed in /etc/loginusers away by adding this line to /etc/pam.d/ssh:
auth       required     pam_listfile.so sense=allow onerr=fail item=user file=/etc/loginusers
Como nota final, dese cuenta que estas directivas son de los archivos de la configuración de OpenSSH. Ahora mismo hay tres demonios SSH usadados habitualmente, ssh1, ssh2, y el OpenSSH de la gente de OpenBSD. Ssh1 fue el primer domonio ssh diaponible y aún es el más comunmente usado (hay rumores de que existe incluso un porte a windows). Ssh2 tiene muchas ventajas sobre ssh1, pero se distribuye con una licencia mixta de código abierto-cerrado. OpenSSH es un demonio completamente libre que soporta tanto ssh1 como ssh2. La versión instalada en Debian cuando se escoge el paquete 'ssh' es OpenSSH.
You can read more information on how to set up SSH with PAM support in the http://lists.debian.org/debian-security/2001/11/msg00395.html.

5.1.1. Chrooting ssh

Currently OpenSSH does not provide a way to chroot automatically users upon connection (the commercial version does provide this functionality). However there is a project to provide this functionality for OpenSSH too, see http://chrootssh.sourceforge.net, it is not currently packaged for Debian, though. You could use, however, the pam_chroot module as described in Sección 4.11.15, “Restringiendo usuarios”.
In Sección B.7, “Chroot environment for SSH you can find several options to make a chroot environment for SSH.

5.1.2. Ssh clients

If you are using an SSH client against the SSH server you must make sure that it supports the same protocols that are enforced on the server. For example, if you use the mindterm package, it only supports protocol version 1. However, the sshd server is, by default, configured to only accept version 2 (for security reasons).

5.1.3. Disallowing file transfers

If you do not want users to transfer files to and from the ssh server you need to restrict access to the sftp-serverand the scp access. You can restrict sftp-server by configuring the proper Subsystem in the /etc/ssh/sshd_config.
You can also chroot users (using libpam-chroot so that, even if file transfer is allowed, they are limited to an environment which does not include any system files.

5.1.4. Restricing access to file transfer only

You might want to restrict access to users so that they can only do file transfers and cannot have interactive shells. In order to do this you can either:
  • disallow users from login to the ssh server (as described above either through the configuration file or PAM configuration).
  • give users a restricted shell such as scponly or rssh. These shells restrict the commands available to the users so that they are not provided any remote execution priviledges.