hosts.deny – Comando Linux – Comando Unix

Esta página del manual describe un lenguaje de control de acceso simple que se basa en los patrones del cliente (nombre/dirección del host, nombre de usuario) y del servidor (nombre del proceso, nombre/dirección del host).

Esta página del manual describe un lenguaje de control de acceso simple que se basa en los patrones del cliente (nombre/dirección del host, nombre de usuario) y del servidor (nombre del proceso, nombre/dirección del host). Se dan ejemplos al final. Se anima al lector impaciente a saltar a la sección de EJEMPLOS para una introducción rápida.

Una versión extendida del lenguaje de control de acceso se describe en el documento hosts_options (5). Las extensiones se activan en el momento de la compilación del programa compilando con -DPROCESS_OPTIONS.

En el siguiente texto, daemon es el nombre de proceso de un proceso de daemon de red, y client es el nombre y/o dirección de un servicio de solicitud de host. Los nombres de proceso del demonio de red se especifican en el archivo de configuración inetd.

Archivos de control de acceso

El software de control de acceso consulta dos archivos. La búsqueda se detiene en el primer partido:

Se otorgará acceso cuando un par (daemon, cliente) coincida con una entrada en el archivo /etc/hosts.allow .

De lo contrario, se denegará el acceso cuando un par (daemon, cliente) coincida con una entrada en el archivo /etc/hosts.deny .

De lo contrario, se otorgará acceso.

Un archivo de control de acceso no existente se trata como si fuera un archivo vacío. Por lo tanto, el control de acceso se puede desactivar al no proporcionar archivos de control de acceso.

Reglas de control de acceso

Cada archivo de control de acceso consta de cero o más líneas de texto. Estas líneas se procesan en orden de aparición. La búsqueda termina cuando se encuentra una coincidencia.

Un carácter de nueva línea se ignora cuando está precedido por un carácter de barra diagonal inversa. Esto le permite dividir líneas largas para que sean más fáciles de editar.

Las líneas en blanco o las líneas que comienzan con un carácter ‘#’ se ignoran. Esto le permite insertar comentarios y espacios en blanco para que las tablas sean más fáciles de leer.

Todas las demás líneas deben cumplir el siguiente formato, las cosas entre [] son ​​opcionales:

daemon_list: client_list [: shell_command]

daemon_list es una lista de uno o más nombres de proceso de daemon (valores argv [0]) o comodines (ver más abajo).

client_list es una lista de uno o más nombres de host, direcciones de host, patrones o comodines (ver más abajo) que se compararán con el nombre o la dirección del host del cliente.

Las formas más complejas daemon @ host y user @ host se explican en las secciones sobre patrones de punto final del servidor y en búsquedas de nombre de usuario del cliente, respectivamente.

Los elementos de la lista deben estar separados por espacios en blanco y/o comas.

Con la excepción de las búsquedas de grupos de red NIS (YP), todas las comprobaciones de control de acceso no distinguen entre mayúsculas y minúsculas.

Patrones

El lenguaje de control de acceso implementa los siguientes patrones:

Una cadena que comienza con un `. ‘ personaje. Un nombre de host coincide si los últimos componentes de su nombre coinciden con el patrón especificado. Por ejemplo, el patrón `.tue.nl ‘coincide con el nombre de host` wzv.win.tue.nl’.

Una cadena que termina con un ‘.’ personaje. Una dirección de host coincide si sus primeros campos numéricos coinciden con la cadena dada. Por ejemplo, el patrón `131.155. ‘ coincide con la dirección de (casi) cada host en la red de la Universidad de Eindhoven (131.155.x.x).

Una cadena que comienza con un carácter `@ ‘se trata como un nombre de grupo de red NIS (anteriormente YP). Un nombre de host coincide si es un miembro de host del grupo de red especificado. Las coincidencias de Netgroup no son compatibles con los nombres de proceso de daemon ni con los nombres de usuario del cliente.

Una expresión de la forma `n.n.n.n/m.m.m.m ‘se interpreta como un par` net/mask’. Una dirección de host IPv4 coincide si ‘net’ es igual al AND bit a bit de la dirección y la ‘máscara’. Por ejemplo, el patrón de red/máscara ‘131.155.72.0/255.255.254.0’ coincide con cada dirección en el rango ‘131.155.72.0’ a ‘131.155.73.255’.

Una expresión de la forma `[n: n: n: n: n: n: n: n]/m ‘se interpreta como un par` [net]/prefixlen’. Una dirección de host IPv6 coincide si los bits ‘prefixlen’ de ‘net’ son iguales a los bits ‘prefixlen’ de la dirección. Por ejemplo, el patrón [net]/prefixlen `[3ffe: 505: 2: 1 ::]/64 ‘coincide con cada dirección en el rango` 3ffe: 505: 2: 1 ::’ a `3ffe: 505: 2: 1: ffff: ffff: ffff: ffff ‘.

