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:
- Hacer referencia a
/etc/hosts.allow— El servicio de envolturas TCP lee en secuencia el archivo/etc/hosts.allowy aplica la primera regla especificada para ese servicio. Si encuentra una regla que coincida, permitirá la conexión. Si no, irá al siguiente paso. - 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.allowse aplican primero, pueden tener prioridad sobre las reglas especificadas enhosts.deny. Por lo tanto, si se permite el acceso al servicio enhosts.allow, se omitirá la regla que niega el acceso al mismo servicio enhosts.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.allowohosts.denyse 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.
Nota
Puede obtener mayor información sobre los términos arriba mencionados en esta guía:
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.0a192.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::through3ffe: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.hostspara 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.
