McAfee отправляет трафик на UDP-порт 2054: ожидаемо ли это поведение?

Question 1

Отказ от ответственности: Я не работаю и не работал в McAfee (или Intel, если на то пошло). Я не проводил аудит безопасности продуктов McAfee.

Выводы и гипотезы

То, что вы видите, это ARP, отправляемый по UDP по неизвестным причинам.. Я бы сказал, что трафикподозрительный.По крайней мере, это достаточно подозрительно, что вы об этом спрашиваете..

Моя первая гипотеза была, что это какой-то VPN. У вас есть VPN? Если то, что выглядит как локальная сеть, на самом деле работает через Интернет, реализация VPN, которая отправляет ARP через UDP, может иметь смысл.

Выбор порта 2054 для ARPвродеимеет смысл, потому чтоEtherTypeдля ARP — 2054 (0806 ₁₆ ).

Моя вторая гипотеза заключается в том, что McAfee использует это как некую форму двойной проверки для ARP или как попытку исправить подмену ARP. Я обнаружилнет документации по McAfee, требующей UDP-порт 2054. Таким образом, мы можем сказать,это не ожидаемое поведение.Интересно, это ли безопасность через неизвестность? Надеюсь, это не так..

Даже если вторая гипотеза верна, это может быть симптомом другой проблемы.

Моя третья гипотеза — это скомпрометированный McAfee, но я не знаю, почему вредоносная программа, способная скомпрометировать McAfee, отправляет такой трафик...

... За исключением, возможно, того, что это было сделано разработчиком, который не понимал разницы между EtherType и Port (некоторые вольно написанные документы и инструменты называют EtherType портами Ethernet-фрейма -пример).

Также обратите внимание, что существуют инструменты, которые упрощают создание вредоносного ПО, позволяя пользователю-злоумышленнику выбирать полезную нагрузку и автоматически оборачивая ее кодом, необходимым для распространения и заражения.

Моя четвертая и последняя гипотеза заключается в том, что это ошибка в McAfee, которую, я надеюсь, они исправили в новой версии.

Расследовать

Есть ли на других машинах программное обеспечение, прослушивающее UDP-порт 2054? Какое это программное обеспечение?
Прослушивает ли McAfee на компьютере отправителя также UDP-порт 2054?
Получает ли McAfee ответ? Как выглядит ответ?

Я предлагаю бежатьWiresharkна машине с McAfee и на другой машине и перехватите пакеты, которыми они обмениваются.

Предполагая, что это ошибка в McAfee или она была скомпрометирована, я предлагаю проверить, обновлены ли Windows и McAfee и находятся ли они в хорошем состоянии ( sfc /scannowдля Windows это исполняемые цифровые подписи McAfee — я предполагаю, что они есть, и лучше бы они были, поскольку они от компании, занимающейся безопасностью).

Вас также может заинтересовать использование Autoruns и Procexp изSysinternals Suiteдля проверки подписей и отправки образцовVirusTotalпрограммного обеспечения при запуске (Autoruns) и во время выполнения (Procexp).Совет профессионала: Вы можете запустить Autoruns из Mini Windows, которая идет в комплектеHiren's BootCDи дать ему команду проанализировать автономную систему, чтобы убедиться, что Autoruns не был скомпрометирован вредоносным ПО.

Если вы считаете, что ваш компьютер заражен вредоносным ПО, рассмотрите возможность использования загрузочного образа ISO или антивирусного решения USB, поскольку их практически невозможно взломать вредоносным ПО.

Надеюсь, тебе не придется призывать очищающий огонь..

Прецеденты

Я нашел еще одинслучай UDP Port 2054 на techsupportforum. В этом случае, по-видимому, решением был ~~очистительный огонь~~ переустановки 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, верно?

Хорошо,АРПсовпадения:

/* 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.

Answer