Una cadena que comienza con un carácter `/ ‘se trata como un nombre de archivo. Un nombre de host o una dirección coinciden si coinciden con cualquier nombre de host o patrón de dirección enumerado en el archivo con nombre. El formato del archivo es cero o más líneas con cero o más nombres de host o patrones de dirección separados por espacios en blanco. Se puede usar un patrón de nombre de archivo en cualquier lugar donde se pueda usar un nombre de host o un patrón de dirección.

Comodines `* ‘y`?’ se puede usar para hacer coincidir nombres de host o direcciones IP. Este método de coincidencia no se puede usar junto con la coincidencia `net/mask ‘, la coincidencia de nombre de host comienza con`.’ o coincidencia de dirección IP que termina con `. ‘.

Comodines

El lenguaje de control de acceso admite comodines explícitos:

Todas

El comodín universal, siempre coincide.

Local

Coincide con cualquier host cuyo nombre no contenga un carácter de punto.

Desconocido

Coincide con cualquier usuario cuyo nombre es desconocido, y coincide con cualquier host cuyo nombre o dirección sea desconocida. Este patrón debe usarse con cuidado: los nombres de host pueden no estar disponibles debido a problemas temporales del servidor de nombres. Una dirección de red no estará disponible cuando el software no pueda determinar con qué tipo de red está hablando.

Conocido

Coincide con cualquier usuario cuyo nombre se conozca y con cualquier host cuyo nombre se conozca y dirección. Este patrón debe usarse con cuidado: los nombres de host pueden no estar disponibles debido a problemas temporales del servidor de nombres. Una dirección de red no estará disponible cuando el software no pueda determinar con qué tipo de red está hablando.

Paranoico

Coincide con cualquier host cuyo nombre no coincida con su dirección. Cuando tcpd se crea con -DPARANOID (modo predeterminado), elimina las solicitudes de dichos clientes incluso antes de mirar las tablas de control de acceso. Construya sin PDARANOID cuando desee tener más control sobre tales solicitudes.

Operadores

EXCEPTO

