10.5.- Desactivar los servidores no utilizados

La mayoría de distribuciones vienen con un gran número de servidores que pueden ser una ventaja, ya que nos evitará tener que buscar los servidores que queramos ejecutar. Por otra parte, es un inconveniente, ya que, si no tenemos cuidado, podemos acabar ejecutando un servidor sin tan siquiera darnos cuenta de que está instalado. Deberíamos buscar periódicamente los servidores y apagar los que no son realmente necesarios. Para ello podemos ejecutar herramientas como netstat, lsof y escáneres de red remotos. También podemos buscar pistas sobre lo que se está ejecutando. Podemos desactivar los servidores desinstalando el paquete o reconfigurando el servidor.

Utilizar netstat

netstat permite diagnosticar la seguridad de la red buscando actividad en los puertos abiertos de un ordenador. Es la navaja suiza de las herramientas de estado, proporciona muchas opciones y formatos de salida para distribuir la información sobre tablas de enrutamiento, estadísticas de la interfaz, etc. Para localizar los servidores innecesarios utilizaremos netstat con las opciones -a y -p:

Vemos como resultado:

 El comando netstat muestra conexiones de red activas que pueden revelar la presencia de servidores que se ejecutan en el ordenador. Las columnas Dirección local y Dirección remota especifican las direcciones local y remota incluyendo el nombre de host o dirección IP y el número de puerto o nombre asociado en /etc/services. La columna Estado especifica que el servidor está escuchando conexiones. La columna final PID/Program name indica que el proceso con ID (PID) está utilizando el puerto que se especifica.

El análisis detallado de la salida de netstat puede llevar algún tiempo, pero nos proporcionará un mejor conocimiento de las conexiones de red de nuestro sistema. Si localizamos servidores que escuchan conexiones que no sabíamos que estaban activas, deberíamos investigar sobre ello; algunos pueden ser inofensivos o incluso necesarios, pero otros pueden ser riesgos potenciales para la seguridad. Cuando utilicemos la opción -p para obtener el nombre y la PID del proceso, la salida de netstat superará la anchura de 80 columnas, por lo que resulta útil abrir una ventana xterm de anchura especial para visualizar la salida o bien redireccionarla  a un fichero que analizaremos posteriormente en un editor de texto capaz de mostrar más de 80 columnas. Para localizar rápidamente servidores que escuchan conexiones utilizaremos netstat -lp en lugar de netstat -ap. El resultado mostrará todos los servidores que escuchan conexiones, omitiendo conexiones cliente e instancias de servidor específicas que ya estén conectadas a clientes.

Utilizar lsof

lsof lista los nombres de los ficheros abiertos. Con él podemos identificar qué ficheros están abiertos en un directorio, quién accede a ellos, etc. La definición de fichero de lsof incluye las conexiones de red. Por lo tanto, podemos utilizar lsof en lugar de netstat para algunas tareas como localizar los servidores que están en uso, la forma más básica de obtener información acerca de la red es pasándole el parámetro -i:

Si escribimos lsof -i como un usuario normal, sólo veremos nuestras propias conexiones de red, por lo que si queremos que el comando nos sea útil, debemos ejecutarlo como root. Para restringir la salida podemos incluir una dirección tras la opción -i. La dirección tomará la siguiente forma:

Type representa una conexión IPv4 o IPv6, NODE es el tipo de protocolo (tcp o udp), NAME  es el nombre o la dirección IP del sistema remoto, servicio es el nombre del servicio de /etc/services y el puerto es el número de puerto. Por ejemplo, si queremos verificar que no se está ejecutando ningún servidor FTP, buscaremos las conexiones asociadas con el:

También podemos sustituir FTP por 21, ya que es el puerto asociado con el servicio FTP. El comando devuelve una lista de todos los procesos asociados con las conexiones FTP, tanto entrantes como salientes. Si no hay conexiones, el comando no genera ninguna salida. Tendremos que notar que líneas de salida están asociadas con servidores y cuáles son procesos cliente. Si los usuarios del ordenador utilizan clientes FTP, el comando producirá decenas de líneas de salida aunque no ejecutemos ningún servidor FTP.

Para realizar una auditoría general de las conexiones de red del sistema, escribiremos lsof -i sin restringir la salida. Es aconsejable canalizar la salida mediante less o utilizar un buffer desplazable de xterm, grep puede resultar un atajo para localizar los servidores activos filtrando mediante la cadena LISTEN:

En este caso no muestra ninguna ESCUCHA.

Utilizar escáneres de red remotos

Los escáneres de red pueden buscar puertos abiertos en el ordenador local o en otros ordenadores, los más sofisticados también buscan vulnerabilidades conocidas, lo que nos indica si un servidor puede estar en riesgo en caso de que lo dejemos funcionando. Los crackers utilizan estos escáneres para localizar posibles sistemas objetivo. Muchas empresas tienen políticas que prohíben el uso de estas herramientas excepto bajo condiciones específicas. Si queremos usarlas en nuestra empresa, deberíamos consultar las políticas y obtener un permiso explícito, por escrito y firmado, de lo contrario podríamos perder el empleo o incluso podrían acusarnos de un delito.

nmap es capaz de realizar una comprobación básica de los puertos abiertos. Le pasaremos el parámetro -sT y el nombre del sistema objetivo tal y como se indica a continuación:

