OpenVPN Modifique el tráfico entrante o la carga útil con un script personalizado

OpenVPN Modifique el tráfico entrante o la carga útil con un script personalizado

Recientemente configuré OpenVPN con Dnsmasq como DNS y quiero hacer algo sobre lo que parece que no puedo encontrar información.

Aquí está mi comprensión actual basada también en lo que he configurado actualmente en mi servidor.

A. El cliente se conecta a OpenVPN, digamos desde un teléfono

B. Los clientes envían tráfico, es decir, abren un sitio web, por ejemplo YouTube.

C. El servidor OpenVPN acepta la solicitud.

D. Reenvía la solicitud al servidor de destino, es decir, YouTube.

E. YouTube responde.

F. OpenVPN reenvía la respuesta al cliente de A

Por supuesto, lo anterior está demasiado simplificado.

¿Lo que quiero hacer?

Entre las etapas C y D, como después de que OpenVPN toma la solicitud (u obtiene una respuesta del servidor de destino, es decir, D->C), quiero procesar los datos reales.

Por ejemplo, un caso de uso típico.

Entre D y C, quiero pasar la carga útil a, por ejemplo, un script de Python, cambiar todo el texto "Te amo" en el html de la página web a "Te odio" antes de que la carga útil se cierre y se envíe al cliente.

Pregunta

¿Existe alguna forma de "Ganchos de ciclo de vida" con OpenVPN donde básicamente pueda escuchar y alterar la carga útil de una solicitud?

Entiendo que cualquier conexión entrante o saliente de OpenVPN está protegida por 'fort knox'. Estoy interesado en el punto en el que la carga útil de respuesta está desnuda en el servidor.

¿Cuáles son mis opciones disponibles? ¿Necesito utilizar un paquete/software diferente para ayudar a lograr tales resultados?

Respuesta1

Su idea es inviable por varias razones:

1)

Hasta donde recuerdo, no existe una función en OpenVPN para canalizar datos desde una conexión VPN a un proceso personalizado, antes de reenviarlos.

Para referencia rápida: compruebe dónde se utiliza TCP/IP en la pila OSI.

OpenVPN reside en la capa 3 de la pila OSI (capa de red), mientras que los paquetes TCP pertenecen a la capa 4 (capa de transporte).

Sólo por este motivo su pregunta está fuera del alcance de lo que OpenVPN quiere lograr.

Lo único que puedes manipular es lo que sucede cuando un cliente se conecta al servidor o se desconecta.

Esas situaciones se pueden definir en el archivo de configuración de su servidor a través de las siguientes configuraciones:

# client connected to VPN server
client-connect "/script/client_connect.sh"

# client disconnected from VPN server
client-disconnect "/script/client_disconnect.sh"

Todas las variables ambientales que están disponibles para su script personalizado están disponibles aquí:

https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4/#scripting-and-environmental-variables

Pero, en esencia, la única información que puede monitorear es qué certificado de cliente se usó para conectarse al servidor y qué dirección IP se asignó al cliente y luego crear una lógica personalizada en el servidor dependiendo de quién se conecta y qué hacer cuando se desconecta nuevamente.

Una configuración típica podría ser implementar un lado del servidor DNS dinámico o realizar algún enrutamiento personalizado, como enrutamiento de conmutación por error dependiendo de qué conexión VPN esté activa.

2)

Refiriéndose a este diagrama de un paquete IPv4 deWikiPedia:

Esquemas de un paquete IPv4

En esencia, lo que desea hacer es manipular el campo de datos, dependiendo de la dirección de origen o destino.

Esto también se conoce como ataque de intermediario.

Como habrás descubierto, es difícil hacerlo escuchando en la interfaz OpenVPN ya que todo el contenido está cifrado. Lo que sucede es que el paquete IPv4 destinado a Internet se encapsula en otro paquete IPv4, que está destinado al servidor OpenVPN.

El paquete IPv4 encapsulado se almacena en el campo de datos del diagrama anterior.

Es el paquete desencapsulado que se reenvía a Internet desde el servidor VPN.

Sin embargo hay una advertencia:

Supongo que el cliente VPN sínoTener una dirección IP pública. Esto significa que interviene la traducción NAT y que la dirección de origen se reescribe para que sea la del servidor VPN antes de contactar con cualquier host en Internet.

Del mismo modo, cuando el host responde con una respuesta, tenemos que la dirección IPv4 de destino es la misma que la del servidor VPN.

Esto significa que para manipular el campo de datos necesitamos realizar un seguimiento de qué puertos se están utilizando en network address translation table(también conocido como NAT).

Los puertos utilizados normalmente son de naturaleza dinámica, ya que más de un cliente VPN puede conectarse a Internet a través de VPN y NAT y cada sesión TCP (correo, web, ssh, lo que sea) utiliza un puerto diferente.

Así que si quieres manipular elpaquete TCP descifradoTiene que ocurrir después del descifrado, pero antes de que se traduzca en NAT.

En teoría, puedes interceptar el paquete usando iptables, pero no es trivial cuando VPN y NAT residen en la misma máquina.

Otro enfoque es atacar el tráfico OpenVPN cifrado directamente, ya que usted controla el servidor OpenVPN significa que también controla qué certificados y claves privadas se utilizan tanto en el servidor como en el cliente.

Esto es factible como un clásico ataque de intermediario. Aunque no sé cómo se hace esto. :-)

... pero esto me lleva a mi último argumento:

3)

La mayor parte del tráfico en Internet está cifrado TLS.

Entonces, incluso después de haber descifrado el tráfico OpenVPN, hay otra capa de cifrado que debes superar para poder manipular el contenido del campo de datos.

Esta parte es incluso más difícil de atacar que simplemente atacar el tráfico OpenVPN cifrado, ya que usted no tiene el control de las claves de cifrado utilizadas para la sesión.

Incluso si intentara descifrar el tráfico TLS y volver a cifrar el contenido para que al usuario final le pareciera que el tráfico cifrado realmente se originó en YouTube o lo que sea, aún así sería inútil, ya que el certificado que utiliza para cifrar el tráfico https esno es de confianzapor los navegadores en las computadoras de los usuarios finales.

Esto por sí solo hace que su ataque de intermediario sea inútil.

Esto es lo más cercano a una respuesta completa a su pregunta.

Hay otros ángulos para atacar una sesión TCP, pero ahora vamos a un campo avanzado que pertenece a un foro lleno de expertos en seguridad.

Esa parte está MUCHO más allá de mis calificaciones. :-)

información relacionada