SEGURIDAD EN UNIX Y REDES

182CAPÍTULO 11. ALGUNOS SERVICIOS Y PROTOCOLOSmitimos nombres de usuarios y contraseñas: estamos otorgando a cualquiera que lea esos datos unacceso total a la máquina destino, bajo nuestra identidad. Por tanto, es muy recomendable noutilizar telnet para conexiones remotas, sino sustituirlo por aplicaciones equivalentes pero queutilicen cifrado para la transmisión de datos: ssh o SSL-Telnet son las más comunes. En estoscasos necesitamos además de la parte cliente en nuestro equipo, la parte servidora en la máquinaremota escuchando en un puerto determinado.Aparte del problema de los atacantes esnifando claves, los demonios telnetd han sido tambiénuna fuente clásica de problemas de programación (se puede encontrar un excelente repaso a algunosde ellos en el capítulo 29 de [Ano97]); básicamente, cualquier versión de este demonio que no estéactualizada es una potencial fuente de problemas, por lo que conviene conseguir la última versiónde telnetd para nuestro Unix particular, especialmente si aún tenemos una versión anterior a1997. Otros problemas, como la posibilidad de que un atacante consiga recuperar una sesión queno ha sido cerrada correctamente, el uso de telnet para determinar qué puertos de un host estánabiertos, o la utilización del servicio telnet (junto a otros, como ftp) para averiguar el clon deUnix concreto (versión de kernel incluida) que un servidor utiliza, también han hecho famosa lainseguridad de este servicio.11.5 El servicio SMTPEl servicio smtp (Simple Mail Transfer Protocol, puerto 25 tcp) se utiliza para transferir correoelectrónico entre equipos remotos; estas máquinas pueden ubicarse físicamente en la misma sala,en la misma universidad, o en la otra parte del mundo, a miles de kilómetros de distancia. Esteservicio suele ser atendido por un demonio denominado sendmail, que ha sido uno de los que másproblemas de seguridad ha tenido a lo largo de la historia de Unix; y no es para menos: se tratade un software muy complejo y potente – incluso demasiado para las necesidades de la mayoría deservidores –, por lo es inevitable que en su código existan bugs; para hacernos una idea del grado decomplejidad de sendmail simplemente tenemos que echarle un vistazo a su fichero de configuracionprincipal, /etc/sendmail.cf. Existen incluso libros casi dedicados exclusivamente a este archivo([CA97a], [CA97b]. . . ).Una medida de protección básica para nuestro servicio smtp, y que muchos administradores desconocen,es la posibilidad de servir sendmail desde inetd en lugar de hacerlo como un demonioindependiente, y por tanto poder restringir el acceso al mismo mediante TCP Wrappers. En lamayoría de organizaciones existe un servidor de correo principal que es el encargado de recoger elmail para todas las direcciones ‘*@*.upv.es’; el resto de equipos sólo recibirán correo desde esteequipo – o desde otro que sirve sólo a un subdominio, y que a su vez recibe sólo desde el principal–. Entonces, parece claro que si nuestro sendmail sólo recibe correo válido desde una máquina,lo lógico es configurarlo para que sólo acepte peticiones desde ella: en lugar de lanzar el demonioal arrancar el sistema, en uno de los scripts de /etc/rc.d/ o similar, lo serviremos desde inetd.Para esto necesitamos en primer lugar modificar el script correspondiente para que sendmail no selance como demonio en el arranque: en lugar de invocarlo como ‘sendmail -bd -q15m’ lo haremoscomo ‘sendmail -q15m’. Ademas, es necesario identificar el servicio en /etc/services, con unalínea como la siguiente:luisa:~# grep smtp /etc/servicessmtp 25/tcp mailluisa:~#Tras reconocer el servicio, hemos de añadir una línea en /etc/inetd.conf indicando cómo se hade ejecutar sendmail cuando inetd reciba una petición en el puerto 25; dicha línea es similar a lasiguiente:luisa:~# grep smtp /etc/inetd.confsmtp stream tcp nowait root /usr/sbin/tcpd sendmail -bs