En este capítulo vamos a hablar de la seguridad (e inseguridad) de algunos
de los protocolos, servicios y programas que los implementan en los entornos
Unix. No vamos a entrar en detalles sobre el funcionamiento de cada uno de
ellos, ya que ese sería un trabajo que excedería los objetivos de este
proyecto; para más referencias se puede consultar [Ste90] (detalles
de la implementación interna de algunos servicios) o [Ste94].
Podemos ver los diferentes servicios que un sistema Unix ofrece como
potenciales puertas de entrada al mismo, o al menos como fuentes de ataques
que ni siquiera tienen por qué proporcionar acceso a la máquina - como las
negaciones de servicio -. De esta forma, si cada servicio ofrecido es un
posible problema para nuestra seguridad, parece claro que lo ideal sería
no ofrecer ninguno, poseer una máquina completamente aislada del resto;
evidentemente, esto no suele ser posible hoy en día en la mayor parte de
los sistemas15.1. Por
tanto, ya que es necesaria la conectividad entre equipos, hemos de ofrecer los mínimos servicios necesarios para que todo funcione correctamente;
esto choca frontalmente con las políticas de la mayoría de
fabricantes de sistemas Unix, que por defecto mantienen la mayoría de
servicios abiertos al instalar un equipo nuevo: es responsabilidad del
administrador preocuparse de cerrar los que no sean estrictamente necesarios.
Típicos ejemplos de servicios que suele ser necesario ofrecer son telnet o ftp; en estos casos no se puede aplicar el esquema todo o nada
que vimos al estudiar el sistema de red de Unix, donde o bien ofrecíamos
un servicio o lo denegábamos completamente: es necesaria una correcta
configuración para
que sólo sea posible acceder a ellos desde ciertas máquinas, como veremos
al hablar de TCP Wrappers. También es una buena idea sustituir estos
servicios por equivalentes cifrados, como la familia de aplicaciones SSH,
y concienciar a los usuarios para que utilicen estos equivalentes: hemos de
recordar siempre - y recordar a los usuarios - que cualquier conexión en
texto claro entre dos sistemas puede ser fácilmente capturada por cualquier
persona situada en una máquina intermedia, con lo simplemente utilizando
telnet estamos poniendo en juego la seguridad de sistemas y redes
completas.
Aparte de puertas de entrada, los servicios ofrecidos también son muy
susceptibles de ataques de negación de servicio (DoS), por ejemplo por
demasiadas conexiones abiertas simultáneamente en una misma máquina; incluso
es posible que uno de estos ataques contra cierto servicio inutilice
completamente a inetd, de forma que todos los ofrecidos desde él quedan
bloqueados hasta que el demonio se reinicia. Este problema incluso puede ser
muy grave: imaginemos que - por cualquier motivo - inetd deja de
responder peticiones; si esto sucede es posible que ni siquiera podamos acceder
a la máquina remotamente para solucionar el problema (por ejemplo telnet o incluso SSH si lo servimos deste inetd dejarían de
funcionar). Para evitar este problema, muchos administradores planifican una
tarea que se ejecute cada pocos minutos mediante cron, y que simplemente
envíe la señal SIGHUP a inetd, por ejemplo añadiendo esta
entrada a su fichero crontab15.2:
* * * * * killall -HUP inetd
Si en nuestro clon de Unix no disponemos de una órden para enviar señales
a los procesos en función de su nombre (como pkill en Solaris o killall en Linux o IRIX) podemos utilizar un poco de programación shellscript para conseguirlo:
* * * * * kill -HUP `ps -auxw|grep inetd|grep -v grep|awk '{print $2}'`
© 2002 Antonio Villalón Huerta
