Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

2.3.2. Archivos de configuración de envolturas TCP

Para determinar si un cliente tiene permiso de conectarse al servicio, las envolturas TCP hacen referencia a los dos archivos siguientes, los cuales se conocen como archivos de acceso de hosts:
  • /etc/hosts.allow
  • /etc/hosts.deny
Cuando un servicio de envolturas TCP recibe una solicitud de cliente, realiza los siguientes pasos:
  1. Hacer referencia a /etc/hosts.allow — El servicio de envolturas TCP lee en secuencia el archivo /etc/hosts.allow y aplica la primera regla especificada para ese servicio. Si encuentra una regla que coincida, permitirá la conexión. Si no, irá al siguiente paso.
  2. Hacer referencia a /etc/hosts.deny — El servicio de envolturas TCP lee en secuencia el archivo /etc/hosts.deny. Si encuentra la regla coincidente, negará la conexión. Si no, otorgará acceso al servicio.
Cuando utilice las envolturas TCP para proteger servicios de red, es importante tener en cuenta lo siguiente:
  • Puesto que las reglas de acceso en hosts.allow se aplican primero, pueden tener prioridad sobre las reglas especificadas en hosts.deny. Por lo tanto, si se permite el acceso al servicio en hosts.allow, se omitirá la regla que niega el acceso al mismo servicio en hosts.deny.
  • Las reglas en cada archivo se leen de arriba a abajo y la primera que concuerde para el servicio determinado será la única que se aplica. El orden de las reglas es extremadamente importante.
  • Si no se encuentran reglas para el servicio en cada archivo o si no existe ningún archivo, se otorgará el acceso al servicio.
  • Los servicios de envolturas TCP no guardan en cache las reglas de los archivos de acceso de hosts, por lo tanto los cambios a hosts.allow o hosts.deny se efectuarán inmediatamente, sin reiniciar los servicios de redes.

Aviso

Si la última línea de un archivo de acceso de hosts no es un caracter de salto de línea (creado al presionar la tecla Enter key), la última regla en el archivo fallará y se registrará un error ya sea en /var/log/messages o en /var/log/secure. También es el caso para la regla que extiende varias líneas sin necesidad de usar el caracter de barra invertida. El ejemplo a continuación ilustra la parte importante de un mensaje de registro de un error de la directiva debido a alguna de estas circunstancias:
warning: /etc/hosts.allow, line 20: missing newline or line too long

2.3.2.1. Cómo dar formato a las reglas de acceso

