Hosts.allow - Comando Linux

Encontrar seus hosts permitidos

Você provavelmente pousou aqui procurando uma maneira de ver os hosts (outros computadores) com permissão para acessar seu Linux sistema. Bem, a menos que você já tenha configurado restrições, provavelmente é qualquer computador que tenta, por padrão.

Na verdade, isso não é totalmente verdade. Sem nenhuma regra definida no arquivo /etc/hosts.allow ou /etc/hosts.deny, seu computador irá passar conexões para seus respectivos aplicativos. Então, se alguém tentar se conectar SSH, a conexão chegará ao seu sistema Linux, onde será entregue ao SSH para login. Se as credenciais adequadas não forem fornecidas, a conexão será negada.

Se certos hosts forem permitidos ou negados, o Linux primeiro verificará essas regras para ver se a solicitação de entrada deve ser permitida. Então, ele seguirá o mesmo padrão de antes.

Você pode verificar seus hosts permitidos listando o conteúdo do arquivo /etc/hosts.allow.

cat /etc/hosts.allow. 

Se você não vir nada lá, seu sistema provavelmente permitirá a passagem de qualquer conexão.

Usando o arquivo Hosts.allow

O arquivo /etc/hosts.allow permite que você escolha quais computadores podem acessar seu sistema. No arquivo, você pode especificar regras simples em texto simples para informar ao seu computador como lidar com as conexões. Para começar, crie uma regra permitindo a qualquer computador todos os serviços.

TUDO TUDO. 

É simples assim. Então, se quiser excluir um computador com problema, você também pode fazer isso.

TODOS: TODOS EXCETO 192.168.1.110. 

Existem várias outras palavras-chave que você pode usar para lidar com diferentes conjuntos de computadores. Por exemplo, você pode permitir todo o tráfego local como este:

TODOS: 192.168.1.0/24. 

Ou você pode usar a palavra-chave "LOCAL".

TODOS: LOCAIS. 

Você também pode usar nomes de domínio. Por exemplo:

TODOS: .example.com. 

Você pode usar a palavra-chave "EXCEPT" aqui também para excluir um subdomínio potencialmente problemático.

TODOS: .example.com EXCETO testing.example.com. 

Você também pode especificar regras para daemons específicos. Portanto, se você deseja controlar o acesso SSH, deve configurar regras para 'sshd'.

sshd: LOCAL. 

O arquivo hosts.allow oferece suporte à listagem de daemons na mesma linha, se suas regras forem as mesmas. Por exemplo:

sshd, in.ftpd: LOCAL. 

Observe a "entrada". parte em "in.ftpd?" Isso permite que você especifique o tráfego de entrada.

Então, você tem a opção de colocar tudo junto.

sshd, in.ftpd: LOCAL EXCETO 192.168.1.110. 

Essas são as maneiras mais comuns de usar o arquivo /etc/hosts.allow em seu sistema Linux. Para uma análise técnica completa do que você pode fazer com o arquivo /etc/hosts.allow, continue na próxima seção.

Análise Técnica

Esta página do manual descreve o Linux como uma linguagem de controle de acesso simples que se baseia no cliente (nome / endereço do host, nome do usuário) e servidor (nome do processo, nome do host / endereço) padrões. Exemplos são dados no final. O leitor impaciente é encorajado a pular para a seção de Exemplos para uma introdução rápida. Uma versão estendida da linguagem de controle de acesso é descrita no hosts_options (5) documento. As extensões são ativadas no momento da criação do programa, compilando com —DPROCESS_OPTIONS.

No texto a seguir, demônio é o nome do processo de um processo daemon de rede, e cliente é o nome e / ou endereço de um serviço de solicitação de host. Os nomes dos processos daemon de rede são especificados no arquivo de configuração inetd.

Arquivos de controle de acesso

O software de controle de acesso consulta dois arquivos. A busca para na primeira correspondência.

