Haftungsausschluss : Ich arbeite nicht und habe nicht bei McAfee (oder Intel) gearbeitet. Ich habe keine Sicherheitsüberprüfungen für McAfee-Produkte durchgeführt.
Befunde und Hypothese
Was Sie sehen, ist, dass ARP aus unbekannten Gründen über UDP gesendet wird . Ich würde sagen, der Verkehr ist verdächtig . Zumindest ist es verdächtig genug, dass Sie danach fragen .
Meine erste Hypothese war, dass dies eine Art VPN war. Hast du ein VPN? Wenn ein lokales Netzwerk tatsächlich über das Internet funktioniert, kann eine VPN-Implementierung, die ARP über UDP sendet, sinnvoll sein.
Auswahl des Anschlusses 2054 für ARP Art macht Sinn, weil die EtherType für ARP ist 2054 (0806 16 ).
Meine zweite Hypothese ist, dass McAfee dies als eine Art Doppelprüfung für ARP oder als Versuch verwendet, ARP-Spoofing zu beheben. Ich habe keine Dokumentation gefunden, in der McAfee den UDP-Port 2054 benötigt . Wir können also sagen, dass dies kein erwartetes Verhalten ist . Ich frage mich, ob dies Sicherheit durch Unklarheit ist, ich hoffe es nicht .
Selbst wenn die zweite Hypothese richtig ist, könnte dies ein Symptom für ein anderes Problem sein.
Meine dritte Hypothese wäre ein kompromittierter McAfee, doch ich weiß nicht, warum eine Malware, die McAfee gefährden kann, diese Art von Datenverkehr sendet ...
... Außer vielleicht, es wurde von einem Entwickler gemacht, der den Unterschied zwischen einem EtherType und einem Port nicht verstand (einige lose geschriebene Dokumentation und Tools beziehen sich auf EtherType als Ethernet-Frame-Ports - Beispiel ).
Beachten Sie auch, dass es Tools gibt, die die Erstellung von Malware vereinfachen, indem der Benutzer von Malicius die Möglichkeit hat, eine Payload auszuwählen und diese automatisch in den Code einzubinden, der für die Verbreitung und Infektion benötigt wird.
Meine vierte und letzte Hypothese besagt, dass dies ein Fehler in McAfee ist, der hoffentlich in einer neueren Version behoben wurde.
Untersuchen
- Gibt es eine Software, die den UDP-Port 2054 auf den anderen Computern überwacht? Welche Software ist das?
- Hört McAfee auf dem Sendercomputer auch den UDP-Port 2054?
- Bekommt McAfee jemals eine Antwort? Wie sieht die Antwort aus?
Ich empfehle, Wireshark auf dem Computer mit McAfee und einem anderen Computer auszuführen und zu erfassen, welche Pakete sie austauschen.
Unter der Hypothese, dass dies ein Fehler in McAfee ist oder ein Kompromiss eingegangen wurde, schlage ich vor, dass Windows und McAfee auf dem neuesten Stand und in einwandfreiem Zustand sind ( sfc /scannow
für Windows ausführbare digitale Signaturen für McAfee - ich nehme an, sie haben, sie haben es besser.) von einer Sicherheitsfirma sein).
Möglicherweise sind Sie auch an der Verwendung von Autoruns und Procexp von Sysinternals Suite zur Überprüfung von Signaturen und zum Senden von Beispielen an VirusTotal der Software beim Start (Autoruns) und an der Ausführung (Procexp) interessiert. Pro-Tipp : Sie können Autoruns über das Mini-Windows von Hirens BootCD ausführen und es anweisen, ein Offline-System zu analysieren, um sicherzustellen, dass Autoruns nicht durch die Malware gefährdet wurden.
Wenn Sie der Meinung sind, dass eine Malware den Computer gefährdet hat, sollten Sie eine Rettungs-ISO oder eine USB-Antimalwarelösung verwenden, da diese für die Malware praktisch unmöglich ist.
Ich hoffe, dass Sie kein reinigendes Feuer beschwören müssen .
Präzedenzfälle
Ich habe einen anderen Fall von UDP-Port 2054 im TechSupportforum gefunden . In diesem Fall war die Lösung offenbar eine reinigende Neuinstallation von Windows.
Ich habe auch Probleme mit anderen Ports gefunden ( hier und hier ).
Analyse der Verkehrserfassung
Ich habe mir die Capture angesehen, die Sie teilen. Das war mein Arbeitsprozess:
Wenn Sie tatsächlich ein UDP-Datagramm erfasst haben, das an den Port 2054 gesendet wurde, muss der Zielport das Capture sein. 2054 in hex ist 0806, und sicher ist es dort in der Mitte der zweiten Zeile.
Deshalb haben wir:
/* ... data ... */ 0806 Destination Port (2054) /* ... data ... */
Betrachten wir nun den UDP-Header :
/* ... data ... */ /* UDP start */ d13b Source Port (53563) 0806 Destination Port (2054) 0024 Length (36 bytes) ba22 Checksum /* ... data ... */
Ich habe die Prüfsumme nicht überprüft. Ich habe die Länge überprüft (die vom Anfang des UDP-Headers bis zum Ende geht) und ist korrekt.
Dies muss in einem IP-Paket sein. Also lassen Sie uns den IP-Header bekommen :
/* 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 ... */
Wir sehen, dass 10.20.30.1 ein UDP-Datagramm an 10.20.30.254 sendet. Nichts Außergewöhnliches. Wieder habe ich die Länge überprüft, aber nicht die Checksumme.
Was ist mit den restlichen Daten? Das ließ mich ein wenig erraten. Welches Protokoll sendet eine MAC? Nun, das wäre ARP, aber ARP läuft nicht auf UPD, richtig?
Nun, ARP stimmt überein:
/* 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 sollte direkt auf dem Frame ausgeführt werden, genauso wie IP ausgeführt wird . Stattdessen läuft ARP auf UDP (das auf IP ausgeführt wird).
Wenn wir uns jedoch nur die ARP-Anfrage ansehen, was macht sie dann? Es scheint 10.20.30.254 nach seinem MAC zu fragen. Außer, wissen Sie, es wird über UDP gefragt.