17.2. Archivos de configuración de Wrappers TCP

Para determinar si una máquina cliente tiene permitido conectarse a un servicio, los wrappers TCP referencian los siguientes dos archivos, los cuales se conocen comúnmente como archivos de acceso a host:

Cuando una solicitud de un cliente es recibida por un servicio wrapped TCP, sigue los pasos siguientes:

  1. Referencias a /etc/hosts.allow. — El servicio wrapped TCP analiza secuencialmente el archivo /etc/hosts.allow y aplica la primera regla especificada para ese servicio. Si encuentra una regla que coincide, permite la conexión. Si no, se va al próximo paso.

  2. Referencias /etc/hosts.deny. — El servicio wrapped TCP analiza secuencialmente el archivo /etc/hosts.deny. Si encuentra una regla que coincide, rechaza la conexión. Si no, se concede acceso al servicio.

Lo siguiente son puntos muy importantes a considerar cuando se usen wrappers TCP para proteger servicios de red:

AvisoAviso
 

Si la última línea de un archivo de acceso a host no es un caracter de nueva línea (creado al presionar la tecla [Intro]), la última regla en el archivo fallará y se registrará un error bien sea a /var/log/messages o a /var/log/secure. Este es también el caso para reglas que se expanden en múltiples líneas sin usar la barra oblicua. El ejemplo siguiente ilustra la porción relevante del mensaje registrado por una falla de una regla debido a alguna de estas circunstancias:

warning: /etc/hosts.allow, line 20: missing newline or line too long

17.2.1. Formatear reglas de acceso

