我希望你的帮助。 我的 cloudWatch 示例如下。
image capture: ssh connection logs with 172.0.0.10
如您所见，cloudWatch 正在记录请求和响应数据包。 在这种情况下，每个人都知道显示 22 作为目的端口的数据包是响应数据包，因为端口 22 是众所周知的 ssh 服务器端口。
但是，如果它不是众所周知的端口号，您将无法区分请求和响应数据包。在这种情况下你如何区分它？单独的 cloudwatch 日志并没有告诉我如何。无论我如何谷歌它，我都找不到方法。请指教。
【问题讨论】：
标签： amazon-web-services amazon-cloudwatch
在这种情况下，每个人都知道显示 22 作为目标端口的数据包是响应数据包，因为端口 22 是众所周知的 ssh 服务器端口。
这实际上是不正确的。恰恰相反。
TCP 连接的服务器端使用的是众所周知的端口，而不是客户端¹，因此众所周知的端口是请求的目的地和响应的来源。
source 端口为 22 的数据包将是 SSH“响应”（服务器 → 客户端）数据包。 destination 端口为 22 的端口将是 SSH“请求”（客户端 → 服务器）数据包。
当我向 Web 服务器发出请求时，我的源端口是临时的，但目标端口是 80。响应来自源端口 80。
当然，可以说“请求”和“响应”这两个术语不适用于数据包， 而是它们适用于数据包包含的内容——这是特定于协议的。在许多情况下，客户端进行请求，服务器进行响应，但这种相关性并没有清晰地映射到协议栈的低层。
在 TCP 的情况下，一方总是在侦听连接，通常在一个特定的端口上，并且该端口通常是你知道的，如果不是“众所周知”的端口，因为你是创建服务并将其配置为在那里侦听。
由于这些流日志记录没有捕获识别 SYN...SYN+ACK...ACK 序列的源和目标所需的标志，因此您无法确定是谁发起了连接。
在不知道“端口 22”的众所周知性或其他意义的情况下，仍然很容易从您的日志中得出结论，即 172.0.0.10 有一个 TCP 套接字在该端口上侦听，并且还有许多其他客户端正在从他们的临时端口连接到它......我们可以通过在该机器上运行 netstat -tln 来确认它仍在监听。
¹ 大多数时候不是客户。在某些情况下，服务器守护程序也是客户端，并将使用众所周知的端口作为其传出连接的源端口，因此在这种情况下，源和目标可能相同。我相信 Sendmail 可能是一个例子，至少在某些情况下，但这些是例外。
【讨论】：