O que impede que pacotes de dados sejam enviados diretamente para IP privado (para hacking/vírus/malware)?

Question 1

Não entendo como a Internet não conseguiu obter contato direto com seus dispositivos na sua rede local.

Os IPs normalmente levam dados diretamente de e para os dispositivos que fizeram uma solicitação

Tenha em mente que o design original da Internet é que é assim que as coisas deveriam funcionar - a Internet deveria ser "ponta a ponta" e os endereços IP deveriam ser literalmente globais - não importa onde um determinado endereço IP está no mundo, posso falar com ele e ele pode falar comigo.

O problema é que ficamos sem endereços IPv4, então esquemas como o NAT tiveram que ser usados.

O NAT não era o modo como as coisas deveriam funcionar e, embora tenha benefícios de segurança como efeito colateral, quebra o princípio ponta a ponta da Internet e incentiva serviços que nada fazem além de agir como intermediários - bons para segurança/aluguel arrecadação, ruim para a liberdade/pessoas pobres.

Eu sei que roteadores e NATs permitem que todos os seus dispositivos tenham o mesmo IP para sua rede

Só aparece desta forma fora da sua rede.

Atrás da sua rede, cada sistema possui um IP exclusivo – de um dos intervalos de IP privados.

O NAT gerencia essa ilusão no seu roteador para que os sistemas atrás do seu roteador possam alcançar outros IPs, e os IPs possam se comunicar com os sistemas atrás do seu roteador se as portas forem encaminhadas corretamente.

Eu não poderia simplesmente transmitir dados para esse IP com dados codificados para ir para alguns dos endereços privados mais comuns (192.168.1.1-80, por exemplo) e realmente enviar os dados para um dispositivo "privado"

Não.

192.168.1.80 não existe na Internet. Ele só existe atrás de roteadores NAT. Você precisa primeiro usar um roteador NAT. A única maneira de fazer isso é falar primeiro com o IP público do roteador NAT.

Na verdade - se esse IP 192.168.1.80 e o seu próprio IP estiverem na mesma sub-rede, o que acontecerá é que o tráfego nem sairá da sua rede - seu sistema tentará alcançar 192.168.1.80 fora da NIC local e nem chegará ao seu roteador.

então, se eu conhecesse o IP de um roteador e adivinhasse corretamente o IP privado, o que me impediria de invadir esse dispositivo?

Os roteadores NAT monitoram e rastreiam as conexões de entrada.

Se uma nova conexão TCP estiver tentando se conectar a uma porta encaminhada, então, e somente então, eles encaminharão os dados para o sistema atrás do roteador.

O UDP não tem conexão, portanto, um roteador NAT, se estiver fazendo seu trabalho corretamente, não encaminhará o tráfego UDP que não vê há algum tempo para um sistema por trás dele. É possível enganar roteadores NAT com UDP devido à sua natureza sem conexão, mas somente se você conseguir primeiro fazer com que o sistema por trás dele envie algo nessa porta e convença o roteador NAT de que o tráfego de entrada pode estar voltando. Existem alguns protocolos que dependem de algo assim, como STUN, por exemplo.

Answer

Não entendo como a Internet não conseguiu obter contato direto com seus dispositivos na sua rede local.

Os IPs normalmente levam dados diretamente de e para os dispositivos que fizeram uma solicitação

Tenha em mente que o design original da Internet é que é assim que as coisas deveriam funcionar - a Internet deveria ser "ponta a ponta" e os endereços IP deveriam ser literalmente globais - não importa onde um determinado endereço IP está no mundo, posso falar com ele e ele pode falar comigo.

O problema é que ficamos sem endereços IPv4, então esquemas como o NAT tiveram que ser usados.

O NAT não era o modo como as coisas deveriam funcionar e, embora tenha benefícios de segurança como efeito colateral, quebra o princípio ponta a ponta da Internet e incentiva serviços que nada fazem além de agir como intermediários - bons para segurança/aluguel arrecadação, ruim para a liberdade/pessoas pobres.

