Suporte TCP Wrapper - Serviços stand-alone no Debian 6

Serviços stand-alone são aqueles que "escutam" as conexões TCP/IP diretamente da interface de rede, como por exemplo, Portmap ou SSH. Estes serviços devem ser protegidos de vários modos pelo administrador, tais como: configurações restritivas, regras de firewall e regras de ACL da biblioteca libwrap, conhecida como TCP Wrapper.

[ Hits: 22.141 ]

Por: Perfil removido em 11/09/2012


Introdução



Serviços stand-alone são aqueles que "escutam" as conexões TCP/IP diretamente da interface de rede como, por exemplo, Portmap ou SSH.

Estes serviços DEVEM ser protegidos de vários modos pelo administrador, tais como:
  • Configurações restritivas;
  • Regras de firewall;
  • Regras de ACL da biblioteca "libwrap", conhecida como TCP Wrapper.

Se você está interessado na configuração Xinetd de TCP Wrapper, este artigo não serve para você.

Se você está estudando para LPI-C2-202 - tópico 212.4, este artigo atende parte deste conteúdo, e será uma boa introdução ao assunto.

Serviços stand-alone versus serviços em xinetd

Os serviços de rede podem funcionar isoladamente em modo stand-alone, como Daemons ou através de um super Daemon, como Xinetd - eXtended Internet Daemon -.

Quando instalado em modo stand-alone, o daemon de um serviço aguarda as requisições de conexão diretamente na interface de rede, e na porta TCP/IP configurada para "ouvir" e "responder" essas requisições. Por exemplo, um servidor SSH normalmente espera por conexões na porta TCP/22.

Quando configurados via xinetd, os serviços ficam adormecidos, e é o super servidor que "ouve" as conexões em um socket e "acorda" o serviço adequado para atendê-las, depois que o destino das mesmas foi corretamente identificado pelo protocolo e porta.

Os daemons configurados via xinetd precisam ser forçados a trabalhar com a biblioteca libwrap. Esta configuração está fora do escopo deste artigo, que aborda somente daemons com suporte nativo a biblioteca libwrap (TCP Wrapper).

A figura a seguir, ilustra o funcionamento desta abordagem, que pode, ou não, incluir um firewall como uma primeira camada de proteção de rede:

Normalmente, o controle de acesso a certos serviços de rede é feito em primeira instância por um firewall de filtragem de pacotes (IPtables), onde os pacotes são confrontados com regras de filtragem, baseadas na permissão ou negação de certas características de cada pacote, que são aceitos ou recusados sumariamente baseado nestas regras.

Se a conexão passar pelo firewall, ainda será analisada pelas regras de ACL de TCP Wrapper (?).

A maior vantagem de TCP Wrapper, neste caso, é que uma mudança nas regras de ACL é aplicada imediatamente, não sendo necessário reiniciar o serviço afetado pela mudança.

Não há um daemon em execução para TCP Wrapper, então, ele não pode falhar ou ficar desativado por algum motivo.

Outra vantagem, é que as regras de ACL de TCP Wrapper, são mais intuitivas e fáceis de aplicar que as regras de um firewall de pacotes, que normalmente exige muito mais conhecimento sobre a arquitetura TCP/IP.

    Próxima página

Páginas do artigo
   1. Introdução
   2. TCP Wrapper
   3. Regras - Padrões - Execução
   4. Extensão - Controle
Outros artigos deste autor

Atualizando o Gnome no Slackware com Dropline

Gerenciamento de pacotes RPM (parte 1)

Montando o cache de DNS

Verificando a temperatura do HD no Slackware

Windows é mais fácil que Linux!? Tá louco!? Você sabe ler!?

Leitura recomendada

ttyrec - Ferramenta para auditoria de sistemas Linux

Snort + MySQL + Guardian - Instalação e configuração

Enjaulamento de usuário no sistema operacional

Acessando o Linux via SSH através do Android

Instalação e configuração do HexChat com a rede Tor

  
Comentários

Nenhum comentário foi encontrado.


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner
Linux banner
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts