私はあなたの助けを願っています。 私のcloudWatchの例は以下の通りです。aws cloudWatchログで要求パケットと応答パケットを区別する方法は？
image capture: ssh connection logs with 172.0.0.10
ご覧のとおり、CloudWatchのは、要求と応答パケットの両方を記録しています。 この場合、宛先ポートとして22を表示しているパケットは、ポート22がよく知られているsshサーバポートであるため、応答パケットであることがわかります。
ただし、既知のポート番号でない場合は、要求パケットと応答パケットを区別できません。あなたはそれをどのように区別しますか？クラウドウォッチログだけでは私にはわかりません。どのように私はそれをGoogleに関係なく、私は方法を見つけることができません。お知らせ下さい。
この場合、宛先ポートとして22を表示しているパケットは、ポート22がよく知られているsshサーバポートであるため、応答パケットであることを誰もが知っています。
これは実際には正しくありません。それは逆です。
TCP接続のサーバー側は、クライアントではなく、既知のポートを使用しています。したがって、既知のポートは要求の宛先と応答元です。
ソースのポートを持つパケットは、SSHの "応答"（サーバー→クライアント）パケットになります。 の宛先ポートが22のポートは、SSHの「要求」（クライアント→サーバ）パケットになります。
私は、Webサーバに要求を行う、私のソースポートは短命ですが、宛先ポートが80応答が送信元ポート80
しかし、もちろん、引数を作ることができるから来ているという用語」 「要求」と「応答」はパケットに正しく適用されません。 しかし、パケットはパケットに含まれています。多くの場合、クライアントは要求を行い、サーバは応答を行いますが、その相関関係はプロトコルスタックの下位レイヤに完全にマッピングされません。
TCPの場合、一方の側は常に特定のポートで常に接続をリスンしており、そのポートは「よく知られている」ポートではないにしても通常はあなたに知られています。それを聞いて設定しました。
これらのフローログレコードは、SYN ... SYN + ACK ... ACKシーケンスの送信元と宛先を識別するために必要なフラグを取得しないため、誰が接続を開始したのかを確認できません。
よく知られている「ポート22」の重要性を知らなくても、ログから172.0.0.10がそのポートでリッスンするTCPソケットを持っていると結論付けるのは簡単です。クライアントは一時的なポートからそのクライアントに接続しています...そして、そのマシンでnetstat -tlnを実行することによって、これがまだリッスンしていることを確認できます。
¹ ないクライアントほとんどの時間。サーバデーモンがクライアントでもあり、よく知られているポートを発信接続の送信元ポートとして使用するため、sourceとdestは同じ場合があります。私は、少なくともいくつかのケースでは、Sendmailがその一例かもしれないと信じていますが、これは例外です。
