Script de firewall para um servidor dedicado

Ao configurar um servidor dedicado, o firewall é ainda mais importante, já que por possuir não apenas um endereço IP fixo, mas também ser acessível através de um domínio potencialmente bem conhecido, o servidor será alvo de ataques contínuos. Por um lado, a configuração é mais simples, já que você não precisará se preocupar com regras de roteamento e de encaminhamento de pacotes, como ao configurar o firewall do gateway da rede, mas, por outro, existe um conjunto de cuidados adicionais a tomar.

Um exemplo básico de script de firewall para uso em um servidor web seria:

#!/bin/bash

iniciar(){

# Abre para a interface de loopback:
iptables -A INPUT -p tcp -i lo -j ACCEPT

# Bloqueia um determinado IP. Use para bloquear hosts específicos:
#iptables -A INPUT -p ALL -s 88.191.79.206 -j DROP

# Abre as portas referentes aos serviços usados:

# SSH:
iptables -A INPUT -p tcp –dport 22 -j ACCEPT

# DNS:
iptables -A INPUT -p tcp –dport 53 -j ACCEPT
iptables -A INPUT -p udp –dport 53 -j ACCEPT

# HTTP e HTTPS:
iptables -A INPUT -p tcp –dport 80 -j ACCEPT
iptables -A INPUT -p tcp –dport 443 -j ACCEPT

# Bloqueia conexões nas demais portas:
iptables -A INPUT -p tcp –syn -j DROP

# Garante que o firewall permitirá pacotes de conexões já iniciadas:
iptables -A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT

# Bloqueia as portas UDP de 0 a 1023 (com exceção das abertas acima):
iptables -A INPUT -p udp –dport 0:1023 -j DROP

}
parar(){
iptables -F
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
}

case “$1” in
“start”) iniciar ;;
“stop”) parar ;;
“restart”) parar; iniciar ;;
*) echo “Use os parâmetros start ou stop”
esac

Se você está configurando um servidor dedicado remotamente, é importante que você teste o script antes de configurar o sistema para executá-lo automaticamente durante o boot. O motivo é simples: se houver alguma regra incorreta no script, que bloqueie seu acesso ao servidor, você poderá solicitar um reboot do servidor para que a configuração seja removida e você recupere o acesso. Entretanto, se o sistema for configurado para carregar o script durante o boot, o reboot não resolverá e você precisará abrir uma chamada de suporte, solicitando que um técnico se logue localmente no servidor e desative seu script (o que provavelmente resultará em uma taxa adicional).

Para evitar a possibilidade de precisar reiniciar o servidor para recuperar o acesso depois de uma configuração de firewall mal-sucedida, você pode usar um script simples, contendo as regras de firewall desejadas, seguidas de um sleep e comandos para limpar a configuração do firewall.

Presumindo que você não esteja usando regras de roteamento (da tabela NAT), um exemplo de bloco de comandos para incluir no final do script seria:

sleep 120
iptables -F
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -X

Já conhecemos o “iptables -F”, que limpa as regras do firewall. As opções “iptables -P INPUT ACCEPT” e “iptables -P OUTPUT ACCEPT” alteram a política padrão do firewall (caso por ventura ela tenha sido alterada anteriormente), fazendo com que ele reverta para o default, que é aceitar todos os pacotes, tanto de entrada quanto de saída. O “iptables -X” elimina qualquer tabela personalizada que tenha sido adicionada, garantindo que qualquer regra oculta de configuração seja eliminada.

O “sleep 120” é um contador, que faz com que o sistema espere dois minutos antes de continuar. Colocando os comandos no final do script de firewall, o sistema executaria os comandos que ativam o firewall, esperaria dois minutos e em seguida executaria os comandos que o desativam.

Com isso, as regras são desativadas automaticamente depois de alguns minutos; se você acabar trancado do lado de fora, vai precisar apenas esperar o tempo especificado e se conectar novamente. Só depois de testar o script e ter certeza de que ele está mesmo fazendo apenas o que deseja, você removeria os comandos de desativação e configuraria o sistema para ativá-lo automaticamente durante o boot.

Em um servidor dedicado, não faz muito sentido bloquear a resposta a pings, já que, de qualquer forma, ele precisará ficar com um conjunto de portas abertas. Ao invés de bloquear os pings, que afinal podem ser úteis em algumas situações, você pode limitar as respostas a apenas uma por segundo, evitando que alguém de má fé possa enviar um grande volume de pings (como ao usar o comando “ping -f”), como parte de um ataque DoS. Nesse caso, a regra seria:

iptables -A INPUT -p icmp –icmp-type echo-request -m limit –limit 1/s -j ACCEPT

Se seu servidor não irá atuar como um roteador, é prudente desativar o suporte a ICMP redirects. Este é um recurso utilizado por roteadores para alertar outros de que existe um melhor caminho para um determinado endereço ou rede, mas não tem uso legítimo em um servidor que não roteia pacotes:

echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects

Outra configuração desejada é desativar o suporte a ping broadcasts, um recurso que tem poucos usos legítimos e pode ser usado para fazer com que servidores participem involuntariamente de ataques DoS, enviando grandes quantidades de pings a outros servidores dentro da mesma faixa de endereços. Ele já vem desativado em quase todas as distribuições atuais, mas não custa verificar:

echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

Mais uma opção que é importante manter desativada é o suporte ao source routing. Este é um recurso usado para testes de roteadores, que permite ao emissor especificar qual o caminho que o pacote tomará até o destino e também o caminho de volta. Ele é perigoso, pois permite falsear pacotes, fazendo com que eles pareçam vir de outro endereço e, ao mesmo tempo, fazer com que as respostas realmente sejam recebidas, permitindo abrir a conexão e transferir dados. Em outras palavras, se você incluiu regras que permitem o acesso de terminados endereços e esqueceu o suporte ao source routing ativo, um atacante que soubesse quais são os endereços autorizados poderia abrir conexões com o seu servidor se fazendo passar por um deles, um risco que você com certeza gostaria de evitar. Como o recurso não possui outros usos legítimos, é fortemente recomendável que você o mantenha desativado:

echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route

Diferente do servidor de rede local que compartilha a conexão, o servidor não deverá compartilhar a conexão, nem encaminhar pacotes de outros hosts. Você pode deixar isso explicito desativando o suporte a ip_forward:

echo 0 > /proc/sys/net/ipv4/ip_forward

Concluindo, temos o suporte a SYN cookies. Um dos tipos mais comuns de ataque DoS e também um dos mais efetivos é o SYN Flood. Este tipo de ataque consiste em enviar um grande volume de pacotes SYN até o alvo, sem nunca efetivamente abrir a conexão. Como os pacotes SYN possuem alguns poucos bytes, o ataque pode ser feito mesmo a partir de uma conexão doméstica.

Uma conexão TCP é iniciada através da troca de três pacotes entre o emissor e o destinatário, o famoso “three-way handshake”. O emissor envia um pacote SYN, o destinatário responde com um pacote SYN/ACK e o emissor confirma, também enviando um pacote ACK. A conexão TCP fica então aberta por um certo tempo, até que a requisição da página, download do arquivo, ou outra operação em questão seja concluída.

Se o servidor recebe um pacote SYN solicitando a abertura da conexão, mas não recebe o pacote ACK de resposta, ele é obrigado a esperar até que o tempo limite seja atingindo, mantendo a conexão aberta. Como existe um limite de conexões TCP que o servidor pode manter ativas simultaneamente, um grande volume de pacotes SYN podem estourar o limite de conexões, fazendo com que o servidor deixe de responder a novas conexões, mesmo que exista banda disponível.

No Linux, isso pode ser evitado de forma bastante simples, ativando o uso de SYN Cookies, um recurso oferecido diretamente pelo Kernel, o que é feito com o comando abaixo, que pode ser incluído no seu script de firewall:

echo 1 > /proc/sys/net/ipv4/tcp_syncookies

Ao ativar o recurso, o sistema passa a responder ao pacote SYN inicial com um cookie, que identifica o cliente. Com isso, o sistema aloca espaço para a conexão apenas após receber o pacote ACK de resposta, tornando o ataque inefetivo. O atacante ainda pode consumir um pouco de banda, obrigando o servidor a enviar um grande volume de SYN Cookies de resposta, mas o efeito sobre o servidor será mínimo.

Concluindo, adicione também as regras que ativam o uso do rp_filter, de forma que o firewall sempre responda aos pacotes na mesma interface da qual eles foram originados, o que previne ataques diversos que tentem tirar proveito da regra que permite conexões na interface de loopback. Outra opção interessante é o bloqueio de pacotes inválidos, o que também melhora a segurança contra ataques diversos, incluindo pacotes enviados sem serem precedidos pelo envio do pacote SYN e da abertura da conexão:

echo 1 > /proc/sys/net/ipv4/conf/default/rp_filter
iptables -A INPUT -m state –state INVALID -j DROP

Juntando tudo, teríamos:

iptables -A INPUT -p icmp –icmp-type echo-request -m limit –limit 1/s -j ACCEPT
echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route
echo 0 > /proc/sys/net/ipv4/ip_forward
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
echo 1 > /proc/sys/net/ipv4/conf/default/rp_filter
iptables -A INPUT -m state –state INVALID -j DROP

Essas regras devem ser adicionadas logo no início do script, de forma que sejam carregadas antes de qualquer regra que abra portas ou permita o acesso de endereços ou faixa de endereços. Com isso, garantimos que elas serão aplicadas a todas as conexões, reduzindo a quantidade de buracos no firewall.

Fonte: Link

Anúncios

~ por 3c0linux em julho 28, 2010.

 
%d blogueiros gostam disto: