TCP Wrappers: qué son y cómo se utilizan en Linux

Hoy vamos a introducir el concepto de TCP Wrappers, o envoltorio TCP, vamos a ver cómo se configura y utiliza para maximizar la seguridad en sistemas *nix como Linux.

¿Qué son los TCP Wrappers?

¿Qué son los TCP wrappers? ¿Qué ventajas y desventajas tienen sobre un firewall común como IPTables? ¿Cómo podemos utilizarlos para maximizar la seguridad de nuestro Linux, Mac OSx o Solaris?

Un TCP Wrapper es una biblioteca que provee un control de acceso simple y administración de logs estandarizada para aplicaciones que lo soporten, y reciban conexiones de red.

Es decir, aquellas aplicaciones de red que puedan recibir conexiones, como los servicios de red (sshd por ejemplo), si soportan TCP Wrappers, vamos a poder realizar algunos controles y logs adicionales con las conexiones entrantes.

Los TCP Wrappers son listas de control de acceso (ACL – access control list) basadas en hosts, y utilizadas para filtrar accesos de red a los servicios locales.

Surgieron en los años ’90 para proteger las estaciones de trabajo Unix de ataques maliciosos por red.

Algunas de sus desventajas son:

• Todas las aplicaciones de servicio Unix deben estar compiladas para trabajar con la biblioteca libwrap.
• Los wrappers no funcionan con servicios de llamadas a procedimiento remoto (RPC) sobre TCP).
• La característica de búsqueda de nombre de usuario del equipo atacante por defecto está desactivada, ya que utiliza identd/xinetd como servicio de identificación, pero identd puede congelarse cuando hay muchas conexiones TCP.

Por otra parte, los TCP/Wrappers presentan una gran ventaja sobre los firewalls comunes: trabajan en capa 7 (App), por lo que pueden, entre otras cosas, filtrar consultas aún cuando se utilice cifrado.

Básicamente, lo recomendable es utilizar mecanismos de protección tanto basados en host, como TCP wrappers, como mecanismos de red, como firewalls netfilter.

Los servicios comunes, como pop3, ftp, sshd, telent, etc, suelen soportar TCP/Wrappers.

Beneficios de los TCP Wrappers

1. Logging: las conexiones monitoreadas con TCP wrappers son reportadas por medio del syslog del sistema
2. Control de acceso: soportan un control de acceso simple basado en patrones de comparación.
3. Verificación del hostname: verifican el nombre del hostname del cliente utilizando los servicios DNS.
4. Poseen protección contra spoofing.

¿Qué aplicaciones soportan TCP Wrappers?

Para saber si un binario soporta TCP Wrappers, o TCPD, deberá haber sido compilado utilizando la biblioteca dinámica libwrap.so, por lo que podremos ver este detalle en la salida del comando ldd de esta forma:

ldd /ruta/al/binario | grep libwrap.so

La ruta al binario podemos encontrarla con el comando which o whereis. Por ejemplo, si en Debian hacemos:

whereis sshd

Tendremos seguramente una salida como esta:

sshd: /usr/sbin/sshd /usr/share/man/man8/sshd.8.gz

Lo que nos dice que el binario es /usr/sbin/sshd. Ahora, podemos ver si fue compilado este software con soporte para tcp wrappers con el siguiente comando:

ldd /usr/sbin/sshd |grep libwrap.so

Cuya salida, dependiendo del sistema, podrá ser:

libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x00007f67b131d000)

Archivos y binarios importantes

• Daemon tcpd: software que controla el acceso para los servicios de red.
• /etc/hosts.allow: Este archivo contiene los nombres de hosts que tienen permitido utilizar servicios de red.
• /etc/hosts.deny: Este archivo contiene los nombres de hosts que no pueden utilizar servicios de red.
• Si el mismo cliente, usuario o ip está listado en ambos archivos, hosts.allow tiene prioridad sobre hosts.deny, a tener cuidado con esto.

Sintaxis de los arvhivos hosts.allow y hosts.deny

La sintaxis de estos archivos es la siguiente:

lista_de_servicios : lista_de_clientes [ : comando_shell ]

Donde:

• lista_de_servicios es una lista de los nombres de proceso de los daemons a considerar.
• lista_de_clientes es una lista de los hostnames, direcciones ip, patrones especiales o comodines que se compararán con cada cliente conectado.

Comodines

Los comodines para match pueden ser estos:

• ALL: comodín universal, coincide con todos los patrones.
• LOCAL: coincide con todos los hostnames que no contengan puntos (los no FQDN).
• UNKNOWN: coincide con cualquier usuario cuyo nombre es desconocido. Este padrón debería utilizarse con cuidado, ya que por problemas temporales del servidor de nombres, puede que un hostname no pueda ser reconocido, y coincida con UNKNOWN y apliquen estas reglas (generalmente de restricción).
• KNOWN: coincide con todos los hosts cuyos nombres puedan ser reconocidos. Igual que en el caso anterior, debe utilizarse con cuidado.
• PARANOID: coincide con cualquier hostname que no coincida con su dirección ip en la resolución de nombres. TCPD bloqueará los accesos de estos hosts incluso antes de leer las reglas de acceso.
• Puede utilizarse además, el operador EXCEPT para cargar patrones de excepción a una determinada regla.

