Quando um sistema é usado com um servidor em um rede pública, torna-se um alvo de ataques. Por esta razão solidificar e trancar os serviços é de suma importância para o administrador de sistemas.
Antes de aprofundar em questões específicas, você deve revisar as seguintes dicas gerais para aumentar a segurança do servidor:
Mantenha todos os serviços atualizados para protegê-los contra as ameaças recentes.
Use protocolos seguros sempre que possível.
Ofereça apenas um tipo de serviço de rede por máquina sempre que possível.
Monitore todos os servidores cuidadosamente e atente para atividades suspeitas.
TCP wrappers oferecem controle de acesso a vários serviços. A maioria dos serviços de rede modernos, como SSH, Telnet e FTP, fazem uso dos TCP wrappers, que fica de guarda entre a entrada de um pedido e o serviço requisitado.
Os benefícios oferecidos pelos TCP wrappers aumentam quando este é usado junto ao xinetd, um super serviço que oferece acesso adicional, registro, vinculação, redirecionamento e controle de utilização de recursos.
![]() | Dica |
---|---|
É uma boa idéia usar regras de firewall do IPTables juntamente ao TCP wrappers e xinetd para criar redundância nos controles de acesso do serviço. Consulte o Capítulo 7para mais informações sobre a implementação de firewalls com comandos do IPTables. |
Mais informações sobre a configuração do TCP wrappers e xinetd podem ser encontradas no capítulo entitulado TCP Wrappers e xinetd do Guia de Referência do Red Hat Enterprise Linux;.
As sub-seções seguintes assumem um conhecimento básico de cada tópico e focam nas opções de segurança específicas.
TCP wrappers são capazes de muito mais que negar acesso aos serviços. Esta seção ilustra como eles podem ser utilizados para enviar banners de conexão, alertar ataques em máquinas específicas e aumentar a funcionalidade de registro. Consulte a página man hosts_options para obter uma lista completa das funcionalidades e controle de idioma do TCP wrapper.
Enviar um banner intimidador para clientes conectando a um serviço é uma boa maneira de disfarçar em qual sistema o servidor está rodando enquanto informa um atacante potencial que o administrador de sistemas está vigiando. Para implementar um banner do TCP wrappers para um serviço, use a opção banner.
Este exemplo implementa um banner para vsftpd. Para começar, crie um arquivo de banner. Pode estar em qualquer lugar do sistema, mas deve levar o mesmo nome que o daemon. Neste exemplo, o arquivo é chamado /etc/banners/vsftpd.
O conteúdo do arquivo é parecido com o seguinte:
220-Hello, %c 220-All activity on ftp.example.com is logged. 220-Act up and you will be banned. |
A expressão %c oferece uma gama de informações do cliente, tais como nome de usuário e nome da máquina ou nome de usuário e endereço IP, para intimar ainda mais a conexão. O Guia de Referência do Red Hat Enterprise Linux tem uma lista de outras expressões disponíveis para TCP wrappers.
Para que este banner seja apresentado em futuras conexões, adicione a seguinte linha ao arquivo /etc/hosts.allow:
vsftpd : ALL : banners /etc/banners/ |
Se uma determinada máquina ou rede for flagrada atacando o servidor, o TCP wrappers pode ser usado para alertar o administrador sobre ataques subsequentes desta máquina ou rede através da diretiva spawn.
Neste exemplo, assuma que um cracker da rede 206.182.68.0/24 foi pêgo tentando atacar o servidor. Ao inserir a seguinte linha no arquivo /etc/hosts.deny, a tentativa de conexão é negada e registrada em um arquivo especial:
ALL : 206.182.68.0 : spawn /bin/ 'date' %c %d >> /var/log/intruder_alert |
A expressão %d traz o nome do serviço que o atacante estava tentando acessar.
Para permitir a conexão e registrá-la, insira o informativo spawn no arquivo /etc/hosts.allow.
![]() | Nota |
---|---|
Já que a diretiva spawn executa qualquer comando de linha, crie um script especial para notificar o administrador ou para executar uma série de comandos na ocasião em que um determinado cliente tenta conectar ao servidor. |
Se determinados tipos de conexões são mais preocupantes que outras, o nível de registro pode ser elevado para estes serviços através da opção severity.
Neste exemplo, assuma que qualquer um tentando conectar à porta 23 (a porta do Telnet) em um servidor FTP é um cracker. Para denotar isso, insira um sinal emerg nos arquivos de registro ao invés do sinal default, info, e negue a conexão.
Para fazer isso, insira a seguinte linha no arquivo /etc/hosts.deny:
in.telnetd : ALL : severity emerg |
Isto usa a facilidade de registro authpriv default, mas eleva a prioridade do valor default do info para emerg, que envia mensagens de registro diretamente ao console.
O super servidor xinetd é uma outra ferramenta útil para controlar o acesso a seus serviços subordinados. Esta seção foca em como o xinetd pode ser usado para montar um serviço-armadilha e controlar a quantidade de recursos que qualquer serviço xinetd pode usar para arruinar ataques 'denial of service'. Para obter uma lista mais completa das opções disponíveis, consulte as páginas man do xinetd e do xinetd.conf.
Uma importante característica do xinetd é sua habilidade em adicionar máquinas (hosts) a uma lista de no_access. Às máquinas desta lista são negadas as conexões subsequentes aos serviços gerenciados pelo xinetd por um determinado período ou até o xinetd ser reiniciado. Isto é feito usando o atributo SENSOR. Esta técnica e uma maneira fácil de bloquear máquinas que tentarem scanear o servidor.
O primeiro passo para definir um SENSOR é escolher um serviço que você não planeja utilizar. Neste exemplo, usamos o Telnet.
Edite o arquivo /etc/xinetd.d/telnet e altere a linha flags para:
flags = SENSOR |
Adicione as seguintes linhas entre os colchetes:
deny_time = 30 |
Isto nega a máquina que tentou conectar à porta por 30 minutos. Outros valores aceitáveis para o atributo deny_time são FOREVER (sempre), que mantém o banimento efetivo até que o xinetd seja reiniciado, e NEVER (nunca), que permite a conexão e a registra.
Finalmente, na última linha deve-se ler:
disable = no |
Apesar de usar o SENSOR ser uma boa maneira de detectar e parar conexões de máquinas periogosas, há duas desvantagens:
Não funciona contra scans secretos.
Um atacante ciente de que você está rodando o SENSOR pode montar um ataque 'denial of service' contra determinadas máquinas forjando seus endereços IP e conectando à porta proibida.
Outra característica importante do xinetd é sua habilidade em controlar a quantidade de recursos que os serviços sob seu controle podem utilizar.
Ele o faz através das seguintes diretivas:
cps = <number_of_connections> <wait_period> — Determina as conexões permitidas ao serviço por segundo. Esta diretiva aceita apenas valores inteiros.
instances = <number_of_connections> Determina o número total de conexões permitidas a um serviço. Esta diretiva aceita tanto um valor inteiro como UNLIMITED.
per_source = <number_of_connections> — Determina as conexões permitidas a um serviço por cada máquina. Esta diretiva aceita tanto um valor inteiro como UNLIMITED.
rlimit_as = <number[K|M]> — Determina a quantidade de memory address space que o serviço pode ocupar em kilobytes ou megabytes. Esta diretiva aceita tanto um valor inteiro como UNLIMITED.
rlimit_cpu = <number_of_seconds> — Determina o tempo em segundos durante o qual um serviço pode ocupar a CPU. Esta diretiva aceita tanto um valor inteiro como UNLIMITED.
Usando estas diretivas pode ajudar a prevenir que qualquer serviço xinetd sobrecarregue o sistema, resultando em recusa de serviço (denial of service).