El uso previsto es de la forma: `list_1 EXCEPT list_2 ‘; esta construcción coincide con todo lo que coincide con list_1 a menos que coincida con list_2 . El operador EXCEPTO se puede usar en daemon_lists y en client_lists. El operador EXCEPT puede estar anidado: si el lenguaje de control permitiera el uso de paréntesis, ‘a EXCEPT b EXCEPT c’ se analizaría como ‘(a EXCEPT (b EXCEPT c))’.

COMANDOS DE SHELL

Si la regla de control de acceso de primera coincidencia contiene un comando de shell, ese comando está sujeto a% de sustituciones (consulte la siguiente sección). El resultado se ejecuta mediante un proceso hijo /bin/sh con entrada, salida y error estándar conectados a /dev/null . Especifique un ‘&’ al final del comando si no desea esperar hasta que se haya completado.

Los comandos de Shell no deben depender de la configuración PATH del inetd. En su lugar, deberían usar nombres de ruta absolutos, o deberían comenzar con una RUTA explícita = cualquier instrucción.

El documento hosts_options (5) describe un lenguaje alternativo que utiliza el campo de comando de shell de una manera diferente e incompatible.

% EXPANSIONES

Las siguientes expansiones están disponibles dentro de los comandos de shell:

% a (% A)

La dirección de host del cliente (servidor).

%C

Información del cliente: usuario @ host, usuario @ dirección, un nombre de host o simplemente una dirección, dependiendo de la cantidad de información disponible.

%re

El nombre del proceso daemon (valor argv [0]).

%S.S)

El nombre o la dirección del host del cliente (servidor), si el nombre del host no está disponible.

% n (% N)

El nombre de host del cliente (servidor) (o «desconocido» o «paranoico»).

%pag

La identificación del proceso daemon.

% s

Información del servidor: daemon @ host, daemon @ address, o simplemente un nombre de daemon, dependiendo de la cantidad de información disponible.

% u

El nombre de usuario del cliente (o «desconocido»).

%%

Se expande a un solo carácter ‘%’.

Los caracteres en% de expansiones que pueden confundir al shell se reemplazan por guiones bajos.

PATRONES DE ENDPOINT DEL SERVIDOR

Para distinguir a los clientes por la dirección de red a la que se conectan, use patrones de la forma:

nombre_proceso @ host_pattern: lista_cliente …

Patrones como estos se pueden usar cuando la máquina tiene diferentes direcciones de Internet con diferentes nombres de host de Internet. Los proveedores de servicios pueden usar este servicio para ofrecer archivos FTP, GOPHER o WWW con nombres de Internet que incluso pueden pertenecer a diferentes organizaciones. Vea también la opción ‘twist’ en el documento hosts_options (5). Algunos sistemas (Solaris, FreeBSD) pueden tener más de una dirección de Internet en una interfaz física; con otros sistemas, es posible que deba recurrir a pseudo interfaces SLIP o PPP que viven en un espacio de direcciones de red dedicado.

Host_pattern obedece las mismas reglas de sintaxis que los nombres de host y las direcciones en el contexto de lista de clientes. Por lo general, la información del punto final del servidor está disponible solo con servicios orientados a la conexión.

BUSQUEDA DE NOMBRE DE USUARIO DEL CLIENTE

Cuando el host del cliente admite el protocolo RFC 931 o uno de sus descendientes (TAP, IDENT, RFC 1413), los programas de contenedor pueden recuperar información adicional sobre el propietario de una conexión. La información del nombre de usuario del cliente, cuando está disponible, se registra junto con el nombre del host del cliente y se puede usar para hacer coincidir patrones como:

daemon_list: … user_pattern @ host_pattern …

Los contenedores de daemon se pueden configurar en tiempo de compilación para realizar búsquedas de nombre de usuario basadas en reglas (por defecto) o para interrogar siempre al host del cliente.En el caso de las búsquedas de nombre de usuario basadas en reglas, la regla anterior provocaría la búsqueda de nombre de usuario solo cuando coincidan daemon_list y host_pattern .

Un patrón de usuario tiene la misma sintaxis que un patrón de proceso de daemon, por lo que se aplican los mismos comodines (no se admite la pertenencia a grupos de red). Sin embargo, uno no debería dejarse llevar por las búsquedas de nombre de usuario.

No se puede confiar en la información del nombre de usuario del cliente cuando más se necesita, es decir, cuando el sistema del cliente se ha visto comprometido. En general, ALL y (UN) KNOWN son los únicos patrones de nombre de usuario que tienen sentido.

Las búsquedas de nombre de usuario solo son posibles con servicios basados ​​en TCP, y solo cuando el host del cliente ejecuta un demonio adecuado; en todos los demás casos, el resultado es «desconocido».

Un conocido error de kernel de UNIX puede causar la pérdida del servicio cuando un firewall bloquea las búsquedas de nombre de usuario. El documento README del contenedor describe un procedimiento para averiguar si su núcleo tiene este error.

Las búsquedas de nombre de usuario pueden causar retrasos notables para los usuarios que no son UNIX. El tiempo de espera predeterminado para las búsquedas de nombre de usuario es de 10 segundos: demasiado corto para hacer frente a redes lentas, pero lo suficientemente largo como para irritar a los usuarios de PC.

Las búsquedas selectivas de nombre de usuario pueden aliviar el último problema. Por ejemplo, una regla como:

daemon_list: @pcnetgroup ALL @ ALL

coincidiría con los miembros del grupo de red de la PC sin realizar búsquedas de nombre de usuario, pero realizaría búsquedas de nombre de usuario con todos los demás sistemas.

DETECCIÓN DE ATAQUES DE DIRECCIÓN DE DIRECCIÓN

Una falla en el generador de números de secuencia de muchas implementaciones de TCP/IP permite a los intrusos hacerse pasar fácilmente por hosts confiables y entrar, por ejemplo, a través del servicio de shell remoto. El servicio IDENT (RFC931, etc.) se puede usar para detectar tales y otros ataques de suplantación de direcciones de host.

Antes de aceptar una solicitud del cliente, los contenedores pueden usar el servicio IDENT para descubrir que el cliente no envió la solicitud. Cuando el host del cliente proporciona el servicio IDENT, un resultado de búsqueda de IDENT negativo (el cliente coincide con `UNKNOWN @ host ‘) es una fuerte evidencia de un ataque de suplantación de host.