O acesso será concedido quando um par (daemon, cliente) corresponder a uma entrada no /etc/hosts.allowArquivo.

Caso contrário, o acesso será negado quando um par (daemon, cliente) corresponder a uma entrada no/etc/hosts.deny Arquivo.

Caso contrário, o acesso será concedido.

Um arquivo de controle de acesso não existente é tratado como se fosse um arquivo vazio. Portanto, o controle de acesso pode ser desativado ao não fornecer arquivos de controle de acesso.

Regras de controle de acesso

Cada arquivo de controle de acesso consiste em zero ou mais linhas de texto. Essas linhas são processadas em ordem de aparecimento. A pesquisa termina quando uma correspondência é encontrada.

Um caractere de nova linha é ignorado quando é precedido por um caractere de barra invertida. Isso permite que você divida linhas longas para que sejam mais fáceis de editar.

Linhas em branco ou linhas que começam com um caractere `# 'são ignoradas. Isso permite inserir comentários e espaços em branco para facilitar a leitura das tabelas.

Todas as outras linhas devem satisfazer o seguinte formato, as coisas entre [] sendo opcionais:

daemon_list: client_list [: shell_command]

daemon_list é uma lista de um ou mais nomes de processos daemon (valores argv [0]) ou curingas (veja abaixo).

lista de clientes é uma lista de um ou mais nomes de host, endereços de host, padrões ou curingas (veja abaixo) que serão comparados com o nome de host ou endereço do cliente.

As formas mais complexas daemon @ host e usuário @ host são explicados nas seções sobre padrões de endpoint do servidor e pesquisas de nome de usuário do cliente, respectivamente.

Os elementos da lista devem ser separados por espaços em branco e / ou vírgulas.

Com a exceção de NIS (YP) netgroup lookups, todas as verificações de controle de acesso não diferenciam maiúsculas de minúsculas.

Padrões

A linguagem de controle de acesso implementa os seguintes padrões:

Uma string que começa com um `. ' personagem. Um nome de host é correspondido se os últimos componentes de seu nome corresponderem ao padrão especificado. Por exemplo, o padrão `.tue.nl 'corresponde ao nome do host` wzv.win.tue.nl'.

Uma string que termina com um `. ' personagem. Um endereço de host é correspondido se seus primeiros campos numéricos corresponderem à string fornecida. Por exemplo, o padrão `131.155. ' corresponde ao endereço de (quase) todos os hosts na rede da Universidade de Eindhoven (131.155.x.x).

Uma string que começa com um caractere `@ 'é tratada como um nome de grupo de rede NIS (anteriormente YP). UMA nome de anfitrião é correspondido se for um membro do host do grupo de rede especificado. As correspondências de grupos de rede não são suportadas para nomes de processos daemon ou para nomes de usuários clientes.

Uma expressão da forma `n.n.n.n / m.m.m.m 'é interpretada como um par` rede / máscara'. Um endereço de host IPv4 é correspondido se `net 'é igual ao bit a bit AND do endereço e da` máscara'. Por exemplo, o padrão de rede / máscara `131.155.72.0/255.255.254.0 'corresponde a todos os endereços no intervalo de` 131.155.72.0' a `131.155.73.255 '.

Uma expressão da forma `[n: n: n: n: n: n: n: n: n] / m 'é interpretada como um par` [net] / prefixlen'. Um endereço de host IPv6 é correspondido se os bits `prefixlen 'de` net' são iguais aos bits `prefixlen 'do endereço. Por exemplo, o padrão [net] / prefixlen `[3ffe: 505: 2: 1 ::] / 64 'corresponde a todos os endereços no intervalo` 3ffe: 505: 2: 1 ::' a `3ffe: 505: 2: 1: ffff: ffff: ffff: ffff '.

