⛹🏾 🕵🏾 🌖 もう1つの「重要な」VPNの「脆弱性」とポート障害がナンセンスである理由 🤛 🤾 🐏

11月26日の朝は興味深いニュースから始まりました。PerfectPrivacyのメンバーがPort Fail脆弱性に関する情報を公開しました。これにより、ポート転送機能を備えたVPNサービスクライアントのIPアドレスを公開できます。脆弱性と呼ばれたので、少し後悔しました。これは脆弱性ではありませんが、ルーティングの機能です。VPNサーバーのIPアドレスへのトラフィックは、VPNをバイパスして常に直接送信されます。ネットワーク管理者が知っておくべき明らかなことです。健全で技術的に有能であることに注意してください。あなたは、脆弱性（脆弱性）という言葉で障害を見つけることができます。しかし、その後、メディアはビジネスに取りかかりました、そして私たちは出発します...

すべてのオペレーティングシステム上のすべてのVPNプロトコルに重大な脆弱性。 おお、なんて怖い！

元々黄色の見出しがあったGeektimesに掲載されたニュースは、最大のVPNサービスの1つであるプライベートインターネットアクセスから見つかった「脆弱性」に対する5,000ドルの報酬について述べています。「ネットワーカにとって完全に明白な典型的なものに対して5,000ドルですか？」と私は「信じられないほど！」と考え、コメントで私のdigりを表明し、同時に2 1台のコンピューター上のより多くのインターネットプロバイダー：着信要求への回答は、必ずしも同じプロバイダーと同じIPを経由するわけではなく、要求側はまったく期待していません。 2番目のプロバイダーの代わりにVPN接続があると想像した場合、プロバイダーのIPアドレスにリクエストを送信すると、特定の条件下で、IP VPNサーバーからリクエストへの応答が返されることがあります。

これはどのように起こりますか？

VPNに接続すると、以前にISPを介して設定されていたデフォルトルートが、VPNを介したルートに変更されます。
ポートでリッスンし、ポートへの着信接続を受け入れるアプリケーションは、着信パケットへの応答を生成するときに、主にオペレーティングシステムに依存します。これは、ネットワークインターフェイスが1つしかない場合に効果的ですが、OSとプロトコルに応じて、いくつかのインターフェイスで状況が変わります。

Windows

OpenVPN（def1）-UDPはVPNインターフェースを経由し、TCPは正しく動作します
IPsec IKEv2-UDPはVPNインターフェイスを通過し、TCPはドロップします

OS X ：

OpenVPN（def1）-UDPはVPNインターフェースを通過し、TCPはドロップされます
IPsec IKEv2-UDPはVPNインターフェースを通過し、TCPは正しく動作します

Linux ：

OpenVPN（def1）-UDPおよびTCPは、rp_filter = 0でVPNインターフェイスを通過し、rp_filter = 1で破棄されます。

Linuxには、ほとんどの最新のディストリビューションでデフォルトで有効になっているリバースパスフィルタリング（rp_filter）の素晴らしい設定があります。フィルターが有効になっている場合、ポートでリッスンしているプログラムは、OSが別のインターフェイスを介して回答が送信されると確信している場合、着信データを受信しません。一部のディストリビューション（少なくともDebianでは）では、このオプションはデフォルトで無効になっていますが、この理由は明らかではありません。
残念ながら、WindowsとOS Xでは、そのような機能はありません。

これはどうして難しいのでしょうか？

ご覧のとおり、UDPポートでリッスンしているアプリケーションへの着信パケットのみに問題があります。一般的なユーザーのコンピューターにこのようなアプリケーションが多数存在することはまずありませんが、原則としていくつかは依然として存在します。

Bittorrent

