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 ouUNLIMITED
(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 ouUNLIMITED
(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 ouUNLIMITED
.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 ouUNLIMITED
(limitado).
Usando estas diretivas pode ajudar a impedir qualquer serviço
xinetd
único de sobrecarregar o sistema, resultando em um DoS (denial of service).