Nuestra siguiente escala es el análisis de utilización de TCP wrappers. Para los que vayáis siguiendo la serie, recordaos que estamos en la parte de análisis de red.
Los TCP wrappers son un desarrollo original de Wietse Venema, liberados en su día bajo licencia BSD. Wietse es un conocido desarrollador del mundo UNIX, y una eminencia en seguridad. Entre sus méritos, está el desarrollo de Postfix, la herramienta SATAN de auditoría o las premiadas herramientas forenses The Coroner´s Toolkit.
TCP wrappers permite usar como tokens para filtrado y control de acceso las direcciones IP, los nombres de los terminales y las consultas ident. Esto es una ventaja tremenda pero a su vez entraña un riesgo muy importante, ya que podemos permitir el acceso a un usuario sólo por el hecho de que su IP, el nombre de su máquina o la respuesta ident sean las que esperamos.
Yo soy de los que creo que los TCP wrappers tienen cabida en sistemas de producción real complejos, pero no en ciertos servicios, ya que son una invitación a descuidar la seguridad del sistema. Creo más en la definición y aplicación de ACLs (listas de control de acceso), en el cuidado de los grupos y usuarios, sus privilegios y en el control de las acciones mediante logs, y eso que TCP Wrappers permite registrar prácticamente todo. Es una opinión personal, y por tanto, no implica que TCP wrappers sea una mala solución: al contrario, en ciertos entornos y ciertas operativas, es hasta saludable y aconsejable, por simplicidad de la administración de la máquina.
Un poco de teoría
El funcionamiento de TCP wrappers es algo difícil de entender al comienzo, pero ya veremos que tampoco es tan complicado. Lo primero que tenemos que entender es el funcionamiento de inetd, el Internet Super Server o Súper Servidor de Internet que tienen las máquinas UNIX. Os aconsejo leer esta anotación de Felipe Alfaro, que complementa perfectamente el tema que tratamos.
inetd es un servidor que permite a nuestra máquina estar atenta a las comunicaciones entrantes, y desviar los mensajes para que lleguen al sitio adecuado, avisando al demonio o servicio correspondiente según el caso. Por ejemplo, si conectamos con un cliente de correo al servidor POP3 de nuestro servidor de correo para descargar los mensajes, el cliente de correo hará una petición que será interceptada por inetd. El servidor inetd entenderá que es una comunicación que va por el puerto 110 (Post Office Protocol – Version 3, aka POP3) y avisará al demonio de correo para que se entienda con la petición recibida.
No siempre nos va a interesar atender las peticiones entrantes, y por tanto, surge la necesidad de gestionar los rechazos. Es aquí donde entra en esecena TCP wrappers, ya que podremos clasificar entre conexiones aceptadas o rechazadas, dependiendo de si se cumplen las condiciones decretadas por los wrappers: básicamente, la IP de origen, nombre de máquina e ident. Si conozco tu máquina, atenderé tu petición, y si no, no le haré caso.
Al instalar TCP wrappers, al menos en una instalación clásica, se instalan los siguientes ficheros:
* tcpdchk y tcpdmatch, para comprobar y hacer matching sobre las las reglas definidas en /etc/hosts.allow y /etc/hosts.deny, ficheros que ya hemos visto en este pequeño cursillo, y que son cruciales para la permisividad o la denegación de conexiones.
* tcpd, el TCP wrapper daemon, el verdadero motor del paquete.
* safe_finger, un sustituto seguro de finger.
* try-from, para probar las respuestas del demonio tcpd ante las peticiones de máquinas remotas que emplean distintos nombres de máquina y ident.
El funcionamiento es tan simple como lo que sigue: Por ejemplo, para someter a TCP wrapping el demonio finger:
finger stream tcp nowait nobody /usr/etc/in.fingerd in.fingerd
se sustituye esa entrada en el fichero etc/inetd.conf por:
finger stream tcp nowait nobody /usr/etc/tcpd in.fingerd
Como se puede comprobar, este cambio de líneas implica dejar de atender las peticiones finger mediante el demonio original in.fingerd, ubicado en /usr/etc/in.fingerd, y atenderlas mediante el demonio tcpd, ubicado en /usr/etc/tcpd.
Si repasáis el ejemplo /etc/inetd.conf que utilizamos en la unidad 17, veréis muchos servicios sometidos a TCP Wrappers. Y es que las distribuciones modernas, especialmente Linux, con el fin de facilitar al máximo la administración por parte de los usuarios, tienden a emplear TCP wrapping.
El objetivo de auditoría será evidenciar si se usan o no se usan TCP wrappers. El auditor será el que, en cada caso, redacte en su informe si este empleo es beneficioso, pernicioso o simplemente neutro para la seguridad del sistema sometido a análisis.
Ejemplo práctico
Para localizar servicios sometidos a TCP Wrapping bastará con buscar, en el fichero /etc/inetd.conf o su equivalente (pensad en la Piedra Rosetta UNIX), la cadena que nos avisará de que los wrappers están activos para un demonio determinado: la presencia del demonio tcpd.
grep tcpd inetdconf.txt | grep -v “#”
Utilizando los datos vistos en la unidad 17, obtenemos los siguientes resultados:
ntalk dgram udp wait root /usr/sbin/tcpd in.ntalkd
finger stream tcp nowait root /usr/sbin/tcpd in.fingerd
Son especialmente críticos los servicios de Telnet y FTP bajo TCP Wrappers. Yo recomiendo que, siempre que se pueda, no se usen wrappers para estos dos mecanismos, ni para cualquier otro protocolo que permita la autenticación contra la máquina. En el etc/inetd.conf deberían aparecer sin la intervención de tcpd.
telnet stream tcp6 nowait root /usr/sbin/in.telnetd in.telnetd
ftp stream tcp6 nowait root /usr/sbin/in.ftpd in.ftpd
Resumen
Nuestro objetivo será enumerar los servicios y demonios que usen TCP wrappers en la máquina. El auditor dictaminará en cada caso la afectación para la seguridad que pueda tener el wrapping de estos servicios.
En el informe de auditoría se explicará, para cada servicio o demonio, la justificación del porqué del wrapping, siendo deseable que la enumeración vaya acompañada por una clasificación del impacto sobre la seguridad (por ejemplo: alto, medio, bajo, nulo) surgida como consecuencia de la aplicación de TCP wrappers en cada caso.
Un saludo :)