Eu sei que roteadores e NATs permitem que todos os seus dispositivos tenham o mesmo IP para sua rede

Só aparece desta forma fora da sua rede.

Atrás da sua rede, cada sistema possui um IP exclusivo – de um dos intervalos de IP privados.

O NAT gerencia essa ilusão no seu roteador para que os sistemas atrás do seu roteador possam alcançar outros IPs, e os IPs possam se comunicar com os sistemas atrás do seu roteador se as portas forem encaminhadas corretamente.

Eu não poderia simplesmente transmitir dados para esse IP com dados codificados para ir para alguns dos endereços privados mais comuns (192.168.1.1-80, por exemplo) e realmente enviar os dados para um dispositivo "privado"

Não.

192.168.1.80 não existe na Internet. Ele só existe atrás de roteadores NAT. Você precisa primeiro usar um roteador NAT. A única maneira de fazer isso é falar primeiro com o IP público do roteador NAT.

Na verdade - se esse IP 192.168.1.80 e o seu próprio IP estiverem na mesma sub-rede, o que acontecerá é que o tráfego nem sairá da sua rede - seu sistema tentará alcançar 192.168.1.80 fora da NIC local e nem chegará ao seu roteador.

então, se eu conhecesse o IP de um roteador e adivinhasse corretamente o IP privado, o que me impediria de invadir esse dispositivo?

Os roteadores NAT monitoram e rastreiam as conexões de entrada.

Se uma nova conexão TCP estiver tentando se conectar a uma porta encaminhada, então, e somente então, eles encaminharão os dados para o sistema atrás do roteador.

O UDP não tem conexão, portanto, um roteador NAT, se estiver fazendo seu trabalho corretamente, não encaminhará o tráfego UDP que não vê há algum tempo para um sistema por trás dele. É possível enganar roteadores NAT com UDP devido à sua natureza sem conexão, mas somente se você conseguir primeiro fazer com que o sistema por trás dele envie algo nessa porta e convença o roteador NAT de que o tráfego de entrada pode estar voltando. Existem alguns protocolos que dependem de algo assim, como STUN, por exemplo.

Question 2

Só porque você conhecia o endereço IP público do roteador, bem como um endereço interno, não torna automaticamente o endereço interno endereçável publicamente.

O IP permite que você se conecte a um endereço público, não implica automaticamente que existam endereços por trás desse endereço público nem fornece qualquer meio de encaminhar dados, mesmo que existam.

O endereço é "ir para esta máquina e esta porta", não "ir para esta máquina e porta, e uma vez lá encaminhar para outra máquina e porta, e a partir daí esteoutroendereço e porta"

Pense nisso como alguém lhe enviando uma carta. Os correios não se importamQuemestá no endereço, só que colocaram a postagem no slot certo. Se a postagem passar pelo slot, alguém no endereço deverá olhar a carta e descobrir a quem ela precisa chegar.

O mesmo acontece em uma rede, mas o NAT não permite “Jim” como endereço interno permanente, os mapeamentos internos para externos ocorrem quando algo interno à rede chega à internet solicitando uma conexão. Nesse momento, ele efetivamente cria uma caixa de correio "jimTmp12345@PublicIP" que é usada até que a conexão seja fechada, momento em que o endereço é inválido e qualquer coisa endereçada a ele é descartada no aterro local.

Answer

Só porque você conhecia o endereço IP público do roteador, bem como um endereço interno, não torna automaticamente o endereço interno endereçável publicamente.

O IP permite que você se conecte a um endereço público, não implica automaticamente que existam endereços por trás desse endereço público nem fornece qualquer meio de encaminhar dados, mesmo que existam.

O endereço é "ir para esta máquina e esta porta", não "ir para esta máquina e porta, e uma vez lá encaminhar para outra máquina e porta, e a partir daí esteoutroendereço e porta"

