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.
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í.
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.
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.
Utilizando 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>.