Por que não bloquear o ICMP?

Eu acho que quase tenho minha configuração do iptables concluída no meu sistema CentOS 5.3. Aqui está o meu script ...

# Establish a clean slate
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
iptables -F # Flush all rules
iptables -X # Delete all chains

# Disable routing. Drop packets if they reach the end of the chain.
iptables -P FORWARD DROP

# Drop all packets with a bad state
iptables -A INPUT -m state --state INVALID -j DROP
# Accept any packets that have something to do with ones we've sent on outbound
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
# Accept any packets coming or going on localhost (this can be very important)
iptables -A INPUT -i lo -j ACCEPT
# Accept ICMP
iptables -A INPUT -p icmp -j ACCEPT

# Allow ssh
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# Allow httpd
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
# Allow SSL
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# Block all other traffic 
iptables -A INPUT -j DROP

Por contexto, esta máquina é um host de aplicativo Web de servidor privado virtual.

Em uma pergunta anterior , Lee B disse que eu deveria "bloquear o ICMP um pouco mais". Por que não apenas bloqueá-lo completamente? O que aconteceria se eu fizesse isso (que coisa ruim aconteceria)?

Se eu não precisar bloquear o ICMP, como posso travá-lo mais?

O ICMP é muito, muito mais que "traceroute" e "ping". É usado para feedback quando você executa um servidor DNS (porta inacessível) que, em um servidor DNS moderno, pode realmente ajudar a selecionar uma máquina diferente para consultar mais rapidamente.

O ICMP também é, como mencionado acima, usado para a descoberta do caminho MTU. Provavelmente, o seu sistema operacional define "DF" (não fragmenta) nos pacotes TCP que ele envia. Ele espera recuperar um pacote "fragmentação necessária" do ICMP, se algo ao longo do caminho falhar ao lidar com esse tamanho de pacote. Se você bloquear todo o ICMP, sua máquina precisará usar outros mecanismos de fallback, que basicamente usam um tempo limite para detectar um "buraco negro" da PMTU e nunca serão otimizados corretamente.

Além disso, você deve se perguntar por que deseja bloquear o ICMP. O que especificamente você está tentando impedir aqui? É bastante claro que você não entende para que o ICMP é usado, o que é bastante comum. Eu seria extremamente cauteloso ao bloquear algo que você não entende completamente.

Para tornar ainda mais difícil aprender sobre isso, muitos livros comuns sobre firewall dizem "bloquear ICMP" - é claro que seus autores nunca leram uma RFC ou tiveram que resolver problemas relacionados a esse conselho. É um mau conselho bloquear todo o ICMP.

Agora, limitar a taxa também pode doer. Se sua máquina estiver ocupada, ou mesmo se não estiver, você poderá obter uma boa quantidade de tráfego ICMP. Meu servidor da Web provavelmente recebe de 10 a 100 pacotes ICMP por minuto, a maioria dos quais é descoberta por PMTU. Mesmo que alguém tenha escolhido atacar meu servidor com pacotes ICMP de algum tipo, isso realmente não é grande coisa. Se sua máquina aceitar pelo menos uma conexão TCP (ssh, http, correio, etc), é provável que esse seja um vetor de ataque maior do que o ICMP mal compreendido.

O ICMP é usado para diversas funções de diagnóstico (por exemplo, ping, traceroute) e controle de rede (por exemplo, descoberta de PMTU). O bloqueio indiscriminado do ICMP causa a outras pessoas todo tipo de azia e, a menos que você saiba exatamente o que está fazendo, deve deixá-lo em paz.

Eu nunca entendi por que as pessoas cronometram o ICMP, como dito acima, isso só causa dores de cabeça para você e para os outros. Você pode determinar se um host é instalado com bastante facilidade e, desde que seja limitado o suficiente para não ser usado como um DOS, nunca ouvi razões convincentes para bloqueá-lo. (Se alguém puder apresentar um motivo, poste)

você pode apenas tentar limitar o icmp para que ele não possa ser usado como um ataque do DOS. mas existem muitas ferramentas de solução de problemas, como ping, mtr (eu esqueço o equivalente ao Windows), traceroute (tracert), que usam o icmp. largá-los inteiramente é simplesmente tolice. É uma boa maneira de verificar se sua instância está ativa, mesmo que você não consiga telnet em nenhuma porta.

--limit 10/second

Aqui está um ponto de vista alternativo, no espírito do que a teoria de segurança sugere. Outros pôsteres estão certos de que a prática de segurança geralmente é excessivamente zelosa, mas há uma boa base para isso.

A teoria da segurança é geralmente que você só ativa o QUE PRECISA. Outras coisas (que podem ser úteis - por exemplo, respostas de ping) podem ser usadas por um invasor para otimizar seu sistema ou, possivelmente, como um vetor de ataque para alguma vulnerabilidade ainda a ser descoberta.

Portanto, olhando para os tipos de mensagens ICMP, o que você precisa para uma operação normal e adequada do seu sistema?

