2.2. Segurança do Servidor


Quando um sistema é usado como um servidor em uma rede pública, ele se torna um alvo para ataques. Endurecendo o sistema e trancando serviços é, portanto, de suma importância para o administrador do sistema.
Antes de se aprofundar em questões específicas, revise as seguintes dicas gerais para aumentar a segurança do servidor:
  • Mantém todos os serviços atualizados, para protege-los contra as últimas ameaças.
  • Use protocolos seguros sempre que possível.
  • Sirva somente um tipo de serviço de rede por máquina sempre que possível.
  • Monitore todos os servidores cuidadosamente por atividades suspeitas.

2.2.1. Assegure os Serviços com TCP Wrappers e xinetd

Os TCP Wrappers fornecem controle de acesso à uma variedade de serviços. A maioria dos serviços de rede modernos, como SSH, Telnet e FTP fazem uso dos TCP Wrappers, que fazem guarda entre pedidos de entrada e os serviços solicitados.
Os benefícios oferecidos pelos TCP Wrappers são reforçados quando usados em conjunto com o xinetd, um super servidor que fornece acesso adicional, registro de logs, associação, redirecionamento e controle de utilização de recursos.

Nota

É uma boa idéia usar as regras de firewall iptables em conjunto com os TCP Wrappers e xinetd para criar redundância dentro dos controles de acesso de serviço. Consulte a Seção 2.5, “Firewalls” para mais informações sobre implementar firewalls com comandos iptables.
As subseções a seguir pressupõem um conhecimento básico de cada tópico e foco em opções de segurança específicas.

2.2.1.1. Aumentando a Segurança com TCP Wrappers

Os TCP Wrappers são capazes de muito mais do que negar acesso á serviços. Esta seção ilustra como eles podem ser usados para enviar banners de conexão, avisos de ataque de determinados hosts e aumenta a funcionalidade de registro de log. Consulte a página man hosts_options para informações sobre a funcionalidade dos TCP Wrappers e idioma de controle. Consulte a página man xinetd.conf disponível online em http://linux.die.net/man/5/xinetd.conf para os sinalizadores disponíveis, que agem como opções que você pode aplicar em um serviço.
2.2.1.1.1. TCP Wrappers e Banners de Conexão
Exibir um banner apropriado quando os usuários conectam é uma boa maneira de fazer que os potencias invasores saibam que o administrador do sistema está vigilante. Você pode também controlar qual informação sobre o sistema é apresentado aos usuários. Para implementar um banner de TCP Wrappers para um serviço, use a opção banner.
Este exemplo implementa um banner para o vsftpd. Para iniciar, crie um arquivo de banner. Ele pode estar em qualquer lugar no sistema, mas ele deve ter o mesmo nome como o daemon. Para este exemplo, este arquivo é chamado /etc/banners/vsftpd e contém a seguinte linha:
220-Hello, %c 
220-All activity on ftp.example.com is logged.
220-Inappropriate use will result in your access privileges being removed.
O token %c fornece uma variedade de informações sobre o cliente, tais como o nome de usuário e hostname ou nome de usuário e endereço de IP para fazer a conexão ainda mais intimidadora.
Para este banner ser mostrado às conexões de entrada, adicione a seguinte linha ao arquivo /etc/hosts.allow:
 vsftpd : ALL : banners /etc/banners/ 
2.2.1.1.2. TCP Wrappers e Avisos de Ataques
Se um determinado host ou rede tiver sido detectada atacando o servidor, os TCP Wrappers podem ser usados para avisar o administrador de ataques subsequentes daquele host ou rede usando a diretiva spawn.
Neste exemplo, pressuponha que um cracker da rede 206.182.68.0/24 foi detectado tentando atacar o servidor. Coloque a seguinte linha no arquivo /etc/hosts.deny para negar quaisquer tentativas de conexão dessa rede, e registrar as tentativas em log em um arquivo especial:
 ALL : 206.182.68.0 : spawn /bin/echo `date` %c %d >> /var/log/intruder_alert 
O token %d fornece o nome do serviço que o invasor estava tentando acessar.
Para permitir a conexão e registra em log, coloque a diretiva spawn no arquivo /etc/hosts.allow.

Nota

Por causa que a diretiva spawn executa qualquer comando shell, é uma boa idéia criar um script especial para notificar o administrador ou executar uma cadeia de comandos no evento de um determinado cliente tentar se conectar ao servidor.
2.2.1.1.3. Os TCP Wrappers e Registro de Log Avançado
Se certos tipos de conexões são mais preocupantes que outras, o nível de log pode ser elevado para esse serviço usando a opção severity.
Neste exemplo, pressuponha que qualquer um tentando se conectar à porta 23 (a porta Telnet) em um servidor FTP seja um invasor. Para simbolizar isso, coloque um sinalizador emerg nos arquivos de log em vez do sinalizador padrão, info e negue a conexão.
Para fazer isso, coloque a seguinte linha no /etc/hosts.deny:
 in.telnetd : ALL : severity emerg 
