ユーザーのファイアウォールをバイパスするために、発信トラフィックにポート80または443を使用する方が本当に良いですか？
最近、C＃でリバース接続シェルを作成しました。一部のコンピューターでテストしましたが、一部のコンピューターが正しく接続され、それらとの接続を確立しましたが、Windows 7を実行している別のコンピューターが機能しないか、接続が確立されていないようです。
通信ポートとしてポート3001を使用していて、リバース接続を確立しようとしました。このコンピュータが機能しない理由は何ですか？通信ポートが役立つのでポート80または443を使用していますか、または接続が逆であるのと同じです！言い換えると、リバース接続での発信トラフィックにはポート80または443を使用する方が本当に良いのでしょうか。
ポート443はSSL用です。 SSLは部外者に対して「不透明」であるため、ファイアウォールは内部の状況を確認できず、透過的なプロキシを実行できません。さらに、Webの多くはポート443を使用しています（すべてhttps:// URL）。したがって、ポート443は、厳密なルールを持つサイトであっても、発信接続用に開かれる可能性が最も高いポートの1つです。
ただし、一部のサイトでは、特定のプロキシに向かう接続を除いて、allのすべての発信接続がブロックされることに注意してください。 SSLはプロキシできません透過的に、明示的に（ CONNECT 呼び出しで）実行できます。ほぼすべての場所で機能する「リバース接続シェル」を実装したい場合は、HTTPSの可能なプロキシを検出して使用できる必要があります。
また、IDSが組み込まれた最新のファイアウォールespはprotocol conformanceの概念で動作することを理解する必要があります。これは、オレンジが引っ掛かりそうなボックスでリンゴを渡すことを計画している場合に意味します。これは、一部のコンテキストではディープパケットインスペクションも意味します。 rfcへの準拠を確認したら、ファイアウォールの応答に応じて、パケットを警告するか、ドロップするか、拒否することができます。
しかし、いつでもc＃アプリケーションをデバッグして、接続しようとするときに何が起こるかを確認できます。 RSTパケットを受信したり、ソケットのエラー（要求の処理、終了）によって接続が切断されたりしませんか？.
パーソナルファイアウォール、ワイヤレスルーター、または企業ファイアウォールは、発信接続を確立するときに使用できるポートを制限するように構成されている可能性があります（別名 出力フィルタリング ）。ご使用の状況では、ポート80または443を使用することをお勧めします。これらは、WebサーバーがそれぞれHTTPおよびHTTPS経由でリッスンする最も一般的なポートであるためです。このため、ほとんどのファイアウォールは、企業の設定であっても、ポート80および443での送信接続を許可します。