Pense nisso como alguém lhe enviando uma carta. Os correios não se importamQuemestá no endereço, só que colocaram a postagem no slot certo. Se a postagem passar pelo slot, alguém no endereço deverá olhar a carta e descobrir a quem ela precisa chegar.

O mesmo acontece em uma rede, mas o NAT não permite “Jim” como endereço interno permanente, os mapeamentos internos para externos ocorrem quando algo interno à rede chega à internet solicitando uma conexão. Nesse momento, ele efetivamente cria uma caixa de correio "jimTmp12345@PublicIP" que é usada até que a conexão seja fechada, momento em que o endereço é inválido e qualquer coisa endereçada a ele é descartada no aterro local.

Question 3

A maioria dos roteadores NAT também será configurada para atuar como firewall, não apenas como roteador.

Considere a seguinte rede:

Sem NAT, os dispositivos devem comunicar-se diretamente:

192.168.1.2quer conversar com192.168.0.2
- Sua rota padrão é 192.168.1.1(Roteador A)
- O roteador A sabe que 192.168.0.0/24pode ser acessado via 198.51.100.2 (Roteador B)
- O roteador B está diretamente conectado 192.168.0.0/24e entrega o pacote
192.168.0.2quer responder192.168.1.2
- Sua rota padrão é 192.168.0.1(Roteador B)
- O roteador B sabe que 192.168.1.0/24pode ser acessado via198.51.100.1
- O roteador A está diretamente conectado 192.168.1.0/24e entrega o pacote

Com NAT no roteador A, masnãoroteador B, as coisas mudam um pouco:

192.168.1.2quer conversar com192.168.0.2
- Sua rota padrão é 192.168.1.1(Roteador A)
- O roteador A está configurado para "Mascaramento de IP", então reescreve o endereço de origem como 192.51.100.1(é interface externa)
- O roteador A sabe que 192.168.0.0/24pode ser acessado via 198.51.100.2(Roteador B)
- O roteador B está diretamente conectado 192.168.0.0/24e entrega o pacote
192.168.0.1quer responder198.51.100.1
- Sua rota padrão é 192.168.0.1(Roteador B)
- O roteador B está diretamente conectado 198.51.100.0/24e entrega o pacote
- O roteador A revisa sua tabela de tradução e reescreve o destino como192.168.1.1
- O roteador A está diretamente conectado 192.168.1.0/24e entrega o pacote

Neste ponto, hánadaimpedir que um host seja usado 192.51.100.1como roteador e solicitar que ele encaminhe um pacote para 192.168.1.2...Nada. As respostas provavelmente serão mascaradas, então a comunicação pode ser um pouco "desafiante", mas comunicação é comunicação.

Expandindo isso para "a Internet"pode mudar meu"Não há nada que pare..."de certa forma. Não tenho materiais de apoio, mas ficaria muito surpreso se os roteadores da Internet fossem realmente configurados para encaminhar o tráfego direcionado a um endereço de rede privado. Em vez disso, eles provavelmente simplesmente descartarão esses pacotes. O resultado é que tentar isso em é provável que a Internet não funcione, mesmo que o roteador esteja mal configurado.

Além disso, devido à forma como o roteamento funciona (ou seja: se um host não estiver na rede local, o endereço MAC tem como alvo o roteador, enquanto o endereço IP tem como alvo o host final), não há uma maneira de fazer uso como 192.51.100.1um roteador, a menos que A) você esteja conectado a ele; ou B) as rotas existentes irão direcionar o tráfego em sua direção.

Para evitar que outros hosts simplesmente usem 198.51.100.1como um roteador simples, são necessárias regras de firewall.

Uma abordagem é rejeitar (ou descartar) pacotes recebidos na interface externa do roteador A ( 198.51.100.1) que não sejam explicitamente direcionados ao seu endereço.

