Kaspersky
Question

Kaspersky Security Center 13, массовое событие "Mac Spoofing Attack: unexpected ARP response"

  • 19 October 2021
  • 5 replies
  • 454 views

  • Theorist
  • 16 replies

Здравствуйте.
Сервер под управлением Kaspersky Security Center 13.0.0.11247
Версия Kaspersky Endpoint Security для Windows 11.6.0.394
Агент администрирования 13.0.0.11247

Обнаружил в критических событиях сервера большое количество событий вида:
Обнаружена сетевая атака
Пользователь: %PCNAME%\Администратор (Активный пользователь) (
либо NT AUTHORITY\СИСТЕМА (Системный пользователь))
Компонент: Защита от сетевых угроз
Описание результата: Запрещено
Название: Mac Spoofing Attack: unexpected ARP response
Объект: ARP от неожиданного источника
Тип объекта: Сетевой пакет
Название объекта: ARP от неожиданного источника
Дополнительно:  
Подозрительный: 19.10.2021 18:08:05: %MAC-адрес% -> %один из локальных IP-адресов%
Дата выпуска баз: 19.10.2021 12:14:00

События отображаются на разных узлах сети - и рабочих станциях и серверах. Запросы могут блокироваться как с таких же рабочих станций под управлением антивируса, либо с других устройств - сетевых принтеров, роутеров, МФУ, мобильных устройств. Несоответствия MAC-адресов между теми, что в логах и реальными на устройствах не выявил. Повторяющихся MAC-адресов в списке по команде arp -a не нашел.

Бывают так же события с отклоненными запросами от внешних IP-адресов www.arin.net с "битыми" MAC-адресами. Например:

Подозрительный: 19.10.2021 18:07:41: 2-50-73-3f-95-6a -> 26.25.162.243 (в первом поле один символ отсутствует). Есть так же адреса 26.194.245.41, 26.206.118.185
 

Событие появилось примерно 20 сентября, где-то в это же время массово появились события "Серверы KSN недоступны".
На всякий случай посмотрел в события в других офисах - там похожая ситуация, много сообщений "Серверы KSN недоступны", есть сообщения про ARP spoofing. Точно так же поддельных MAC`ов не выявил и так же есть ссылки на адреса от www.arin.net. Офисы между собой никак не связаны.

Выполнил обновление в на площадке, где изначально обнаружил проблему до KSC 13.2, начал на хостах обновлять агент до 13.2.0.1511, установил октябрьское обновление Windows на сервер управления (Windows Server 2016). После перезагрузки сервера пока было только одно сообщение ARP spoofing от одного хоста через несколько минут и пока тишина почти полтора часа, но подобные промежутки и раньше бывали. Буду дальше мониторить.

Это какой-то глюк KSC 13 или какая-то массовая атака?


5 replies

По состоянию на текущий момент удалось выяснить, что сообщения о MAC Spoofing атаках появляются от беспроводных клиентов- мобильных устройств и ноутбуков, подключенных по WiFi, на которых так же установлен антивирус. Несоответствия в MAC-адресах не нашел. Т.е. те запросы, которые блокирует антивирус происходят от реальных MAC-адресов. Иногда появляются записи с “неполным” MAC, как уже писал выше, когда один из символов в одном из полей отсутствует, но при этом значения в остальных полях сходятся.

Есть так же второй тип сообщений о MAC Spoofing при обращении к внешним IP-адресам, которые оказались адресами сервиса Radmin-VPN, который соответственно стоит на компьютерах, где появляются эти сообщения.

Очевидно, события об атаках появляются, когда пакеты доходят не полностью, что возможно при подключении по беспроводной сети, а так же подключении по RadminVPN.

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

И почему это началось 19-20 сентября, а до этой даты этих сообщений не было?

Так же очень настораживает наличие запросов от мобильных устройств к рабочим станциям и серверу управления, но это скорее к вопросу организации гостевого WiFi, который давно уже стоит на повестке.

Userlevel 2
Badge +1

Тоже столкнулся с такой бедой на ровном месте…

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

 

Не знаю, что могло послужить причиной, но нервишек потрепало.

 

Так задавать в исключения полностью рабочую подсеть не совсем правильно же.

Тогда получается, что если кто-то реально захочет подменить MAC-адрес какого-нибудь устройства в  вашей локальной сети, вы этого не увидите.

Userlevel 2
Badge +1

Так задавать в исключения полностью рабочую подсеть не совсем правильно же.

Тогда получается, что если кто-то реально захочет подменить MAC-адрес какого-нибудь устройства в  вашей локальной сети, вы этого не увидите.

Как говориться, тут уж выбираешь меньшую из зол - упавшая локалка это паралич всей организации.

Локальная сеть как доверенный сегмент.

Сдается Мне, что к такому неконтролируемому спуффингу может способствовать сбойное сетевое оборудование, или петля на “тупых” свитчах.

Соединения по MAC-адресам работают в пределах одного сегмента локальной сети(2-й, канальный уровень модели OSI) и посмотреть статистику ARP-запросов можно только по адресам из этой сети. Соединения из других сетей, идут уже по IP(3-й уровень модели OSI, сетевой).

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

У меня никто на разрывы соединений не жаловался, как ни странно, петли и сбойное сетевое оборудование исключаю, так как это проявилось на 4 площадках. А на одной из них вообще почти все по WiFi подключаются. При петлях точно пожаловались бы. И с оборудованием все в порядке.

В своем случае связываю это с частичной потерей пакетов из-за соединений по WiFi и нестабильной работы RAdmin VPN.

Reply