ご存知かもしれませんが、たとえば米国、ドイツ、フランス、オーストリア、カナダ、英国などの一部の国では、著作権所有者の要求に応じて、関心のあるBitTorrent配信の参加者を追跡する特別な組織があります。彼らはBitTorrentトラッカーとDHTネットワークに接続し、特定のディストリビューションのすべてのIPアドレスを保存し、後で「幸福の手紙」を送信できるようにします。 -それはすべて違法であり、このビジネスに対して罰金を支払う必要があること。これらの国の居住者は、これらの悪人のスキャナーに陥らないように、他の「未開発」国でVPNを使用しており、企業はこれについて悲しんでいます。

したがって、知的財産権の侵害を監視する企業は、このルーティング機能をどのように活用できますか。

プロバイダーが「白い」（ルーティング可能な）IPアドレスを提供するユーザーは、VPNに接続し、BitTorrentクライアントを起動して、配布のダウンロード後も残っているいくつかのファイルをダウンロードします。 BitTorrentクライアントはポートをリッスンし、必要に応じてUPnPを介してポートを開きます。
監視会社は、ユーザーのVPNサーバーのIPアドレスとポートを含む、このディストリビューションのすべてのIPアドレスを収集します。
同社は、インターネット上のすべてのIPアドレス上のBitTorrentクライアントに、以前に収集したポートにUDPパケットを大量に送信します。 10ギガビットチャネルを使用すると、数十分以内に留まることができます。
プロバイダーのネットワークインターフェイスへの着信パケットを受信したユーザーのBitTorrentクライアントは、IP VPNサーバーからVPNインターフェイスを介して応答を送信します。
同社は、関心のある素材を配布している実際のIPクライアントを発見します。

私の意見では、ほとんどすべてのBitTorrentクライアントが最初の起動時にランダムなポートを選択し、インターネット上のすべてのポートとすべてのIPアドレスにメッセージを送信できるため、このアプローチを悪用することは非常に問題です常に行うのは難しい。ただし、8999や6881などの標準ポートを使用するお客様がいます。
そのようなクライアントとの接続は標準ネットワークスタックでは機能しませんが、そのような接続が確立されるように変更できます。

Skype

この手法を使用すると、VPNを使用している場合に関心のあるSkypeユーザーの実際のIPを見つけることができます。 Skypeログイン経由でユーザーのIPとポートを表示する多数のパブリックSkypeリゾルバーがあります。次に、著作権所有者が使用するのと同じ手法に頼る必要があります-インターネット全体でUDPポートにデータを送信し、答えに従います。ほとんどすべてのごみをSkypeに送信できることは注目に値します！ nmapのすばらしいnpingプログラムを使用します。

# nping --udp -p 13318 --data-string 'hellothere!' -c 1 serv.valdikss.org.ru Starting Nping 0.7.00 ( https://nmap.org/nping ) at 2015-12-20 19:54 MSK SENT (0.0157s) UDP 195.154.127.59:53 > 92.42.31.8:13318 ttl=64 id=10802 iplen=39 RCVD (0.0859s) UDP 185.61.149.121:4272 > 195.154.127.59:53 ttl=54 id=1534 iplen=32 Max rtt: N/A | Min rtt: N/A | Avg rtt: N/A Raw packets sent: 1 (39B) | Rcvd: 1 (46B) | Lost: 0 (0.00%) Nping done: 1 IP address pinged in 1.01 seconds

自分を守る方法は？

この機能はそれほど大きな問題ではないと思いますが、技術的な観点からこのようなリークを防ぐ方法はまだ疑問です。
Linuxでは、すべてが非常に簡単です-IPv4のオプションを設定するだけです

 net.ipv4.conf.*.rp_filter

1がインストールされていない場合。私のVPNインターフェースはtun0と呼ばtun0 、私のインターネットインターフェースはwlp3s0とwlp3s0ので、次のことを行います。

 # sysctl net.ipv4.conf.all.rp_filter=1 # sysctl net.ipv4.conf.default.rp_filter=1 # sysctl net.ipv4.conf.tun0.rp_filter=1 # sysctl net.ipv4.conf.wlp3s0.rp_filter=1

また、IPv6の場合、iptablesルールを追加する必要があります。

 # ip6tables -t raw -A PREROUTING -m rpfilter --invert -j DROP