Isto também resolverá omodelo de host fracoque o Linux implementa (por exemplo: o roteador B pode se comunicar com o roteador A através de seuexternointerface, usando o endereço atribuído aointernointerface).

Answer

A maioria dos roteadores NAT também será configurada para atuar como firewall, não apenas como roteador.

Considere a seguinte rede:

Sem NAT, os dispositivos devem comunicar-se diretamente:

192.168.1.2quer conversar com192.168.0.2
- Sua rota padrão é 192.168.1.1(Roteador A)
- O roteador A sabe que 192.168.0.0/24pode ser acessado via 198.51.100.2 (Roteador B)
- O roteador B está diretamente conectado 192.168.0.0/24e entrega o pacote
192.168.0.2quer responder192.168.1.2
- Sua rota padrão é 192.168.0.1(Roteador B)
- O roteador B sabe que 192.168.1.0/24pode ser acessado via198.51.100.1
- O roteador A está diretamente conectado 192.168.1.0/24e entrega o pacote

Com NAT no roteador A, masnãoroteador B, as coisas mudam um pouco:

192.168.1.2quer conversar com192.168.0.2
- Sua rota padrão é 192.168.1.1(Roteador A)
- O roteador A está configurado para "Mascaramento de IP", então reescreve o endereço de origem como 192.51.100.1(é interface externa)
- O roteador A sabe que 192.168.0.0/24pode ser acessado via 198.51.100.2(Roteador B)
- O roteador B está diretamente conectado 192.168.0.0/24e entrega o pacote
192.168.0.1quer responder198.51.100.1
- Sua rota padrão é 192.168.0.1(Roteador B)
- O roteador B está diretamente conectado 198.51.100.0/24e entrega o pacote
- O roteador A revisa sua tabela de tradução e reescreve o destino como192.168.1.1
- O roteador A está diretamente conectado 192.168.1.0/24e entrega o pacote

Neste ponto, hánadaimpedir que um host seja usado 192.51.100.1como roteador e solicitar que ele encaminhe um pacote para 192.168.1.2...Nada. As respostas provavelmente serão mascaradas, então a comunicação pode ser um pouco "desafiante", mas comunicação é comunicação.

Expandindo isso para "a Internet"pode mudar meu"Não há nada que pare..."de certa forma. Não tenho materiais de apoio, mas ficaria muito surpreso se os roteadores da Internet fossem realmente configurados para encaminhar o tráfego direcionado a um endereço de rede privado. Em vez disso, eles provavelmente simplesmente descartarão esses pacotes. O resultado é que tentar isso em é provável que a Internet não funcione, mesmo que o roteador esteja mal configurado.

Além disso, devido à forma como o roteamento funciona (ou seja: se um host não estiver na rede local, o endereço MAC tem como alvo o roteador, enquanto o endereço IP tem como alvo o host final), não há uma maneira de fazer uso como 192.51.100.1um roteador, a menos que A) você esteja conectado a ele; ou B) as rotas existentes irão direcionar o tráfego em sua direção.

Para evitar que outros hosts simplesmente usem 198.51.100.1como um roteador simples, são necessárias regras de firewall.

Uma abordagem é rejeitar (ou descartar) pacotes recebidos na interface externa do roteador A ( 198.51.100.1) que não sejam explicitamente direcionados ao seu endereço.

Isto também resolverá omodelo de host fracoque o Linux implementa (por exemplo: o roteador B pode se comunicar com o roteador A através de seuexternointerface, usando o endereço atribuído aointernointerface).

Question 4

[NAT] encaminha as solicitações para a web e de volta para o cliente que as solicitou

certo, mas como um esclarecimento sobre como isso funciona: o NAT faz com que seus endereços IP privados pareçam um endereço IP público, normalmente antes do tráfego sair da sua rede. Assim, a web não encaminha o tráfego de volta para o seu endereço IP privado. A web retorna o tráfego para o endereço IP público onde você é visto.