Otros patrones

• Una cadena que comienza con «.», como «.juncotic.com», coincidirá con todos los hosts que sean subdominios de juncotic.com, como campus.juncotic.com.
• Una cadena que termine con «.», como «192.168.», coincidirá con cualquier dirección ip que comience con «192.168.x.y».
• Una cadena que comienza con «@» indica el nombre de un grupo NIS (o YP).
• Una expresión de la forma «n.n.n.n/m.m.m.m» es considerada dirección_ip/mascara.
• Una expresión de la forma «n.n.n.n/mm» es considerada dirección_ip/longitud_mascara.
• Una expresión de la forma «[n:n:n:n:n:n:n:n]/m» es considerada dirección IPv6 y longitud de prefijo.
• Una expresión que comience con «/» es considerado nombre de archivo, y coincidirá con todos los patrones listados en el archivo especificado.
• Los caracteres «*» y «?» pueden utilizarse para coincidir hostnames y direcciones IP.

Algunas sustituciones %

Podemos utilizar las sustituciones % para generar cadenas y loguear en archivos de reporte, por ejemplo.

• %a (%A) La dirección del cliente/servidor.
• %c Información del cliente, usuario@hostname, usuario@dirección, un hostname, una dirección sola, todo depende de la info que se pueda recabar.
• %d El nombre del proceso daemon (*(argv) para los que programan C :-))
• %h (%H) El hostname o dirección del cliente/servidor si el hostname no está disponible.
• %n (%N) El hostname del cliente/servidor, o «unknown» o «paranoid»).
• %r (%R) El número de puerto del cliente/servidor, o 0 (cero).
• %p El PID del daemon.
• %s Información del cliente, usuario@hostname, usuario@dirección, un hostname, una dirección sola, todo depende de la info que se pueda recabar.
• %u El username del cliente (o «unknown»).
• %% Un caracter «%».

Un ejemplo vale mas que mil palabras

Veamos ahora algunos ejemplos de configuración para aclarar los conceptos.

Ejemplo 1:

Si en el hosts.deny colocamos esta regla:

ALL: ALL

Todo acceso desde la red será denegado, salvo que lo habilitemos en el hosts.allow.

Si ahora en el hosts.allow colocamos lo siguiente:

ALL: LOCAL @devels
ALL: .juncotic.com EXCEPT campus.juncotic.com

Ahora, si quisiéramos loguear un acceso mediante syslog y luego denegarlo, podemos hacer algo como lo siguiente en el hosts.deny:

ALL : .maliciosos.com \
    : spawn (/bin/echo %h intento acceder al servicio %d >> \
      /var/log/connections.log ) \
    :deny

Esta línea verifica si el acceso se hace desde el dominio maliciosos.com, y en el caso de hacerlo, introduce una línea en /var/log/connections.log con un mensaje, para luego denegar el acceso.

Ejemplo 2:

Un ejemplo típico de Unix: en el hosts.allow podemos habilitar a ciertos y determinados hosts a acceder a algunos servicios:

popd : 192.168.1.2 192.168.1.140
imapd : 192.168.10.0/255.255.255.0
sendmail : 192.168.10.0/255.255.255.0
sshd : 192.168.1.22 172.13.21.34

Y denegamos el resto de los accesos en el hosts.deny:

ALL : ALL

Ejemplo 3:

Por otro lado, si en el hosts.allow tenemos esto:

sshd ,ftpd : ALL
ALL: localhost

Y en el hosts.deny tenemos esto:

ALL: ALL

Vamos a permitir el acceso local a cualquier servicio, vamos a permitir el acceso remoto solamente a sshd y a ftpd, y vamos a denegar todos los demás accesos.

Viendo la configuración implementada

Con el comando «tcpdchk -v» podemos ver la configuración sumarizada de los archivos hosts.allow y hosts.deny.

Algunas consideraciones sobre firewalling

• Se necesitan ambos, TCP wrappers, y firewalling de Layer 3 para proteger un sistema. El TCP Wrapper NO sustituye a un firewall como netfilter/iptables o pf sense.
• Los TCP Wrappers suelen utilizarse para filtrar direcciones ip y hostnames.
• Nunca hay que configurar un TCP Wrapper en un host firewall, ahí solamente dejamos el firewall para evitar confusiones, puesto que el host firewall no debería disponer de servicios locales a la red.
• Los TCP Wrappers deberían estar configurados en todas las estaciones de trabajo Unix/Linux.
• No está bueno utilizar grupos NIS / YP en los TCP Wrappers, ya no suelen activarse.
• El TCP Wrapper puede incrementar un poco la seguridad de un firewall Layer 3 en un server porque puede leer tráfico de aplicación cifrada, mientras que un firewall Layer 3 no.

Conclusiones

Hemos llegado al final del artículo, espero que haya sido interesante y constructivo.

Esta información ha sido extraída principalmente de la página de manual de hosts_access:

man hosts_access

Ahí se detallan y explican los comodines, patrones %, etc.

Hasta la próxima!!