El formato para /etc/hosts.allow y /etc/hosts.deny es idéntico. Cada regla debe tener su propia línea. Las líneas en blanco o líneas que inician con el símbolo de numeral (#) se omiten.
Cada regla usa el siguiente formato básico para controlar el acceso a servicios de redes:
<daemon list>: <client list> [: <option>: <option>: ...]
  • <Lista de demonios> — Una lista de los nombres de procesos separados por coma (no los nombres del servicio) o el comodín ALL. La lista de demonios también acepta operadores (consulte la Sección 2.3.2.1.4, “Operadores”) para permitir mayor flexibilidad.
  • <Lista de clientes> — Una lista de nombres de hosts separados por coma, direcciones IP de host, patrones especiales o comodines que identifican a los hosts afectados por la regla. El cliente también acepta los operadores listados en la Sección 2.3.2.1.4, “Operadores” para permitir mayor flexibilidad.
  • <opción> — Una acción óptima o lista separada por comas de las acciones realizadas cuando se activa la regla. Los campos de opciones soportan expansiones, lanzan los comandos de shell, permiten o niegan el acceso y alteran la conducta de registro.
A continuación, una muestra básica de una regla de acceso de host:
vsftpd : .example.com
Esta regla le solicita a las envolturas TCP observar las conexiones para el demonio FTP (vsftpd) desde cualquier host en el dominio example.com. Si la regla aparece en hosts.allow, se acepta la conexión. Si la regla aparece en hosts.deny, se rechaza la conexión.
La siguiente muestra de reglas de acceso de hosts es más compleja y utiliza dos campos de opciones:
sshd : .example.com  \ : spawn /bin/echo `/bin/date` access denied>>/var/log/sshd.log \ : deny
Observe que cada campo de opción va precedido por la barra invertida (\). Use la barra invertida para evitar fallas de la regla debido a la longitud.
Esta regla de muestra establece que si se intenta una conexión al demonio SSH (sshd) desde un host en el dominio example.com, se ejecuta el comando echo para anexar el intento en un archivo de registro especial y se niega la conexión. Puesto que se utiliza la directiva opcional deny, esta línea niega el acceso incluso si aparece en el archivo hosts.allow. Consulte la Sección 2.3.2.2, “Campos de opciones\n” para obtener una visión más detallada en opciones disponibles.
2.3.2.1.1. Comodines
Los comodines le permiten a las envolturas TCP encontrar más fácilmente los grupos de demonios o hosts. Los comodines se utilizan en el campo de la lista del cliente de reglas de acceso.
Los siguientes comodines están disponibles:
  • ALL — Concuerda con todo. Puede servir tanto para la lista de demonios como para la lista de clientes.
  • LOCAL — Concuerda con cualquier host que no contiene un punto (.), tal como localhost.
  • KNOWN — Concuerda con cualquier host cuyo nombre y dirección se conocen o cuando el usuario es conocido.
  • UNKNOWN — Concuerda con cualquier host cuyo nombre o dirección se desconozcan o cuando el usuario es desconocido.
  • PARANOID — Concuerda con cualquier host cuyo nombre no corresponda a la dirección.

Importante

Los comodines KNOWN, UNKNOWN y PARANOID se deben usar con cuidado, puesto que dependen de un servidor de DNS para corregir la operación. Cualquier interrupción de la resolución de nombre puede impedir que usuarios legítimos puedan acceder a un servicio.
2.3.2.1.2. Patrones
Los patrones se pueden usar en el campo de cliente de reglas de acceso para más grupos específicos de hosts de clientes.
A continuación, una lista de los patrones comunes para entradas en el campo de cliente:
  • Nombre de host que comienza por un punto (.) — Al poner un punto en el comienzo de un nombre de host buscará todos los hosts que comparten los componentes listados del nombre. El ejemplo a continuación se aplica a cualquier host dentro del dominio example.com:
    ALL : .example.com
  • Dirección IP que termina en un punto (.) — Al poner un punto al final de una dirección IP encontrará todos los hosts que compartan los grupos numéricos de una dirección IP. El ejemplo a continuación se aplica a cualquier host dentro de la red 192.168.x.x:
    ALL : 192.168.
  • Par de dirección IP y máscara de red — Las expresiones de máscara de red también sirven de patrón para controlar el acceso a un grupo de direcciones IP determinado. Los ejemplos a continuación se aplican a cualquier host con un rango de direcciones de 192.168.0.0 a 192.168.1.255:
    ALL : 192.168.0.0/255.255.254.0

    Importante

    Cuando se opera en un espacio de direcciones IPv4, el par de longitud del prefijo y dirección (prefixlen) las declaraciones de pares (notación CIDR) are no son compatibles. Solamente las reglas IPv6 pueden usar este formato.
  • [IPv6 address]/prefixlen pair — los pares [net]/prefixlen también sirven de patrón para controlar el acceso a un grupo determinado de direcciones IPv6. El siguiente ejemplo se aplicaría a cualquier host con un rango de direcciones de 3ffe:505:2:1:: through 3ffe:505:2:1:ffff:ffff:ffff:ffff:
    ALL : [3ffe:505:2:1::]/64
  • Asterisco (*) — Los asteriscos pueden usarse para buscar todos los grupos o nombres de hosts o direcciones IP siempre y cuando no estén mezclados en una lista de cliente que contenga otros tipos de patrones. El ejemplo a continuación se aplicaría a cualquier host dentro del dominio example.com:
    ALL : *.example.com
  • Barra invertida (/) — Si la lista de un cliente comienza por una barra invertida, se considerará como un nombre de archivo. Esto es útil si se necesitan las reglas que especifican grandes cantidades de hosts. El ejemplo a continuación, se refiere a las envolturas TCP para el archivo /etc/telnet.hosts para todas las conexiones de Telnet:
    in.telnetd : /etc/telnet.hosts
Las envolturas TCP también aceptan otros patrones menos utilizados. Consulte la página de manual 5 hosts_access para obtener mayor información.

Aviso

Sea cuidadoso al utilizar nombres de hosts y nombres de dominio. Los agresores pueden realizar una variedad de trucos para sortear la resolución de nombre. Además, la ruptura del servicio DNS evita incluso a usuarios autorizados el uso de servicios de red. Por lo tanto, es mejor usar las direcciones IP cuando sea posible.
2.3.2.1.3. Portmap y envolturas TCP
La implementación de Portmap de envolturas TCP no soporta la búsqueda de hosts, lo cual significa que portmap no puede usar nombres de host para identificar hosts. Como consecuencia, las reglas de control de acceso para portmap en hosts.allow o hosts.deny deben usar direcciones IP o la palabra clave ALL, para especificar hosts.
Los cambios a las reglas de control de acceso portmap no se efectúan inmediatamente. Necesitará reiniciar el servicio de portmap.
Los servicios ampliamente utilizados, tales como NIS y NFS, dependen de portmap para operar, por lo tanto tenga en cuenta estas limitaciones.
2.3.2.1.4. Operadores
En el momento, las reglas de control de acceso solamente aceptan el operador, EXCEPT. Se puede utilizar tanto para la lista de demonios como para la lista de clientes de una regla.
El operador EXCEPT permite a excepciones específicas ampliar las coincidencias dentro de la misma regla.
En el siguiente ejemplo del archivo hosts.allow, todos los hosts example.com tienen permiso para conectarse a los servicios, a excepción de cracker.example.com:
ALL: .example.com EXCEPT cracker.example.com
En otro ejemplo del archivo hosts.allow, los clientes de la red 192.168.0.x pueden usar todos los servicios a excepción de FTP:
ALL EXCEPT vsftpd: 192.168.0.

Nota

Para ordenar, suele ser más fácil evitar el uso de los operadores EXCEPT. De esta manera se permite que otros administradores puedan escanear rápidamente los archivos para ver qué hosts tienen permiso o no de acceder a los servicios sin tener que ordenar a través de los operadores EXCEPT.