TCP Wrappers, la alternativa a iptables

Cada día la gente es más consciente de la necesidad de un sistema seguro, preocupándose más y más de las medidas de seguridad que tienen que tomar... La necesidad más básica de todas es sin duda el uso de un cortafuegos; todo equipo o servidor requiere de un cortafuegos, y más de una vez se ha mencionado en este blog el uso del cortafuegos iptables; un cortafuegos muy útil y completo, cuya única "pega" es su elevada curva de aprendizaje. Es por eso que, si no queremos recurrir a herramientas de terceros, como fail2ban, podemos recurrir a una herramienta parecida a iptables que está instalada por defecto en el sistema denominada TCP Wrappers.

Una de las principales ventajas de TCP Wrappers es que los cambios realizados en éste son realizados permanentemente, mientras que en iptables es necesario almacenar las reglas en un script y de ahí hacer que éste se ejecute en cada arranque; es decir que por defecto los cambios de TCP Wrappers son persistentes, cosa que en iptables no.

La configuración de TCP Wrappers se divide en dos ficheros; uno que establece los HOSTS o fuentes desde las que aceptará las conexiones y otro que establecería los HOSTS a los que negaría la conexión.  Dichos ficheros se llaman hosts.allow y hosts.deny. Ambos ficheros están vacíos pero tienen varias líneas de ejemplo que nos pueden servir como guías para añadir nuestras reglas.

El primero de estos ficheros, y el más importante de los dos es hosts.allow; en caso de estar correctamente configurado es posible omitir el uso de hosts.deny ya que se pueden poner para ÚNICAMENTE se admitan ciertos hosts o para que se excluyan ciertos orígenes. También es importante saber que un host que tenga el acceso permitido en hosts.allow, tendrá acceso aunque se le haya especificado lo contrario en hosts.deny, pues allow tiene prioridad sobre deny.

Aunque cada uno de los ficheros tienen un propósito distinto, con conocer la estructura general a aplicar en cualquiera de éstos bastaría, pues ambos se rigen por las mismas reglas y sintaxis. Toda regla que se aplique en estos ficheros tiene la siguiente estructura:

<servicio/servicios> : cliente/clientes :[opciones]

Cada parte tiene el siguiente significado:

• Servicios: La primera opción de todas está basada en el servicio o servicios que deseamos controlar. Para referirnos a éste tendremos que llamarlo por su nombre de proceso (por ejemplo sshd o atftpd), con lo que es muy importante tener claros dichos nombres. 

• Cliente: Aquí lo único que habría que especificar sería la fuente que queremos tener controlada en esta regla. Para hacer referencia a dicha fuente se puede poner una ip en concreto, un rango de ips o un nombre de dominio. Para hacer referencia a un rango de ips podemos hacerlo de dos formas; la primera y la más simple sería dejando un espacio vacío, es decir que si por ejemplo quisiésemos controlar las ips desde 192.168.1.0 a 192.168.1.255, podríamos simplemente decir en la regla que queremos controlar dicho rango así: 192.168.1., pero si quisiésemos ser más precisos, podemos especificar el rango de ip completo junto a la mascara de la siguiente forma: 192.168.1.0/255.255.255.0. 
• Opciones: Una acción ocpional o una serie de acciones opcionales; dichas acciones son comandos de shell que pueden permitir o prohibir el acceso o incluso alterar el comportamiento de la conexión.

Para hacer nuestra vida más fácil, podemos recurrir a una serie de nombres, reverenciados también como comodines, que agrupan algunos conceptos; nombres que pueden envolver los servicios, los clientes o ambos. Estos comodines no son nada menos que 5:

• ALL: Hace referencia a "todo" y puede ser usado tanto para hacer referencia a los servicios como a los clientes. Si se usase ALL con los servicios, se mencionarían a TODOS los servicios, mientras que con los clientes haríamos referencia a todos ellos.
• LOCAL: Este comodín únicamente puede ser usado con los clientes; comodín que hace referencia a localhost.
• KNOWN: También puede ser usado únicamente con los clientes y hace referencia a todos los hosts conocidos por el sistema operativo; hosts que serían conocidos porque han sido especificados en el apartado /etc/hosts o porque están presentes en la tabla ARP.
• UNKNOWN: Es usado en el apartado de clientes y hace exactamente lo contrario que KNOWN, es decir hacer referencia a los hosts desconocidos.
• PARANOID: Hace referencia a los hosts cuyo "hostname" o nombre no corresponden con su dirección ip; esto viene bien para evitar accesos desde orígenes suplantados.

Con lo visto hasta ahora ya seríamos capaces de crear reglas tanto en el fichero hosts.allow, como en el hosts.deny; por ejemplo podríamos añadir estas reglas en el fichero allow:

Esta regla permitiría el acceso a cualquiera 

ALL: ALL

Si deseásemos permitir que la ip 192.168.1.5 pudiese acceder al servicio sshd; habría que añadir la regla:

sshd: 192.168.1.5

Podemos ser un poco más laxos y decir que en vez de limitarse con la 192.168.1.5; se incluyan a todas las ips dentro del rango 192.168.1.0/255.255.255.0:

sshd: 192.168.1.0/255.255.255.0

Imaginemos que queremos añadir unas acciones extra al comando anterior; acciones que en este caso serían que mostrase un mensaje en pantalla y que además, en vez de permitir el acceso a dicho rango de ips lo denegase:

sshd: 192.168.1.0/255.255.255.0 :spawn /bin/echo "Prohibido el acceso" >/var/log/syslog :deny

Esto es perfectamente aplicable tanto en host.allow como en deny; con la salvedad de que el comportamiento por defecto de host.deny sería bloquear las conexiones que coincidiesen con las reglas añadidas en el fichero en cuestión. 

Además de lo comentado anteriormente, existe un operador especial llamado EXCEPT, que permite crear excepciones específicas para las reglas añadidas. La mejor forma de entender esto sería viendolo aplicado a una regla. Imaginemos que tenemos esta regla añadida al host.allow:

ALL: 192.168.1.0/255.255.255.0 EXCEPT 192.168.1.1

En esta regla diríamos que todas las ips del rango 192.168.1.0-255 serían contempladas por ésta, a excepción de la ip 192.168.1.1; dicha ip estaría excluida de dicho rango. 

También podemos usar el operador EXCEPT para los servicios, tal y como podemos ver a continuación:

ALL EXCEPT atftpd: .testdomain.com

En este caso la regla relacionaría a los clientes provenientes de testdomain.com que se conectasen a a cualquier servicio a excepción de atftpd.

Como podéis ver, TCP Wrappers, si bien no abarca tantas cosas como iptables, puede ser un cortafuegos muy sólido y valioso que puede bloquear cualquier amenaza a la perfección; siempre y cuando se hayan creado las reglas adecuadas para ello.

Espero que os haya resultado útil

Saludos.