McAfee 在 UDP 端口 2054 上发送流量：这是预期的行为吗？
Flu*_*lup 6 networking windows-10
我今天注意到McSvHost.exe（在 Windows 10 上运行的 McAfee LiveSafe 的一部分）正在通过 UDP 端口 2054 向我网络上的每个主机发送流量。
这是数据包的样子（带Xs的部分实际上是发送方的 MAC 地址）：
0x0000: 4500 0038 16c5 0000 8011 d2c9 0a14 1e01 E..8............
0x0010: 0a14 1efe d13b 0806 0024 ba22 0001 0800 .....;...$."....
0x0020: 0604 0001 XXXX XXXX XXXX 0a14 1e01 ffff ........V[......
0x0030: ffff ffff 0a14 1efe ........
...这是显示McSvHost.exe发送数据包的进程监视器：
我的问题是——
- 这是预期的行为，还是我应该怀疑？和
- 如果这是预期行为，McAfee 试图做什么？我已经检查过，我的电脑上没有任何东西在监听 UDP 端口 2054。
我曾尝试联系 McAfee 支持，但我很难让支持代理理解我的问题。
免责声明：我不工作，也没有在迈克菲（或英特尔）工作过。我没有对 McAfee 产品进行安全审计。
发现和假设
您看到的是 ARP 由于未知原因通过 UDP 发送。我会说交通是可疑的。至少，你问这件事已经够可疑了。
我的第一个假设是，这是某种 VPN。你有VPN吗？如果看起来像本地网络的东西实际上是通过 Internet 工作的，那么通过 UDP 发送 ARP 的 VPN 实现可能是有意义的。
选择端口2054 ARP种是有道理的，因为以太网类型为ARP是2054（0806 16）。
我的第二个假设是 McAfee 将此用作某种形式的 ARP 双重检查，或尝试修复 ARP 欺骗。我没有发现有关需要 UDP 端口 2054 的 McAfee 的文档。因此我们可以说这不是预期的行为。我想知道这是否是默默无闻的安全，我希望不是。
即使第二个假设是正确的，它也可能是另一个问题的征兆。
我的第三个假设是被入侵的 McAfee，但是，我不知道为什么可以入侵 McAfee 的恶意软件会发送这种流量......
...除了，也许，它是由不了解 EtherType 和端口之间区别的开发人员完成的（一些编写松散的文档和工具将 EtherType 称为以太网帧端口 -示例）。
另请注意，有一些工具可以通过允许恶意软件用户选择有效负载并自动将其包装在传播和感染所需的代码中来简化恶意软件的创建。
我的第四个也是最后一个假设是，这是 McAfee 中的一个错误，我希望他们在新版本中修复。
调查
- 是否有软件侦听其他机器上的 UDP 端口 2054？是哪个软件？
- 发件人计算机上的 McAfee 是否也在侦听 UDP 端口 2054？
- 迈克菲会收到回复吗？回复看起来如何？
我建议在装有 McAfee 的机器和另一台机器上运行Wireshark，并捕获它们交换的数据包。
假设这是 McAfee 中的错误或已被入侵，我建议验证 Windows 和 McAfee 是最新的并且具有良好的完整性（sfc /scannow对于 Windows，McAfee 的可执行数字签名 - 我认为他们有，他们最好有，来自一家安全公司）。
您可能还对使用Sysinternals Suite 中的Autoruns 和 Procexp来验证签名并将样本发送到软件启动 (Autoruns) 和执行中 (Procexp) 的VirusTotal感兴趣。专业提示：您可以从Hiren 的 BootCD 中的 Mini Windows 运行 Autoruns，并告诉它分析离线系统，确保 Autoruns 不会受到恶意软件的影响。
如果您认为自己的恶意软件已经入侵了机器，请考虑使用救援 ISO 或引导 USB 反恶意软件解决方案，因为这些几乎不可能被恶意软件入侵。
我希望你不需要召唤净化之火。
先例
我在 techsupportforum 上发现了另一个UDP 端口 2054 的案例。在那种情况下，显然解决方案是净化火重新安装 Windows。
流量捕获分析
我看了你分享的截图。这是我的工作流程：
如果您实际捕获了发送到端口 2054 的 UDP 数据报，则目标端口必须是捕获的端口。十六进制的 2054 是 0806，果然，它在第二行的中间。
因此，我们有：
/* ... data ... */
0806 Destination Port (2054)
/* ... data ... */
现在，查看UDP 标头，我们有：
/* ... data ... */
/* UDP start */
d13b Source Port (53563)
0806 Destination Port (2054)
0024 Length (36 bytes)
ba22 Checksum
/* ... data ... */
我没有验证校验和。我确实验证了长度（从 UDP 标头的开头到结尾）并且它是正确的。
这必须在 IP 数据包中。因此，让我们获取IP 标头：
/* IP start */
4500 Version (IPv4) IHL (20 bytes) Differentiated Services (Default Forwarding)
0038 Total length (56 bytes)
16c5 Identification
0000 Flags & Fragment offset (unique fragment)
8011 TTL (128 hops) Protocol (UDP)
d2c9 Header checksum
0a14 \
1e01 -> Source IP address (10.20.30.1)
0a14 \
1efe -> Destination IP address (10.20.30.254)
/* UDP start */
d13b Source Port (53563)
0806 Destination Port (2054)
0024 Length (36 bytes)
ba22 Checksum
/* ... data ... */
我们看到 10.20.30.1 正在向 10.20.30.254 发送 UDP 数据报。没有什么花哨。再次，我检查了长度，但没有检查校验和。
剩下的数据呢？这让我有点猜测。什么协议发送MAC？嗯，那就是 ARP，但 ARP 不在 UPD 之上运行，对吗？
嗯，ARP匹配：
/* IP start */
4500 Version (IPv4) IHL (20 bytes) Differentiated Services (Default Forwarding)
0038 Total length (56 bytes)
16c5 Identification
0000 Flags & Fragment offset (unique fragment)
8011 TTL (128 hops) Protocol (UDP)
d2c9 Header checksum
0a14 \
1e01 -> Source IP address (10.20.30.1)
0a14 \
1efe -> Destination IP address (10.20.30.254)
/* UDP start */
d13b Source Port (53563)
0806 Destination Port (2054)
0024 Length (36 bytes)
ba22 Checksum
/* ARP start */
0001 Hardware Type (Ethernet)
0800 Protocol type (IPv4)
0604 Hardware length (6 bytes, MAC) Protocol length (4 bytes, IPv4)
0001 Operation (Request)
XXXX \
XXXX -> Sender hardware address (sender's MAC address)
XXXX /
0a14 \
1e01 -> Sender protocol address (10.20.30.1)
ffff \
ffff -> Target hardware address (ignored in Operation = Request)
ffff /
0a14 \
1efe -> Target protocol address (10.20.30.254)
ARP 应该直接在框架顶部运行，与 IP 运行的方式相同。相反，它是运行在 UDP 之上的 ARP（运行在 IP 之上）。
但是，如果我们只看 ARP 请求，它在做什么？它的 MAC 似乎要求 10.20.30.254。除了，你知道，它是通过 UDP 询问的。
小智 0
如果在防火墙下网络设置为家庭，那么我认为它正在尝试识别网络上需要保护的其他设备。尝试使用防火墙网络连接并更改为工作网络，我认为这些可能会停止？
抱歉 - 我知道有点老了，但当我看到同样的问题时我发现了你的帖子。
| 归档时间： |
|
| 查看次数： |
4815 次 |
| 最近记录： |