NAME
hosts_access - formato de ficheiros de control de acceso host
DESCRICIÓN
Esta páxina de manual describe un linguaxe de control de acceso simple que está baseado no patrón (nome do servidor / enderezo, nome de usuario) e servidor (nome do proceso, nome do servidor / enderezo) patróns. Exemplos amósanse ao final. O lector impaciente encárgase de saltarse á sección EXEMPLOS para unha rápida introdución. Unha versión ampliada da linguaxe de control de acceso descríbese no documento hosts_options (5). As extensións están activadas ao tempo de compilación do programa construíndo con -DPROCESS_OPTIONS.
No seguinte texto, o daemon é o nome do proceso dun proceso daemon da rede e o cliente é o nome e / ou enderezo dun servizo que solicita o anfitrión. Os nomes do proceso daemon da rede especifícanse no ficheiro de configuración inetd.
ARCHIVOS DE CONTROL DE ACCESO
O software de control de acceso consulta dous ficheiros . A busca pé na primeira partida.
O acceso concederase cando un par (daemon, client) coincide cunha entrada no ficheiro /etc/hosts.allow .
En caso contrario, negarase o acceso cando un par (daemon, client) coincide cunha entrada no ficheiro /etc/hosts.deny .
En caso contrario, o acceso concederase.
Un ficheiro de control de acceso non existente é tratado como se fose un ficheiro baleiro. Deste xeito, o control de acceso pódese desactivar sen proporcionar ficheiros de control de acceso.
REGLAS DE CONTROL DE ACCESO
Cada ficheiro de control de acceso consta de cero ou máis liñas de texto. Estas liñas son procesadas por orde de aparición. A busca finaliza cando se atopa unha coincidencia.
Ignórase un carácter de liña nova cando está precedido por un carácter de barra invertida. Isto permítelle romper longas liñas para que sexan máis fáciles de editar.
As liñas ou liñas en branco que comezan cun carácter `# 'son ignoradas. Isto permítelle inserir comentarios e espazos en branco para que as táboas sexan máis fáciles de ler.
Todas as outras liñas deben cumprir o seguinte formato, as cousas entre [] son opcionais:
daemon_list: client_list [: shell_command]
daemon_list é unha lista de un ou máis nomes de proceso de demos (valores argv [0]) ou comodíns (consulte a continuación).
client_list é unha lista de un ou máis nomes de host, enderezos de host, patróns ou comodíns (consulte a continuación) que coincidirán co nome ou o enderezo do servidor cliente.
As formas máis complexas daemon @ host e usuario @ host explicanse nas seccións nos patróns do punto final do servidor e nas búsquedas de nome de usuario do cliente, respectivamente.
Os elementos da lista deben estar separados por espazos en branco e / ou comas.
Con excepción das buscas de grupo de NIS (YP), todas as comprobacións de control de acceso non son sensibles a maiúsculas e minúsculas.
PATRONES
A linguaxe de control de acceso implementa os seguintes patróns:
Unha cadea que comeza cun `. ' carácter. Un nome de servidor coincide se os últimos compoñentes do seu nome coinciden co patrón especificado. Por exemplo, o patrón `.tue.nl 'coincide co nome do servidor` wzv.win.tue.nl'.
Unha cadea que remata cun `. ' carácter. Un enderezo host coincide se os seus primeiros campos numéricos coinciden coa cadea indicada. Por exemplo, o patrón '131.155.' coincide coa dirección de (case) cada servidor na rede da Universidade de Eindhoven (131.155.xx).
Unha cadea que comeza cun carácter `@ 'trátase como un nome de grupo de rede NIS (anteriormente YP). Un nome de servidor coincide se é un membro do servidor do grupo de rede especificado. As coincidencias de Netgroup non son compatibles con nomes de proceso de demarcación ou para nomes de usuarios de clientes.
Unha expresión do formulario `nnnn / mmmm 'interprétase como un par de` rede / máscara'. Unha dirección host de IPv4 coincide se `net 'é igual á AND bit a bit da dirección e a` mask'. Por exemplo, o patrón de rede / máscara `131.155.72.0/255.255.254.0 'coincide con todas as direccións no intervalo` 131.155.72.0' a través de '131.155.73.255'.
Unha expresión do formulario `[n: n: n: n: n: n: n: n] / m 'interprétase como un par de [net] / prefixlen'. Un enderezo host de IPv6 coincide se os bits 'prefixlen' de `net 'son iguais aos bits' prefixlen 'da dirección. Por exemplo, o patrón [net] / prefixlen `[3ffe: 505: 2: 1 ::] / 64 'coincide con todas as direccións no rango` 3ffe: 505: 2: 1 ::' a través de `3ffe: 505: 2: 1: ffff: ffff: ffff: ffff '.
Unha cadea que comeza cun carácter `/ 'trátase como un nome de ficheiro . Un nome ou enderezo de host coincide se coincide con calquera nome de host ou patrón de enderezo listado no ficheiro con nome. O formato do ficheiro é cero ou máis liñas con cero ou máis nome de servidor ou patróns de enderezos separados por espazo en branco. Pode empregarse un patrón de nome de ficheiro en calquera lugar onde se poida usar un nome de host ou un patrón de enderezo.
Os comodíns `* 'e`?' pódese empregar para combinar nomes de host ou enderezos IP . Este método de correspondencia non se pode usar xunto coa combinación `net / mask ', o nome do servidor coincide co inicio de`.' ou a dirección IP que acaba con '.'.
WILDCARDS
A linguaxe de control de acceso admite comodíns explícitos:
TODOS
O comodín universal, sempre coincide.
LOCAL
Coincide con calquera servidor cuxo nome non contén un carácter de punto.
DESCONOCIDO
Coincide con calquera usuario cuxo nome se descoñece e coincide con calquera servidor cuxo nome ou enderezo sexan descoñecidos. Este patrón debe ser usado con coidado: os nomes de host poden non estar dispoñibles debido a problemas de servidor de nomes temporais. Un enderezo de rede non estará dispoñible cando o software non poida descubrir o tipo de rede coa que está a falar.
Coñecido
Coincide con calquera usuario cuxo nome sexa coñecido e coincide con calquera servidor co nome e enderezo coñecidos. Este patrón debe ser usado con coidado: os nomes de host poden non estar dispoñibles debido a problemas de servidor de nomes temporais. Un enderezo de rede non estará dispoñible cando o software non poida descubrir o tipo de rede coa que está a falar.
PARANOID
Coincide con calquera servidor cuxo nome non coincida co seu enderezo. Cando tcpd está construído con -DPARANOID (modo predeterminado), deixa caer as solicitudes de devanditos clientes mesmo antes de mirar as táboas de control de acceso. Construír sen -DPARANOID cando desexa máis control sobre tales solicitudes.
OPERADORES
EXCEPTO
O uso desexado é do seguinte xeito: `list_1 EXCEPT list_2 '; esta construción corresponde a calquera cousa que coincida coa lista_1 a menos que coincida coa lista_2 . O operador EXCEPT pódese empregar en listas daemon_ e listas_ cliente. O operador EXCEPT pode ser anidado: se a linguaxe de control permita o uso de parénteses, `un EXCEPTO b EXCEPTO c 'parse como` (un EXCEPTO (b EXCEPTO c))'.
Se a regra de control de acceso de primeiro alcance contén un comando shell, ese comando está suxeito a% substitucións (ver a seguinte sección). O resultado é executado por un proceso de fillo a / bin / sh con entrada estándar, saída e erro conectado a / dev / null . Especifique un `& 'ao final do comando se non quere esperar ata que se complete.
Os comandos Shell non deben confiar na configuración PATH do inetd. En cambio, deberían empregar nomes de camiño absolutos ou deberían comezar cun PATH = declaración explícita.
O documento hosts_options (5) describe un idioma alternativo que usa o campo comando shell de xeito diferente e incompatible.
% EXPANSIÓNS
As seguintes expansións están dispoñibles nos comandos shell:
% a (% A)
Enderezo do servidor do cliente (servidor).
% c
Información do cliente: usuario @ hóspede, enderezo @ usuario, nome do servidor ou só un enderezo, dependendo da cantidade de información dispoñible.
% d
Nome do proceso daemon (argv [0] value).
% h (% H)
O nome ou o enderezo do servidor (servidor) do cliente, se o nome do servidor non está dispoñible.
% n (% N)
O nome do servidor cliente (servidor) (ou "descoñecido" ou "paranoico").
% p
O ID do proceso daemon.
% s
Información do servidor: daemon @ host, daemon @ address, ou só un nome do daemon, dependendo da cantidade de información dispoñible.
% u
O nome de usuario do cliente (ou "descoñecido").
%%
Expande a un único carácter `% '.
Os caracteres en% expansións que poden confundir o shell substitúense por guións baixos.
PATROLES DE TERMINACIÓN DO SERVIDOR
Para distinguir os clientes polo enderezo de rede ao que se conectan, use os patróns do formulario:
process_name @ host_pattern: client_list ...
Os patróns como estes pódense usar cando a máquina ten diferentes enderezos de internet con diferentes nómina de internet. Os provedores de servizos poden usar esta instalación para ofrecer arquivos FTP, GOPHER ou WWW con nomes de Internet que ata poden pertencer a diferentes organizacións. Vexa tamén a opción `twist 'no documento hosts_options (5). Algúns sistemas (Solaris, FreeBSD) poden ter máis dun enderezo de internet nunha interface física; con outros sistemas pode ter que recorrer a pseudo interfaces SLIP ou PPP que viven nun espazo de enderezos de rede dedicado.
O host_pattern obedece as mesmas regras de sintaxe que os nomes e os enderezos do servidor no contexto de client_list. Normalmente, a información do punto final do servidor só está dispoñible con servizos orientados á conexión.
CLIENTE USERNAME LOOKUP
Cando o servidor cliente admite o protocolo RFC 931 ou un dos seus descendentes (TAP, IDENT, RFC 1413), os programas de envoltorio poden obter información adicional sobre o propietario dunha conexión. A información do nome de usuario do cliente, cando está dispoñible, rexístrase xunto co nome do servidor cliente e pódese empregar para combinar modelos como:
daemon_list: ... user_pattern @ host_pattern ...
Os embolados do daemon pódense configurar ao tempo de compilación para realizar buscas de nome de usuario dirixidas por regras (por defecto) ou para interrogar sempre o servidor do cliente. No caso das buscas de nome de usuario dirixidas por regras, a regra anterior fará que a procura de nomes de usuario só sexa cando tanto a lista de daemon_list como o host_pattern coincidan.
Un patrón de usuario ten a mesma sintaxe que un patrón de proceso daemon, polo que se aplican os mesmos comodíns (non se admite a asociación do netgroup). Non se debe deixar levar con buscas de nome de usuario, porén.
Non se pode confiar a información do nome de usuario do cliente cando máis se necesita, é dicir, se o sistema cliente foi comprometido. En xeral, ALL e (UN) KNOWN son os únicos patróns de nomes de usuario que teñen sentido.
As buscas de nome de usuario só son posíbeis con servizos baseados en TCP e só cando o servidor cliente executa un demo axeitado; en todos os outros casos o resultado é "descoñecido".
Un erro de kernel coñecido de UNIX pode causar a perda de servizo cando un firewall bloquee as búsquedas de nome de usuario. O documento README envolto describe un procedemento para descubrir se o seu kernel ten este erro.
As buscas de nome de usuario poden causar atrasos notables para usuarios que non sexan UNIX. O tempo de espera predeterminado para as buscas de nome de usuario é de 10 segundos: demasiado curto para xestionar redes lentas, pero o tempo suficiente para irritar aos usuarios de PC.
As buscas selectivas de nome de usuario poden aliviar o último problema. Por exemplo, unha regra como:
daemon_list: @pcnetgroup ALL @ ALL
correspondería aos membros do netgroup de pc sen facer buscas de nome de usuario, pero realizaría buscas de nome de usuario con todos os demais sistemas.
DETECCIÓN DE DIRECCIÓN ACTOS DE ESPAZO
Un fallo no xerador de número de secuencia de moitas implementacións de TCP / IP permite que os intrusos sufran de xeito sinxelo hosts de confianza e que poidan romper vía, por exemplo, o servizo de shell remoto. O servizo IDENT (RFC931, etc.) pode usarse para detectar ataques de falsificación de enderezos de host e outros.
Antes de aceptar unha solicitude de cliente, os envolvedores poden usar o servizo IDENT para descubrir que o cliente non enviou a solicitude. Cando o servidor do cliente fornece o servizo IDENT, un resultado de busca de IDENT negativo (o cliente coincide con `UNKNOWN @ host ') é unha proba clara dun ataque de falsificación host.
Un resultado de busca IDENT positivo (o cliente coincide con `KNOWN @ host ') é menos fiable. É posible que un intruso falsee tanto a conexión do cliente como a busca de IDENT, aínda que facelo é moito máis difícil que o spoofing só cunha conexión de cliente. Tamén pode haberse mentir o servidor IDENT do cliente.
Nota: As buscas IDENT non funcionan con servizos UDP.
EXEMPLOS
O idioma é o suficientemente flexible como para que se poidan expresar diferentes tipos de políticas de control de acceso cun mínimo de alboroto. Aínda que a linguaxe utiliza dúas táboas de control de acceso, as políticas máis comúns pódense implementar cunha das táboas triviais ou mesmo baleiras.
Ao ler os exemplos a continuación, é importante darse conta de que se escanea a táboa de admitidos antes da táboa negativa, que a investigación finaliza cando se atopa unha coincidencia e que o acceso se concede cando non se atopa ningunha coincidencia.
Os exemplos usan o servidor e os nomes de dominio. Pódense mellorar incluíndo a información de enderezo e / ou rede / netmask, para reducir o impacto das fallas de busca de servidor temporal de nomes.
MÁIS CERRADO
Neste caso, o acceso é denegado por defecto. Só se admiten os hosts explícitamente autorizados.
A política por defecto (sen acceso) implementarase cun ficheiro de denegación trivial:
/etc/hosts.deny: ALL: ALL
Isto nega todo o servizo a todos os hosts, a non ser que se lles permita o acceso das entradas no ficheiro de permiso.
Os servidores explicitamente autorizados están listados no ficheiro de permiso. Por exemplo:
/etc/hosts.allow: ALL: LOCAL @some_netgroup
TODOS: .foobar.edu EXCEPTO terminalserver.foobar.edu
A primeira regra permite o acceso dos servidores no dominio local (non `. 'No nome do servidor) e dos membros do grupo net some_netgroup . A segunda regra permite o acceso de todos os servidores no dominio foobar.edu (notar o punto principal), coa excepción de terminalserver.foobar.edu .
Máis aberto
Aquí, o acceso obtense por defecto; só os servidores especificados explícitamente son rexeitados.
A política predeterminada (acceso concedido) fai redundante o ficheiro de permiso para que se poida omitir. Os servidores explicitamente non autorizados están listados no ficheiro de denegación. Por exemplo:
/etc/hosts.deny: ALL: some.host.name, .some.domain
ALL EXCEPT in.fingerd: other.host.name, .other.domain
A primeira regra denega algúns servidores e dominios de todos os servizos; A segunda regra aínda permite pedidos de demais hosts e dominios.
TRAPS BOOBY
O seguinte exemplo permite as solicitudes de tftp dos servidores no dominio local (notar o punto principal). As solicitudes de calquera outro servidor son rexeitadas. No canto do ficheiro solicitado, unha sonda de dedo envíase ao host infractor. O resultado envíase por correo ao 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-% raíz h) &O comando safe_finger vén co envoltorio tcpd e debe instalarse nun lugar axeitado. Limita os posibles danos dos datos enviados polo servidor de dedo remoto. Dá mellor protección que o comando dedo estándar.
A expansión das secuencias% h (servidor cliente) e% d (nome de servizo) descríbese na sección de comandos de shell.
Advertencia: non booby-trapache o dedo do dedo, a non ser que estea preparado para bucles infinitos.
Nos sistemas de devasa de rede este truco pode ser aínda máis levantado. O típico firewall de rede só fornece un conxunto limitado de servizos para o mundo exterior. Todos os demais servizos poden ser "erróneamente" como o exemplo anterior tftp. O resultado é un excelente sistema de alerta precoz.
VER TAMÉN
tcpd (8) tbp / ip daemon wrapper program. tcpdchk (8), tcpdmatch (8), programas de proba.Importante: use o comando man ( % home ) para ver como se usa un comando na súa computadora particular.