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.