¿Qué impide que los paquetes de datos se envíen directamente a una IP privada (para piratería/virus/malware)?

Question

Soy nuevo en el mundo de las redes y ya conozco muchos de los conceptos básicos, pero no entiendo cómo Internet no puede obtener contacto directo con sus dispositivos en su red de área local.

Sé que los enrutadores y NAT permiten que todos sus dispositivos tengan la misma IP para su red, y enrutan las solicitudes a la web y de regreso al cliente que las solicitó, pero mi pregunta es la siguiente:

Digamos que quería hackear la computadora de alguien y conocía la IP de su red doméstica (enrutador). ¿No podría simplemente transmitir datos a esa IP con datos codificados para ir a algunas de las direcciones privadas más comunes (192.168.1.1-80, por ejemplo) y enviar los datos a un dispositivo "privado"?

Las IP generalmente toman datos directamente hacia y desde los dispositivos que realizaron una solicitud, por lo que si conocía la IP de un enrutador y adiviné correctamente la IP privada, ¿qué me impide piratear ese dispositivo?

Supongo que hay otro medio para enrutar datos al cliente correcto en el enrutador/NAT que no es solo IP, pero no estoy seguro de cómo se hace.

¿O es simplemente que PODRÍAS enviar datos mal intencionados de esta manera, pero no habría ningún beneficio si todo el software no hace nada con los datos de todos modos (no envió una solicitud)?

Cualquier información que encuentro generalmente solo habla de cómo las IP privadas permiten que se usen menos IP públicas en general, y nunca mencionan realmente lo que corta el acceso de sus clientes de IP privados al mundo exterior.

¿Alguien puede explicarme esto?

Answer 1

No entiendo cómo Internet no pudo obtener contacto directo con sus dispositivos en su red de área local.

Las IP generalmente toman datos directamente hacia y desde los dispositivos que realizaron una solicitud.

Tenga en cuenta que el diseño original de Internet es que así es como se supone que funcionan las cosas: se supone que Internet es "de extremo a extremo" y se supone que las direcciones IP son literalmente globales, sin importar dónde una dirección IP determinada está en el mundo, puedo hablar con ella y ella puede hablar conmigo.

El problema es que nos quedamos sin direcciones IPv4, por lo que tuvimos que utilizar esquemas como NAT.

NAT no era la forma en que se suponía que debían funcionar las cosas y, si bien tiene beneficios de seguridad como efecto secundario, rompe el principio de extremo a extremo de Internet y fomenta servicios que no hacen más que actuar como intermediarios, lo que es bueno para la seguridad y el alquiler. Colección, mala para la libertad/los pobres.

Sé que los enrutadores y NAT permiten que todos sus dispositivos tengan la misma IP para su red

Sólo aparece así fuera de tu red.

Detrás de su red, cada sistema tiene una IP única, de uno de los rangos de IP privados.

NAT gestiona esta ilusión en su enrutador para que los sistemas detrás de su enrutador puedan comunicarse con otras IP, y las IP pueden comunicarse con los sistemas detrás de su enrutador si los puertos se reenvían correctamente.

¿No podría simplemente transmitir datos a esa IP con datos codificados para ir a algunas de las direcciones privadas más comunes (192.168.1.1-80, por ejemplo) y enviar los datos a un dispositivo "privado"?

No.

192.168.1.80 no existe en Internet. Sólo existe detrás de enrutadores NAT. Primero debe ponerse detrás de un enrutador NAT. La única forma de hacerlo es hablar primero con la IP pública del enrutador NAT.

De hecho, si esa IP 192.168.1.80 y su propia IP están en la misma subred, lo que sucederá es que el tráfico ni siquiera abandonará su red: su sistema intentará llegar a 192.168.1.80 desde la NIC local. y ni siquiera llegará a tu enrutador.

entonces, si conocía la IP de un enrutador y adiviné correctamente la IP privada, ¿qué me impide piratear ese dispositivo?

Los enrutadores NAT monitorean y rastrean las conexiones entrantes.

Si una nueva conexión TCP intenta conectarse a un puerto reenviado, entonces y sólo entonces reenviará los datos al sistema detrás del enrutador.

