SEGURIDAD EN UNIX Y REDES

Capítulo 11Algunos servicios y protocolos11.1 IntroducciónEn este capítulo vamos a hablar de la seguridad (e inseguridad) de algunos de los protocolos, serviciosy programas que los implementan en los entornos Unix. No vamos a entrar en detalles sobre elfuncionamiento de cada uno de ellos, ya que ese sería un trabajo que excedería los objetivos de esteproyecto; para más referencias se puede consultar [Ste90] (detalles de la implementación interna dealgunos servicios) o [Ste94].Podemos ver los diferentes servicios que un sistema Unix ofrece como potenciales puertas de entradaal mismo, o al menos como fuentes de ataques que ni siquiera tienen por qué proporcionar accesoa la máquina – como las negaciones de servicio –. De esta forma, si cada servicio ofrecido es unposible problema para nuestra seguridad, parece claro que lo ideal sería no ofrecer ninguno, poseeruna máquina completamente aislada del resto; evidentemente, esto no suele ser posible hoy en díaen la mayor parte de los sistemas 1 . Por tanto, ya que es necesaria la conectividad entre equipos,hemos de ofrecer los mínimos servicios necesarios para que todo funcione correctamente; estochoca frontalmente con las políticas de la mayoría de fabricantes de sistemas Unix, que por defectomantienen la mayoría de servicios abiertos al instalar un equipo nuevo: es responsabilidad del administradorpreocuparse 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 nose puede aplicar el esquema todo o nada que vimos al estudiar el sistema de red de Unix, dondeo bien ofrecíamos un servicio o lo denegábamos completamente: es necesaria una correcta configuraciónpara que sólo sea posible acceder a ellos desde ciertas máquinas, como veremos al hablarde 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 entredos 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 sistemasy redes completas.Aparte de puertas de entrada, los servicios ofrecidos también son muy susceptibles de ataquesde negación de servicio (DoS), por ejemplo por demasiadas conexiones abiertas simultáneamenteen una misma máquina; incluso es posible que uno de estos ataques contra cierto servicio inutilicecompletamente a inetd, de forma que todos los ofrecidos desde él quedan bloqueados hasta que eldemonio se reinicia. Este problema incluso puede ser muy grave: imaginemos que – por cualquiermotivo – inetd deja de responder peticiones; si esto sucede es posible que ni siquiera podamos accedera la máquina remotamente para solucionar el problema (por ejemplo telnet o incluso ssh si1 No obstante, algunos equipos que no necesitan estar conectados entre sí, lo están; cada administrador deberíapreguntarse si realmente necesita sus máquinas conectadas a la red.171