Los formatos para /etc/hosts.allow y /etc/hosts.deny son idénticos. Cualquier línea en blanco que comience con un símbolo de numeral o almohadilla (#) será ignorada, y cada regla debe estar en su propia línea.

Las reglas se tienen que formatear de la siguiente manera:

<daemon list>: <client list> [: <option>: <option>: ...]

A continuación una muestra básica de una regla de acceso:

vsftpd : .example.com 

Esta regla instruye a los wrappers TCP a que estén atentos por conexiones al demonio FTP (vsftpd) desde cualquier host en el dominio example.com. Si esta regla aparece en hosts.allow, la conexión será aceptada. Si esta regla aparece en hosts.deny, la conexión será rechazada.

El próximo ejemplo de regla de acceso es un poco más compleja y utiliza dos campos de opciones:

sshd : .example.com  \
: spawn /bin/echo `/bin/date` access denied>>/var/log/sshd.log \
: deny

Note que cada campo de opción está precedido por una barra oblicua invertida (\). Use la barra para prevenir que falle la regla debido al largo de la misma.

Esta regla de ejemplo indica que si una conexión al demonio SSH (sshd) se intenta desde un host en el dominio example.com, ejecute el comando echo (lo cual registrará el intento a un archivo especial) y rechace la conexión. Puesto que se usa la directiva opcional deny, esta línea rechazará el acceso aún si aparece en el archivo hosts.allow. Para más detalles sobre las opciones disponibles, consulte la Sección 17.2.2.

17.2.1.1. Comodines

Los comodines permiten a los wrappers TCP coincidir más fácilmente grupos de demonios o hosts. Son usados con mayor frecuencia en el campo de lista de cliente de las reglas de acceso.

Se pueden utilizar los siguientes comodines:

  • ALL — Hace corresponder todo. Se puede usar para la lista de demonios o en la lista de clientes.

  • LOCAL — Hace corresponder todos los nombres de máquinas que no contengan un punto (.), tal como localhost.

  • KNOWN — Hace corresponder todas las máquinas cuyos nombres y direcciones son conocidos o donde el usuario es conocido.

  • UNKNOWN — Hace corresponder todas las máquinas cuyos nombres y direcciones sean desconocidas o en el caso en el que se desconozca el usuario.

  • PARANOID — Hace corresponder todas las máquinas cuyo nombre no se corresponda con la dirección.

AtenciónAtención
 

Los comodines KNOWN, UNKNOWN y PARANOID tienen que usarse con cuidado porque si se utilizan de una manera incorrecta los usuarios que sí que tengan acceso a un determinado servicio pueden perderlo.

17.2.1.2. Patrones

Los patrones se pueden utilizar en el campo de lista de cliente de las reglas de acceso para especificar de forma más precisa grupos de host clientes.

La siguiente es una lista de los patrones más comúnmente aceptados para una entrada de lista de cliente:

  • Nombre de host comenzando con un punto (.) — Al colocar un punto al comienzo de un nombre de host, se hace coincidir todos los hosts compartiendo los componentes listados del nombre. El ejemplo siguiente aplicaría a cualquier host dentro del dominio example.com:

    ALL : .example.com
  • Dirección IP que termina con un punto (.) — Al colocar un punto al final de una dirección IP hace corresponder todos los hosts compartiendo el grupo numérico inicial de una dirección IP. El ejemplo siguiente aplicará a cualquier host dentro de la red 192.168.x.x:

    ALL : 192.168.
  • Par dirección IP/máscara — Las expresiones de máscaras de red también pueden ser usadas como un patrón de control de acceso a un grupo particular de direcciones IP. El ejemplo siguiente aplicaría a cualquier host con una dirección de 192.168.0.0 hasta 192.168.1.255:

    ALL : 192.168.0.0/255.255.254.0
     

    ImportanteImportante
     

    Cuando se esté trabajando en el espacio de direcciones de IPv4, no se soporta el largo del par dirección/prefijo (prefixlen). Sólo las reglas IPv6 pueden utilizar este formato.

  • Par [Dirección IPv6]/prefixlen — Los pares [net]/prefixlen también pueden ser usadas como un patrón de control de acceso a un grupo particular de direcciones IPv6. El ejemplo siguiente aplicaría a cualquier host con una dirección de 3ffe:505:2:1:: hasta 3ffe:505:2:1:ffff:ffff:ffff:ffff:

    ALL : [3ffe:505:2:1::]/64
     
  • El asterisco (*) — Los asteríscos pueden ser usados para coincidir grupos completos de nombres de host o direcciones IP, siempre y cuando no se mezclen en la lista de cliente conteniendo otros tipos de patrones. El ejemplo siguiente aplicaría a cualquier host dentro del dominio example.com:

    ALL : *.example.com
  • La barra oblicua (/) — Si una lista de cliente con una barra, es tratado como un nombre de archivo. Esto en muy útil si es necesario reglas especificando un gran número de hosts. El ejemplo siguiente se refiere a wrappers TCP en el archivo /etc/telnet.hosts para todas las conexiones de Telnet:

    in.telnetd : /etc/telnet.hosts

Otros patrones menos usados son también aceptados por los wrappers TCP. Vea la página de manual 5 de hosts_access para mayor información.

AvisoAviso
 

Tenga mucho cuidado cuando utilice nombres de host y de dominio.Los invasores pueden usar una variedad trucos para burlar las resolución de nombres.Además, cualquier interrupción en el servicio DNS podría impedir el acceso a servicios incluso a la usuarios que tienen el permiso.

Por lo tanto, lo mejor es usar direcciones IP siempre que sea posible.

17.2.1.3. Portmap y Wrappers TCP

Cuando se crean reglas de control de acceso para portmap, no utilice nombres de host pues la implementación de wrappers TCP de portmap no soporta las búsqueda por host. Por esta razón, sólo utilice direcciones IP o la palabra clave ALL cuando especifique hosts en hosts.allow o en hosts.deny.

Además, cambios a las reglas de control de acceso portmap pueden que no tomen efecto de inmediato si no se reinicia el servicio portmap.

Los servicios ampliamente usados, tales como NIS y NFS, dependen de portmap para funcionar, por lo tanto este consciente de estas limitaciones.

17.2.1.4. Operadores

Actualmente, las reglas de control de acceso aceptan un operador, EXCEPT. Se puede usar tanto en la lista de demonios como en la lista de cliente de una regla.

El operador EXCEPT permite excepciones específicas a coincidencias más amplias dentro de la misma regla.

En el ejemplo siguiente desde un archivo hosts.allow, todos los hosts de example.com pueden conectarse a todos los servicios excepto cracker.example.com:

ALL: .example.com EXCEPT cracker.example.com

En el otro ejemplo desde un archivo hosts.allow, clientes desde la red 192.168.0.x pueden usar todos los servicios excepto para FTP:

ALL EXCEPT vsftpd: 192.168.0.

NotaNota
 

Organizacionalmente, a menudo es más fácil evitar el uso de operadores EXCEPT. Esto permite a otros administradores escanear rápidamente los archivos adecuados para ver qué hosts deberían tener o no acceso a los servicios, sin tener que revisar varios operadores EXCEPT.

17.2.2. Campos de opciones

Además de las reglas básicas para permitir o prohibir el acceso, la implementación de Red Hat Enterprise Linux de wrappers TCP soporta extensiones al lenguaje de control de acceso a través de los campos de opciones. Mediante el uso de campos de opciones dentro de las reglas de acceso al host, los administradores pueden llevar a cabo una gran variedad de tareas tales como alterar el comportamiento del registro, consolidar el control de acceso y lanzar comandos del shell.

17.2.2.1. Registro

Los campos de opciones le permiten a los administradores cambiar fácilmente la facilidad de conexión y el nivel de prioridad para una regla usando la directiva severity.

En el ejemplo siguiente, las conexiones al demonio SSH desde cualquier host en el dominio example.com son registrados a la facilidad por defecto authpriv syslog (debido a que no se especifica un valor de facilidad) con una prioridad de emerg:

sshd : .example.com : severity emerg

Es también posible especificar una facilidad utilizando la opción severity. El ejemplo siguiente registra cualquier intento de conexión SSH por cualquier hosts desde el dominio example.com a la facilidad local0 con una prioridad de alert:

sshd : .example.com : severity local0.alert

NotaNota
 

En práctica, este ejemplo no funcionará hasta que el demonio syslog (syslogd) sea configurado para registrar a la facilidad local0. Consulte la página del manual de syslog.conf para información sobre la configuración de las facilidades de registro personalizadas.

17.2.2.2. Control de acceso

Los campos de opciones también le permiten a los administradores explícitamente otorgar o prohibir el acceso de máquinas en un sola regla, añadiendo la directiva allow o deny al final de la opción.

Por ejemplo, las dos reglas siguientes permiten conexiones SSH desde client-1.example.com, pero prohiben conexiones desde client-2.example.com:

sshd : client-1.example.com : allow
sshd : client-2.example.com : deny

Al permitir el control de acceso por regla, el campo de opciones permite a los administradores consolidar todas las reglas de acceso en un sólo archivo: bien sea hosts.allow o hosts.deny. Algunos consideran que esta es una forma más fácil de organizar reglas de acceso.

17.2.2.3. Comandos de la Shell

Los campos de opciones permiten a las reglas de acceso lanzar comandos de la shell a través de las directivas siguientes:

  • spawn — Lanza un comando de la shell como un proceso hijo. Esta directiva de opción puede realizar tareas como el uso de /usr/sbin/safe_finger para obtener más información sobre el cliente solicitante o la creación de archivos de registro especiales usando el comando echo.

    En el ejemplo siguiente, los clientes intentando accesar servicios Telnet desde el dominio example.com son registrados discretamente a un archivo especial:

    in.telnetd : .example.com \
      : spawn /bin/echo `/bin/date` from %h>>/var/log/telnet.log \
      : allow
  • twist — Reemplaza el servicio solicitado con el comando especificado. Esta directriz se utiliza a menudo para colocar trampas para intrusos (también llamados "potes de miel"). También se puede utilizar para enviar mensajes a los clientes que se estan conectando. La directriz twist debe estar al final de la línea de la regla.

    En el ejemplo siguiente, los clientes intentando accesar servicios FTP desde el dominio example.com se les envía un mensaje a través del comando echo:

    vsftpd : .example.com \
    : twist /bin/echo "421 Bad hacker, go away!"

Para más información sobre las opciones de comando de la shell, consulte la página del manual de hosts_options.

17.2.2.4. Expansiones

Las expansiones, cuando se utilizan en conjunto con las directrices spawn y twist, proporcionan información sobre el cliente, servidor y los procesos relacionados.

Abajo se encuentra una lista de las expansiones soportadas:

  • %a — Suministra la dirección IP del cliente.

  • %A — Suministra la dirección IP del servidor.

  • %c — Proporciona información variada sobre el cliente, como el nombre de usuario y el de la máquina o el nombre del usuario y la dirección IP.

  • %d — Proporciona el nombre del proceso demonio.

  • %h — Suministra el nombre de la máquina del cliente (o la direccción IP, si el nombre de la máquina no está disponible).

  • %H — Suministra el nombre de la máquina del servidor (o la dirección IP si el nombre de la máquina no está disponible).

  • %n — Proporciona el nombre de la máquina del cliente. Si no está disponible aparecerá unknown. Si el nombre de la máquina y la dirección de la máquina no se corresponden, aparecerá paranoid.

  • %N — Proporciona el nombre de la máquina del servidor. Si no está disponible aparecerá unknown. Si el nombre de la máquina y su dirección no coinciden, aparecerá paranoid.

  • %p — Suministra el ID del proceso demonio.

  • %s — Suministra información varia del servidor como el proceso demonio y la máquina o la dirección IP del servidor.

  • %u — Proporciona el nombre de usuario del cliente. Si no está disponible aparecerá unknown.

El ejemplo siguiente usa una expansión en conjunto con el comando spawn para identificar el host cliente en un archivo de registro personalizado.

Cuando se intentan conexiones al demonio SSH (sshd) desde un host en el dominio example.com, ejecute el comando echo para registrar el intento, incluyendo el nombre del host cliente (usando la expansión %h), a un archivo especial:

sshd : .example.com  \
: spawn /bin/echo `/bin/date` access denied to %h>>/var/log/sshd.log \
: deny

De forma similar, las expansiones se pueden utilizar para personalizar mensajes de vuelta al cliente. En el ejemplo siguiente, los clientes intentando accesar servicios FTP desde el dominio example.com son informados que se les ha prohibido acceder al servidor:

vsftpd : .example.com \
: twist /bin/echo "421 %h has been banned from this server!"

Para una explicación completa de las expansiones disponibles, así como también opciones de control de acceso adicionales, revise la sección 5 de la página man para hosts_access (man 5 hosts_access) y la página man de hosts_options.

Para información adicional sobre los TCP wrappers, refiérase a la Sección 17.5. Para más información sobre cómo asegurar los TCP wrappers, consulte el capítulo llamado Seguridad del Servidor en el Manual de seguridad de Red Hat Enterprise Linux.