UDP no tiene conexión, por lo que un enrutador NAT, si está haciendo su trabajo correctamente, no reenviará el tráfico UDP que no haya visto en mucho tiempo a un sistema detrás de él. Es posible engañar a los enrutadores NAT con UDP debido a su naturaleza sin conexión, pero solo si primero puede lograr que el sistema envíe algo a ese puerto y convencer al enrutador NAT de que el tráfico entrante podría estar regresando. Hay algunos protocolos que dependen de algo como esto, como STUN, por ejemplo.

Answer 2

El hecho de que conociera la dirección IP pública del enrutador, así como una dirección interna, no hace que la dirección interna sea públicamente direccionable automáticamente.

La IP le permite conectarse a una dirección pública, no implica automáticamente que haya direcciones detrás de esa dirección pública ni proporciona ningún medio para reenviar datos, incluso si las hubiera.

La dirección es "ir a esta máquina y este puerto", no "ir a esta máquina y puerto, y una vez allí reenviar a otra máquina y puerto, y desde allí estootrodirección y puerto"

Piense en ello como si alguien le enviara una carta. A la oficina de correos no le importaOMSEstá en la dirección, solo que pusieron el correo en la ranura correcta. Si el correo está a través de la ranura, entonces alguien en la dirección debe mirar la carta y averiguar a quién debe llegar la carta.

Lo mismo sucede en una red, pero NAT no permite "Jim" como dirección interna permanente; las asignaciones internas a externas ocurren cuando algo interno de la red llega a Internet solicitando una conexión. En ese momento, crea efectivamente un buzón de correo "jimTmp12345@PublicIP" que se usa hasta que se cierra la conexión, momento en el que la dirección no es válida y todo lo que esté dirigido a ella se descarta en el vertedero local.

Answer 3

La mayoría de los enrutadores NATing también estarán configurados para actuar como firewall, no solo como enrutador.

Considere la siguiente red:

---

Sin NAT, los dispositivos deben comunicarse directamente:

• 192.168.1.2quiere hablar con192.168.0.2
  • Su ruta predeterminada es 192.168.1.1(Enrutador A)
  • El enrutador A sabe que 192.168.0.0/24es accesible a través del 198.51.100.2 (enrutador B)
  • El enrutador B está conectado directamente 192.168.0.0/24y entrega el paquete.
• 192.168.0.2quiere responder a192.168.1.2
  • Su ruta predeterminada es 192.168.0.1(Enrutador B)
  • El enrutador B sabe que 192.168.1.0/24es accesible a través de198.51.100.1
  • El enrutador A está conectado directamente 192.168.1.0/24y entrega el paquete.

---

Con NAT en el enrutador A, peronoenrutador B, las cosas cambian ligeramente:

• 192.168.1.2quiere hablar con192.168.0.2
  • Su ruta predeterminada es 192.168.1.1(Enrutador A)
  • El enrutador A está configurado para "Enmascaramiento de IP", por lo que reescribe la dirección de origen como 192.51.100.1(su interfaz externa)
  • El enrutador A sabe que 192.168.0.0/24es accesible a través del 198.51.100.2(enrutador B)
  • El enrutador B está conectado directamente 192.168.0.0/24y entrega el paquete.
• 192.168.0.1quiere responder a198.51.100.1
  • Su ruta predeterminada es 192.168.0.1(Enrutador B)
  • El enrutador B está conectado directamente 198.51.100.0/24y entrega el paquete.
  • El enrutador A revisa su tabla de traducción y reescribe el destino como192.168.1.1
  • El enrutador A está conectado directamente 192.168.1.0/24y entrega el paquete.

En este punto, haynadapara evitar que un host se utilice 192.51.100.1como enrutador y pedirle que reenvíe un paquete a 192.168.1.2...Nada. Es probable que las respuestas estén enmascaradas, por lo que la comunicación puede ser un poco "desafiante", pero la comunicación es comunicación.

Ampliando esto a "La Internet" podría cambiar mi "No hay nada que pueda detener..." un poco. No tengo materiales de apoyo, pero me sorprendería mucho si los enrutadores de Internet estuvieran realmente configurados para reenviar el tráfico dirigido a una dirección de red privada. En lugar de eso, probablemente simplemente descartarán dichos paquetes. El resultado es que intentar esto en Es probable que Internet no funcione, incluso si el enrutador estaba mal configurado.

Además de esto nuevamente, debido a cómo funciona el enrutamiento (es decir, si un host no está en la red local, la dirección MAC apunta al enrutador, mientras que la dirección IP apunta al host final), no hay forma de utilizarlo. como 192.51.100.1enrutador a menos que A) esté conectado a él; o B) las rutas existentes impulsarán el tráfico en esa dirección.

