15.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:
/etc/hosts.allow
/etc/hosts.deny
Cuando una solicitud de un cliente es recibida por un servicio wrapped TCP, sigue los pasos siguientes:
El servicio referencia 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 paso 2.
El servicio referencia /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:
Puesto que las reglas de acceso en hosts.allow son aplicadas primero, ellas toman precedencia sobre las reglas en hosts.deny. Por lo tanto, si se permite el acceso a un servicio en hosts.allow, una regla negando el acceso al mismo servicio en hosts.deny es ignorada.
Puesto que las reglas en cada archivo son leídas de arriba hacia abajo y la primera regla que coincida para un servicio dado es la única aplicada, el orden de las reglas es extremadamente importante.
Si no se encuentra ninguna regla para el servicio en ninguno de los archivos, o si no existe ninguno de los archivos, se concede el acceso al servicio.
Los sevicios wrapped TCP no hacen caché de las reglas desde los archivos acceso de host, por lo tanto cualquier cambio a hosts.allow o a hosts.deny tomarán efecto de inmediato sin tener que reiniciar el servicio de red.
15.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>: ...] |
<daemon list> — Una lista separada por comas de los nombres de procesos (no de los nombres de servicios) o el comodín ALL (consulte Sección 15.2.1.1). La lista de demonios también acepta operadores listados en Sección 15.2.1.3 para permitir mayor flexibilidad.
<client list> — Una lista separada por comas de nombres de host, direcciones IP, patrones especiales (consulte Sección 15.2.1.2), o comodines especiales (consulte Sección 15.2.1.1) el cual identifica los hosts afectados por la regla. La lista de clientes también acepta operadores listados en Sección 15.2.1.3 para permitir mayor flexibilidad.
<option> — Una acción opcional o una lista separada con puntos y comas de acciones realizadas cuando la regla es activada. Los campos de opciones soportan expansiones (consulte Sección 15.2.3.4), lance los comandos desde el shell, otorgue o prohiba el acceso y altere el comportamiento de registro (consulte Sección 15.2.3).
A continuación una muestra básica de una regla de acceso:
vsftpd : .example.com |
Esta regla instruye a los wrappers TCP a que vigile 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 en este ejemplo cada campo de opción está precedido por una barra oblicua invertida (\). Use la barra para prevenir la falla de la regla debido al largo.
 | Aviso | |
|---|---|---|
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
|
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 Sección 15.2.3.
15.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ó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. |
15.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.
Dirección IP/par máscara de red — 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
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 acceso a host para mayor información.
| Aviso |
|---|---|
Tenga mucho cuidado cuando esté creando reglas que requieran la resolución de nombres, tales como nombres de máquinas o de dominio. Los invasores pueden usar una variedad trucos para cambiar las reglas de tal manera que le den el acceso. Además, cualquier interrupción en el servicio DNS podría impedir el acceso a servicios incluso a la usuarios que tienen el permiso. Lo mejor es usar direcciones IP siempre que sea posible. |
15.2.1.3. 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. |
 | Nota |
|---|---|
Organizacionalmente, a menudo es más fácil usar operadores EXCEPT muy de vez en cuando, colocando las excepciones a la regla en el otro archivo de control de acceso. 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 ordenar a través de varios operadores EXCEPT. |
15.2.2. 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 no soporta la bíusqueda de host. Por esta razón, sólo utilice direcciones IP o la palabra clave ALL cuando la especificación de host es en hosts.allow o hosts.deny.
Además, cambios a las reglas de control de acceso portmap pueden que no tomen efecto de inmediato.
Los servicios ampliamente usados, tales como NIS y NFS, dependen de portmap para funcionar, por lo tanto este consciente de estas limitaciones.
15.2.3. Campos de opciones
Además de las reglas básicas para permitir o prohibir el acceso, la implementación de Red Hat 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.
15.2.3.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 (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 |
| Nota |
|---|---|
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. |
15.2.3.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.
15.2.3.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 directiva es a menudo usada 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. El comando twist debe ocurrir 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.
15.2.3.4. Expansiones
Las expansiones, cuando se utilizan en conjunto con las directivas spawn y twist proporcionan información sobre el cliente, servidor y los procesos relacionados.
Abajo se encuentra una lista de las expansiones soportadas:
%a — La dirección IP del cliente.
%A — 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 — El nombre del proceso demonio.
%h — El nombre de la máquina del cliente (o la direccción IP, si el nombre de la máquina no está disponible).
%H — El nombre de la máquina del servidor (o la dirección IP si el nombre de la máquina no está disponible).
%n — 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 — El nombre de la máquina del servidor. Si no está disponible aparecerá unknown. Si el nombre de la máquina y la dirección de la máquina no coinciden, aparecá paranoid.
%p — El ID del proceso demonio.
%s — Información varia del servidor como el proceso demonio y la máquina o la dirección IP del servidor.
%u — 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.
Instruye a los wrappers TCP que si una conexión al demonio SSH (sshd) es intentada 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 recursos adicionales concernientes a los wrappers TCP, vea Sección 15.5.