O ARP é um protocolo de pergunta e resposta utilizado para mapear dinamicamente endereços da camada 3 (rede) com a camada 2 (enlace). Tipicamente, ele é utilizado para mapear endereços IPs (Internet Protocol) em endereços MAC (Media Access Control).

Para controlar esse mapeamento, o protocolo ARP mantém uma tabela chamada ARP Table. Sempre que um novo pacote com endereços MAC ou IP aparecem e ainda não estão na tabela ARP ou precisam se atualizar, o protocolo modifica a tabela com os novos dados.

O protocolo ARP foi originalmente definido pela RFC 826. Nesse artigo vamos abordar as características do protocolo, seu funcionamento com alguns exemplos de código escritos na linguagem C.

Tente entender o seu funcionamento

A imagem acima exemplifica o funcionamento básico do protocolo ARP. O computador da esquerda envia um pergunta ARP querendo saber qual o endereço MAC do computador cujo endereço IP é 10.0.0.5. Essa pergunta é enviada para rede na forma de broadcast.

O computador da direita então responde a pergunta ARP dizendo que endereço MAC do computador com ip 10.0.0.5 é 00:00:00:00:00:02. Cada computador armazena em sua tabela ARP os mapeamentos de endereços aprendidos. Essa informação é utilizada como cache em momentos futuros.

Seu cabeçalho

O protocolo ARP trafega em seus pacotes um conjunto pequeno de dados sobre máquinas de origem e destino. A imagem abaixo mostra cada campo dentro do cabeçalho ARP:

Vamos compreender cada campo do cabeçalho

Tipo de hardware

O Protocolo ARP não é exclusivo de um equipamento. Esse campo de 2 bytes permite guardar um número que define qual o tipo do equipamento daquele pacote. No caso mais comum, com equipamentos Ethernet, temos que o valor desse campo seria: 0x0001

Tipo de protocolo

    Assim como para o campo tipo de hardware o ARP permite mais de um endereço de protocolo. Para tal, esse campo também tem 2 bytes e armazena o tipo do protocolo ao qual será mapeado o endereço de equipamento (hardware). No caso comum, o protocolo IP é utilizado e seu valor para o campo seria: 0x0800

Tamanho endereço hardware

Como o tipo de hardware varia, o tamanho necessário para armazenar o endereço desse hardware também. No nosso exemplo, para colocar no pacote um endereço Ethernet (MAC address) são necessário 6 bytes, então o valor desse campo é 6.

Tamanho endereço protocolo

Com a variação do tipo de protocolo, variamos também o tamanho do endereço do protocolo. Para nosso exemplo utilizando o IP, temos um valor 4 para o campo.

Opções

Esse campo define o tipo do pacote ARP. Ele pode ser um pacote de requisição (request) ou de resposta (response). Para cada um desses tipos, teríamos os valores 0x0001 e 0x0002, respectivamente.

Endereço de hardware de origem

Esse campo recebe o endereço do equipamento de quem está enviando o pacote. Se o hardware for Ethernet, por exemplo, teríamos o seguinte valor: 00:00:00:00:00:01.

Endereço de protocolo de origem

Esse é o endereço do protocolo de origem. Se considerarmos o protocolo IP como exemplo, o valor poderia ser: 10.0.0.2.

Endereço de hardware de destino

Esse campo é reservado para receber o endereço do equipamento de destino. Se o hardware for Ethernet, por exemplo, teríamos o seguinte valor: 00:00:00:00:00:02.

Endereço de protocolo de destino

Esse é o endereço do protocolo de destino. Se considerarmos o protocolo IP como exemplo, o valor poderia ser: 10.0.0.5

Um exemplo de frame do protocolo ARP para o nosso exemplo de ARP reply mostrado na seção FUNCIONAMENTO seria:

SONDAGEM ARP (ARP PROBE)

A sondagem ARP acontece quando um computador recebe um endereço IP, manualmente ou via DHCP, para verificar se outra máquina na rede já possui esse IP. A RFC 5227 especifica essa sondagem.

Para enviar pacotes de sonda, é necessário montar um pacote ARP onde o IP de destino é o endereço desejado e o IP de origem deve ser composto por zeros. O zeros evitam que outros nós façam cache desse endereço. Quando recebe-se um reply confirmando o endereço, tem um conflito de endereços.

ARP INVERSO (INARP)

O ARP inverso ou Inverse Address Resolution Protocol (RFC 2390), é uma extensão do protocolo ARP que permite fazer o caminho inverso do ARP padrão. Ele descobre o endereço de protocolo (IP por exemplo) a partir do endereço de hardware (Ethernet por exemplo).

