65535より高いポートにバックドアを配置することは理論的に可能ですか？
サーバー/クライアントのOS /ファームウェア/デバイスを変更して65535を超えるポートで送受信することができると想定すると、バックドアを設置して、たとえばポート70000でリッスンすることは可能でしょうか？
本当の質問はこれだと思います：
TCP/IPスタックをマシン上でローカルに再構築した場合、RFC 793 - Transmission Control Protocol Standardいくつかの回答で以下のように機能しますか？ 65535以上のポートで実行されているサービスにアクセスできないようにします。
ハードウェアとデバイスのバックドアが作成され、政府だけが監視するためのアクセス権を持っているとの話が多かったのですが、これが彼らがそれを実行し、検出と発見を回避する方法の1つであるのかどうか知りたいだけでした。
いいえ、TCPヘッダーのポート番号フィールドは技術的に2バイトに制限されています。（2^16=65536可能なポートを提供します）
より高いポート用により多くのビットを予約することによってプロトコルを変更すると、 TCPセグメント の指定に違反することになり、クライアントには理解されません。つまり、TCP=もう話していないので、「TCP送信元/宛先ポート」のような「ポート」という用語は適用されません。UDPポートにも同じ制限が存在します。
そうは言っても、バックドアはTCPまたはUDPとは異なるプロトコルを介して通信し、通信を不明瞭にする可能性があります。たとえば、 icmpsh はリバースシェルですICMPのみを使用します。最終的には、独自のカスタムトランスポート層プロトコルを実装することもできます raw sockets は、0〜65535より大きな範囲の独自のポートの概念を持つことができます。
いいえ、 TCPフィールドは16ビット長（65536、ただし0から始まる）） 、65535より高いポートを通信することは基本的に不可能です
この投稿には、なぜこれがIPv4でそうであるのか、どのようにIPv6で同じであるのか、そして通常の使用でポートをどのように再利用できるのかについての本当に素晴らしい記事があります。
TCP/IPスタックをマシン上でローカルに再構築した場合、RFC 793-Transmission Control Protocol Standardがいくつかの回答で後述するように機能するため、全体的な概念が機能しませんか？ 65535以上のポートで実行されているサービスにアクセスできなくなります。
65535を超えるポートにはTCP/UDPサービスがありません。2より大きいポート番号をサポートする場合16-1の場合、TCP（またはUDP）ではなくなります。
何か他のものそれはありますか...？承知しました。そしてそれはTCPに非常に似ているのでしょうか？下位互換性のあるポイントまで？はい、両方の質問に。
バックドアが作成されたハードウェアとデバイスについての話が多すぎて、政府だけが監視にもアクセスできるようになりました。これが、彼らがそれを実行し、検出と発見を回避する方法の1つであるかどうかだけ知りましたか？
私がそのようなデバイスを開発した場合、それは目立たなくなるほど一般的なプロトコルに依存することになります。未知の/不正なプロトコルパケットは、その後いくつかの余分なトラフィックが発生し、かなり疑わしいものになります。
（ほとんど）単純な視界に隠れる
このようなデバイスが実行できることは、たとえば、ペイロードのいくつかのバイトを検査することです。通常、これらは非相関値です。次に、ターゲットにパケットを送信できます。または、それがルーターの場合は、IPアドレスがなくても、ランダムで、存在しない可能性のあるホストにも送信できますbeyondターゲットと見せかけ、（たとえば）a HTTPSリクエスト、またはSSHログイン試行。
知らないパケットを見つけた場合、疑わしいかもしれません。しかし、ログで次のようなものを見たとしても
SSH: failed attempt for user maintenance
SSH: failed attempt for user maintenance
SSH: failed attempt for user maintenance
心配する必要はありません特にnoユーザー「メンテナンス」があった場合。おそらく、どこかで、デフォルトのユーザーが「メンテナンス」であるデバイスに対する攻撃を誰かが発見したと想定します（実際、私が政府だった場合、私はmarketこのようなデバイスに脆弱性があり、修正しないでください完全に異なるデバイスでのこのような接続を正当化するという唯一の目的。そのような試みを見たときに最初に何をしますか？何もしない（ "無害なブルートフォース。馬鹿"）、googleおよびshrug （「ああ、私がCheapRouter 2000を持っていると思っている人。馬鹿」は、IPをブロックするファイアウォールルールを作成する可能性があります-パケットがまだ到着する場合を除いてネットワークカードに）。
そして実際に何が起こるかというと、ルーター、ネットワークカード、マザーボードなどの悪質なファームウェアパケットを認識および返答を返すです。これは、「実際の」パケットを上書きする応答パケットを偽造することで可能になります。
非常に悪いことが起こった場合の唯一の症状は、たとえば、悪意のあるルーターからの受信トラフィックと送信トラフィックを比較した場合です。
SSHサーバーを備えたホスト：
--> SSH SYN --> ROUTER --> SSH SYN --> Host
<-- SSH S+A --- ROUTER <-- SSH S+A <-- Host
--> SSH ACK --> ROUTER --> SSH ACK --> Host
...
--> LOGIN ----> ROUTER --> LOGIN ----> Host
<-- FAIL2------ ROUTER <-- FAIL1 <---- Host packets are different!
SSHサーバーなしのホスト：
--> SSH SYN --> ROUTER --> SSH SYN --> Host
<-- SSH S+A --- ROUTER <-- SSH RST <-- Host wait, WTF?
--> SSH ACK --> ROUTER Host
...
--> LOGIN ----> ROUTER Host
<-- FAIL2------ ROUTER Host
侵害されたデバイスの左側または右側のいずれかでケーブルを盗聴した場合、すぐに何も問題がないことに気付くでしょう。
他の疑わしいことは、送信者が明らかに TCP Fast Open 拡張を使用していることです。 TCP/FOがなくてもSYNで追加のデータを送信できることに注意してください。both non-FOであり、妥協のないデバイスでは、データは単に無視されます。
すでに述べたように、ポート番号は符号なし16ビット整数で表され、65535を超えることはできません。
しかし、異なるプロトコルを使用する可能性があります（TCPまたはUDPではありません）。IPヘッダーには、この内部で使用されるトランスポートプロトコルを示す、「プロトコル番号」と呼ばれる8ビットのフィールドがあります。パケット。
ここでトランスポートプロトコルの表を見ることができます： http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
このリストの一部のプロトコルはユーザーに広く使用されています（たとえば、TCPまたはUDP）、まれに（DCCPまたはUDPLite）。一部のプロトコル番号はまだ使用されておらず、一部は非推奨（ARGUS、 EMCON）。
そのため、バックドアは未使用のプロトコル番号を使用してサーバーにデータを送信できます。もちろん、この手法は実装が困難です（rawsocketへのアクセスまたはOSカーネルモジュールとしてのバックドアの実装が必要です）。
ソース： https://www.frozentux.net/iptables-tutorial/iptables-tutorial.html#TCPIPREPETITION
この本当に広範なドキュメントは、TCPを介してインターネット上でビットがどのように割り当てられるかを明確に示しています。送信元ポートと宛先ポートが隣り合って表示されます。
それで、あなたは32ビットのソースポートを作りましたか？ソースポートのインターネットバイト3＆4（下位）に触れるとすぐに、NOPEは宛先で処理されます。
シーケンス番号を一掃する宛先ポート、およびすべてがラインのさらに下にプッシュされます。
これで、シーケンス番号が破壊されたため、宛先はそのシーケンス番号を期待せず、スプーフィングされたパケットのようにドロップします。
この時点を過ぎても、確認番号はシーケンス番号によって破壊され、その番号は無効になっているため、インターネットに関する限り、確認されません。
私はこれを数日間考えました、そして答えは実際にははいかもしれませんが、奇妙な方法であると思います。
他の多くの回答が指摘しているように、TCPはポート番号が16ビットであると述べています。その16の1と0。これには65535の繰り返し可能なポートの制限があります。残りの例では、私は怠惰なので4ビットを使用します。
したがって、4ビットで15個のポートを表すことができます。
劇場用バックドアは、不正なTCPパケットの処理方法に依存する必要があります。したがって（16ビットではなく4ビットを覚えてください）。ポート17でトラフィックを送信します。
ヘッダーは10001として不正な形式になります。TCPスタックは、不正なヘッダーを取得した場合、別のロジックパスをたどり、データを「右端」の4ビットのポートに接続することを示します。この場合、ポート1または0001です。本当のトリックは、TCPがビット数を使用するだけです。 [port] 10001 [/ port]があるxmlとは異なります。したがって、ポートヘッダーのオーバーフローを検出する方法が必要になります。 SYNはポートのすぐ隣にあるため、そうすることができます。SYNが正確に「1073741823」の場合、宛先ポートが1つ大きくなります。
この異なる論理パスは、接続がポート1でアクティブである間、アクティブのままである可能性があります。
このようにして、不正なパケットを受け入れ、それらに対して特別な処理を行うTCPバックドアをどこかに置くことができます。本当の問題は、特別なTCPスタックだけがそれらを理解できないことです。ルーター、スマートスイッチ、理論的には一部のNICカードはパケットの形式が正しくないため、パケットをドロップします。パケットがその不正なヘッダーを持つ宛先に到達するかどうかを判断する方法はほとんどありません。
ただし、不安定なTCPスタックを使用して2つのデバイスを「ダム」スイッチまたはハブに接続した場合。理論的には、これを機能させることができますが、これはTCP仕様には含まれません。
これは実現可能ですが、UDPやTCPなどのプロトコルは最大ポートが65535であるため使用できません。
IPプロトコルの上に独自のプロトコルを実装する必要があります。
これは、生のソケットを使用して可能になる場合があります。
バックドアが作成されたハードウェアとデバイスについての多くの話があり、政府だけが監視にもアクセスできるようになりました。これが、彼らがそれを実行し、検出と発見を回避する方法の1つであるかどうかに興味がありましたか？
ネットワークを通過するパケットを見ることができるので、これが接続をよりステルスにするのに役立つとは思いません。
誰もがTCP/IPパケットに関してそれを説明しました：ポートフィールドはたった16ビット長です。
しかし、Linuxカーネルのソースコードとそれがどのようにポートを処理するかはどうでしょうか。 Linuxカーネルのあらゆる場所で、TCP/IPポートの場合、常に「短い」、つまり16ビットとしてキャストされます。また、x86アセンブリにコンパイルされると、16ビットバージョンの命令が16ビットデータの処理に使用されます。
そして、あなたがIPv6について疑問に思っているなら、それはIPv4と同じです-TCPとUDPについてのすべて。
https://stackoverflow.com/questions/186829/how-do-ports-work-with-ipv6
しかしもちろん、通信にTWOサーバーを使用するような奇妙な通信をセットアップすることもできます。それぞれに個別の16ビットポートがあり、それらを組み合わせると仮想32ビットポートができます。しかし、全世界だけが2つのサーバーと通信する方法を知っています。たとえば、データを半分に分割して2つのサーバー間で分割し、クライアント側で再構築します。
16ビットより長くすることはほとんど不可能のようでした。