Edição número 1:

Acho que se você entender detalhadamente como o NAT funciona, isso ajudará a responder algumas de suas perguntas. A implementação mais típica que já vi é a tradução baseada em NAPT ("Network Address Port"). Quando você envia dados de um endereço privado, o roteador pega esse endereço privado e adiciona essas informações a um gráfico/tabela na memória do roteador. O roteador também escolhe um número de porta TCP ou UDP (provavelmente selecionado aleatoriamente) e mantém o controle disso no mesmo gráfico/tabela. O roteador então envia as informações para a Internet usando o endereço IP público e identifica o número da “porta de origem” como o número escolhido. (Tanto o TCP quanto o UDP usam dois números de porta: um número de "origem" e um número de "destino".) Quando o destino (digamos, um servidor web escutando na porta TCP 443) percebe o tráfego indo para a porta TCP 443 e vindo de uma porta TCP diferente (por exemplo, porta TCP 53874), esse servidor poderá responder enviando o tráfego de volta para o endereço IP público do roteador de origem nessa mesma porta TCP (por exemplo, porta TCP 53874). O roteador então procura informações em sua tabela/gráfico e sabe para qual endereço IP privado enviar as informações.

Se você escolher um endereço IP privado aleatoriamente, o roteador não deverá ter esse endereço IP privado em sua tabela/gráfico, então isso não funcionaria.

Presumo que haja outro meio de rotear dados para o cliente correto acontecendo no roteador/NAT que não seja apenas IP, mas não tenho certeza de como isso é feito.

Não.

Quero dizer, bem, sim, existe. Há algum outro roteamento que pode ocorrer e, portanto, reconhecerei isso rapidamente. Há uso de marcação "VLAN" 802.1q e outras tecnologias que podem ser usadas para algumas nuvens de dados/sinalização e podem afetar o modo como o tráfego acaba viajando por uma rede. No entanto, esses métodos de roteamento adicionais são normalmente implantados para fins de velocidade, segurança ou compatibilidade (principalmente com redes não IP, como talvez algumas redes mais antigas dentro de uma companhia telefônica). Você realmente não precisa pensar que essas técnicas avançadas de rede de nível profissional irão introduzir uma parte nova e necessária da compreensão de como funciona o roteamento básico, porque o roteamento IP simples e básico pode ser usado para explicar o que você está perguntando.

Problema nº 2: as defesas internas do roteador

Agora, vamos fingir que o roteador não está executando NAPT, então vamos ignorar toda a tabela/gráfico que corresponde aos números de porta TCP/UDP públicos com endereços privados. Vamos fingir que você está no ISP do cliente e deseja enviar o pacote de forma maliciosa através do roteador para os endereços IP privados do cliente.

A maioria dos roteadores, executando algumas ações básicas semelhantes a um firewall, notará que o tráfego de entrada está chegando na porta denominada "WAN" (que significa "Wide-Area Network"). Para fornecer alguma proteção, os roteadores perceberão que o tráfego de entrada naquela porta de rede deve usar o endereço IP público do roteador e certamente não qualquer um dos intervalos de endereços IP "privados" comuns.

Assim, o roteador defenderá a rede descartando o pacote.

Questão 3: os ISPs nos protegem melhor

O padrão para qualquer ISP é não permitir qualquer tráfego de ou para intervalos de endereços IP privados (que são os intervalos de endereços de rede identificados emIETF RFC 1918 Seção 3para IPv4 ou endereços começando com "fd" para IPv6).

Portanto, se você estiver tentando enviar tráfego de sua casa, através do seu ISP e, em seguida, através do restante do backbone principal da Internet dos ISPs, depois através do ISP da vítima, depois através do roteador da vítima e, finalmente, para o "IP privado" endereço de sua escolha, então você deve falhar. Isso ocorre porque os ISPs normalmente seguem a convenção de bloquear o tráfego envolvendo endereços IP privados. (Os ISPs seriam loucos se não fizessem isso.)