La salida muestra dos puertos abiertos: 80 y 443, utilizados por http y https. Si no somos conscientes de que estos puertos estaban abiertos, deberíamos acceder al sistema escaneado e investigar un poco utilizando netstat, lsof o ps, para localizar los programas que utilizan estos puertos. -sT especifica un análisis de puertos tcp, pero también hay servidores que se ejecutan sobre puertos udp, por lo que tendremos que utilizar -sU para analizar los servidores de los puertos udp. nmap puede realizar escaneos más sofisticados, incluyendo escaneos que no detectan la mayoría de los cortafuegos y escaneos mediante ping para detectar que host están activos.

nessus está montado sobre nmap, proporciona GUI y medios para realizar pruebas automatizadas y aun más sofisticadas. Viene como cliente y componentes de servidor independientes, el cliente permite controlar el servidor que hace el trabajo real.

Cuando utilizamos un escáner de red debemos tener en cuenta que los puertos que vemos desde nuestro sistema de prueba pueden no ser los mismos que serían visibles para un atacante. Esto es importante si estamos probando un sistema que está detrás de un cortafuegos desde otro sistema que esta detrás del mismo cortafuegos. El sistema de prueba revelará puertos accesibles que no lo estarán desde el mundo exterior. Por otra parte un cracker que esté en nuestra red local tendrá acceso a estos puertos, por lo que no debemos darnos por satisfechos con utilizar un cortafuegos, aunque los cortafuegos son herramientas importantes para ocultar servidores sin tener que apagarlos.

 Examinar los ficheros de configuración

La mayoría de servidores de Linux incluyen ficheros de configuración, por lo que podemos localizar servidores instalados buscando sus ficheros de configuración. La mayoría de sistemas incluyen dos tipos de ficheros importantes: los que controlan scripts de inicio SysV y los que controlan nuestro súper servidor.slackware no utiliza scripts de inicio SysV, sino un script de inicio por cada modo de ejecución, por lo que en este sistema tendremos que localizar el script de inicio del modo de ejecución relevante buscando llamadas sospechosas.

Generalmente, tendremos que buscar en /etc/rc?.d, /etc/init.d/rc?.d o /etc/rc.d/rc?.d, donde ? es el número del modo de ejecución, para aquellos scripts cuyos nombres adoptan la forma S##servidor, donde ## es un número y servidor es el nombre del servidor. Si localizamos un script para un servidor que no queremos ejecutar, deberíamos desactivarlo mediante los scripts de inicio SysV. No debemos desactivarlo automáticamente, ya que puede que sea necesario aunque no nos suene el nombre, antes debemos investigar más sobre el tema.

La otra clase de ficheros de configuración principal son los de configuración del súper servidor. Deberíamos revisar los ficheros de inetd o xinetd en busca de ficheros o servidores no deseados;  los súper servidores sólo inician servidores de red, por lo que deberíamos utilizar un método más agresivo para desactivar las entradas que no reconozcamos de la configuración de nuestro súper servidor.

En los sistemas antiguos vale la pena examinar /etc/inittab. Este fichero controla algunas de las primeras etapas del proceso de inicio, por lo que es de especial interés el hecho de que las instalaciones de /etc/inittab más antiguas iniciaban los procesos que se empleaban para aceptar accesos de tipo texto, accesos a través de MODEM y puertos rs-232. Estos procesos suelen recibir el nombre de getty o alguna de sus variantes como mingetty. Normalmente, una máquina Linux tiene uno de estos procesos en ejecución y se controla mediante una entrada de /etc/inittab:

El primer carácter (1) especifica la terminal virtual (VT) que controla. La mayoría de distribuciones incluyen líneas similares para las primeras 6 VT, normalmente, no hay necesidad de ajustar estas líneas. Las líneas que empiezan por S#, donde # es un número, controlan el acceso por puerto serie rs-232 y MODEM:

Si queremos utilizar un MODEM y no queremos activar accesos remotos a través del MODEM, debemos asegurarnos de que /etc/inittab no posee líneas de este tipo.

Los sistemas modernos que carecen de inittab o tienen ficheros básicos inittab, suelen pasar estas funciones a otros ficheros, como los scripts de inicio SysV o ficheros de /etc/event.d. No suele ser necesario modificar estas configuraciones, pero debemos asegurarnos de que nuestro sistema no escucha innecesariamente conexiones por MODEM de marcado. Los ficheros con nombre /etc/event.d/tty# controlan los accesos locales mientras que los ficheros /etc/event.d/ttyS# controlan los accesos por puertos serie rs-232 o MODEM.

Desinstalar o reconfigurar servidores

Cuando identifiquemos un servidor innecesario, la siguiente tarea es apagarlo. Para ello existen dos opciones:

• Podemos desactivar el servidor cambiando la configuración SysV o desactivándolo en el súper servidor. Desactivar el servidor de esta manera tiene la ventaja de que podemos volver a activarlo fácilmente si deseamos volver a utilizarlo. Tiene el inconveniente de que los ficheros del servidor seguirán consumiendo espacio, además el servidor podría activarse accidentalmente.
• Podemos desinstalar completamente el servidor utilizando la herramienta de administración de paquetes o borrando de algún otro modo sus ficheros. Este método tiene la ventaja de reducir el riesgo de reactivación accidental, pero el inconveniente es que no podremos reactivar fácilmente el servidor.

En general, suele ser preferible eliminar el servidor a menos que deseemos desactivarlo temporalmente. Si decidimos volver a activarlo en el futuro siempre podremos reinstalarlo.