Classicamente, se você gostaria de manter um serviço de telnet rodando, você simplesmente o deixava ligado escutando a porta 23 e respondendo a eventuais solicitações. Esse método funciona, porém dessa maneira, além de você estar consumindo processamento com um programa que muitas vezes poderia nem estar sendo executado você ainda ficava sem qualquer controle sobre quem estava acessando tal serviço.
O daemon inet.d (e seu sucesso xinet.d) tomam para si essa tarefa: eles monitoram todas as portas do sistema e acionam os serviços conforme a demanda, além de trabalhar em conjunto com o daemon tcpd, que fornecer um sistema eficaz de autorização/negação de serviços a determinados clientes da rede.
No caso do inetd, o seu arquivo de configuração fica localizado em /etc/inetd.conf, onde os serviços disponíveis são listados linha a linha e seguem a lógica:
serviço socket protocolo flags usuário.grupo executável opções
O que resultaria, no caso de utilizarmos por exemplo o inetd para gerenciar o nosso servidor de telnet uma linha como essa abaixo:
telnet stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.telnetd
Repare que na linha acima o service tcpd foi especificado com o objetivo de controlarmos o acesso ao nosso servidor.
Caso estivéssemos utilizando o xinetd, nossa configuração seria ligeiramente diferente. Embora o mesmo possua um arquivo de configuração, /etc/xinetd.conf, onde as configurações de todos os serviços possam estar especificadas, o usual é que esse arquivo contenha apenas as seguintes linhas:
# Simple configuration file for xinetd
#
defaults
{
# Please note that you need a log_type line to be able to use log_on_success
# and log_on_failure. The default is the following :
# log_type = SYSLOG daemon info
}
includedir /etc/xinetd.d
O primeiro detalhe a se notar é formato do arquivo, que difere bastante do inetd por não ser organizado linha a linha e sim por seção. Nesse arquivo, retirado do Ubuntu Server, existe apenas uma única seção sem qualquer configuração, apenas uma chamada para um diretório, /etc/xined.d.
#
# xinetd.conf
#
# Copyright (c) 1998-2001 SuSE GmbH Nuernberg, Germany.
# Copyright (c) 2002 SuSE Linux AG, Nuernberg, Germany.
#
defaults
{
log_type = FILE /var/log/xinetd.log
log_on_success = HOST EXIT DURATION
log_on_failure = HOST ATTEMPT
# only_from = localhost
instances = 30
cps = 5000 10
#
# The specification of an interface is interesting, if we are on a firewall.
# For example, if you only want to provide services from an internal
# network interface, you may specify your internal interfaces IP-Address.
#
# interface = 127.0.0.1
}
includedir /etc/xinetd.d
Esse outro arquivo foi retirado do SuSE 10. nele podemos encontrar algumas opções deifinas como log, instâncias, mas ainda assim nenhuma relativa diretamente a algum serviço. No final do arquivo também encontramos a referência ao diretório /etc/xinetd.d. Olhando em ambas distribuições nesse diretório iremos encontrar vários arquivos, com o nome de cada serviço disponível na máquina, contendo as seguintes intruções:
service telnet
{
flags = REUSE NAMEINARGS
protocol = tcp
socket_type = stream
wait = no
user = telnetd
server = /usr/sbin/tcpd
server_args = /usr/sbin/in.telnetd
}
Esse seria o conteúdo do arquivo telnet, serviço utilizado em nosso exemplo. As informação são basicamente as mesmas. Protocolo, o uso do tcpd. O que diferencia mais uma vez é a divisão em seção e não por linha. Essas informações, assim como as informações presentes nos demais arquivos referentes aos demais serviços, poderiam estar todas presentes no /etc/xinetd.conf, porém dessa maneira o trabalho de localizar, habilitar e desabilitar serviços fica bem mais simples.
Em ambos os casos nossos falamos sobre controle de acesso através do tcpd. Esse controle é chamado TCPWrappers e sua configuração ocorre em dois arquivos /etc/hosts.allow e /etc/hosts.deny. A entrada em ambos é simples:
serviço : ip/range
Podendo ser usado o coringa ALL tanto como substiuição para o nome do serviço quanto para o ip dos clientes. Por exemplo:
# cat /etc/hosts.allow
# Permite acesso ao FTP para clients locais
ftp: LOCAL
ou
# cat /etc/hosts.allow
# Permite acesso a todos os clientes a todos os servidores
ALL: ALL
Outra sintaxe que pode ser utilizada é:
# cat /etc/hosts.allow
# permite acesso a todos
# permite acesso a todos os usuários locais a todos os serviços
ALL : localhost
# permite acesso ao telnet vindos do dominio empresa.com ou do IP especificado
telnetd : .empresa.com, 192.168.17.24
# permite acesso vindo do subdomínio e dos ranges de IP especificados
ftpd : gerents.empresa.com, 192.168.39., 10.162.23.0/255.255.255.0
Procurando na internet, você pode encontrar o mesmo arquivo anterior escrito da seguinte maneira:
ALL : localhost : allow
telnetd : .empresa.com, 192.168.17.24 : allow
ftpd : gerentes.empresa.com, 192.168.39., 10.162.23.0/255.255.255.0 : allow
ALL : ALL : deny
Embora tal configuração já seja ultrapassada. Tais utilizações podem ser utilizadas para configuração do arquivo /etc/hosts.deny. A regra geral é: se existir allow apenas os clientes especificados nele poderão utilizar os serviços mencionados. Caso não exista allow mas exista deny, apenas os clientes fora dele poderão acessar os serviços.
Após você configurar os arquivos /etc/hosts.allow e hosts.deny é recomendável que você execute o programa tcpdchk para verificar se as configurações escritas são válidas. Outra boa opção também é utilizar o programa tcpdmatch para simular o acesso de clientes remotos aos serviços da máquina.
sábado, 3 de maio de 2008
Controle de Serviços de Rede: Inetd, Xinetd e TCPWrappers
É inegável que classicamente o campo de atuação mais forte dos sistemas Unix-like foram os servidores de rede. Servidor no sentido exato de servir, prover, oferecer um determinado serviço como e-mail, páginas, etc, serviços que sabemos bem são compostos por programas executados no sistema.
