Limitar los accesos remotos

En primer lugar, vamos a impedir el acceso a aquellas m´aquinas que son cr´ıticas para el correcto funcionamiento del Laboratorio. Principalmente, los servidores, tanto del campus de M´ostoles como el de Fuenlabrada. Aunque tambi´en, ser´a necesario limitar las conexiones en los servidores LDAP para que solamente sea posible que se conecten a ellos estaciones de los Laboratorios.

Limitar el acceso SSH mediante los ficheros hosts.allow y hosts.deny

Para limitar el acceso SSH a los servidores, vamos a restringir la conectividad a redes pertenecientes o bien al Departamento de Sistemas Telem´aticos o al Laboratorio. Esto es, a m´aquinas pertenecientes a la subredes 212.128.4.0/24, 193.147.71.0/24 para el Campus de M´ostoles, y 193.147.73.0/24 junto con la subred 193.147.71.0/24 para el Campus de Fuenlabrada. De esta forma, aseguramos que nadie pueda iniciar una sesi´on SSH en ning´un servidor si no lo hace desde dentro de alguna de nuestras redes. Esta norma se aplicar´a a todos los servidores excepto al servidor pantuflo y al servidor bilo, en los que se puede iniciar una sesi´on SSH en principio desde cualquier host.

Para poder llevar a cabo esta restricci´on, haremos uso de los ficheros /etc/hosts.deny y /etc/hosts.allow. En concreto, en el fichero /etc/hosts.deny, debemos indicar que por defecto se deniegue cualquier conexi´on SSH a no ser que alguna regla lo permita (descrita en el fichero /etc/hosts.allow. Por tanto, el fichero /etc/hosts.deny debe contener lo siguiente:

sshd : ALL

34

http://bilo.cct.urjc.es

4.5. SEGURIDAD

De esta forma estamos indicando que el servicio SSH ser´a denegado a cualquier host, a no ser que el fichero /etc/hosts.allow diga lo contrario. Y es aqu´ı donde este fichero entra en juego:

sshd : 212.128.4. , 193.147.71. , 1 9 3 . 1 4 7 . 7 3 .

Como vemos, es posible indicar mediante los tres primeros d´ıgitos de la IP desde que subredes s´ı se admitir´a usar el servicio SSH. De esta forma, no podremos abrir una conexi´on SSH desde fuera de estas tres subredes, lo que a priori, reducir´a considerablemente la probabilidad de que alguien ajeno a los laboratorios o al departamento intente nada contra estas m´aquinas. Si intentamos conectarnos a cualquiera de los servidores que incluyan estas restricciones, obtendremos el siguiente error:

s s h _ e x c h a n g e _ i d e n t i f i c a t i o n : C o n n e c t i o n closed by remot e host

Limitar el acceso SSH mediante clave p´ublica/privada

Si queremos aumentar a´un m´as el grado de seguridad a la hora de inicar una sesi´on SSH en cualquiera de los servidores, podemos desactivar el inicio de sesi´on mediante desaf´ıo pregunta/respuesta (el tradicional acceso introduciendo una contrase˜na), y activar la autenticaci´on ´unicamente usando mecanismos de criptograf´ıa de clave p´ublica/privada. De esta forma, ser´a necesario generar un par de claves, copiar la clave p´ublica del host desde el que queremos conectar al servidor en cuesti´on y a˜nadirlo en el fichero authorized keys del directorio /root/.ssh/. De esta forma, solamente podr´an inciar sesi´on en el servidor aquellos usuarios que posean la clave privada y la palabra de paso que la desbloquea (en caso de que haya sido generada con contrase˜na). Adem´as, en caso de perder la clave privada, no tendr´ıamos por qu´e preocuparnos (demasiado) debido a que sin la palabra de paso, es una clave totalmente in´util. Por tanto, para poder iniciar sesi´on en cualquiera de los servidores, necesitaremos cumplir estrictamente estos dos requisitos:

Poseer una IP perteneciente a la red del Laboratorio o del Departamento

Poseer la clave privada incluida como autorizada en el servidor al que nos queremos conectar (y adem´as saber la palabra de paso que desbloquea la clave)

Como vemos, son dos requisitos suficientemente restrictivos que nos proporcionan bastante tranquilidad en la seguridad del servidor y disminuyen bastante la probabilidad de intrusi´on en la m´aquina.

Impedir la conexi´on a los servidores LDAP desde fuera de los Laboratorios

Los servidores LDAP, si nada lo impide, permiten que cualquier m´aquina pueda realizar peticiones de lectura sin emplear ning´un mecanismo de autenticaci´on previo. Debido a la arquitectura de LDAP como mecanismo de autenticaci´on, es necesario que de forma an´onima, un usuario pueda realizar peticiones de lectura de su nombre de usuario (adem´as de otra serie de datos), de forma totalmente an´onima (de hecho, esto es lo que le permite autenticarse). Cabe rese˜nar que entre estos datos no se encuentra la contrase˜na, aunque existen otros que son tambi´en muy sensibles, y que se pueden consultar de forma an´onima si nada lo impide. La otra posibilidad es introducir un usuario que permita leer los datos de todos los usuarios, inclu´ıda la contrase˜na, y configurar los clientes para que se aten a este usuario para realizar operaciones de autenticaci´on. En nuestro caso hemos optado por el primer mecanismo, ya que configuraremos los servidores para que no respondan a peticiones que vengan de m´aquinas que no se encuentran en los Laboratorios.

CAP´ITULO 4. IMPLANTACI ´ON

Para llevar a cabo esta restricci´on, vamos a emplear el mismo mecanismo que en el punto anterior, cuando limit´abamos el acceso a los servidores mediante SSH: haciendo uso de los ficheros hosts.allow y hosts.deny. De esta forma, en cada servidor LDAP debemos incluir las subredes de todos los laboratorios (recordamos que las peticiones de autenticaci´on de un campus pueden resolverse en un servidor LDAP de otro campus, si todos los servidores de este campus se han caido). De la misma forma que en el punto anterior, debemos denegar todas las conexiones al servicio slapd (encargado de atender las peticiones LDAP) desde cualquier host. Esta regla debe ser incluida en el fichero /etc/hosts.deny:

slapd : ALL

Y si queremos que se acepten conexiones al servicio slapd desde redes espec´ıficas, solamente lo debemos indicar en el fichero /etc/hosts.allow:

slapd : 212.128.4. , 193.147.56. , 193.147.57. , 1 9 3 . 1 4 7 . 7 3 .

En este caso no se contempla que m´aquinas pertenecientes a la red del Departamento se puedan conectar a un servidor LDAP, puesto que no es necesario.