14.6. TCP Wrappers
Anterior | Capítulo 14. Seguridad | Siguiente

## 14.6. TCP Wrappers

Escrito por: Tom Rhodes.

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.

### 14.6.1. Configuración inicial

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`.

### 14.6.2. Configuración avanzada

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.

#### 14.6.2.1. Órdenes externas

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).

#### 14.6.2.2. Opciones comodín

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ón:

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.

Anterior | Subir | Siguiente
14.5. Contraseñas de un solo uso | Inicio | 14.7. KerberosIV

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