McAfee 在 UDP 連接埠 2054 上傳送流量:這是預期行為嗎?

McAfee 在 UDP 連接埠 2054 上傳送流量:這是預期行為嗎?

今天我注意到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發送資料包的進程監視器:

Process Monitor 的螢幕截圖顯示 McSvHost.exe 傳送 UDP 流量

我的問題是——

  • 這是預期的行為,還是我該懷疑?和
  • 如果它預期行為,McAfee 想要做什麼?我檢查過,我的電腦上沒有任何內容正在偵聽 UDP 連接埠 2054。

我嘗試聯絡 McAfee 支持,但我很難讓支持代理理解我的問題。

答案1

免責聲明:我不工作,也沒有在麥克菲(或英特爾)工作過。我尚未對 McAfee 產品進行安全審核。


研究結果和假設

您看到的是 ARP 透過 UDP 發送,原因未知。我會說交通是可疑的至少,你問這個問題就夠可疑了


我的第一個假設是這是某種 VPN。你有VPN嗎?如果看似本地網路的網路實際上透過 Internet 運行,則透過 UDP 發送 ARP 的 VPN 實作可能有意義。

選擇 ARP 連接埠 2054有點兒有道理,因為以太類型ARP 為 2054 (0806 16 )。


我的第二個假設是 McAfee 使用此作為某種形式的 ARP 雙重檢查,或嘗試修復 ARP 欺騙。我已經發現沒有有關需要 UDP 連接埠 2054 的 McAfee 的文檔。因此我們可以說這不是預期的行為我想知道這是否是默默無聞的安全,我希望不是

即使第二個假設是正確的,它也可能是另一個問題的症狀。


我的第三個假設是麥克菲遭到破壞,但是,我不知道為什麼能夠破壞麥克菲的惡意軟體會發送這種流量...

……也許,它是由不了解 EtherType 和連接埠之間差異的開發人員完成的(一些鬆散編寫的文檔和工具將 EtherType 稱為乙太網路幀連接埠 -例子)。

另請注意,有些工具可以透過允許惡意使用者選擇有效負載並將其自動包裝在傳播和感染所需的程式碼中來輕鬆建立惡意軟體。


我的第四個也是最後一個假設是,這是 McAfee 中的一個錯誤,我希望他們在新版本中修復該錯誤。


調查

  • 其他機器上有沒有監聽UDP 2054埠的軟體?它是哪個軟體?
  • 發送方電腦上的 McAfee 是否也在偵聽 UDP 連接埠 2054?
  • 麥克菲收到回覆了嗎?回覆看起來怎麼樣?

我建議跑Wireshark在裝有 McAfee 的電腦和另一台電腦上,擷取它們交換的資料包。


假設這是 McAfee 中的錯誤或已洩露,我建議驗證 Windows 和 McAfee 是否是最新的且完整性良好(sfc /scannow對於 Windows,McAfee 的可執行數位簽名 - 我認為他們有,他們最好有,來自保安公司)。

您可能也對使用 Autoruns 和 Procexp 感興趣系統內部套件驗證簽名並將樣本發送至病毒總數軟體在啟動時 (Autoruns) 和執行時 (Procexp) 的情況。專家提示:您可以從自帶的 Mini Windows 執行 AutorunsHiren 的 BootCD並告訴它分析離線系統,確保 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(運行在 IP 之上)之上的 ARP。

但是,如果我們只看ARP請求,它在做什麼呢?它似乎正在向 10.20.30.254 詢問其 MAC。除了,你知道,它是透過 UDP 請求的。

答案2

我發現罪魁禍首是麥克菲的家庭網路程序,它是防毒+套件的一部分。它會對應出您的裝置所在的網絡,以識別其他網路裝置。它似乎會探測設備的漏洞,以保護整個家庭網路。我用我妻子的 Windows 10 PC 購買了訂閱,但不知道這是其中一個模組。我使用 Mac,昨晚在控制台中看到了 udp 嘗試,每分鐘都會出現一次。您的貼文縮小了要查看的服務範圍。我停止了 Windows 10 服務應用程式和 viola 的服務!不再有控制台訊息。我重新啟動後幾分鐘它們就出現了。哇。我現在有新的安全應用程式需要學習!謝謝!

答案3

如果在防火牆下網路設定為家庭,那麼我認為它正在嘗試識別網路上需要保護的其他設備。嘗試使用防火牆網絡連接並更改為工作網絡,我認為這些可能會停止?

抱歉 - 我知道有點老了,但當我看到同樣的問題時我發現了你的帖子。

相關內容