Isto usa a facilidade de registro de log padrão authpriv, mas eleva a prioridade do valor padrão de info para emerg, que posta mensagens de log diretamente ao console.

2.2.1.2. Aumentando a Segurança com o xinetd

Esta seção foca no uso do xinetd para definir um serviço de interceptação (trap) e usa-lo para controlar os níveis de recursos disponíveis para qualquer serviço xinetd dado. Definindo limites de recursos disponíveis para serviços pode ajudar impedir ataques DoS (Denial of Service ). Consulte as páginas man do xinetd e do xinetd.conf para uma lista de opções disponíveis.
2.2.1.2.1. Configurando uma Interceptação (Trap)
Um recurso importante do xinetd é sua habilidade de adicionar hosts à uma lista no_access global. Hosts nesta lista são conexões subsequentes negadas a serviços gerenciados pelo xinetd por um período especificado ou até que o xinetd seja reiniciado. Você pode fazer isto usando o atributo SENSOR. Esta é uma fácil maneira de bloquear hosts tentando escanear as portas neste servidor.
O primeiro passo para definir um SENSOR é escolher um serviço que você não planeja usar. Para este exemplo, o Telnet é usado.
Edite o arquivo /etc/xinetd.d/telnet e mude as linhas das flags (sinalizadores) para:
flags           = SENSOR
Adicione a seguinte linha:
deny_time       = 30
Isto nega qualquer outra tentativa de conexão à esta porta por esse host por 30 minutos. Outros valores aceitáveis para o atributo deny_time são o FOREVER, que mantém o banimento em efeito até que o xinetd seja reiniciado, e o NEVER, que permite a conexão e registra isso em log.
Finalmente, a última linha deve ser:
disable         = no
Isto ativa a própria interceptação.
Enquanto usar o SENSOR é uma boa maneira para detectar e parar conexões de hosts indesejáveis, ela possui desvantagens:
  • Não funciona contra escaneamentos stealth.
  • Um invasor que sabe que o SENSOR está rodando pode montar um ataque Dos (Denial of Service) contra determinados hosts, falsificando seus endereços IP e se conectando à porta proibida.
2.2.1.2.2. Controlando Recursos de Servidor
Um outro recurso importante do xinetd é a habilidade de configurar limites de serviços sobre seu controle.
Isso pode ser feito usando as seguintes diretivas:
  • cps = <number_of_connections> <wait_period> — Limita a taxa de conexões de entrada. Esta diretiva leva dois argumentos:
    • <number_of_connections> — O número de conexões por segundo para manuseio. Se a taxa de conexões de entrada é maior que isso, o serviço é temporariamente desativado. O valor padrão é cinquenta (50).
    • <wait_period> — O número de segundos para esperar antes da reativação do serviço depois que ele foi desativado. O intervalo padrão é dez (10) segundos.
  • instances = <number_of_connections> — Especifica o número total de conexões permitidas a um serviço. Esta diretiva aceita tanto um valor de número inteiro ou UNLIMITED (ilimitado).
  • per_source = <number_of_connections> — Especifica o número de conexões permitidas a um serviço por cada host. Esta diretiva aceita tanto um valor de número ou UNLIMITED (ilimitado).
  • rlimit_as = <number[K|M]> — Especifica a quantidade de espaço de endereço de memória que o serviço pode ocupar em kilobytes ou megabytes. Esta diretiva aceita tanto um valor de número inteiro ou UNLIMITED.
  • rlimit_cpu = <number_of_seconds> — Especifica o período de tempo em segundos que um serviço pode ocupar na CPU. Esta diretiva aceita tanto um integrador de número inteiro ou UNLIMITED (limitado).
Usando estas diretivas pode ajudar a impedir qualquer serviço xinetd único de sobrecarregar o sistema, resultando em um DoS (denial of service).
Red Hat logoGithubRedditYoutubeTwitter

Aprender

Experimente, compre e venda

Comunidades

Sobre a documentação da Red Hat

Ajudamos os usuários da Red Hat a inovar e atingir seus objetivos com nossos produtos e serviços com conteúdo em que podem confiar.

Tornando o open source mais inclusivo

A Red Hat está comprometida em substituir a linguagem problemática em nosso código, documentação e propriedades da web. Para mais detalhes veja oBlog da Red Hat.

Sobre a Red Hat

Fornecemos soluções robustas que facilitam o trabalho das empresas em plataformas e ambientes, desde o data center principal até a borda da rede.

© 2024 Red Hat, Inc.