[ anterior ] [ Contenidos ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ siguiente ]

COMO-Asegurar-Debian
Capítulo 4 - Asegurar los servicios que corren en su sistema


4.1 Asegurar ssh

Si todavía usa telnet en vez de ssh, debería dejar descansar este manual y hacer este cambio. Ssh se debería usar para logins remotos en vez de telnet. En una época en la que es fácil husmear el tráfico en internet y obtener contraseñas en claro, debería utilizar solamente protocolos que hagan uso de cifrado. Así que realize un apt-get install ssh en su sistema ahora mismo. Apremie a todos los usuarios del sistema a utilizar ssh en vez de telnet, o mejor incluso, desinstale telnet. Además debería evitar entrar al sistema utilizanso ssh como root y utilizar métodos alternativos de convertirse en root, como su o sudo. Finalmente, también debería modificarse el fichero de configuración de ssh, /etc/ssh/ssh_config, para incrementar la seguridad: PermitRootLogin No. Intente no permitir Root Login siempre que sea posible. Si alguien quiere convertirse en root vía ssh, ahora se necesitarán dos login y la contraseña de root no podrá obtenerse usando fuerza bruta vía SSH. Listen 666 Cambie el puerto de escucha de manera que el intruso no pueda estar completamente seguro de si está corriendo un demonio sshd. PermitEmptyPasswords no Las contraseñas en blanco convierten en broma la seguridad de un sistema. AllowUsers alex ref Permita que solamente ciertos usuarios tengan acceso vía ssh a esta máquina. AllowGroups wheel admin Permita que solamente los miembros de ciertos grupos tengan acceso vía ssh a esta máquina. AllowGroups y Allow Users tienen directivas equivalentes para denegar el acceso a una máquina. Predeciblemente, se llaman "DenyUsers" y "DenyGroups". PasswordAuthentication yes 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 claves ssh en el fichero ~/.ssh/authorized_keys. Si así lo quiere, déle el valor "no". Como nota final, asegúrese que estas directivas son de un fichero de configuración de OpenSSH. Ahora mismo hay tres demonios SSH usados habitualmente, ssh1, ssh2 y el OpenSSH de la gente de OpenBSD. Ssh1 fue el primer demonio ssh y sigue siendo el más usado (hay rumores de que existe incluso un port a windows). Ssh2 tiene muchas ventajas sobre ssh1, pero no se distribuye con una licencia de código abierto. OpenSSH es un demonio complétamente libre que soporta tanto ssh1 como ssh2. La versión instalada en Debian cuando se escoge el paquete 'ssh' es OpenSSH.


4.2 Dése cuenta de la inseguridad de X en red

Hoy día más y más empresas usan las terminales-X cuando necesitan un servidor para muchas estaciones de trabajo. Ésto puede ser peligroso, porque necesita permitir que un servidor de ficheros conecte con los clientes (el servidor X, desde el punto de vista de X. X intercambia la definición de cliente y servidor). Si sigue la (muy mala) sugerencia de muchos documentos, teclea xhost + en su máquina. Esto permite conectar con su sistema a cualquier cliente X. Para tener una seguridad ligeramente mejor, puede usar la orden xhost +hostname en vez de la anterior para permitir accesos desde hosts específicos. Una solución mucho más segura es usar ssh para hacer de túnel para X y cifrar la sesión completa. Ésto se hace automáticamente cuando se hace ssh a otra máquina. Por supuesto, incluso ésto se puede desabilitar en el fichero /etc/ssh/ssh_config. Para una mejor seguridad, si no necesita acceso a X desde otras máquinas, desabilite el enlace con tcp puerto 6000 tecleando simplemente: startx -- -nolisten tcp


4.3 El asunto lpd y lprng

Imagine que llega al trabajo y la impresora está escupiendo montones sin fin de papeles porque alguien esta provocando Denegación de Servicio en su demonio de impresión en línea. Desagradable, ¿verdad? Así que mantenga los servidores de impresión especialmente seguros. ARRÉGLAME. Content missing (sin experiencia en lpr)


4.4 Usar el correo con seguridad

La lectura/escritura de correo es el protocolo más común de transmisión de datos en claro. Si usa POP3 o IMAP para obtener su correo manda su contraseña en claro a lo largo y ancho de la red, así que cualquiera puede leer su correo a partir de ahora. En su lugar, use SSL (Secure Socket Layer, Capa de Socket Segura) para recibir su correo. La otra alternativa es ssh, si tiene una cuenta shell en su máquina. Aquí tiene un fetchmailrc básico:

     poll my-imap-mailserver.org via "localhost"
       with proto IMAP port 1236
           user "ref" there with password "hackme" is alex here warnings 3600
         folders
           .Mail/debian
         preconnect 'ssh -f -P -C -L 1236:my-imap-mailserver.org:143 -l ref
          my-imap-mailserver.org sleep 15 </dev/null > /dev/null'

La línea importante es la de preconnect. Lanza una sesión ssh y crea el túnel necesario, que reenvía conexiones al puerto 1236 del servidor imap, pero cifradas. Otra posibilidad sería usar fetchmail con la característica ssl.

Si quiere dar servicios de correo electrónico cifrado como POP e IMAP, haga apt-get install stunnel e inicie sus demónios de esta manera: stunnel -p /etc/ssl/certs/stunnel.pem -d pop3s -l /usr/sbin/popd Esta orden envuelve el demonio (-l) al puerto (-d) y usa el cert ssl especificado (-p).


4.5 Asegurar BIND

En una instalación Debian estándar, el demonio de servicio de nombres, BIND, se ejecuta como usuario root y como grupo root. Es bastante fácil hacer correr BIND bajo otra identidad (UID). Sin embargo, si otro usuario que no sea root hace correr BIND, éste no puede detectar nuevas interfaces automáticamente. Por ejemplo, si pone una tarjeta PCMCIA en su portátil. Compruebe el fichero README.Debian en su directorio de documentación de named para más información. Recientemente ha habido muchos problemas de seguridad con respecto a BIND, de modo que cambiar el usuario es útil siempre que sea posible.

Para hacer correr BIND bajo un usuario diferente, en primer lugar cree un usuario y un grupo separados para él (no es una buena idea usar nobody o nogroup para cada servicio que no se hace correr bajo root). En este ejemplo, se van a usar el usuario y el grupo 'named'. Puede conseguirlo haciendo lo siguiente:

     # addgroup named
     # adduser --system --ingroup named named

Ahora modifique /etc/init.d/bind con su editor favorito y cambie la línea que empieza por

start-stop-daemon --start por start-stop-daemon --start --quiet --exec /usr/sbin/named -- -g named -u named

Todo lo que necesita hacer ahora es reiniciar bind vía /etc/init.d/bind restart, y después comprobar que en su syslog aparecen dos entradas como estas:

     Sep  4 15:11:08 nexus named[13439]: group = named
     Sep  4 15:11:08 nexus named[13439]: user = named

¡Voilà! Su named no corre ahora como root. Para conseguir la máxima seguridad en BIND, construya una jaula chroot (vea 3.13) sobre su demonio. #No estoy seguro acerca de esto: ¿no se debería cambiar de #propietario.grupo (chown) a los ficheros de bind a los grupos #creados. Se debería especificar ésto. jfs


[ anterior ] [ Contenidos ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ siguiente ]

COMO-Asegurar-Debian

v1.1 27 april 2002Thu, 7 Dec 2000 19:10:13 +0100
Alexander Reelsen. Traducción: Antonio Álvarez Platero ar@rhwd.net (Alexander Reelsen)