OpenVPN Modifique o tráfego de entrada ou carga útil com script personalizado

OpenVPN Modifique o tráfego de entrada ou carga útil com script personalizado

Recentemente configurei o OpenVPN com Dnsmasq como DNS e quero fazer algo sobre o qual não consigo encontrar nenhuma informação.

Aqui está meu entendimento atual com base também no que configurei atualmente em meu servidor.

A. O cliente se conecta ao OpenVPN, digamos, de um telefone

B. Os clientes enviam tráfego, ou seja, abrem um site, digamos, YouTube

C. O servidor OpenVPN aceita a solicitação.

D. Encaminha a solicitação para o servidor de destino, ou seja, YouTube.

E. O YouTube responde de volta.

F. OpenVPN encaminha resposta ao cliente de A

É claro que o que foi dito acima é simplificado demais.

O que eu quero fazer?

Entre os estágios C e D, como depois que o OpenVPN recebe a solicitação (ou obtém uma resposta do servidor de destino, ou seja, D-> C), quero processar os dados reais.

Por exemplo, um caso de uso típico.

Entre D e C, quero passar a carga para, por exemplo, um script Python, alterar todo o texto "Eu te amo" no html da página da web para "Eu te odeio" antes que a carga seja finalizada e enviada ao cliente.

Pergunta

Existe alguma forma de "Life Cycle Hooks" com OpenVPN onde eu possa basicamente ouvir e alterar a carga útil de uma solicitação?

Entendo que qualquer conexão de entrada ou saída do OpenVPN é protegida por 'fort knox'. Estou interessado no ponto em que a carga útil da resposta está nua no servidor.

Quais são as minhas opções disponíveis? Preciso usar um pacote/software diferente para ajudar a obter tais resultados?

Responder1

Sua ideia é inviável por vários motivos:

1)

Pelo que me lembro, não há um recurso no próprio OpenVPN para canalizar dados de uma conexão VPN para um processo personalizado, antes de encaminhar.

Para referência rápida: Verifique onde o TCP/IP está sendo usado na pilha OSI.

OpenVPN reside na camada 3 da pilha OSI (camada de rede), enquanto os pacotes TCP pertencem à camada 4 (camada de transporte).

Sua pergunta está apenas por esse motivo fora do escopo do que o OpenVPN deseja alcançar.

A única coisa que você pode manipular é o que acontece quando um cliente se conecta ao servidor ou se desconecta.

Essas situações podem ser definidas no arquivo de configuração do seu servidor através das seguintes configurações:

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

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

Todas as variáveis ​​ambientais disponíveis para seu script personalizado estão disponíveis aqui:

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

Mas, em essência, a única informação que você pode monitorar é qual certificado de cliente foi usado para conectar-se ao servidor e qual endereço IP foi atribuído ao cliente e, em seguida, criar alguma lógica personalizada no servidor, dependendo de quem se conecta e o que fazer quando se desconectar novamente.

Uma configuração típica poderia ser implementar um servidor DNS dinâmico ou fazer algum roteamento personalizado, como roteamento de failover, dependendo de qual conexão VPN está ativa.

2)

Referindo-se a este diagrama de um pacote IPv4 deWikiPédia:

Esquemas de um pacote IPv4

Em essência, o que você deseja fazer é manipular o campo de dados, dependendo do endereço de origem ou de destino.

Isso também é conhecido como ataque man-in-the-middle.

Como você descobriu, é difícil fazer isso ouvindo a interface do OpenVPN, pois todo o conteúdo é criptografado. O que acontece é que o pacote IPv4 destinado à Internet é encapsulado em outro pacote IPv4, que é destinado ao servidor OpenVPN.

O pacote IPv4 encapsulado é armazenado no campo de dados do diagrama acima.

É o pacote desencapsulado que é encaminhado para a Internet a partir do servidor VPN.

No entanto, há uma ressalva:

Presumo que o cliente VPN faça issonãoter um endereço IP público. Isso significa que a tradução do NAT está envolvida e o endereço de origem é reescrito para ser o do servidor VPN antes que qualquer host seja contatado na Internet.

Da mesma forma, quando o host responde com uma resposta, temos que o endereço IPv4 de destino é o mesmo do servidor VPN.

Isso significa que, para manipular o campo de dados, precisamos controlar quais portas estão sendo usadas no network address translation table(também conhecido como NAT).

As portas usadas são normalmente de natureza dinâmica, já que mais de um cliente VPN pode se conectar à Internet via VPN e NAT e cada sessão TCP (mail, web, ssh, qualquer que seja) usa uma porta diferente.

Então, se você quiser manipular opacote TCP descriptografadoisso tem que acontecer após a descriptografia, mas antes de ser traduzido no NAT.

Em teoria, você pode interceptar o pacote usando iptables, mas não é trivial quando VPN e NAT residem na mesma máquina.

Outra abordagem é atacar diretamente o tráfego criptografado do OpenVPN, já que controlar o servidor OpenVPN significa também controlar quais certificados e chaves privadas estão sendo usados ​​no servidor e no cliente.

Isso é possível como um clássico ataque man-in-the-middle. Eu não sei como isso é feito. :-)

... mas isso me leva ao meu último argumento:

3)

A maior parte do tráfego na Internet é criptografada TLS.

Portanto, mesmo depois de descriptografar o tráfego do OpenVPN, há outra camada de criptografia que você precisa vencer para manipular o conteúdo do campo de dados.

Esta parte é ainda mais difícil de atacar do que apenas atacar o tráfego criptografado do OpenVPN, já que você não controla as chaves de criptografia usadas para a sessão.

Mesmo se você tentasse descriptografar o tráfego TLS e criptografar novamente o conteúdo para que o usuário final parecesse que o tráfego criptografado realmente se originou do YouTube ou algo assim, ainda seria inútil, já que o certificado usado para criptografar o tráfego https énão confiávelpelos navegadores nos computadores dos usuários finais.

Isso por si só torna seu ataque man-in-the-middle inútil.

Agora, isso é o mais próximo de uma resposta completa à sua pergunta.

Existem outros ângulos para atacar uma sessão TCP, mas agora estamos abordando um campo avançado que pertence a um fórum cheio de especialistas em segurança.

Essa parte está MUITO além das minhas qualificações. :-)

informação relacionada