No cenário acima, a proteção não é fornecida pelo ISP da vítima alvo. É verdade que o ISP da vítima alvo provavelmente está configurado para descartar os pacotes, protegendo assim o roteador da vítima alvo. No entanto, é provável que o seu ISP também descarte os pacotes, de modo que os pacotes nem chegarão ao ISP da vítima alvo.

Questão 4: Motivação do ISP

Por que os ISPs seriam loucos em permitir tráfego envolvendo IPs privados?

Bem, lembre-se de que todas as organizações podem usar endereços IP privados para suas próprias redes internas. Isso inclui ISPs. Seu ISP pode estar usando endereçamento privado para alguns equipamentos locais do ISP. Você não deve ser capaz de perceber/detectar se eles estão fazendo isso ou não.

A forma como o tráfego de roteamento do ISP é baseado em "tabelas de roteamento" que determinam para onde o tráfego deve ir em seguida. Essas "tabelas de roteamento" não especificam qual outro ISP ficará feliz em receber tráfego que tenha um endereço privado como destino. O ISP não terá para onde enviar o tráfego, exceto possível para alguns de seus próprios equipamentos internos. Como muito tráfego envolvendo endereços IP privados provavelmente será malicioso ou problemático (talvez envolvendo tráfego proveniente de um dispositivo configurado incorretamente), o ISP certamente não deseja que esse tráfego seja enviado para seu próprio equipamento interno ( e possivelmente causando problemas para o ISP). Portanto, o ISP desejará bloquear pacotes que vão para um endereço privadoimediatamente, antes de permitir o tráfego através da rede do ISP.

Se um ISP violasse essas regras, provavelmente estaria convidando tráfego malicioso que provavelmente não teria nenhum efeito (além do uso de largura de banda), mas se houvesse algum efeito, isso provavelmente seria ruim para o ISP.

Questão 5: O que realmente aconteceria

Até agora, expliquei por que a Internet bloqueará o tráfego. Mas vamos ver o que realmente vai acontecer.

Se você estiver sentado em seu computador e decidir enviar um pacote malicioso para um endereço IP privado, o que acontecerá?

Se o tráfego chegasse ao seu ISP local, esse ISP local bloquearia o tráfego imediatamente, conforme já explicado.

No entanto, o que é realmente provável que aconteça é que o tráfego não chegue até o seu ISP local. Em vez disso, o seu roteador local descobrirá o que fazer com esse tráfego.

Se você não estiver usando o mesmo endereço IP "privado", então seu próprio roteador provavelmente não saberá o que fazer com o tráfego, então o tráfego será descartado.

Caso contrário, se você estiver usando o mesmo endereço "IP privado", provavelmente estará atacando um dispositivo na rede em que está. Se você for o administrador dessa rede, estará atacando sua própria rede!

De qualquer forma, é improvável que seu roteador (ao usar configurações padrão comuns) passe o tráfego pela Internet.

Análise:

Todas essas questões dizem respeito ao motivo pelo qual a Internet não permite o ataque a um endereço IP privado. Se você estiver na mesma rede local que seu alvo, talvez nem precise passar por um roteador, portanto nenhuma dessas defesas estará no seu caminho. No entanto, se você estiver localizado em outro lugar na Internet, essas defesas provavelmente atrapalharão uma tentativa de realizar tal ataque.

Embora você possa violar certas regras padrão com (pelo menos alguns tipos de) roteadores que você pode controlar, é provável que outras organizações também bloqueiem endereços IP privados, evitando assim efetivamente ataques a sistemas remotos.

Answer

[NAT] encaminha as solicitações para a web e de volta para o cliente que as solicitou

certo, mas como um esclarecimento sobre como isso funciona: o NAT faz com que seus endereços IP privados pareçam um endereço IP público, normalmente antes do tráfego sair da sua rede. Assim, a web não encaminha o tráfego de volta para o seu endereço IP privado. A web retorna o tráfego para o endereço IP público onde você é visto.