Windowsには強力なWindowsフィルタリングプラットフォームがあり、これを使用してユーザー空間に非常に柔軟なファイアウォールルールを直接記述できます。これが十分でない場合は、カーネルドライバーを記述します。
Windows 10のDNSリークの場合のように、OpenVPNのプラグインとして、Windowsでのリバースパス転送の類似性を実装しようとしました。彼は次のことを行います。

アドレス10.0.0.0/8、172.16.0.0/12、192.168.0.0/16、169.254.0.0/16およびアクティブなネットワークアダプターのサブネットからの着信IPv4ユニキャストUDPパケットを許可します。 fd00 :: / 8、fe80 :: / 10およびアクティブなネットワークアダプターのサブネットを持つすべての着信IPv6ユニキャストUDPパケット。
VPNインターフェイスの外部からのすべての新しいユニキャストUDPパケットをブロックします。

これは本格的なリバースパスフォワーディングではありませんが、非常にうまく機能します。UDP要求に対する応答は、ルーティングできないアドレスの範囲から来た場合にのみVPNトンネルに送られますが、この場合、VPN側でドロップされます以来のサーバー実際、これらはルーティング不可能です（特定のローカルネットワーク内でのみ機能します）。 UDPを使用するプログラム（たとえば、BitTorrent Sync）はLAN内で動作を停止せず、プロバイダーサブネット上の隣接者は引き続き正しく連絡できます。
ここからプラグインをダウンロードできます： github.com/ValdikSS/openvpn-block-incoming-udp-plugin

OS Xでは、すべてがやや複雑です。PFは新しいUDPパケットのみのフィルタリングを許可しないため、ローカルアドレス、プロバイダーサブネット、VPNサーバー自体を除くすべての着信UDPをブロックする必要があります。これは、たとえば、必要に応じてDNSプロバイダーを使用できないためです。答えが得られないだけで、IP DNSサーバーをホワイトリストに登録する必要があります。
いずれにせよ、これはおおよそ次のように実行できます。

 echo 'pass in quick proto udp from 10.0.0.0/8 to any pass in quick proto udp from 192.168.0.0/16 to any pass in quick proto udp from 172.16.0.0/12 to any pass in quick proto udp from 169.254.0.0/16 to any pass in quick proto udp from 185.61.149.121/32 to any block in quick on ! utun1 proto udp to any' | sudo pfctl -Ef -

ここで、 185.61.149.121はVPNサーバーのIPアドレスであり、 utun1はVPNインターフェイスです。

あとがき

あなたがすべて悪役であり、この機能を悪用しようとする場合、netfilterを使用してLinuxでパッケージをログに記録すると役立ちます。次のiptablesルールを追加するだけで十分です。火星からのすべてのパケットが完全に表示されます。

 iptables -I INPUT -m conntrack -p udp --sport 4455 --ctstate NEW -j LOG

4455は興味のあるポートです。

この機能に関するメッセージを11のVPNプロバイダーに送信し、5からのみ応答を受信しました：プライベートインターネットアクセス、パーフェクトプライバシー、およびMullvadは、着信接続をブロックする機能を備えた更新されたクライアントをリリースしました。 VPNとの関係。技術的には正しいのですが、クライアントは他のクライアントの問題（IPv6、DNS、WebRTCリーク）から保護されており、別のクライアントを追加しないのは謎のままです。 CryptostormのスタッフはWindowsレジストリキーを要求しましたが、これにはリバースパスフォワーディングが含まれているはずですが、機能せず、TorGuardは彼らからの質問に答えた後何も書きませんでした。

ちなみに、 OpenVPN 2.3.9には、Windowsエラーの多数の修正と、Windows 8.1および10でのDNSリークを修正する待望のオプション--block-outside-dnsが付属しています。

プライベートインターネットアクセスから5,000ドル、パーフェクトプライバシーから1,000ドル、マルバッドから1,300ドルを受け取りました。もう1つのナンセンスで、正直言って少し気まずいです。お金の一部はOpenVPNとstrongSwanの開発者に送られます。