Hardening de Linux
En el artículo anterior se explicó de manera general lo que se debe hacer en el endurecimiento (hardening) de un sistema operativo. Ahora, a manera de ejemplificar, se abordará el endurecimiento de un equipo Linux.
Antes de comenzar cabe señalar que el tema es por demás amplio, ya que el endurecimiento se ve a distintos niveles, por lo que no se profundizará técnicamente y se pasarán por alto algunos temas.
Si el lector desea conocer más sobre este tema, está cordialmente invitado a visitar las ligas incluidas al final del presente artículo. En entregas posteriores se verán aspectos concretos y desde la perspectiva técnica.
El proceso comienza por tener en claro “para qué” va a usarse el servidor (Web, archivos, impresión, correo, etcétera). No menos importante es el “diseño” o cómo estará particionado el servidor (para manejo de cuotas o sistemas de archivo cifrados, etcétera).
El siguiente paso sería realizar la instalación personalizada (no elegir las opciones por defecto), esto con la finalidad de que se instale sólo aquello que realmente se necesitará, quitando los servicios innecesarios; por ejemplo, para una instalación de servidor no se instalarían herramientas de edición, juegos, incluso la interfaz gráfica no sería recomendable; servicios como el FTP no deberían instalarse dada la inseguridad que implica (transfiere las credenciales en texto claro).
En un servidor de producción no deberían tenerse herramientas de desarrollo como compiladores, ya que de tenerlos se estarían dando las herramientas necesarias para que un posible atacante pudiera compilar sus herramientas y afectar.
Una vez que se ha realizado la instalación es necesario actualizar el sistema base, ya que debe tenerse en claro que cuando se instale el servidor muy probablemente ya ha pasado tiempo desde que la versión de la distribución de Linux que ha sido instalada fue liberada.
Es necesario mencionar que las nuevas versiones de un programa no siempre significan problemas de seguridad, en ocasiones son mejoras en las funcionalidades o incremento de las mismas, por lo que no es recomendable actualizar sin haber realizado un estudio previo de vulnerabilidades reportadas (por ejemplo, sale alguna vulnerabilidad que afecta a una versión del servidor Apache en particular, distinta a la que se tenga por lo que no sería afectada).
Aunque se ha realizado una instalación personalizada, siempre se instalan ciertos servicios por default, por lo que se debe hacer una revisión de todo lo que se tiene en ejecución, servicios que levanten al arranque e ir depurando para dejar los mínimos necesarios (un servicio con un puerto a la escucha es una posible puerta por la que un atacante puede entrar).
Es recomendable configurar un firewall (IPTables para Linux) en el que siempre lo más recomendable es optar por una política prohibitiva (todo lo que no está explícitamente permitido está prohibido) e ir abriendo sólo los puertos necesarios para la operación del servidor.
Es común que la cuenta de root (administrador) se emplee como cuenta de uso frecuente; ésta es una muy mala costumbre, por lo que debe evitarse su uso, forzando a que la cuenta root sólo se pueda firmar al equipo desde la consola. Para administrarlo remotamente, deberá firmarse con la cuenta personal y de ahí convertirse en root.
Debe forzarse que sólo se empleen protocolos seguros para la comunicación con el servidor; es decir, utilizar SSH para su administración. En este punto es necesario forzar a que el demonio de SSH sólo sea compatible con la versión 2 del protocolo, ya que las anteriores son vulnerables.
En este mismo punto se debe limitar quiénes de los usuarios pueden establecer sesión con el servidor (tengan shell) y de ellos quiénes podrán convertirse en root.
En la medida de lo posible debe “enjaularse” (chroot) tanto a los usuarios que tengan acceso al shell como a los servicios que se tengan en ejecución, esto con la finalidad de que en caso de ser explotada una vulnerabilidad o el acceso de un usuario sea comprometido, el impacto sea menor.
Debe tenerse un control estricto en todas las bitácoras, apoyándose en herramientas para su análisis, sobre todo si el servidor tendrá un alto tráfico. Esto será de utilidad para saber cuándo alguien está tratando de hacer un ataque de diccionario al SSH.
Como podrá comprobar el lector es grande la tarea de endurecer un equipo, por lo que puede continuar la lista de recomendaciones y mejores prácticas. Asimismo se trató el tema de una manera general, sin apego a una distribución en particular y sin utilizar comandos ya que la intención es dejar en claro las acciones.
Para profundizar en este tema se recomiendan las siguientes direcciones:
+Reforzando la instalación de Debian GNU/Linux
www.arcert.gov.ar/ncursos/material/hardening-v2.pdf
+Asegurando un Linux Fedora Core
www.apc.org/apps/img_upload/478cd24e3b86bdf5d2fa0c212f473f4d/Asegurando_FC.pdf
+Asegurando una estación de trabajo
www.nautopia.net/archives/es/linux_varios/asegurando_estacion_de_trabajo/asegurando_una_estacion_de_trabajo.php
+Slackware Linux Benchmark
checklists.nist.gov/repository/1105.html
+Hardening Slackware
pof.eslack.org/hardening-slack/HARDENING_SLACKWARE.txt
