Отказ от ответственности: я не работаю и не работал в McAfee (или Intel в этом отношении). Я не проводил аудит безопасности продуктов McAfee.
Выводы и гипотезы
Вы видите, что ARP отправляется по UDP по неизвестным причинам. Я бы сказал, что движение подозрительно. По крайней мере, это достаточно подозрительно, что вы спрашиваете об этом.
Моей первой гипотезой было то, что это был своего рода VPN. У вас есть VPN? Если то, что выглядит как локальная сеть, на самом деле работает через Интернет, может иметь смысл реализация VPN, которая отправляет ARP через UDP.
Выбор порта 2054 для ARP вид имеет смысл, потому что EtherType для ARP является 2054 (0806 16).
Моя вторая гипотеза заключается в том, что McAfee использует это как некоторую форму двойной проверки ARP или как попытку исправить спуфинг ARP. Я не нашел документации по McAfee, которому нужен UDP-порт 2054. Таким образом, мы можем сказать, что это не ожидаемое поведение. Интересно, если это безопасность по неизвестности, я надеюсь, что это не так.
Даже если вторая гипотеза верна, это может быть признаком другой проблемы.
Моей третьей гипотезой будет скомпрометированный McAfee, но я не знаю, почему вредоносная программа, которая может скомпрометировать McAfee, будет отправлять такой трафик ...
... За исключением, возможно, это было сделано разработчиком, который не понимал разницу между EtherType и портом (некоторые свободно написанные документация и инструменты называют EtherType как порты Ethernet - пример).
Также обратите внимание, что существуют инструменты, которые облегчают создание вредоносных программ, позволяя пользователю malicius выбирать полезную нагрузку и автоматически включать ее в код, необходимый для распространения и заражения.
Моя четвертая и последняя гипотеза заключается в том, что это ошибка в McAfee, которую, я надеюсь, они исправили в более новой версии.
расследовать
- Есть ли программное обеспечение, прослушивающее UDP-порт 2054 на других машинах? Какое программное обеспечение это?
- McAfee на отправляющем компьютере также прослушивает UDP-порт 2054?
- McAfee когда-нибудь получает ответ? Как выглядит ответ?
Я предлагаю запустить Wireshark на компьютере с McAfee и другой машиной и перехватить пакеты, которыми они обмениваются.
Исходя из предположения, что это ошибка в McAfee или она была скомпрометирована, я предлагаю убедиться, что Windows и McAfee обновлены и находятся в хорошем состоянии (sfc /scannow для Windows, исполняемые цифровые подписи для McAfee - полагаю, они есть, они лучше иметь, будучи из охранной компании).
Вы также можете быть заинтересованы в использовании Autoruns и Procexp из Sysinternals Suite для проверки подписей и отправки образцов VirusTotal программного обеспечения при запуске (Autoruns) и при выполнении (Procexp). Совет для профессионалов: вы можете запускать автозапуск из Mini Windows, входящей в BootCD Hiren, и предлагать ему анализировать автономную систему, гарантируя, что автозапуск не был скомпрометирован вредоносным ПО.
Если вы считаете, что у вас есть вредоносная программа, скомпрометировавшая компьютер, рассмотрите возможность использования аварийного ISO или загрузочного USB-решения для защиты от вредоносных программ, поскольку их практически невозможно скомпрометировать для вредоносной программы.
Я надеюсь, что вам не нужно вызывать очищающий огонь.
Прецеденты
Я обнаружил еще один случай с портом UDP 2054 на сайте техподдержки. В этом случае, очевидно, решение было очистить огонь переустановки Windows.
Я также обнаружил случаи проблем с другими портами (здесь и здесь).
Анализ захвата трафика
Я посмотрел на снимок, которым вы делитесь. Это был мой рабочий процесс:
Если вы фактически перехватили UDP-дейтаграмму, отправленную на порт 2054, порт назначения должен быть перехвачен. 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 отправляет дейтаграмму UDP на 10.20.30.254. Ничего фантастического. Я снова проверил длину, но не контрольную сумму.
Как насчет остальных данных? Это заняло у меня немного догадок. Какой протокол отправляет 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. Вместо этого это ARP, работающий поверх UDP (который работает поверх IP).
Однако, если мы посмотрим только на запрос ARP, что он делает? Кажется, он просит 10.20.30.254 его MAC. За исключением, вы знаете, это спрашивает через UDP.
