No censo da Internet conduzido pelo DefCon-Lab, nós constatamos que muitos dispositivos filtram (bloqueiam) mensagens do protocolo ICMP e, apesar de não responderem às mensagens Echo Request, estavam on-line pois respondem em portas TCP/UDP. Percebemos isso ao comparar o Censo da Internet 2018 com outros mapeamentos realizados anteriormente, como o Mapeamento Global do HTTPS.
Conforme prometido naquela ocasião, hoje iremos aprofundar esse assunto. Em primeiro lugar, vamos entender do que se trata o protocolo ICMP. O comando ping é a aplicação mais famosa que utiliza esse protocolo. Na imagem abaixo, é possível observar que o ICMP pertence à camada de rede, ou seja, no mesmo nível do IP. Isto é, uma camada abaixo dos protocolos de transporte TCP ou UDP e duas abaixa das aplicações.
Em comparação com outros protocolos TCP/IP, o ICMP é simples, mas atende a um grande número de funções diferentes. Ele foi projetado para facilitar a depuração de erros, resolução de problemas e para gerar relatórios de diagnósticos da camada de rede. Ou seja, é o amigo do administrador da rede nos momentos mais difíceis, então, é preciso ponderar bastante antes de simplesmente desativá-lo ou bloqueá-lo.
O comando ping é um dos programas mais famosos que utilizam o ICMP. Por meio de mensagens echo request e echo reply ele é capaz de verificar se dois hosts são capazes de se comunicar pela rede. Isso é valioso para a depuração de erros, visto que eventuais problemas podem não estar na comunicação, mas sim nas aplicações das camadas superiores.
$ ping6 defcon-lab.org PING defcon-lab.org(defcon-lab.org (2607:5300:201:3100::44e6)) 56 data bytes 64 bytes from defcon-lab.org (2607:5300:201:3100::44e6): icmp_seq=1 ttl=45 time=245 ms 64 bytes from defcon-lab.org (2607:5300:201:3100::44e6): icmp_seq=2 ttl=45 time=267 ms 64 bytes from defcon-lab.org (2607:5300:201:3100::44e6): icmp_seq=3 ttl=45 time=289 ms --- defcon-lab.org ping statistics --- 4 packets transmitted, 3 received, 25% packet loss, time 7ms rtt min/avg/max/mdev = 245.000/267.062/289.318/18.093 ms
No exemplo acima é possível verificar que o host defcon-lab.org está online e está acessível, uma vez que responde a mensagens echo request. Em um cenário de diagnóstico de problemas, isso é fundamental pois o simples fato de o host responder já é suficiente para que seja descartada uma série de possíveis causas.
$ traceroute6 defcon-lab.org traceroute to defcon-lab.org (2607:5300:201:3100::44e6), 30 hops max, 80 byte packets 5 * 2804:a8:2:88::cd (2804:a8:2:88::cd) 13.002 ms * 6 2804:a8::200:244:27:99 (2804:a8::200:244:27:99) 12.114 ms 12.812 ms 12.820 ms 7 * * * 8 * * * 9 * * * 10 be100-153.mia-mi1-bb1-a9.fl.us (2607:5300::10a) 138.815 ms 137.095 ms 136.791 ms 11 be100-1290.ash-5-a9.va.us (2607:5300::183) 163.282 ms 163.686 ms 162.856 ms 12 * * * 13 vl100.bhs-d2-a75.qc.ca (2607:5300::1cd) 178.342 ms * * 14 vl100.bhs-d2-a75.qc.ca (2607:5300::1cd) 179.602 ms 181.461 ms 176.349 ms 15 be7.bhs-z2g1-a75.qc.ca (2607:5300::155) 176.835 ms be7.bhs-z2g2-a75.qc.ca (2607:5300::157) 181.531 ms be7.bhs-z2g1-a75.qc.ca (2607:5300::155) 178.174 ms 16 2607:5300:0:1:1:c9:2:0 (2607:5300:0:1:1:c9:2:0) 176.486 ms 176.165 ms 2607:5300:0:1:1:c9:1:0 (2607:5300:0:1:1:c9:1:0) 176.568 ms 17 2607:5300:201:c9::12 (2607:5300:201:c9::12) 181.574 ms 2607:5300:201::6 (2607:5300:201::6) 176.577 ms 177.233 ms 18 defcon-lab.org (2607:5300:201:3100::44e6) 176.884 ms 2607:5300:201::6 (2607:5300:201::6) 230.324 ms 230.260 ms
No traceroute acima, é possível observar que todos os nós da rede (roteadores) entre um host e o defcon-lab.org estão em funcionamento e realizando o encaminhamento de pacotes. Isso permite identificar de forma precisa os pontos de falha e gargalos.
Diante das funcionalidades, porque alguns administrados optam por bloquear o ICMP? Provavelmente por falta de um diagnóstico real dos efeitos colaterais de se bloquear esse protocolo e porque, de fato, a partir do uso furtivo do ICMP é possível realizar algum nível de reconhecimento da rede por um agente malicioso.
Se um computador responde uma mensagem ICMP para alguém, então esse alguém saberá que aquele endereço possui um dispositivo TCP/IP ligado. Pode-se usar pings (echo requests) para determinar se um host está realmente ligado e acessível, ou o tempo excedido (como parte de um traceroute) para mapear arquiteturas de rede.
O ponto que deve ser ponderado é que esse mapeamento é relativamente limitado em detrimento das vantagens que o ICMP poderia trazer se estivesse habilitado. Além disso, existem muitas outras maneiras de mapear a infraestrutura. Uma ameaça persistente irá realizar o reconhecimento da rede independentemente do ICMP estar disponível. Um eventual atacante motivado certamente irá rodar ferramentas como o NMAP e outros recursos para coletar informações. Portanto, o ICMP não é um problema nesse aspecto.
Em outras palavras, se o host tiver algum serviço disponível, isso será suficiente para que ele seja visto e mapeado. Ademais, o reconhecimento não se limitará a mera existência do computador, mas incluirá os serviços disponibilizados, bem como as portas e protocolos disponíveis. Além disso, muitas ferramentas de reconhecimento de rede são capazes, inclusive, de identificar a versão do software atrás da porta aberta. Nesse contexto, as varreduras ocorrem diretamente nas portas UDP e TCP, pois o ICMP, por estar restrito a camada de rede, não trabalha na lógica de portas, serviços e aplicações.
Evidência disso são os dados coletados por nossos honeypots, onde é possível verificar que a maioria massiva das sondagens em portas TCP e UDP são realizadas sem prévio probing ICMP. As mensagens ICMP correspondem a menos de 0,5% do total de requisições, em comparação ao UDP e, sobretudo, ao TCP.
Considerando que todo tráfego contra um honeypot pode ser taxado como malicioso e que boa parte dessas sondagens são realizadas por bots, pode-se afirmar que a estratégia de bloqueio de ICMP não agrega camada de segurança sequer contra atividades totalmente automatizadas.
Portanto, uma abordagem mais eficiente é manter os servidores e hosts atualizados (pois isso realmente corrige os problemas reais) do que escondê-los sob o tapete, onde um agente adverso devidamente motivado irá encontrá-los de qualquer maneira. Isso fica evidente ao entender como os serviços são disponibilizados no TCP/IP.
O TCP/IP é fortemente orientado a encapsulamento e abstração entre as camadas do protocolo, conforme imagem abaixo.
Exemplificando a imagem acima, em uma requisição HTTP, o conteúdo de uma página web é encapsulado com um cabeçalho HTTP, depois por um cabeçalho TCP, em seguida por um cabeçalho IP e, finalmente, será encapsulado em um frame para transmissão por um canal de comunicação, como um cabo, uma rede wifi, etc. Todos os dados são serializados e o quadro é encaminhado para o nó de destino como um fluxo de bits.
Ao chegar ao destino, o processo inverso é realizado, onde o frame é desencapsulado camada por camada até chegar à aplicação correspondente.
O resultado desse processo de encapsulamento é que cada camada inferior fornece um serviço para a camada ou camadas acima dela, o que permite que cada camada se comunique com sua camada correspondente no receptor. Logo, é o encapsulamento das informações que fornece a abstração e o isolamento entre as diferentes camadas do protocolo TCP/IP.
O protocolo de transporte (UDP ou TCP) é quem faz o bind da porta para o processo ou para o aplicativo correspondente, ou seja, é a porta quem especifica o serviço disponível, como Web, MySQL, SMB, SSH ou RDP. Diante disso, é fácil visualizar que as vulnerabilidades se encontram, quase que em sua totalidade, nas aplicações, isto é, nos serviços propriamente ditos. Essa é a razão pela qual as regras de bloqueio e de autorização no firewall ocorrem nas portas (serviços) e na origem do tráfego, ao invés de ser realizado nos protocolos de comunicação e de endereçamento, os quais é desejável que estejam em pleno funcionamento.
A questão da fragmentação de pacotes é um exemplo clássico de como o bloqueio sem critérios pode ser prejudicial. A maioria dos pacotes IPv4 é configurado com a flag Don’t Fragment (DF), enquanto que o IPv6 sequer trabalha com fragmentação no roteador. Nesses casos, quando um gateway recebe um pacote maior do que ele consegue retransmitir, ele descarta o pacote e gera uma mensagem ICMP do tipo Destination Unreachable com o código 4 Fragmentation Required e envia de volta a origem para avisar que o pacote está muito grande e que é necessária a fragmentação em partes menores. Se este erro não puder ser transmitido ao remetente, ele não saberá do problema. Além disso, ele interpretará a falta de ACK por parte do receptor como congestionamento ou simples perda do pacote. Após uns instantes, o emissor, devido a não confirmação do recebimento pelo receptor, simplesmente retransmitirá o pacote, que, obviamente, também será descartado, inviabilizando a comunicação. Essa questão já foi tão grave que foi necessário implementar uma estratégia descrita na RFC 4821 como Packetization Layer Path MTU Discovery (PLPMTUD) para mitigar o problema.
Voltando ao bloqueio do ICMP, outro ponto é a preocupação de que os pacotes “ICMP TTL EXCEEDED” podem revelar a existência de roteadores entre dois hosts. Na verdade, essa é a base do comando traceroute, pois ele envia vários pacotes com valores TTL deliberadamente incrementais, o que faz com que eles expirem em trânsito e capturam quais roteadores reportam de volta com o aviso “ICMP TTL EXCEEDED”. Logo, isso é importante e desejável para identificar pontos de falha e para melhorar as rotas de tráfego.
É compreensível que não se deseje revelar a existência de alguns detalhes, mas, de todo modo, a obscuridade não é uma forma de se implementar segurança. Na prática, a obscuridade não resiste por muito tempo, não sendo, portanto, uma camada de segurança.
Isso não quer dizer que devemos necessariamente deixar todo o ICMP aberto para a Internet. É possível ter uma abordagem ponderada. Em regra, as mensagens ICMP utilizadas para solução de problemas (vide Wikipedia) são:
- Echo Request – ICMP Type 8 Code 0
- Echo Replies – ICMP Type 0 Code 0
- Time Exceeded – ICMP Type 11 Code 0
- Fragment needed but DF bit set – ICMP Type 3 Code 4
Alguns firewalls como o UFW (que é um gerenciador do netfilter) já trazem em sua configuração padrão um ajuste fino para o ICMP. Para olhara as regras pré-configuradas, basta visualizar o arquivo /etc/ufw/before.rules.
$ cat /etc/ufw/before.rules # ok icmp codes for INPUT -A ufw-before-input -p icmp --icmp-type destination-unreachable -j ACCEPT -A ufw-before-input -p icmp --icmp-type source-quench -j ACCEPT -A ufw-before-input -p icmp --icmp-type time-exceeded -j ACCEPT -A ufw-before-input -p icmp --icmp-type parameter-problem -j ACCEPT -A ufw-before-input -p icmp --icmp-type echo-request -j ACCEPT
Em uma passagem de olho, é possível identificar que a linha referente à mensagem source-quench pode ser comentada e desativada, visto que esse tipo de mensagem ICMP já possui o status deprecated (descontinuada).
Conclusão
A comparação dos resultados entre o Censo da Internet 2018 e outros mapeamentos de portas realizados anteriormente, demonstrou que muitos dispositivos filtram (bloqueiam) mensagens do protocolo ICMP, pois não responderam a mensagens Echo Request, mas estavam on-line pois respondem em portas TCP/UDP específicas. Isso permite concluir que essa é uma estratégia de segurança adotada em algumas redes.
O ICMP é um protocolo da camada de rede e tem várias funções. No nosso ponto de vista, filtrar ICMP sem critério pode trazer muitos problemas, sem a contrapartida de agregar camada de segurança.
Manter o sistemas e serviços atualizados é uma abordagem mais eficiente do que aplicar filtros sem critérios e objetivos específicos.
Obscuridade não é uma camada de segurança. Segmentação e segregação por meio de VLAN e DMZ são alternativas mais interessantes.
Em regra, os bloqueios e autorizações no firewall se dão em nível de porta (aplicações) e de origens. Relações de confiança pré-estabelecidas e análise reputacional são pontos a serem considerados nas regras de bloqueio ou de autorização com base na origem do tráfego.
Segurança deve ser pensada em camadas e em dificuldade por profundidade, a depender da criticidade da informação. Existe uma gama de soluções maduras e livres: criptografia, firewall, firewall de aplicação, IPS, IDS, SIEM, honeypot, blacklist, anti vírus, etc. O sucesso está na integração dessas tecnologias e no monitoramento contínuo.
É sempre aconselhável adotar uma abordagem ponderada ao se optar por bloqueios genéricos e abrangentes, pois tendem a afetar tráfego legítimo. Bloquear o ICMP em sua totalidade provavelmente não é a melhor implementação, sobretudo porque pode ser prejudicial ao pleno funcionamento da rede. Além disso, é possível fazer um ajuste fino dos filtros ICMP.