特定のアプリケーション用にある種のプロキシ サーバーを構築しています。クライアントはこのサーバーに接続し、プロキシ サーバーが接続するホストを指定します。そこから、プロキシ サーバーが最終サーバーに接続し、データを中継します。
接続を確立するときに、プロキシ サーバーのユーザーがアクセスしてはならないリソースにアクセスできないようにするにはどうすればよいですか? たとえば、サーバー管理に使用する localhost や VPN に接続させたくありません。ブラックリストに登録することはできますが、特定のネットワーク インターフェイスでのみ発信接続を許可するより良い解決策があるかどうか疑問に思っています。おそらく、TCP クライアントを特定のインターフェースにバインドする方法や、選択したルートが特定のインターフェースを使用していることを確認する方法です。
それが問題になる場合は、Node.js を使用してこのプロキシ サーバーを構築し、net.connect()リモート サーバーへの TCP 接続を作成する標準的な方法を使用しています。
これに対する答えは、構築している「プロキシ」の種類に完全に依存しますが、現時点では不明です。おそらく言い換えてください。
SOCKSまたはHTTPプロキシについて話している場合、これは不可能だと思います.ターゲットがvpnエンドポイントであるかどうかを知る方法はありません（少なくともプロキシサービスの観点から）. プロキシ アプリがフィルター処理するために使用できる唯一の参照は、ソックス ネゴシエーション中にサーバーに渡される IP アドレスまたは DNS 名、および接続の発信元のソース IP アドレスです。ただし、ファイアウォールを使用することはできますが、これはもちろんプロキシ関連ではありません。
ある種のファイアウォール/ネットワーク スタック エクステンション/ドライバー、iptables/カーネル モジュールなどを構築している場合、自分で接続を切断して再確立し、深刻なパケット処理を実行する場合、もちろん、はるかに優れた制御が可能であり、検査することができます。接続のほぼすべての層。ただし、その場合、あなたの質問は答えるには広すぎます。
どのソフトウェア/ツール/言語を自由に使用できますか? また、どのプラットフォームについて話しているのですか?
編集：おっと、Node.jsに言及している段落を逃したので、接続を最終的な宛先に転送するために靴下のようなプロトコルを使用していて、プロキシアプリがより深いネットワーク層を照会できないと仮定しています。プロトコルがどのように機能するかについての詳細がなくても、確立された/確立されるtcp接続からの送信元IPと、プロトコルハンドシェイクでネゴシエートされている宛先IP/DNSだけで作業する必要があります。これを使用して、プロキシ サービスにサーバーまたはネットワークの vpn/ルーティング構成 (ppp.conf/ldap/yellow pages/database/what have you) を照会させ、リソースを制限するかどうかを判断させることができます。
コメントの情報から更新:
わかりました、これを 3 つのコンポーネントに分けることができます。
登録ユーザーにブラウザベースのshoutcastクライアントを提供するパブリックWebアプリケーション（議論のために、これら2つは1つの同じコンポーネントと見なすことができます）
公共のインターネット上のどこかにある任意の数の規制されていないシャウトキャスト サーバーで、これらのユーザーがクライアントに接続してもらいたい場合とそうでない場合があります。これらのサーバーの存在を認識している場合と認識していない場合があります。
Web クライアントからの接続を受け入れ、これらのサーバーにストリームを転送する中間のプロキシ サービス。
これらのコンポーネントを保護する最善の方法は、webapp を信頼できるものにすることだと思います (拡張性が高く、実装が簡単で、管理が簡単で、何らかの形で既に存在しています)。プロキシは、デフォルトですべての接続をドロップする必要があります。ユーザーが webapp/shoutcast クライアントにログインした場合にのみ、トークンまたはユーザー/パスの組み合わせに基づいて、接続できるサーバーと接続先のサーバーをプロキシに通知します。
クライアントがプロキシに接続し、その一時的なトークン (またはその他の識別手段) を提示すると、プロキシは内部ハッシュ テーブルでそれを検索して、接続先を決定します (または、そこへの接続が許可されていることを確認します)。
管理者に、ユーザーが webapp で選択できるように、既存の Shoutcast サーバーのリストを事前に承認してもらうか、後でプログラムまたは手動で確認できるように、ユーザーにシステムに追加してもらうこともできます。
ファイアウォールに関しては、すべての転送接続がプロキシ アプリケーションで開始されるため、プロキシで開始され、特定のネットワーク インターフェイス (admin、lan、vpn、tun、tap など) を通過するすべての接続をドロップすることも非常に簡単です。インターウェブ上の外国のアドレス宛のもの。
ウェブアプリがプロキシと通信するだけでなく、プロキシを介したすべての悪意のあるトラフィックを防止するために、(または Amazon などの) ファイアウォール ルールを構成することもできます (または、少なくともポリシーの適用と監査をはるかに簡単にします。したがって、有効な既存のユーザーが所有している必要があります)。また、初歩的なサービス拒否攻撃を防ぐため (Web アプリケーションは、従来のプロキシ サービスよりもはるかに簡単かつ安価にクラウドでホストできます)、デフォルトですべてをファイアウォールで保護し、に基づいて穴を開けます。 Web/ユーザー アクティビティは、規模、複雑さ、パフォーマンス、およびセキュリティ面の両方において堅実なゲーム プランです。
いくつかの追加の常識：
プロトコルの強制 (アプリケーションのプロトコルの通過のみを許可したい)、rfc の/プロトコルに準拠していない接続を強制終了します。これは、脆弱なサービスへのエクスプロイトを無効にするのにも役立ち、他のプロトコルがランダムに通過するのを防ぎます。
ホワイトリストに登録されていると見なされるサイト/サービス (IP + ポートのペア) の構成可能な (フラットファイル/データベース) リストを確立します。
設定可能なブラックリストを確立する (管理ネットワーク、ローカルホストなど)
送信する診断エラーに注意するか、何かを送信する場合は注意してください (攻撃者がプロキシ サービスを使用して、プロキシからの応答を見て内部ネットワーク リソースをプローブ/マップすることを考えてください)。
絶対に必要な場合を除いて、このプロキシをまったく実装しないことを検討してください.静的に構成された転送/ルートで十分な場合は、代わりにそれを使用してください..リレー（オープンまたはクローズ）は理由により回避されます.
敬具、