Para que seja possível uma comunicação entre computadores é necessário que algumas regras sejam estabelecidas. Esse conjunto de normas e padrões que definem como se dará esse contato é conhecido como protocolos de rede.
Gostaria de saber mais sobre o assunto? Neste artigo explicaremos o que são os protocolos de rede e abordaremos mais a fundo os seus principais tipos. Continue a leitura e confira!
O que são protocolos de rede?
Protocolos de rede são os conjuntos de normas que permitem que duas ou mais máquinas conectadas à internet se comuniquem entre si. Funciona como uma linguagem universal, que pode ser interpretada por computadores de qualquer fabricante, por meio de qualquer sistema operacional.
Eles são responsáveis por pegar os dados transmitidos pela rede e dividi-los em pequenos pedaços, que são chamados de pacotes. Cada pacote carrega em si informações de endereçamento de origem e destino. Os protocolos também são responsáveis pela sistematização das fases de estabelecimento, controle, tráfego e encerramento.
Existem três elementos-chave que definem os protocolos de rede. São eles:
- sintaxe: representa o formato dos dados e a ordem pela qual eles são apresentados;
- semântica: refere-se ao significado de cada conjunto sintático que dá sentido à mensagem enviada;
- timing: define uma velocidade aceitável de transmissão dos pacotes.
Quais são os principais tipos de protocolos de rede?
Para que a comunicação entre computadores seja realizada corretamente, é necessário que ambos os computadores estejam configurados segundo os mesmos parâmetros e obedeçam aos mesmos padrões de comunicação.
A rede é dividida em camadas, cada uma com uma função específica. Os diversos tipos de protocolos de rede variam de acordo com o tipo de serviço utilizado e a camada correspondente. Conheça a seguir as principais camadas e seus tipos de protocolos principais:
- camada de aplicação: WWW, HTTP, SMTP, Telnet, FTP, SSH, NNTP, RDP, IRC, SNMP, POP3, IMAP, SIP, DNS, PING;
- camada de transporte: TCP, UDP, RTP, DCCP, SCTP;
- camada de rede: IPv4, IPv6, IPsec, ICMP;
- camada de ligação física: Ethernet, Modem, PPP, FDDi.
Selecionamos neste artigo 11 dos principais tipos de protocolos de rede para analisarmos mais a fundo. Vamos conhecê-los nos tópicos seguintes.
1. IP
O protocolo IP, do termo em inglês Internet Protocol (Protocolo de Internet) faz parte da camada de internet e é um dos protocolos mais importantes da web. Ele permite a elaboração e transporte dos pacotes de dados, porém sem assegurar a sua entrega.
O destinatário da mensagem é determinado por meio dos campos de endereço IP (endereço do computador), máscara de sub rede (determina parte do endereço que se refere à rede) e o campo gateway estreita por padrão (permite saber qual o computador de destino, caso não esteja localizado na rede local).
2. TCP/IP
Trata-se do acrônimo de dois protocolos combinados. São eles o TCP (Transmission Control Protocol — Protocolo de Controle de Transmissão) e IP (Internet Protocol — Protocolo de Internet).
Juntos, são os responsáveis pela base de envio e recebimento de dados por toda a internet. Essa pilha de protocolos é dividida em 4 camadas:
- aplicação: usada para enviar e receber dados de outros programas pela internet. Nessa camada estão os protocolos HTTP, FTP e SMTP;
- transporte: responsável por transportar os arquivos dos pacotes recebidos da camada de aplicação. Eles são organizados e transformados em outros menores, que serão enviados à rede;
- rede: os arquivos empacotados na camada de transporte são recebidos e anexados ao IP da máquina que envia e recebe os dados. Em seguida, eles são enviados pela internet;
- interface: é a camada que executa o recebimento ou o envio de arquivos na web.
3. HTTP/HTTPS
O protocolo HTTP (Hypertext Transfer Protocol — Protocolo de Transferência de Hipertexto) é usado para navegação em sites da internet. Funciona como uma conexão entre o cliente (browser) e o servidor (site ou domínio).
O navegador envia um pedido de acesso a uma página, e o servidor retorna uma resposta de permissão de acesso. Junto com ela são enviados também os arquivos da página que o usuário deseja acessar.
Já o HTTPS (Hyper Text Transfer Secure — Protocolo de Transferência de Hipertexto Seguro) funciona exatamente como o HTTP, porém, existe uma camada de proteção a mais. Isso significa que os sites que utilizam esse protocolo são de acesso seguro.
O protocolo HTTPS é comumente usado por sites com sistemas de pagamentos. Esse tipo de site depende de proteção que garanta a integridade dos dados, informações de conta e cartão de créditos dos usuários. A segurança é feita por meio de uma certificação digital, que cria uma criptografia para impedir ameaças e ataques virtuais.
4. FTP
Significa Protocolo de Transferência de Arquivos (do inglês File Transfer Protocol). É a forma mais simples para transferir dados entre dois computadores utilizando a rede.
O protocolo FTP funciona com dois tipos de conexão: a do cliente (computador que faz o pedido de conexão) e do servidor (computador que recebe o pedido de conexão e fornece o arquivo ou documento solicitado pelo cliente).
O FTP é útil caso o usuário perca o acesso ao painel de controle do seu site. Assim sendo,essa ferramenta pode ser usada para realizar ajustes página, adicionar ou excluir arquivos, ou ainda solucionar qualquer outra questão no site.
5. SFTP
Simple Transfer Protocol (Protocolo de Transferência Simples de Arquivos) consiste no protocolo FTP acrescido de uma camada de proteção para arquivos transferidos.
Nele, a troca de informações é feita por meio de pacotes com a tecnologia SSH (Secure Shell – Bloqueio de Segurança), que autenticam e protegem a conexão entre cliente e servidor. O usuário define quantos arquivos serão transmitidos simultaneamente e define um sistema de senhas para reforçar a segurança.
6. SSH
SSH (Secure Shell, já citado acima) é um dos protocolos específicos de segurança de troca de arquivos entre cliente e servidor. Funciona a partir de uma chave pública. Ela verifica e autentica se o servidor que o cliente deseja acessar é realmente legítimo.
O usuário define um sistema de proteção para o site sem comprometer o seu desempenho. Ele fortifica a segurança do projeto e garante maior confiança e estabilidade na transferência de arquivos.
7. SSL
O protocolo SSL (Secure Sockets Layer — Camada de Portas de Segurança) permite a comunicação segura entre os lados cliente e servidor de uma aplicação web, por meio de uma confirmação da identidade de um servidor e a verificação do seu nível de confiança.
Ele age como uma subcamada nos protocolos de comunicação na internet (TCP/IP). Funciona com a autenticação das partes envolvidas na troca de informações.
A conexão SSL é sempre iniciada pelo cliente, que solicita conexão com um site seguro. O browser, então, solicita o envio do Certificado Digital e verifica se ele é confiável, válido, e se está relacionado ao site que fez o envio. Após a confirmação das informações, a chave pública é enviada e as mensagens podem ser trocadas.
8. ICMP
Sigla para Internet Control Message Protocol (Protocolo de Mensagens de Controle da Internet). Esse protocolo autoriza a criação de mensagens relativas ao IP, mensagens de erro e pacotes de teste.
Ele permite gerenciar as informações relativas a erros nas máquinas conectadas. O protocolo IP não corrige esses erros, mas os mostra para os protocolos das camadas vizinhas. Por isso, o protocolo ICMP é usado pelos roteadores para assinalar um erro, chamado de Delivery Problem (Problema de Entrega).
9. SMTP
Protocolo para transferência de e-mail simples (Simple Mail Transfer Protocol) é comumente utilizado para transferir e-mails de um servidor para outro, em conexão ponto a ponto.
As mensagens são capturadas e enviadas ao protocolo SMTP, que as encaminha aos destinatários finais em um processo automatizado e quase instantâneo. O usuário não tem autorização para realizar o download das mensagens no servidor.
10. TELNET
Protocolo de acesso remoto. É um protocolo padrão da Internet que permite obter uma interface de terminais e aplicações pela web. Fornece regras básicas para ligar um cliente a um intérprete de comando.
Ele tem como base uma conexão TCP para enviar dados em formato ASCII codificados em 8 bits, entre os quais se intercalam sequências de controle Telnet. Assim, fornece um sistema orientado para a comunicação bidirecional e fácil de aplicar.
11. POP3
Acrônimo para Post Office Protocol 3 (Protocolo de Correios 3). É um protocolo utilizado para troca de mensagens eletrônicas. Funciona da seguinte forma: um servidor de email recebe e armazena mensagens. O cliente se autentica ao servidor da caixa postal para poder acessar e ler as mensagens.
Assim, as mensagens armazenadas no servidor são transferidas em sequência para o computador do cliente. Quando, a conexão é encerrada as mensagens ainda são acessadas no modo offline.
TNG aumenta a produtividade da gestão de TI com o OpMon. Leia o case completo.
Monitoramento de protocolos de rede e tráfego
Além de conhecer os principais protocolos, muitas empresas precisam realizar o monitoramento da rede para que ela funcione da melhor forma possível. Para esta tarefa, existem muitas soluções que realizam o monitoramento da rede para, assim, evitar o desperdício de recursos.
Uma plataforma que recomendamos é o OpMon Traffic Analyzer, software desenvolvido no Brasil e que faz o gerenciamento qualitativo da rede em tempo real para obter uma análise detalhada do status, do tipo de tráfego e de quem são os consumidores de recursos da rede.
Com a leitura deste artigo, conhecemos mais sobre o que são protocolos de redes e quais são os seus principais tipos. Graças a eles é possível realizar a comunicação entre diferentes tipos de computadores, sem que para isso seja necessária uma linguagem nova para cada um.
Nós da OpServices podemos ajudá-lo com a infraestrutura em TI e monitoramento de negócios. Quer saber mais sobre os nossos serviços? Basta entrar em contato com a nossa equipe!
Você conhece realmente como funciona o Ping e o Traceroute?
- Se você já teve que resolver um problema de rede com certeza já utilizou os comandos do ICMP ping e trace, mas você sabe realmente em quais situações eles funcionam melhor?
- Nesse artigo eu vou falar um pouco do protocolo utilizado para ambos os comandos traceroute e ping, assim como para reportar problemas na rede IP chamado de ICMP ou Internet Control Message Protocol.
- O ICMP é importante tanto para sua vida prática como para provas de certificação, tais como CCENT 100-101 e CCNAX 200-120, assim como para concursos públicos na área de infraestrutura de TI.
- Por isso leia com atenção, anote os principais pontos e se precisar utilize nossa área de comentários caso tenha alguma dúvida, combinado?
- Nesse artigo você vai estudar os seguintes tópicos:
- Então vamos começar…
Quer passar na sua PRIMEIRA Certificação Cisco SEM RISCO de Reprovar? Baixe o E-Book e descubra como conseguir essa façanha:
Protocolo ICMP
- O ICMP é um protocolo integrante do Protocolo IP, definido pela RFC 792, e utilizado para fornecer relatórios de erros ao host que deu origem aos pacotes enviados na rede.
- Qualquer computador que utilize o protocolo IP precisa aceitar as mensagens ICMP e alterar o seu comportamento de acordo com o erro relatado.
- Os gateways (roteadores) devem também estar programados para enviar mensagens ICMP quando receberem pacotes que provoquem algum tipo de erro ou detectarem algum problema listado no protocolo ICMP.
- O ICMP é transportado no campo de dados do pacote IP e identificado como tipo de protocolo “1” pelo cabeçalho do IP.
- As principais mensagens de erro ou informacionais do ICMP geralmente são enviadas automaticamente em uma das seguintes situações:
- Um pacote IP não consegue chegar ao seu destino, por exemplo, quando o tempo de vida (TTL) do pacote está expirado (o contador chegou à zero). Esta mensagem é o tempo de vida expirado ou “time exceeded”.
- O roteador não consegue retransmitir os pacotes na frequência adequada, ou seja, o roteador está congestionado (mensagem “source quench”).
- O roteador indica uma rota melhor para o host que está enviando pacotes (mensagem de redirecionamento de rota ou “redirect”).
- Quando um host de destino ou rota não está alcançável (mensagem “destination unreachable” ou destino inalcançável).
- Quando o host ou o roteador descobrem um erro de sintaxe no cabeçalho do IP (mensagem “parameter problem”).
Existem diversas outras mensagens que o ICMP pode fornecer e cada uma é representada por um tipo ou código, conforme será mostrado no quadro do ICMP no final desse artigo.
Agora vamos estudar um pouco mais sobre o funcionamento do ping, esse comando tão importante que acompanha a vida profissional de iniciantes até os “Jedis” da área de Redes de Computadores.
Funcionamento e Uso do Ping
O Ping é baseado em duas mensagens, o echo request e echo reply.
Quando você entra no prompt de comandos do Windows e, por exemplo, digita “ping www.dltec.com.br”, na realidade seu computador está enviando mensagens de “echo request” ao servidor onde a página da DlteC está hospedada.
Ao receber essa mensagem de “echo request” nosso servidor responde seu computador com um “echo reply”.
Caso o servidor não responda seu computador indicará um timeout (tempo de resposta expirado), indicando que não houve resposta.
Veja na figura abaixo um exemplo de ping enviado do host com endereço IP 192.168.1.2 para o host com o IP 192.168.1.3.
Veja um exemplo de teste de ping no Windows com taxa de resposta de 100% (ping bem sucedido) e depois com perda de 100% (ping com problema, sem comunicação entre os hosts).
- O teste de ping é utilizado para verificar se há comunicação fim a fim, ou seja, entre origem e destino.
- Esse teste é realizado na camada-3 do modelo OSI (ou Internet do TCP/IP) e não se importa com os dispositivos (roteadores e switches) que estão no meio do caminho.
- Vale a pena lembrar que as mensagens de ping podem ser bloqueadas por firewalls e/ou IPS’s (Intrusion Prevention System), portanto nem sempre não obter uma resposta a um ping significa necessariamente um erro, pode ser que esse teste esteja bloqueado por motivos de segurança.
- O comando ping básico é o mesmo em maioria dos sistemas operacionais.
Bloqueio de ICMP: camada de segurança ou uma medida ruim?
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.
Protocolo TCP/IP
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.
Atividade em honeypot por protocolo
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.
TCP/IP: encapsulamento e abstração
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.
Dica De Segurança: Previna Ataques Bloqueando Pacotes Icmp Indesejados · Marcelo Cavalcante Rocha
O protocolo ICMP pode ser utilizado para facilitar diversas rotinas e tarefas importantes de um administrador de redes, tais como na utilização de ferramentas como o ping e o traceroute, mas também pode ser manipulado por pessoas mal intencionadas que podem manipular mensagens ou pacotes ICMP para mapear sua rede.
É comum ver administradores de rede se preocupando e fazendo um ótimo trabalho em termos de filtrar o tráfego TCP e/ou UDP, porém quase sempre esquecem de dar a mesma atenção ao tráfego ICMP, sendo este tão crítico quanto os dois anteriores. Uma vez que este protocolo pode ser utilizado para mapear e realizar ataques em sua rede, ele não pode simplesmente ser deixado de lado.
ICMP, sigla para Internet Control Message Protocol, é um protocolo integrante do Protocolo IP utilizado para fornecer relatórios de erros à fonte original. Seu tráfego é, basicamente, baseado em mensagens trocadas entre hots, gateways, etc., cujo intuito é, principalmente, reportar erros, como por exemplo um pacote IP que não consegue chegar ao seu destino.
Por padrão, alguns servidores e firewalls bloqueiam as respostas ICMP como medida de segurança, tentando assim bloquear os ataques que consistem na sobrecarga da memória, enviando dados (em ping) até o sistema não ter a capacidade de administrar suas próprias funções. Bom, ao mesmo tempo em que é um mecanismo de defesa interessante, este bloqueio total acaba comprometendo e atrapalhando diversas atividades do administrador de redes, não sendo portanto a estratégia mais inteligente a ser adotada.
Ao invés de bloquear o ICMP por completo, é mais interessante conhecer o que é bom e o que é ruim em termos de mensagens ICMP, de forma que sejam realizados filtros corretos.
A importância desta gangorra é não permitir que o lado ruim do ICMP, como por exemplo ICMP Smurf, Ping of death, ataques com ICMP flood ou ICMP nuke, prejudiquem o administrador de redes que pode tirar proveito de boas ferramentas que se utilizam do ICMP, como o Ping e o Traceroute.
A estratégia mais simples, portanto, é utilizar uma regra geral contendo exceções.
- Bloquear todos os tipos de tráfego ICMP;
- Permitir ping – CMP Echo-Request outbound (saída) e Echo-Reply inbound (entrada);
- Permitir traceroute – TTL-Exceeded e Port-Unreachable inbound (entrada);
- Permitir path MTU – ICMP Fragmentation-DF-Set inbound (entrada).
- É claro que este é apenas um exemplo, visto que você poderá permitir mais ou menos, de acordo com a sua necessidade.
- Não deixemos pobre a nossa configuração, facilitando as coisas para ataques quando isto pode ser facilmente bloqueado.
- Happy Hacking!
Internet Control Message Protocol
| Esta página ou seção precisa ser wikificada. Por favor ajude a formatar esta página de acordo com as diretrizes estabelecidas. (Novembro de 2015) |
| Esta página cita fontes confiáveis, mas que não cobrem todo o conteúdo. Ajude a inserir referências. Conteúdo não verificável poderá ser removido.—Encontre fontes: Google (notícias, livros e acadêmico) (Junho de 2011) |
|
|
|
|
|
ICMP, sigla para o inglês Internet Control Message Protocol, é um protocolo integrante do Protocolo IP, definido pelo RFC 792, é utilizado para fornecer relatórios de erros à fonte original. Qualquer computador que utilize IP precisa aceitar as mensagens ICMP e alterar o seu comportamento de acordo com o erro relatado. Os gateways devem estar programados para enviar mensagens ICMP quando receberem datagramas que provoquem algum erro.
As mensagens ICMP geralmente são enviadas automaticamente em uma das seguintes situações:
- Um pacote IP não consegue chegar ao seu destino (i.e. Tempo de vida do pacote expirado)
- O Gateway não consegue retransmitir os pacotes na frequência adequada (i.e. Gateway congestionado)
- O Roteador ou Encaminhador indica uma rota melhor para a máquina a enviar pacotes.
Ferramentas comumente usadas em Windows baseadas nesse protocolo são: Ping e Traceroute.
Frames ICMP (1)
- Echo Request / ReplyMensagens para funções de teste e controle da rede, caso a maquina esteja ligada ira responder com um reply e se estiver inalcançavel request;Usadas pelo comando PING
- Destination UnreachableEnviado por um router que deixa fora um Datagrama;
Tipo de mensagem que é obtida quando não se consegue localizar o equipamento alvo;(nem todos os datagramas perdidos são detectados)
- CODE – Indica a razão da perda do datagrama
- Timestamp Request / ReplyMensagens para sincronização dos relógios das máquinas
Estrutura de um datagrama ICMP
Os pacotes ICMP são encapsulados dentro de datagramas IPv4 composto pelas secções cabeçalho (header) e dados.
Cabeçalho (Header)
Este começa no final do cabeçalho IPv4 e é constituído por 8 bytes.
Tipo (Type)
O tipo de mensagem ICMP, ver Mensagens de controle.
Código (Code)
O código (subtipo) da mensagem ICMP, ver Mensagens de controle.
Checksum (Soma de verificação)
Especificado em RFC 1071, é uma soma de verificação da integridade dos dados, calculado a partir do cabeçalho e dos dados do pacote ICMP.
Resto do cabeçalho (Rest of Header)
Um campo de 4 bytes, de conteúdo variado dependendo do tipo e código ICMP.
| Tipo | Código | Checksum |
| Resto do Cabeçalho (Rest of Header) |
Dados
O tamanho da secção dos dados de um pacote ICMP é variável. As mensagens de erro ICMP contêm uma cópia do cabeçalho IPv4 completo, bem como pelo menos 8 bytes dos dados provenientes do mesmo datagrama IPv4 que causou a mensagem de erro. O tamanho máximo de uma mensagem ICMP é de 576 bytes.
Mensagens de controle
As mensagens de controle são identificadas pelo valor no campo tipo, o campo código fornece informação contextual adicional para a mesma. Desde a implementação do protocolo ICMP, algumas mensagens de controle foram postas em desuso.
| 0 – Echo Reply[3]:14 | 0 | Resposta Echo (usado para fazer ping) | |
| 1 and 2 | não atribuídos | Reservado | |
| 3 – Destination Unreachable[3]:4 | 0 | Rede de destino inacessível | |
| 1 | Máquina de destino inacessível | ||
| 2 | Protocolo de destino inacessível | ||
| 3 | Porta de destino inacessível | ||
| 4 | Fragmentação necessária mas impossível devido à bandeira (flag) DF | ||
| 5 | Falha na rota de origem | ||
| 6 | Rede de destino desconhecida | ||
| 7 | Máquina de destino desconhecida | ||
| 8 | Source host isolated | ||
| 9 | Network administratively prohibited | ||
| 10 | Host administratively prohibited | ||
| 11 | Rede inacessível para ToS | ||
| 12 | Máquina inacessível para ToS | ||
| 13 | Communication administratively prohibited | ||
| 14 | Host Precedence Violation | ||
| 15 | Precedence cutoff in effect | ||
| 4 – Source Quench | 0 | deprecada | Source quench (congestion control) |
| 5 – Redirect Message | 0 | Redirecionamento do datagrama para a rede. | |
| 1 | Redirecionamento do datagrama para a máquina | ||
| 2 | Redirecionamento do datagrama para o ToS & rede | ||
| 3 | Redirecionamento do datagrama para o ToS & máquina | ||
| 6 | deprecada | Alternate Host Address | |
| 7 | não atribuído | Reservado | |
| 8 – Echo Request | 0 | Echo request (used to ping) | |
| 9 – Router Advertisement | 0 | Router Advertisement | |
| 10 – Router Solicitation | 0 | Router discovery/selection/solicitation | |
| 11 – Time Exceeded[3]:6 | 0 | TTL expired in transit | |
| 1 | Fragment reassembly time exceeded | ||
| 12 – Parameter Problem: Bad IP header | 0 | Pointer indicates the error | |
| 1 | Opção obrigatória em falta | ||
| 2 | Bad length | ||
| 13 – Timestamp | 0 | Timestamp | |
| 14 – Timestamp Reply | 0 | Timestamp reply | |
| 15 – Information Request | 0 | deprecada | Information Request |
| 16 – Information Reply | 0 | deprecada | Information Reply |
| 17 – Address Mask Request | 0 | deprecada | Pedido da mascara do endereço |
| 18 – Address Mask Reply | 0 | deprecada | Resposta da mascara do endereço |
| 19 | reserved | Reservada para segurança | |
| 20 through 29 | reservadas | Reserved for robustness experiment | |
| 30 – Traceroute | 0 | deprecada | Information Request |
| 31 | deprecada | Datagram Conversion Error | |
| 32 | deprecada | Mobile Host Redirect | |
| 33 | deprecada | Where-Are-You (originalmente destinado para IPv6) | |
| 34 | deprecada | Here-I-Am (originalmente destinado para IPv6) | |
| 35 | deprecada | Mobile Registration Request | |
| 36 | deprecada | Mobile Registration Reply | |
| 37 | deprecada | Domain Name Request | |
| 38 | deprecada | Domain Name Reply | |
| 39 | deprecada | SKIP Algorithm Discovery Protocol, Simple Key-Management for Internet Protocol | |
| 40 | Photuris, Security failures | ||
| 41 | experimental | ICMP for experimental mobility protocols such as Seamoby [RFC4065] | |
| 42 – Extended Echo Request[4] | 0 | Sem erros | |
| 43 – Extended Echo Reply[4] | 0 | Sem erros | |
| 1 | Pedido mal formado | ||
| 2 | Interface desconhecida | ||
| 3 | No Such Table Entry | ||
| 4 | Múltiplas interfaces satisfazem o pedido | ||
| 44 through 252 | não atribuídos | Reservado | |
| 253 | experimental | RFC3692-style Experiment 1 (RFC 4727) | |
| 254 | experimental | RFC3692-style Experiment 2 (RFC 4727) | |
| 255 | reservado | Reservado |
Ligações externas
- RFC 792, Internet Control Message Protocol.
- RFC 1071, Computing the Internet Checksum.
Referências
[5]
- ↑ «IANA ICMP Parameters». Iana.org. 21 de setembro de 2012. Consultado em 7 de janeiro de 2013
- ↑ Computer Networking – A Top-Down Approach by Kurose and Ross
- ↑ a b c Predefinição:Cite rfc
- ↑ a b [[[:Predefinição:Cite IETF/makelink]] PROBE: A Utility for Probing Interfaces]. Predefinição:Cite IETF/doctypes. Predefinição:Cite IETF/makelink.
- ↑ Erro de citação: Código inválido; não foi fornecido texto para as refs de nome :0
Faça um comentário