Edição número 1:

Acho que se você entender detalhadamente como o NAT funciona, isso ajudará a responder algumas de suas perguntas. A implementação mais típica que já vi é a tradução baseada em NAPT ("Network Address Port"). Quando você envia dados de um endereço privado, o roteador pega esse endereço privado e adiciona essas informações a um gráfico/tabela na memória do roteador. O roteador também escolhe um número de porta TCP ou UDP (provavelmente selecionado aleatoriamente) e mantém o controle disso no mesmo gráfico/tabela. O roteador então envia as informações para a Internet usando o endereço IP público e identifica o número da “porta de origem” como o número escolhido. (Tanto o TCP quanto o UDP usam dois números de porta: um número de "origem" e um número de "destino".) Quando o destino (digamos, um servidor web escutando na porta TCP 443) percebe o tráfego indo para a porta TCP 443 e vindo de uma porta TCP diferente (por exemplo, porta TCP 53874), esse servidor poderá responder enviando o tráfego de volta para o endereço IP público do roteador de origem nessa mesma porta TCP (por exemplo, porta TCP 53874). O roteador então procura informações em sua tabela/gráfico e sabe para qual endereço IP privado enviar as informações.

Se você escolher um endereço IP privado aleatoriamente, o roteador não deverá ter esse endereço IP privado em sua tabela/gráfico, então isso não funcionaria.

Presumo que haja outro meio de rotear dados para o cliente correto acontecendo no roteador/NAT que não seja apenas IP, mas não tenho certeza de como isso é feito.

Não.

Quero dizer, bem, sim, existe. Há algum outro roteamento que pode ocorrer e, portanto, reconhecerei isso rapidamente. Há uso de marcação "VLAN" 802.1q e outras tecnologias que podem ser usadas para algumas nuvens de dados/sinalização e podem afetar o modo como o tráfego acaba viajando por uma rede. No entanto, esses métodos de roteamento adicionais são normalmente implantados para fins de velocidade, segurança ou compatibilidade (principalmente com redes não IP, como talvez algumas redes mais antigas dentro de uma companhia telefônica). Você realmente não precisa pensar que essas técnicas avançadas de rede de nível profissional irão introduzir uma parte nova e necessária da compreensão de como funciona o roteamento básico, porque o roteamento IP simples e básico pode ser usado para explicar o que você está perguntando.

Problema nº 2: as defesas internas do roteador

Agora, vamos fingir que o roteador não está executando NAPT, então vamos ignorar toda a tabela/gráfico que corresponde aos números de porta TCP/UDP públicos com endereços privados. Vamos fingir que você está no ISP do cliente e deseja enviar o pacote de forma maliciosa através do roteador para os endereços IP privados do cliente.

A maioria dos roteadores, executando algumas ações básicas semelhantes a um firewall, notará que o tráfego de entrada está chegando na porta denominada "WAN" (que significa "Wide-Area Network"). Para fornecer alguma proteção, os roteadores perceberão que o tráfego de entrada naquela porta de rede deve usar o endereço IP público do roteador e certamente não qualquer um dos intervalos de endereços IP "privados" comuns.

Assim, o roteador defenderá a rede descartando o pacote.

Questão 3: os ISPs nos protegem melhor

O padrão para qualquer ISP é não permitir qualquer tráfego de ou para intervalos de endereços IP privados (que são os intervalos de endereços de rede identificados emIETF RFC 1918 Seção 3para IPv4 ou endereços começando com "fd" para IPv6).

Portanto, se você estiver tentando enviar tráfego de sua casa, através do seu ISP e, em seguida, através do restante do backbone principal da Internet dos ISPs, depois através do ISP da vítima, depois através do roteador da vítima e, finalmente, para o "IP privado" endereço de sua escolha, então você deve falhar. Isso ocorre porque os ISPs normalmente seguem a convenção de bloquear o tráfego envolvendo endereços IP privados. (Os ISPs seriam loucos se não fizessem isso.)