Un resultado de búsqueda IDENT positivo (el cliente coincide con `KNOWN @ host ‘) es menos confiable. Es posible que un intruso falsifique tanto la conexión de cliente como la búsqueda de IDENT, aunque hacerlo es mucho más difícil que falsificar solo una conexión de cliente. También puede ser que el servidor IDENT del cliente esté mintiendo.

Nota: las búsquedas de IDENT no funcionan con los servicios UDP.

Ejemplos

El lenguaje es lo suficientemente flexible como para que se puedan expresar diferentes tipos de políticas de control de acceso con un mínimo de alboroto. Aunque el lenguaje utiliza dos tablas de control de acceso, las políticas más comunes se pueden implementar con una de las tablas que es trivial o incluso vacía.

Al leer los ejemplos a continuación, es importante darse cuenta de que la tabla de permisos se escanea antes que la tabla de denegación, que la búsqueda termina cuando se encuentra una coincidencia y que se otorga acceso cuando no se encuentra ninguna coincidencia.

Los ejemplos usan nombres de host y dominio. Se pueden mejorar mediante la inclusión de información de dirección y/o red/máscara de red, para reducir el impacto de las fallas temporales de búsqueda del servidor de nombres.

Mayormente cerrado

En este caso, el acceso es denegado por defecto. Solo los hosts explícitamente autorizados tienen acceso permitido.

La política predeterminada (sin acceso) se implementa con un archivo trivial de denegación:

/etc/hosts.deny: ALL: ALL

Esto niega todo servicio a todos los hosts, a menos que se les permita el acceso mediante entradas en el archivo de permiso.

Los hosts explícitamente autorizados se enumeran en el archivo de permiso. Por ejemplo:

/etc/hosts.allow: ALL: LOCAL @some_netgroup ALL: .foobar.edu EXCEPTO terminaleserver.foobar.edu

La primera regla permite el acceso desde los hosts en el dominio local (no `. ‘En el nombre del host) y desde los miembros del grupo de red some_netgroup . La segunda regla permite el acceso desde todos los hosts en el dominio foobar.edu (observe el punto inicial), con la excepción de terminaleserver.foobar.edu .

Mayormente abierto

Aquí, el acceso se otorga por defecto; solo a los hosts especificados explícitamente se les niega el servicio.

La política predeterminada (acceso otorgado) hace que el archivo de permiso sea redundante para que pueda omitirse. Los hosts explícitamente no autorizados se enumeran en el archivo denegado. Por ejemplo:

/etc/hosts.deny: ALL: some.host.name, .some.domain ALL EXCEPT in.fingerd: other.host.name, .other.domain

La primera regla niega a algunos hosts y dominios todos los servicios; la segunda regla todavía permite solicitudes de dedo de otros hosts y dominios.

Trampas explosivas

El siguiente ejemplo permite solicitudes tftp de hosts en el dominio local (observe el punto inicial). Las solicitudes de cualquier otro host son denegadas. En lugar del archivo solicitado, se envía una sonda de dedo al host infractor. El resultado se envía por correo al superusuario.

/etc/hosts.allow:

 in.tftpd: LOCAL, .my.domain 
/etc/hosts.deny:
in.tftpd: ALL: spawn (/ some/where/safe_finger -l @% h | \
/usr/ucb/mail -s% d-% h root) &

El comando safe_finger viene con el contenedor tcpd y debe instalarse en un lugar adecuado. Limita el posible daño de los datos enviados por el servidor de dedo remoto. Ofrece una mejor protección que el comando de dedo estándar.

La expansión de las secuencias% h (host del cliente) y% d (nombre del servicio) se describe en la sección sobre comandos de shell.

Advertencia: no atrapes con tu dedo demonio, a menos que estés preparado para bucles infinitos.

En los sistemas de firewall de red, este truco puede llevarse aún más lejos. El firewall de red típico solo proporciona un conjunto limitado de servicios al mundo exterior. Todos los demás servicios se pueden «corregir» al igual que el ejemplo tftp anterior. El resultado es un excelente sistema de alerta temprana.

Use el comando man (% man ) para ver cómo se usa un comando en su computadora en particular.

Rate article
labsfabs.com
Add a comment