Uma string que começa com um caractere `/ 'é tratada como um nome do arquivo. Um nome de host ou endereço é correspondido se corresponder a qualquer nome de host ou padrão de endereço listado no arquivo nomeado. O formato do arquivo é zero ou mais linhas com zero ou mais nomes de host ou padrões de endereço separados por um espaço em branco. Um padrão de nome de arquivo pode ser usado em qualquer lugar que um nome de host ou padrão de endereço possa ser usado.

Curingas `* 'e`?' pode ser usado para combinar nomes de host ou Endereços IP. Este método de correspondência não pode ser usado em conjunto com a correspondência `net / mask ', correspondência de nome de host começando com`.' ou endereço IP que termina em `. '.

Curingas

A linguagem de controle de acesso oferece suporte a caracteres curinga explícitos, incluindo:

• 'TUDO' - O curinga universal, sempre corresponde.
• 'LOCAL' - Corresponde a qualquer host cujo nome não contenha um caractere de ponto.
• 'DESCONHECIDO' - Corresponde a qualquer usuário cujo nome é desconhecido e corresponde a qualquer host cujo nome ou endereço são desconhecidos. Esse padrão deve ser usado com cuidado: nomes de host podem não estar disponíveis devido a problemas temporários do servidor de nomes. UMA Endereço de rede estará indisponível quando o software não conseguir descobrir com que tipo de rede está se comunicando.
• 'CONHECIDO' - Corresponde a qualquer usuário cujo nome é conhecido e corresponde a qualquer host cujo nome e endereço são conhecidos. Esse padrão deve ser usado com cuidado: nomes de host podem não estar disponíveis devido a problemas temporários do servidor de nomes. Um endereço de rede ficará indisponível quando o software não conseguir descobrir com que tipo de rede está se comunicando.
• 'PARANOID' - Corresponde a qualquer host cujo nome não corresponda a seu endereço. Quando o tcpd é construído com -DPARANOID (modo padrão), ele elimina as solicitações de tais clientes antes mesmo de olhar as tabelas de controle de acesso. Crie sem -DPARANOID quando quiser mais controle sobre essas solicitações.

'OPERADORES'

• 'EXCETO' —O uso pretendido é no formato: `lista_1 EXCETO lista_2 '; esta construção corresponde a qualquer coisa que corresponda list_1 a menos que corresponda lista_2. O operador EXCEPT pode ser usado em daemon_lists e em client_lists. O operador EXCEPT pode ser aninhado: se a linguagem de controle permitir o uso de parênteses, `a EXCEPT b EXCEPT c 'seria analisado como` (a EXCEPT (b EXCEPT c))'.
• Comandos Shell —Se a primeira regra de controle de acesso correspondida contiver um comando shell, esse comando está sujeito a% substituições (consulte a próxima seção). O resultado é executado por um /bin/sh processo filho com entrada, saída e erro padrão conectado a /dev/null. Especifique um `& 'no final do comando de terminal se você não quiser esperar até que seja concluído. Os comandos do shell não devem depender da configuração PATH do inetd. Em vez disso, eles devem usar nomes de caminho absolutos ou devem começar com uma instrução PATH = qualquer coisa explícita.

o hosts_options(5) documento descreve uma linguagem alternativa que usa o campo de comando shell de uma forma diferente e incompatível.

% De expansão

As seguintes expansões estão disponíveis nos comandos do shell:

• % a (% A) - O cliente (servidor) hospedeiro Morada.
• % c - Informações do cliente: usuário @ host, usuário @ endereço, um nome de host ou apenas um endereço, dependendo da quantidade de informações disponíveis.
• % d - O nome do processo do daemon (valor argv [0]).
• % h (% H) - O nome ou endereço do host do cliente (servidor), se o nome do host não estiver disponível.
• % n (% N) - O nome do host do cliente (servidor) (ou "desconhecido" ou "paranóico").
• % p - O id do processo do daemon.
• % s - Informações do servidor: daemon @ host, daemon @ address ou apenas o nome de um daemon, dependendo de quanta informação está disponível.
• %você - O nome de usuário do cliente (ou "desconhecido").
• %% - Expande-se para um único caractere `% '.