No cenário acima, a proteção não é fornecida pelo ISP da vítima alvo. É verdade que o ISP da vítima alvo provavelmente está configurado para descartar os pacotes, protegendo assim o roteador da vítima alvo. No entanto, é provável que o seu ISP também descarte os pacotes, de modo que os pacotes nem chegarão ao ISP da vítima alvo.

Questão 4: Motivação do ISP

Por que os ISPs seriam loucos em permitir tráfego envolvendo IPs privados?

Bem, lembre-se de que todas as organizações podem usar endereços IP privados para suas próprias redes internas. Isso inclui ISPs. Seu ISP pode estar usando endereçamento privado para alguns equipamentos locais do ISP. Você não deve ser capaz de perceber/detectar se eles estão fazendo isso ou não.

A forma como o tráfego de roteamento do ISP é baseado em "tabelas de roteamento" que determinam para onde o tráfego deve ir em seguida. Essas "tabelas de roteamento" não especificam qual outro ISP ficará feliz em receber tráfego que tenha um endereço privado como destino. O ISP não terá para onde enviar o tráfego, exceto possível para alguns de seus próprios equipamentos internos. Como muito tráfego envolvendo endereços IP privados provavelmente será malicioso ou problemático (talvez envolvendo tráfego proveniente de um dispositivo configurado incorretamente), o ISP certamente não deseja que esse tráfego seja enviado para seu próprio equipamento interno ( e possivelmente causando problemas para o ISP). Portanto, o ISP desejará bloquear pacotes que vão para um endereço privadoimediatamente, antes de permitir o tráfego através da rede do ISP.

Se um ISP violasse essas regras, provavelmente estaria convidando tráfego malicioso que provavelmente não teria nenhum efeito (além do uso de largura de banda), mas se houvesse algum efeito, isso provavelmente seria ruim para o ISP.

Questão 5: O que realmente aconteceria

Até agora, expliquei por que a Internet bloqueará o tráfego. Mas vamos ver o que realmente vai acontecer.

Se você estiver sentado em seu computador e decidir enviar um pacote malicioso para um endereço IP privado, o que acontecerá?

Se o tráfego chegasse ao seu ISP local, esse ISP local bloquearia o tráfego imediatamente, conforme já explicado.

No entanto, o que é realmente provável que aconteça é que o tráfego não chegue até o seu ISP local. Em vez disso, o seu roteador local descobrirá o que fazer com esse tráfego.

Se você não estiver usando o mesmo endereço IP "privado", então seu próprio roteador provavelmente não saberá o que fazer com o tráfego, então o tráfego será descartado.

Caso contrário, se você estiver usando o mesmo endereço "IP privado", provavelmente estará atacando um dispositivo na rede em que está. Se você for o administrador dessa rede, estará atacando sua própria rede!

De qualquer forma, é improvável que seu roteador (ao usar configurações padrão comuns) passe o tráfego pela Internet.

Análise:

Todas essas questões dizem respeito ao motivo pelo qual a Internet não permite o ataque a um endereço IP privado. Se você estiver na mesma rede local que seu alvo, talvez nem precise passar por um roteador, portanto nenhuma dessas defesas estará no seu caminho. No entanto, se você estiver localizado em outro lugar na Internet, essas defesas provavelmente atrapalharão uma tentativa de realizar tal ataque.

Embora você possa violar certas regras padrão com (pelo menos alguns tipos de) roteadores que você pode controlar, é provável que outras organizações também bloqueiem endereços IP privados, evitando assim efetivamente ataques a sistemas remotos.

O que impede que pacotes de dados sejam enviados diretamente para IP privado (para hacking/vírus/malware)?

Responder1

Responder2

Responder3

Responder4

informação relacionada