OpenVPN カスタムスクリプトを使用して着信トラフィックまたはペイロードを変更する

Question

あなたのアイデアはいくつかの理由で実現不可能です:

1)

私の記憶では、OpenVPN 自体には、転送する前に VPN 接続からカスタムプロセスにデータをパイプする機能はありません。

クイックリファレンス: OSI スタック内で TCP/IP が使用されている場所を確認してください。

OpenVPN は OSI スタックのレイヤー 3 (ネットワーク層) に存在し、TCP パッケージはレイヤー 4 (トランスポート層) に属します。

この理由だけで、あなたの質問は OpenVPN が達成しようとしている範囲外です。

操作できるのは、クライアントがサーバーに接続したとき、または切断したときに何が起こるかだけです。

これらの状況は、サーバー構成ファイルで次の設定を通じて定義できます。

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

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

カスタムスクリプトで使用できるすべての環境変数は、次の場所で確認できます。

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

しかし、本質的には、監視できる唯一の情報は、サーバーに接続するためにどのクライアント証明書が使用されたか、どの IP アドレスがクライアントに割り当てられたかであり、その後、誰が接続したか、再び切断したときに何を行うかに応じて、サーバー上でカスタムロジックを作成します。

典型的な設定としては、動的 DNS サーバー側を実装するか、どの VPN 接続が稼働しているかに応じてフェイルオーバールーティングなどのカスタムルーティングを実行することが考えられます。

2)

IPv4パケットの図を参照すると、ウィキペディア:

本質的には、送信元または宛先のアドレスに応じてデータフィールドを操作することが目的です。

これは中間者攻撃とも呼ばれます。

ご存知のとおり、すべてのコンテンツが暗号化されているため、OpenVPN インターフェイスでリッスンしてこれを実行するのは困難です。インターネット宛ての IPv4 パケットが、OpenVPN サーバー宛ての別の IPv4 パケットにカプセル化されることになります。

カプセル化された IPv4 パケットは、上図のデータフィールドに格納されます。

VPN サーバーからインターネットに転送されるのは、カプセル化解除されたパケットです。

ただし、注意点があります:

VPNクライアントはないパブリック IP アドレスを持ちます。つまり、NAT 変換が実行され、インターネット上のホストに接続する前に、送信元アドレスが VPN サーバーのアドレスに書き換えられます。

同様に、ホストが応答を返すと、宛先 IPv4 アドレスは VPN サーバーと同じになります。

つまり、データフィールドを操作するには、network address translation table(NAT とも呼ばれる) で使用されているポートを追跡する必要があります。

複数の VPN クライアントが VPN と NAT を介してインターネットに接続でき、すべての TCP セッション (メール、Web、ssh など) が異なるポートを使用するため、使用されるポートは通常、本質的に動的です。

だから、もしあなたが復号化されたTCPパケットこれは、復号化の後、NAT で変換される前に実行する必要があります。

理論的にはを使用してパケットを傍受できますiptablesが、VPN と NAT が同じマシン上に存在する場合は簡単ではありません。

もう 1 つのアプローチは、暗号化された OpenVPN トラフィックを直接攻撃することです。OpenVPN サーバーを制御するということは、サーバーとクライアントの両方で使用される証明書と秘密キーも制御できることを意味します。

これは、典型的な中間者攻撃として実行可能です。ただし、どのように実行されるかはわかりません。:-)

...しかし、これが私の最後の議論につながります。

3)

インターネット上のほとんどのトラフィックは TLS で暗号化されています。

したがって、OpenVPN トラフィックを復号化した後でも、データフィールドの内容を操作するには、別の暗号化レイヤーを突破する必要があります。

この部分は、セッションに使用される暗号化キーを制御できないため、暗号化された OpenVPN トラフィックを攻撃するよりも攻撃がさらに困難です。

TLSトラフィックを復号化してコンテンツを再暗号化し、エンドユーザーにとって暗号化されたトラフィックが実際にYouTubeなどから発信されたように見えるようにしたとしても、httpsトラフィックの暗号化に使用した証明書が信頼されていないエンドユーザーのコンピュータ上のブラウザによって。

これだけで、中間者攻撃は無意味になります。

これであなたの質問に対する完全な答えに近づきました。

TCP セッションを攻撃する他の角度もありますが、現在、私たちはこれをセキュリティの専門家が集まるフォーラムに属する高度な分野として扱っています。

その部分は私の能力をはるかに超えています。:-)

Answer 1