Os caracteres em% de expansões que podem confundir a concha são substituídos por sublinhados.

Padrões de endpoint de servidor

Para distinguir os clientes pelo endereço de rede ao qual eles se conectam, use os padrões da forma:

process_name @ host_pattern: client_list... 

Padrões como esses podem ser usados ​​quando a máquina tem endereços de Internet diferentes com nomes de host de Internet diferentes. Os provedores de serviços podem usar esta facilidade para oferecer arquivos FTP, GOPHER ou WWW com nomes da Internet que podem até pertencer a organizações diferentes. Veja também a opção `twist 'no documento hosts_options (5). Alguns sistemas (Solaris, FreeBSD) podem ter mais de um endereço de Internet em uma interface física; com outros sistemas, você pode ter que recorrer a pseudo interfaces SLIP ou PPP que vivem em um espaço de endereço de rede dedicado.

O host_pattern obedece às mesmas regras de sintaxe que os nomes de host e endereços no contexto client_list. Normalmente, as informações do terminal do servidor estão disponíveis apenas com serviços orientados a conexão.

Pesquisa de nome de usuário do cliente

Quando o host cliente suporta o protocolo RFC 931 ou um de seus descendentes (TAP, IDENT, RFC 1413), os programas wrapper podem recuperar informações adicionais sobre o proprietário de uma conexão. As informações de nome de usuário do cliente, quando disponíveis, são registradas junto com o nome do host do cliente e podem ser usadas para corresponder a padrões como:

daemon_list:... user_pattern @ host_pattern... 

Os daemon wrappers podem ser configurados em tempo de compilação para realizar pesquisas de nome de usuário baseadas em regras (padrão) ou para sempre interrogar o host do cliente. No caso de pesquisas de nome de usuário baseadas em regras, a regra acima causaria a pesquisa de nome de usuário apenas quando ambos daemon_list e a host_patternpartida.

Um padrão de usuário tem a mesma sintaxe de um padrão de processo daemon, portanto, os mesmos curingas se aplicam (a associação de grupo de rede não é suportada). No entanto, não se deve se deixar levar pelas pesquisas de nome de usuário.

As informações de nome de usuário do cliente não podem ser confiáveis ​​quando são mais necessárias, ou seja, quando o sistema do cliente foi comprometido. Em geral, ALL e (UN) KNOWN são os únicos padrões de nome de usuário que fazem sentido.

As pesquisas de nome de usuário são possíveis apenas com serviços baseados em TCP e apenas quando o host do cliente executa um daemon adequado; em todos os outros casos, o resultado é "desconhecido".

Um conhecido UNIX bug do kernel pode causar perda de serviço quando as pesquisas de nome de usuário são bloqueadas por um firewall. O documento README do wrapper descreve um procedimento para descobrir se seu kernel tem esse bug.

As pesquisas de nome de usuário podem causar atrasos perceptíveis para usuários não UNIX. O tempo limite padrão para pesquisas de nome de usuário é de 10 segundos: muito curto para lidar com redes lentas, mas longo o suficiente para irritar os usuários de PC.

Pesquisas seletivas de nome de usuário podem aliviar o último problema. Por exemplo, uma regra como:

daemon_list: @pcnetgroup ALL @ ALL. 

corresponderia a membros do grupo de rede do pc sem fazer pesquisas de nome de usuário, mas faria pesquisas de nome de usuário com todos os outros sistemas.

Detecção de ataques de falsificação de endereço

Uma falha no gerador de número de sequência de muitos Implementações TCP / IP permite que os invasores representem facilmente hosts confiáveis ​​e invadam por meio, por exemplo, do serviço de shell remoto. O serviço IDENT (RFC931 etc.) pode ser usado para detectar esses e outros ataques de falsificação de endereço de host.

Antes de aceitar um pedido do cliente, os wrappers podem usar o serviço IDENT para descobrir que o cliente não enviou o pedido. Quando o host cliente fornece serviço IDENT, um resultado negativo de pesquisa IDENT (o cliente corresponde a `UNKNOWN @ host ') é uma forte evidência de um ataque de falsificação de host.