Para permitir isso, ele utiliza o mesmo frame ARP mas com novos códigos de operação: 8 e 9, InARP request e InARP response, respectivamente.

O ARP Inverso não utiliza broadcast, pois o endereço de hardware de destino já é conhecido. O campo Endereço de protocolo de destino é preenchido com zeros. Através dos códigos de operação (8 e 9), o pacote é encaminhado pela rede até o computador de destino.

ARP SPOOFING / ARP POISONING

Spoofing ou Poisoning de ARP é uma técnica de ataque utilizando protocolo ARP. O Poisoning (envenenamento) acontece quando um atacante dispara mensagens ARP na rede dizendo que o computador dele responde pelo endereço IP de alguma outra máquina na rede, o default gateway, por exemplo. 

Se o ataque funcionar, o computador do atacante passa a receber os pacotes destinados ao computado atacado. Recebendo esses pacotes, ele pode modificá-los, não encaminhá-los, mandar para outros computadores e etc. 

ARP GRATUITO (GRATUITOUS ARP)

O ARP gratuito é uma forma de um computador se anunciar na rede. Esse pacote não é uma resposta a nenhuma requisição ARP.  O computador envia esse pacote na forma de broadcast de forma voluntária e gratuita.

Para construir um frame ARP gratuito é necessário colocar os Endereços de protocolo da origem e do destino como o endereço (IP por exemplo) do computador que irá enviar o ARP gratuito. Além disso, o Endereço de hardware de destino deve ser um endereço de broadcast, no caso do Ethernet, seria ff:ff:ff:ff:ff:ff. Essa requisição não necessita de nenhuma resposta. Os demais campos continuam normais a uma requisição ARP.

Um pacote de ARP gratuito para o nosso exemplo inicial a esse artigo poderia ser:

PROXY ARP

O proxy ARP, ou aproximação ARP, é uma forma de fazer com que sub-redes diferentes consigam receber pacotes ARP uma da outra. Esse mecanismo é definido na RFC 1027. 

Uma forma de implementar o proxy é colocando o default gateway das duas redes apontando para o mesmo computador/gateway . Assim, esse computador sempre que receber pacotes ARP direcionados à uma sub-rede, ele  apenas encaminha para essa rede. A mesma coisa é feita para o caminho inverso.

Para possibilitar o encaminhamento, é necessário modificar os pacotes colocando os endereços do computador/gateway para que as redes locais consigam comunicar-se. Todos os pacotes de uma sub-rede externa à atual, contém como endereços de hardware o endereço do computador/gateway.

Para fazer esse tipo de bloqueio usaremos a opção TLS HOST e Transport Layer Security , para o bloqueio de endereços virtuais.

Este método consiste em criar uma lista dinâmica que filtra as URL acessadas e armazena os endereços IP correspondentes. Na tabela de endereços do RouterOS, criaremos uma regra de “drop” para definir a rede ou interface à qual o filtro será aplicado. Ou seja, a “Address List”.

Etapa – 01 Configurando o endereço

• Clique na seção “IP”, depois em “Firewall” e em “Filter”.
• Adicione uma regra no botão “+”.
• Em “Chain”, escreva “forward”, e em “Protocol” coloque “tcp”.
• A seguir, clique na seção “Advanced”.
• Em “TLS Host”, inclua, entre asteriscos, a palavra “facebook”.
• Na seção “Action”, defina como “add dst to address list” e, voltando para a aba anterior, escreva “redes-sociais” em “Address List”.

A partir daqui só precisamos, de fato, efetuar o bloqueio dos endereços indesejados. Embora neste caso seja o Facebook, você pode – e deve – repetir a mesma regra para anular qualquer outro website, apenas alterando a marcação no “TLS Host”. Para os mesmos comandos via New Terminal do MikroTik, digite:

• /ip firewall filter
• add action=add-dst-to-address-list address-list=redes-sociais
• chain=forward comment=facebook protocol=tcp tls-host=*facebook*

Etapa – 02 Ativando o Bloqueio

• Acesse o menu IP, e depois clique novamente em “Firewall.”
• Em “filter-rules”, adicione uma nova regra em “+”.
• Nas seções “Chain” e “Protocol”, coloque o mesmo da parte anterior.
• Em “Src. Address”, digite o endereço da rede em que o filtro será aplicado.
• Na aba “Advanced”, selecione a “Address List” que criamos anteriormente em “Dst. Address List”.
• Em “Action”, selecione a opção “drop”.

