Cualquiera que esté familiarizado con inetd(8) probablemente haya oído hablar de TCP Wrappers, pero poca gente parece comprender completamente su utilidad en un entorno de red. Parece que todos quieren instalar un cortafuegos para manejar conexiones de red. Aunque un cortafuegos tiene una amplia variedad de usos hay cosas que un cortafuegos no es capaz de gestionar, como el envío de texto como respuesta al creador de la conexión. El software TCP hace esto y más. En las siguientes secciones se explicarán unas cuantas opciones de TCP Wrappers y, cuando sea necesario, se mostrarán ejemplos de configuraciones.
El software TCP Wrappers extiende las habilidades de inetd para ofrecer soporte para cada servidor dæmon bajo su control. Utilizando este método es posible proveer soporte de logs, devolver mensajes a conexiones, permitir a un dæmon aceptar solamente conexiones internas, etc. Aunque algunas de estas opciones pueden conseguirse gracias a un cortafuegos, no sólo añadirá una capa extra de seguridad, sino que irá más allá del nivel de control ue un cortafuegos puede ofrecerle.
Las brillantes capacidades de TCP Wrappers no deben considerarse una alternativa a un buen cortafuegos. TCP Wrappers puede usarse conjuntamente con un cortafuegos u otro sistema de de seguridad, pues ofrece una capa extra de protección para el sistema.
Ya que es una extensión de la configuración de inetd, se da por hecho que el lector ha leído la sección configuración de inetd.
Nota: Aunque los programas ejecutados por inetd(8) no son exactamente “dæmons” tradicionalmente han recibido ese nombre. Dæmon es, por tanto, el término que usaremos en esta sección.
El único requisito para usar TCP Wrappers
en FreeBSD es que el servidor inetd se inicie desde rc.conf con la opción -Ww (es la
configuración por defecto). Por descontado, se presupone que /etc/hosts.allow estará correctamente configurado, pero syslogd(8) enviará
mensajes a los logs del sistema si no es así.
Nota: A diferencia de otras implementaciones de TCP Wrappers, se ha dejado de usar hosts.deny. Todas las opciones de configuración deben ir en /etc/hosts.allow.
En la configuración más simple las políticas de conexión de dæmons están configuradas ya sea a permitir o bloquear, dependiendo de las opciones en /etc/hosts.allow. La configuración por defecto en FreeBSD consiste en permitir una conexión a cada dæmon iniciado por inetd. Es posible modificar esta configuración, pero explicaremos cómo hacerlo después de exponer la configuración básica.
La configuración básica tiene la estructura dæmon : dirección : acción, donde dæmon es el nombre de dæmon que inicia inetd. La dirección puede ser un nombre de equipo válido, una dirección IP o IPv6 encerrada en corchetes ([ ]). El campo acción puede ser permitir o denegar para el dar el acceso apropiado. Tenga presente que la configuración funciona en base a la primera regla cuya semántica concuerde; esto significa que el fichero de configuración se lee en orden ascendente hasta que concuerde una regla. Cuando se encuentra una concordancia se aplica la regla y el proceso se detendrá.
Existen muchas otras opciones pero estas se explican en una sección posterior. Una línea de configuración simple puede generarse mediante datos así de simples. Por ejemplo, para permitir conexiones POP3 mediante el dæmon mail/qpopper, añada las siguientes líneas a hosts.allow:
# This line is required for POP3 connections: qpopper : ALL : allow
Despues de añadir esta línea tendrá que reiniciar inetd. Use
kill(1) o use el
parámetro restart de /etc/rc.d/inetd.
Las opciones avanzadas de TCP Wrappers le permiten un mayor control sobre la gestión de conexiones. En algunos casos puede convenir el enío de un comentario a ciertos equipos o conexiones de dæmons. En otros casos, quizás se deba registrar una entrada en un log o enviar un correo al administrador. Otro tipo de situaciones pueden requerir el uso de un servicio solamente para conexiones locales. Todo esto es posible gracias al uso de unas opciones de configuración conocidas como comodines, caracteres de expansión y ejecución de órdenes externas. Las siguientes dos secciones intentarán cubrir estas situaciones.
Imaginemos una situación en la que una conexión debe ser denegada pero se debe mandar
un motivo a quien intentó establecer esa conexión. ?Cómo? Mediante la opción twist. Ante un intento de conexión se invoca a twist, que ejecuta una orden de shell o un “script”.
Tiene un ejemplo en el fichero hosts.allow:
# The rest of the daemons are protected.
ALL : ALL \
: severity auth.info \
: twist /bin/echo "No se permite utilizar %d desde %h."
Este ejemplo muestra que el mensaje, “No se permite utilizar dæmon desde nombre de equipo.” se enviará en el caso de cualquier dæmon no configurado previamente en el fichero de acceso. Esto es extremadamente útil para enviar una respuesta al creador de la conexión justo después de que la conexión establecida es rechazada. Observe que cualquier mensaje que se desee enviar debe ir entre comillas "; esta regla no tiene excepciones.
Aviso Es posible lanzar un ataque de denegación de servicio al servidor si un atacante o grupo de atacantes pueden llegar a sobrecargar estos dæmons con peticiones de conexión.
Otra posibilidad en estos casos es usar la opción spawn.
Igual que twist, spawn niega
implícitamente la conexión, y puede usarse para ejecutar órdenes de shell externos o
“scripts”. A diferencia de twist, spawn no enviará una respuesta al origen de la conexión. Veamos un
ejemplo; observe la siguiente línea de configuración:
# No permitimos conexiones desde ejemplo.com: ALL : .ejemplo.com \ : spawn (/bin/echo %a desde %h intento acceder a %d >> \ /var/log/connections.log) \ : deny
Esto denegará todos los intentos de conexión desde el dominio *.ejemplo.com; simultáneamente creará una entrada con el nombre del equipo, dirección IP y el dæmon al que intentó conectarse al fichero /var/log/connections.log.
Además de la sustitución de caracteres ya expuesta más arriba (por ejemplo %a) existen unas cuantas más. Si quiere ver la lista completa consulte la página de manual hosts_access(5).
Hasta ahora se ha usado ALL en todos los ejemplos, pero hay otras opciones interesantes para extender un poco más la funcionalidad. Por ejemplo, ALL puede usarse para concordar con cualquier instancia ya sea un dæmon, dominio o dirección IP. Otro comodín es PARANOID, que puede utilizarse para concordar con cualquier equipo que presente una dirección IP que pueda estar falsificada. En otras palabras, paranoid puede usarse para definir una acción a tomar siempre que tenga lugar una conexión desde una dirección IP que difiera de su nombre de equipo. Quizás todo se vea más claro con el siguiente ejemplo:
# Bloquear peticiones posiblemente falsificadas a sendmail: sendmail : PARANOID : deny
En ese ejemplo todas las peticiones de conexión a sendmail que tengan una dirección IP que varíe de su nombre de equipo serán denegadas.
AtenciónUtilizando PARANOID puede bloquear el acceso a servidores si el cliente o el servidor tiene una configuración de DNS incorrecta. Recomendamos al administrador la máxima cautela en su uso.
Consulte hosts_access(5) si quiere saber más sobre los comodines y sus posibilidades de uso.
Si quiere que cualquiera de los ejemplos citados funcione debe comentar la primera línea de hosts.allow (tal y como se dijo al principio de la sección.
Puede descargar éste y muchos otros documentos desde ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.
Si tiene dudas sobre FreeBSD consulte la documentación antes de escribir a la lista
<questions@FreeBSD.org>.
Envíe sus preguntas sobre la documentación a <doc@FreeBSD.org>.