---

Para evitar que otros hosts lo utilicen simplemente 198.51.100.1como un enrutador simple, se requieren reglas de firewall.

Un enfoque es rechazar (o descartar) los paquetes entrantes en la interfaz externa del enrutador A ( 198.51.100.1) que no estén dirigidos explícitamente a su dirección.

Esto también resolverá elmodelo de huésped débilque Linux implementa (por ejemplo: el enrutador B puede comunicarse con el enrutador A a través de suexternointerfaz, utilizando la dirección asignada alinternointerfaz).

Answer 4

[NAT] enruta las solicitudes a la web y de regreso al cliente que las solicitó

Bien, pero como punto de aclaración sobre cómo funciona: NAT hace que sus direcciones IP privadas parezcan una dirección IP pública, generalmente antes de que el tráfico abandone su red. Por lo tanto, la web no dirige el tráfico a su dirección IP privada. La web devuelve el tráfico a la dirección IP pública donde eres visto.

Asunto número 1:

Creo que si comprende cómo funciona NAT en detalle, esto le ayudará a responder algunas de sus preguntas. La implementación más típica que he visto es NAPT (traducción basada en "puerto de dirección de red"). Cuando envía datos desde una dirección privada, el enrutador toma esa dirección privada y agrega esa información a un gráfico/tabla en la memoria del enrutador. El enrutador también elige un número de puerto TCP o UDP (probablemente seleccionado de forma bastante aleatoria) y realiza un seguimiento de ello en el mismo gráfico/tabla. Luego, el enrutador envía la información a Internet utilizando la dirección IP pública e identifica el número de "puerto de origen" como el número que eligió. (Tanto TCP como UDP utilizan dos números de puerto: un número de "origen" y un número de "destino"). Cuando el destino (por ejemplo, un servidor web que escucha en el puerto TCP 443) detecta que el tráfico va al puerto TCP 443 y proviene de un puerto TCP diferente (por ejemplo, puerto TCP 53874), ese servidor puede responder enviando tráfico de regreso a la dirección IP pública del enrutador de origen en ese mismo puerto TCP (por ejemplo, puerto TCP 53874). Luego, el enrutador busca información en su tabla/gráfico y sabe a qué dirección IP privada enviar la información.

Si simplemente elige una dirección IP privada al azar, el enrutador no debería tener esa dirección IP privada en su tabla/gráfico, por lo que eso no funcionaría.

Supongo que hay otro medio para enrutar datos al cliente correcto en el enrutador/NAT que no es solo IP, pero no estoy seguro de cómo se hace.

No.

Quiero decir, bueno, sí, lo hay. Hay otras rutas que pueden ocurrir, así que lo reconoceré rápidamente. Se utiliza el etiquetado "VLAN" 802.1q y otras tecnologías que se pueden utilizar para algunas nubes de datos/señalización y podrían afectar la forma en que el tráfico termina viajando a través de una red. Sin embargo, esos métodos de enrutamiento adicionales generalmente se implementan por motivos de velocidad, seguridad o compatibilidad (principalmente con redes que no son IP, como quizás algunas redes más antiguas dentro de una compañía telefónica). Realmente no necesita pensar que estas técnicas avanzadas de redes de nivel profesional introducirán una parte nueva y necesaria para comprender cómo funciona el enrutamiento básico, porque el enrutamiento IP simple y básico se puede utilizar para explicar lo que está preguntando.

Problema nº 2: las defensas internas del enrutador

Ahora, supongamos que el enrutador no está realizando NAPT, por lo que ignoraremos toda la tabla/gráfico que relaciona los números de puertos TCP/UDP públicos con las direcciones privadas. Supongamos que está sentado frente al ISP del cliente y desea enviar maliciosamente el paquete a través del enrutador a las direcciones IP privadas del cliente.

La mayoría de los enrutadores, al realizar algunas acciones muy básicas similares a las de un firewall, notarán que el tráfico entrante llega al puerto denominado "WAN" (que significa "red de área amplia"). Para brindar cierta protección, los enrutadores se darán cuenta de que el tráfico entrante en ese puerto de red debe utilizar la dirección IP pública del enrutador y ciertamente no ninguno de los rangos de direcciones IP "privadas" comunes.

Entonces, el enrutador defenderá la red descartando el paquete.

Problema 3: Los ISP nos protegen mejor