Um resultado de pesquisa IDENT positivo (o cliente corresponde a `KNOWN @ host ') é menos confiável. É possível que um invasor falsifique a conexão do cliente e a pesquisa IDENT, embora fazer isso seja muito mais difícil do que falsificar apenas uma conexão do cliente. Também pode ser que o servidor IDENT do cliente esteja mentindo.

Mais exemplos

A linguagem é flexível o suficiente para que diferentes tipos de política de controle de acesso possam ser expressos com o mínimo de barulho. Embora a linguagem use duas tabelas de controle de acesso, as políticas mais comuns podem ser implementadas com uma das tabelas sendo trivial ou mesmo vazia.

Ao ler os exemplos abaixo, é importante perceber que a tabela de permissões é verificada antes da negação tabela, que a pesquisa termina quando uma correspondência é encontrada, e que o acesso é concedido quando nenhuma correspondência é encontrada em tudo.

Os exemplos usam nomes de host e domínio. Eles podem ser melhorados incluindo informações de endereço e / ou rede / máscara de rede, para reduzir o impacto de falhas temporárias de pesquisa de servidor de nomes.

Quase Fechado

Nesse caso, o acesso é negado por padrão. Somente hosts explicitamente autorizados têm acesso permitido.

A política padrão (sem acesso) é implementada com um arquivo de negação comum:

/etc/hosts.deny:

TUDO TUDO. 

Isso nega todos os serviços a todos os hosts, a menos que tenham acesso permitido por entradas no arquivo de permissão.

Os hosts explicitamente autorizados são listados no arquivo de permissão. Por exemplo:

/etc/hosts.allow:

ALL: LOCAL @some_netgroup
TODOS: .foobar.edu EXCETO terminaiserver.foobar.edu. 

A primeira regra permite o acesso de hosts no domínio local (sem `. 'no nome do host) e de membros do algum_grupo netgroup. A segunda regra permite o acesso de todos os hosts nofoobar.edu domínio (observe o ponto inicial), com exceção de terminaiserver.foobar.edu.

Quase Aberto

Aqui, o acesso é concedido por padrão; apenas hosts explicitamente especificados têm o serviço recusado.

A política padrão (acesso concedido) torna o arquivo de permissão redundante para que possa ser omitido. Os hosts explicitamente não autorizados são listados no arquivo de negação. Por exemplo:

/etc/hosts.deny:

TODOS: algum.host.nome, .algum.dominio
ALL: ALL EXCEPT in.fingerd: other.host.name, .other.domain. 

A primeira regra nega a alguns hosts e domínios todos os serviços; a segunda regra ainda permite solicitações de dedo de outros hosts e domínios.

Armadilhas

O próximo exemplo permite pedidos tftp de hosts no domínio local (observe o ponto inicial). As solicitações de qualquer outro host são negadas. Em vez do arquivo solicitado, uma sonda de dedo é enviada ao host ofensor. O resultado é enviado ao superusuário.

/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) &

O comando safe_finger vem com o wrapper tcpd e deve ser instalado em um local adequado. Limita possíveis danos de dados enviados pelo servidor remoto de dedo. Oferece melhor proteção do que o comando padrão do dedo.

A expansão das sequências% h (host cliente) e% d (nome do serviço) é descrita na seção sobre comandos shell.

Na rede sistemas de firewall esse truque pode ser levado ainda mais longe. O firewall de rede típico fornece apenas um conjunto limitado de serviços para o mundo exterior. Todos os outros serviços podem ser "bugados" como o exemplo tftp acima. O resultado é um excelente sistema de alerta precoce.

Veja também

tcpd (8) programa wrapper daemon tcp / ip.
tcpdchk (8), tcpdmatch (8), programas de teste.