SEGURIDAD EN UNIX Y REDES

176CAPÍTULO 11. ALGUNOS SERVICIOS Y PROTOCOLOSaquellos que sólo utilizarán el equipo para gestionar su correo), pero en muchas ocasiones esta soluciónno es del todo conveniente: aparte de los peligros que implica un servicio adicional, que de otraforma no utilizaríamos – en algunos demonios de pop han surgido bugs que incluso otorgaban unprivilegio de root remoto sin necesidad de ninguna clave –, estamos generando un tránsito peligrosode contraseñas a través de la red. pop ofrece tres modelos distintos de autenticación: uno basadoen Kerberos, apenas utilizado, otro basado en un protocolo desafío–respuesta (apop, que tampocose suele utilizar), y otro basado en un simple nombre de usuario con su password correspondiente.Este último, el más usado en todo tipo de entornos, es un excelente objetivo para un pirata conun sniffer: los usuarios suelen configurar sus clientes para que chequeen el buzón de correo cadapocos minutos, con lo que a intervalos muy cortos envían su clave a un puerto conocido de unamáquina conocida; al realizar toda esta comunicación en texto claro, un atacante no tiene más queinterceptar la sesión pop para averiguar nombres de usuario y claves (aparte de poder leer el correoque baja del servidor al cliente). Si lo que deseamos es que nuestros usuarios no disfruten de unacuenta completa simplemente para gestionar su correo, podemos sustituir su shell en /etc/passwdpor el nombre de dicho lector:ircd:x:1001:100:Gestion IRC,,,:/home/ircd:/usr/bin/pineEn este caso hemos de tomar una precaución adicional: la mayoría de programas de correo (elm,pine. . . ) permiten escapes al shell, procedimientos que tarde o temprano ejecutan con éxito unintérprete de órdenes; por ejemplo, con elm no tenemos más que iniciar vi para escribir un mensajey en el editor ejecutar :!/bin/sh para ejecutar este intérprete. Para evitar estos escapes o bienpodemos modificar el código del gestor de correo – algo no muy habitual – o utilizar ya versionesmodificadas disponibles a través de Internet.11.2.8 authSe llama socket a la combinación de una dirección de máquina y un puerto; esta entidad identificaun proceso único en la red ([CZ95]). Un par de sockets, uno en la máquina receptora y otro enla emisora definen una conexión en protocolos como tcp; esta conexión también será única en lared en un instante dado. Como vemos, no entra en juego ningún nombre de usuario: en tcp/ipse establecen canales de comunicación entre máquinas, no entre personas; no obstante, en muchasocasiones nos puede interesar conocer el nombre de usuario bajo el que cierta conexión se inicia.Por ejemplo, de esta forma podríamos ofrecer o denegar un servicio en función del usuario que losolicita, aparte de la máquina desde donde viene la petición.El protocolo auth (puerto 113, tcp) viene a solucionar este problema con un esquema muy simple:cuando un servidor necesita determinar el usuario que ha iniciado una conexión contacta con eldemonio identd y le envía los datos necesarios para distinguir dicha conexión (los componentes delos dos sockets que intervienen) de las demás. De esta forma, el demonio identifica al usuario encuestión y devuelve al servidor información sobre dicho usuario, generalmente su login. Por ejemplo,si utilizamos TCP Wrappers – un programa servidor que utiliza este mecanismo para determinarnombres de usuario siempre que sea posible –, se registará el login del usuario remoto que solicitaun servicio en nuestra máquina si el sistema remoto tiene habilitado auth:luisa:~# tail -2 ~adm/syslogApr 24 04:16:19 luisa wu.ftpd[1306]: connect from rositaApr 24 04:16:21 luisa ftpd[1306]: ANONYMOUS FTP LOGIN FROM \rosita [195.195.5.1], toni@luisa:~#No obstante, si el sistema desde el que esa persona conecta no tiene habilitado dicho servicio, elnombre de usuario no se va a poder conseguir:luisa:~# tail -2 ~adm/syslogApr 24 04:19:37 luisa wu.ftpd[1331]: connect from root@anita