El estándar para cualquier ISP es no permitir ningún tráfico hacia o desde los rangos de direcciones IP privadas (que son los rangos de direcciones de red identificados enIETF RFC 1918 Sección 3para IPv4, o direcciones que comienzan con "fd" para IPv6).

Entonces, si está intentando enviar tráfico desde su casa, a través de su ISP y luego a través del resto de la red principal de Internet de los ISP, luego a través del ISP de la víctima, luego a través del enrutador de su víctima y finalmente a la "IP privada". dirección de su elección, entonces debería fallar. Esto se debe a que los ISP suelen seguir la convención de bloquear el tráfico que involucra direcciones IP privadas. (Los ISP estarían locos si no hicieran esto).

En el escenario anterior, la protección no la proporciona el ISP de la víctima objetivo. Por supuesto, es probable que el ISP de la víctima objetivo esté configurado para descartar los paquetes, protegiendo así el enrutador de la víctima objetivo. Sin embargo, es probable que su ISP también descarte los paquetes, por lo que ni siquiera llegarán al ISP de la víctima objetivo.

Asunto 4: Motivación del ISP

¿Por qué los ISP estarían locos al permitir el tráfico que involucra IP privadas?

Bueno, tenga en cuenta que todas las organizaciones pueden utilizar direcciones IP privadas para sus propias redes internas. Eso incluye a los ISP. Es posible que su ISP esté utilizando direcciones privadas para algunos de sus equipos locales. No deberías poder notar/detectar si están haciendo eso o no.

La forma en que los ISP enrutan el tráfico se basan en "tablas de enrutamiento" que determinan hacia dónde debe dirigirse el tráfico a continuación. Estas "tablas de enrutamiento" no especifican qué otro ISP estará dispuesto a recibir tráfico que tenga una dirección privada como destino. El ISP no tendrá a dónde enviar el tráfico, excepto, posiblemente, a algunos de sus propios equipos internos. Dado que una gran cantidad de tráfico que involucra direcciones IP privadas probablemente sea malicioso o problemático (quizás implique tráfico proveniente de un dispositivo configurado incorrectamente), el ISP ciertamente no quiere que dicho tráfico se envíe a su propio equipo interno ( y posiblemente causar problemas al ISP). Por lo tanto, el ISP querrá bloquear los paquetes que van a una dirección privada.inmediatamente, antes de permitir que el tráfico continúe a través de la red del ISP.

Si un ISP infringiera estas reglas, probablemente estaría invitando a tráfico malicioso que probablemente no tendría ningún efecto (aparte del uso del ancho de banda), pero si hubiera algún efecto, probablemente sería malo para el ISP.

Asunto 5: ¿Qué pasaría realmente?

Hasta ahora he explicado por qué Internet bloqueará el tráfico. Pero veamos lo que realmente va a pasar.

Si estás sentado frente a tu computadora y decides enviar un paquete malicioso a una dirección IP privada, ¿qué pasará?

Si el tráfico llegara hasta su ISP local, ese ISP local bloquearía el tráfico inmediatamente, como ya se explicó.

Sin embargo, lo que realmente sucederá es que el tráfico no llegue hasta su ISP local. En cambio, su enrutador local descubrirá qué hacer con ese tráfico.

Si no está utilizando la misma dirección IP "privada", entonces su propio enrutador probablemente no sabrá qué hacer con el tráfico, por lo que se descartará.

De lo contrario, si usted mismo está utilizando la misma dirección "IP privada", es probable que esté atacando un dispositivo en la red en la que se encuentra. Si eres el administrador de esa red, ¡estarías atacando tu propia red!

En cualquier caso, no es probable que su enrutador (cuando utilice configuraciones predeterminadas comunes) pase el tráfico a través de Internet.

Revisar:

Todas estas cuestiones tienen que ver con por qué Internet no permite su ataque a una dirección IP privada. Si realmente estás en la misma red local que tu objetivo, es posible que ni siquiera necesites pasar por un enrutador, por lo que ninguna de estas defensas se interpondrá en tu camino. Sin embargo, si se encuentra en otro lugar de Internet, estas defensas probablemente obstaculizarán el intento de realizar dicho ataque.

Aunque puede violar ciertas reglas estándar con (al menos algunos tipos de) enrutadores que puede controlar, es probable que otras organizaciones también bloqueen direcciones IP privadas, evitando así de manera efectiva ataques a sistemas remotos.