• resposta de eco (ping) - nem tanto
• destino inacessível - muitas informações úteis aqui. Desative isso e você interromperá o acesso ao seu servidor para alguns clientes.
• desativação da fonte - descontinuada desde 1995 e aparentemente removida das implementações de host desde (o mais tardar) em 2005. tools.ietf.org/html/rfc6633#section-1.
• redirecionar - quase certamente não
• anúncio e solicitação de roteador - não é necessário se você configurar estaticamente suas rotas e puder ser usado para DoS. Eu o bloquearia, a menos que você saiba que precisa e, se precisar, talvez codifique uma regra para aceitar informações apenas dos possíveis roteadores conhecidos.
• ttl excedido - não apenas para traceroute, informa que seu tráfego não está chegando ao destino

...e assim por diante. Se você realmente quer entender isso, aprenda sobre os vários tipos de ICMP e para que servem. O artigo da Wikipedia é um bom ponto de partida.

Na prática, o realmente feio é o redirecionamento; se você quiser fazer algo rápido e útil, bloqueie-o e permita o resto.

Eu acrescentaria que o rastreamento da conexão IPtables permitirá os pacotes ICMP de retorno apropriados para conexões ativas. Portanto, se você estiver executando o conntrack, poderá bloquear a maioria das entradas de ICMP, desde que esteja aceitando pacotes RELATED (antes de bloquear o ICMP no seu conjunto de regras).

É uma ferramenta de diagnóstico útil para resolver problemas de conectividade de rede.

Ele também permite que você use conexões em outros lugares da Internet que usam MTUs menores do que na sua rede. Se você tentar enviar um pacote para um local muito grande e não puder ser fragmentado, o dispositivo descarta o pacote e envia um pacote necessário de fragmentação ICMP de volta ao remetente. Se você soltar todos os pacotes ICMP, você os perde e coisas estranhas acontecem na sua rede.

A verdadeira questão é "por que bloquear o ICMP?" O que você ganha? Basta ter boas regras de filtragem na sua fronteira e na frente de seus ativos avaliados.

ping é uma boa ferramenta de diagnóstico, você realmente desejará ter um dia. Eu estou usando estes:

-A icmp_packets -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A icmp_packets -p icmp -m icmp --icmp-type 11 -j ACCEPT

você também pode querer estrangulá-lo.

Atualmente, até a limitação dos pacotes ICMP no lado do servidor pode causar dor de cabeça em ataques DDoS. Ataques feitos principalmente enviando enormes solicitações de janela ICMP para um servidor e se o servidor está tentando responder a cada um deles, adivinhe o que acontece?

Principal coisa que nós temos um servidor de teampeak que recebe pacotes ruins todos os dias, houve alguns dias em dois meses que tivemos um "tempo livre". O que tínhamos feito é respostas de ICMP completamente desabilitadas / bloqueadas, não temos servidores DNS no servidor, servidores NTP, servidores de correio, servidores FTP, apenas dois apache e teampeak. todas as portas desnecessárias para os serviços estão desativadas. Estamos planejando bloquear até o ssh e deixar apenas duas portas abertas. Hoje existem 21k (!) Proibições permanentes.

A situação é que os atacantes usam principalmente túneis ICMP e poucas linhas de registro realmente interessantes foram discutidas com os administradores do servidor e eles disseram que têm solicitações de servidor ICMP ativadas, então os atacantes usaram isso para encapsular o ataque através deles e nos atacar. Soa estranho, mas é verdade.

Se você não precisa de diagnóstico do seu servidor e se é capaz de bloquear completamente as solicitações ou filtrá-las para abrir janelas enormes, por exemplo, faça-o. Também sugiro que você bloqueie completamente: China, Coréia, Tailândia, Turquia, porque a maioria dos endereços IP vem de lá. Eu tinha listas inteiras desses países, mas quase todos os dias vem algumas novas de lá.

Eu digo o que faço, se você não concorda - não faça. Simples assim. Boa sorte

No mínimo, você deve permitir a passagem de tipos icmp 3 (destino inacessível), 4 (extinção da origem) e 11 (tempo excedido). Todos esses tipos são usados ​​para lidar com problemas de rede e não devem ser filtrados.

iptables -A INPUT -p icmp -m icmp --icmp-type 3 -j ACCEPT
iptables -A INPUT -p icmp -m icmp --icmp-type 4 -j ACCEPT
iptables -A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT

No momento, o tipo de desativação da fonte está obsoleto, mas não será prejudicial deixar isso aberto.

Eu permito o tráfego ICMP da intranet local, bloqueio-o da Internet. Dessa forma, meu servidor está praticamente invisível online (responde apenas em uma porta SSH não padrão).

iptables -I INPUT 7 -d 208.180.X.X -p icmp --icmp-type 8  -j DROP
iptables -I INPUT 8 -d 208.180.X.X -p icmp --icmp-type 0  -j DROP
iptables -I INPUT 9 -d 208.180.X.X -p icmp --icmp-type 11 -j DROP

Isso o insere após o loopback padrão, a lista de desbloqueio LAN estabelecida, a lista de desbloqueio de provedor VOIP e os ACCEPTs da porta SSH. Permito o tráfego que desejo e, em seguida, faço o possível para manter o servidor invisível para o resto do mundo.