2.3.2. Arquivos de Configuração dos TCP Wrappers
Para determinar se um cliente é permitido se conectar a um serviço, os TCP Wrappers referenciam os seguintes dois arquivos, que são comumente referidos como arquivos de acesso de hosts:
/etc/hosts.allow/etc/hosts.deny
Quando um serviço TCP wrapped recebe uma solicitação de um cliente, ele realiza os seguintes passos:
- Ele faz referencia ao
/etc/hosts.allow— O serviço TCP wrapper analisa sequencialmente o arquivo/etc/hosts.allowe aplica a primeira regra especificada para aquele serviço. Se ele encontra uma regra correspondente, ele permite a conexão. Se não, vai para o próximo passo. - Ele faz referência ao
/etc/hosts.deny— O serviço TCP wrapper analisa sequencialmente o arquivo/etc/hosts.deny. Se ele encontrar uma regra correspondente, ele nega a conexão. Se não, garante acesso ao serviço.
A seguir estão pontos importantes a considerar quando usar TCP Wrappers para proteger serviços de rede:
- Como as regras de acesso no
hosts.allowsão aplicadas primeiro, elas têm preferência sobre as regras especificadas nohosts.deny. Portanto, se o acesso a um serviço é permitido nohosts.allow, uma regra negando acesso ao mesmo serviçohosts.denyé ignorado. - As regras em cada arquivo são lidas de cima para baixo e a primeira regra correspondente para um determinado serviço é a única aplicada. A ordem das regras é extremamente importante.
- Se nenhuma regra para o serviço é encontrada em qualquer arquivo ou nenhum arquivo existe, acesso ao serviço é garantido.
- Os serviços TCP wrappers não fazem cache das regras dos arquivos de acesso dos hosts, então quaisquer mudanças no
hosts.allowouhosts.denyacontecem imediatamente, sem reiniciar os serviços de rede.
Atenção
Se a última linha do arquivo de acesso ao host não é um carácter de nova linha (criado ao se pressionar o Enter), a última regra no arquivo falha e um erro é registrado tanto no logs
/var/log/messages ou /var/log/secure. Isto é também o caso para uma regra que se extende por múltiplas linhas sem usar a barra invertida. O seguinte exemplo ilustra a porção relevante de uma mensagem de log para uma falha de regra devido a uma dessas circunstâncias:
warning: /etc/hosts.allow, line 20: missing newline or line too long
2.3.2.1. Formatando Regras de Acesso
Os formatos para ambos
/etc/hosts.allow e /etc/hosts.deny são idênticos. Cada regra deve estar em sua própria linha. Linhas em branco ou linhas que iniciam com um hash (#) são ignoradas.
Cada regra usa o seguinte formato básico para controlar acesso aos serviços de rede:
<daemon list>: <client list> [: <option>: <option>: ...]
- <daemon list> — Uma lista separada por vírgula de nomes de processos (não os nomes dos serviços) ou o carácter coringa
ALL. A lista daemon também aceita operadores (consulte a Seção 2.3.2.1.4, “Operadores”) para permitir maior flexibilidade. - <client list> — Uma lista separada por vígula de nomes de host, endereços IP de host, modelos especiais ou carácteres coringa que identificam os hosts afetados pela regra. A lista de clientes também aceita operadores listados na Seção 2.3.2.1.4, “Operadores” para permitir maior flexibilidade.
- <option> — Uma ação opcional ou lista separada por dois pontos de ações realizadas quando a regra é acionada. Campos opcionais suportam expansões, dão inicio à comandos shell, permitem ou negam acesso e alteram o comportamento de logging.
Nota
Mais informações sobre alguns dos termos acima podem ser encontrados em outras partes deste guia:
A seguir há um exemplo básico de regra de acesso ao host:
vsftpd : .example.com
Esta regra instrui o TCP Wrapper para aguardar por conexões do daemon FTP (
vsftpd) de qualquer host no domínio example.com. Se esta regra aparecer no hosts.allow, a conexão é aceita. Se esta regra aparecer no hosts.deny, a conexão é rejeitada.
O próximo exemplo de regra de acesso à host é mais complexa e usa dois campos de opções:
sshd : .example.com \ : spawn /bin/echo `/bin/date` access denied>>/var/log/sshd.log \ : deny
Note que cada campo de opção é precedido com uma barra inversa (\). O uso da barra invertida previne falha da regra devido ao comprimento.
Este exemplo de regra declara que se uma conexão ao daemon SSH (
sshd) é tentada a partir de um host no domínio example.com, executa o comando echo para anexar a tentativa ao arquivo de log especial e nega a conexão. Pelo motivo que a diretiva opcional deny é usada, esta linha nega o acesso mesmo se ele aparecer no arquivo hosts.allow. Consulte a Seção 2.3.2.2, “Campos de Opção” para uma visão mais detalhada das opções disponíveis.
2.3.2.1.1. Carácteres Coringa (wildcards)
Carácteres coringa permitem aos TCP Wrappers corresponder mais facilmente grupos de daemons ou hosts. Eles são usados mais frequentemente no campo de lista de clientes das regras de acesso.
Os seguintes carácteres coringa estão disponíveis:
ALL— Corresponde a tudo. Ele pode ser usado para ambas listas de daemons e lista de clientes.LOCAL— Corresponde a qualquer host que não contém um ponto (.), como o localhost.KNOWN— Corresponde a qualquer host onde o hostname e endereço de host são conhecidos ou onde o usuário é conhecido.UNKNOWN— Corresponde a qualquer host onde o hostname ou endereço de host são desconhecidos ou onde o usuário é desconhecido.PARANOID— Corresponde a qualquer host onde o hostname não corresponde ao endereço de host.
Importante
Os coringas
KNOWN, UNKNOWN e PARANOID devem ser usados com cuidado, por causa que eles dependem em um servidor DNS em funcionamento para que a operação seja correta. Qualquer disruptura na resolução de nome pode impedir usuários legítimos de ganhar acesso ao serviço.
2.3.2.1.2. Modelos
Modelos podem ser usados no campo de cliente das regras de acesso para mais precisamente especificar grupos de hosts clientes.
A seguir há uma lista de modelos comuns para serem usadas no campo do cliente:
- Hostname iniciando com ponto (.) — Colocar um ponto no início de um hostname corresponde a todos os hosts compartilhando os componentes listados do nome. O exemplo a seguir se aplica a qualquer host dentro do domínio
example.com:ALL : .example.com
- Endereço de IP terminando com um ponto (.) — Colocar um ponto no final do endereço IP corresponde a todos os hosts compartilhando os grupos numéricos iniciais de um endereço de IP. O exemplo seguinte se aplica a qualquer host dentro da rede
192.168.x.x:ALL : 192.168.
- endereço de IP /par máscara de rede — Expressões de máscara de rede podem também ser usadas como um modelo para controlar acesso a um grupo particular de endereços IP. O exemplo seguinte se aplica a qualquer host com uma variação de endereço de
192.168.0.0até192.168.1.255:ALL : 192.168.0.0/255.255.254.0
Importante
Quando trabalhar com espaço de endereço IPv4, a extensão do endereço/prefixo (prefixlen) declarações de par (notação CIDR) não são suportadas. Somente regras IPv6 podem usar este formato. - [endereço IPv6]/par prefixlen — pares [net]/prefixlen podem também ser usados como um modelo para controlar acesso a um grupo particular de endereços IPv6. O exemplo seguinte se aplicaria a qualquer host com uma faixa de
3ffe:505:2:1::até3ffe:505:2:1:ffff:ffff:ffff:ffff:ALL : [3ffe:505:2:1::]/64
- O asterisco (*) — Asteriscos podem ser usados para corresponder grupos inteiros de hostnames ou endereços de IP, desde que eles não sejam misturados em uma lista de clientes contendo outros tipos de modelos. O exemplo seguinte se aplicaria a qualquer host dentro do domínio
example.com:ALL : *.example.com
- A barra (/) — Se uma lista de clientes iniciar com uma barra (/), ela é tratada como um nome de arquivo. Isto é útil se regras especificando números grandes de hosts são necessárias. O exemplo seguinte se refere aos TCP Wrappers para o arquivo
/etc/telnet.hostspara todas as conexões Telnet:in.telnetd : /etc/telnet.hosts
Outro exemplo, modelos menos usados também são aceitos pelos TCP Wrappers. Consulte a página man 5
hosts_access para mais informações.
Atenção
Seja cuidadoso quando usar hostnames e nomes de domínio. Invasores podem usar uma variedade de truques para burlar uma resolução de nomes precisa. Além disso, disruptura no serviço DNS impede que mesmo usuários autorizados usem os serviços de rede. É melhor, portanto usado endereços de IP sempre que possível.
2.3.2.1.3. Portmap e TCP Wrappers
A implementação do
Portmap de TCP Wrappers não suporta busca de hosts, que siginifca que o portmap não pode usar hostnames para identificar hosts. Consequentemente, regras de controle de acesso para portmap no hosts.allow ou hosts.deny devem usar endereços de IP ou a palavra chave ALL, para especificar os hosts.
Mudanças nas regras de controle de acesso do
portmap podem não ter efeito imediatamente. Você pode necessitar reiniciar o serviço portmap.
Serviços usados amplamente, como NIS e NFS, dependem do
portmap para operar, então esteja atento à estas limitações.
2.3.2.1.4. Operadores
No presente, regras de controle de acesso aceitam um operador, o
EXCEPT. Ele pode ser usado em ambas listas daemon e listas clientes para uma regra.
O operador
EXCEPT permite exceções específicas para abranger correspondências com a mesma regra.
No exemplo seguinte de um arquivo
hosts.allow, todos os hosts example.com são permitidos se conectarem a todos os serviços, exceto cracker.example.com:
ALL: .example.com EXCEPT cracker.example.com
Em um outro exemplo de um arquivo
hosts.allow, clientes da rede 192.168.0.x podem usar todos os serviços exceto para o FTP:
ALL EXCEPT vsftpd: 192.168.0.
Nota
Organizacionalmente, é muito mais fácil evitar os operadores
EXCEPT. Isto permite a outros administradores rapidamente escanear os arquivos apropriados para ver quais hosts tem acesso permitido ou negado aos serviços sem ter de classificar operadores EXCEPT.