Prontinho! Após confirmar todos os passos, os pacotes que trafegam no MikroTik com o protocolo TCP – ou seja, que originam na sua rede local e chegam aos endereços na “Address List” – serão, popularmente falando, “dropados”.

Gostou? Se esse artigo ajudou você, compartilhe para que alcance mais pessoas!

Você sabe onde insere suas informações?

Primeiramente vamos entender como funciona o HTTP

O HTTP é o protocolo responsável pelas requisições de páginas na WEB.

Vez por outra acessamos alguns sites que rodam o HTTP por trás de suas requisições, e esse protocolo possui alguns métodos , ou como também são chamados “Verbos” .

Os métodos (ou “Verbos”) no http definem como tal ação deve se realizada e em alguns casos dependendo do verbo o servidor poderá dar uma resposta diferente para o usuário.

Quando acessamos algum site é quase que rotineiro passarmos por uma tela com de Login, em formulários como esse inserimos nossas credenciais para termos acesso ao sistema.

Tais informações devem ser sigilosas e “invisiveis” a qualquer outra pessoa, tudo deve acontecer entre você e o servidor web.

Porém algo que pode facilmente acontecer se encontra nessa imagem abaixo , algo que aconteceu comigo mesmo:

As minhas credenciais de acesso ficaram tudo no corpo da minha URL , algo que não é nem um pouco seguro , concorda?

Essas informações na URL ficam expostas, não estou apenas me referindo se caso alguém esteja perto de você e veja as “olho” o que você digitou. Me refiro ao fato de quando essas informações trafegam na internet. O que é considerado como uma vulnerabilidade na segurança.

Quem define o local onde os parâmetros são passados são o HTTP.

Os “verbos”

Um desses verbos mais comuns são o “GET”, quando utilizamos o GET os dados (parâmetros) inseridos no formulário são passados no cabeçalho da requisição.

Por essa razão, podem ser vistos pela URL , como pode ocorrer nos formulários de login.

Esse método é padrão para enviar dados quando submetemos um formulário HTTP.

Por isso no exemplo acima, foi utilizado o GET. Contudo, conseguimos alterar esse comportamento dizendo para o formulário qual do método (method) ele deve usar.

No caso de formulários web, é muito comum que esse método seja o POST:

<!DOCTYPE html>
<html>
<form method="post" action="logar">
<input type="text" name="nome" placeholder="digite seu Nome aqui">
<input type="e-mail" name="email" placeholder="Digite seu e-mail">
<input type="submit" name="enviar" value="Enviar">
</html>    
</form>

O parâmetro (ou “Verbo”)  POST, ao contrário do GET, envia os parâmetros no corpo da requisição HTTP. Escondendo eles da URI:

Mas com isso , você talvez se pergunte ” Significa então que se eu utilizar o POST eu vou 100% proteger meus dados atribuídos ao formulário , já que eles não aparecem mais na URL?

Não é bem assim, na verdade eles ainda não estão seguros!

A única coisa que o POST faz é enviar os parâmetros no corpo da requisição. Se inspecionarmos a requisição, ou usarmos algum tipo de sniffer de rede como o Wireshark , conseguiremos facilmente vêr os dados inseridos nos campos do formulário que utiliza esse método.

Então caso não queira que seus dados sejam vistos , procure utilizar a versão segura do HTTP o “HTTPS” .

Com essa versão conseguimos criptografar os dados que serão enviados.

Ambos os verbos são muito utilizado em formulários de sites na internet e possuem algumas outras diferenças entre si.

Como o GET envia os dados no cabeçalho da requisição, ele tende a ser, não é uma regra,um pouco mais performático que o POST.

Porém, por enviar os dados no cabeçalho da requisição, o GET tem um tamanho máximo de dados que podem ser enviados, que no geral é de 255 caracteres.

Com POST, podemos enviar informações um pouco maiores, como imagens. Ou seja, se tentarmos passar uma grande quantidade de informações via GET, algumas partes podem ser perdidas no caminho.

Mas não conclua que utilizar o POST é o melhor caminho já que ele encapsula os dados no corpo da requisição e consegue transportar mais dados que o GET, portanto, utilizaríamos o POST em todo lugar.

Porém, se existem dois verbos diferentes, não concorda que é porque eles foram feitos para serem utilizados em locais diferentes?

As requisições do tipo GET são recomendadas para obter dados de um determinado recurso. Como em um formulário de busca ou em uma listagem de todos os produtos cadastrados.

Já as requisições POST são mais utilizadas para para enviar informações para serem processadas, como por exemplo, criar algum recurso, como um produto, ou um cliente.