Mar 13 16:23:33 root1sw 192.168.ххх.ххх CRIT: Possible spoofing attack from хх-хх-хх-хх-хх-хх port 6

Раскажите как работает , данная функция, и что такое на руском языке спуфинг атак ?

это означает, что за 6 портом у вас кольцо, а мак который у вас там указан мак самого свича.

_________________
console for real man...

нет там не может быть кальца ибо там куча 3526 которые сказали бы если кальцо... в том то и дело.. в одном и сегментов в таком то вилане этот мак всветиться..

кстати, а это нормально что длинки реагируют только на кольца, а на реальные спуфинговые атаки не реагируют?
допустим DGS-3627 именно так себя и ведет.

Device Type : DGS-3612G Gigabit Ethernet Switch
MAC Address : хх-хх-F0-хх-хх-хх


во во , впринцепе они говорят о том что видят свой мак абратно, в таком то вилане..

DGS-3324 видит спуфинг - проверено собственно спуфингом.
DES-3828 видит кольцо (думаю и спуфинг) проверено нерадивыми клиентами сети.

Вторая вероятная причина что кто-то поменял IP-адрес на адрес интерфейса свитча в этом VLAN-е, поэтому ловит spoofing атаки.

Управление железом выносим в отдельный влан и не мучаемся ...
и если где и появится такая мессага, то только на L3.

эм... а смысл 36** использовать как L2? микроскоп больно мощный получается, чтобы гвозди забивать...
вопрос в том, что сообщения есть только о кольцах за портом (то бишь мак самого свитча на интерфейсе). а вот реальные спуфинговые атаки свитч не ловит... вот и интересуюсь почему, эта функция вроде как ненастраиваемая...

А эта и не функция вообще-то а просто логирование. Так разве подмена адреса на адрес шлюза не подвид spoofing атаки? А такие вещи он ловит.

так если это и не насраиваемая фитча, она присутсвует, то можно её как то развить, чтоб писала подмена мака , или кольцо... тоесть чтоб поточнее было, а не просто факт ошибки некой в вилане ..

Мухи отдельно, котлеты отдельно. Для диагностики колец нужно включать STP, для защиты от спуфинга ARP Spoofing prevention и ACL. Как без этих механизмов маршрутизатор поймёт, петля это или пользователь шалит?

Проблема решится если на порты применять функцию
address_binding ip_mac в режиме arp?

IP и мак соответственно порта, на котором spoofing attack

кстати заспуфенные пакеты проходят IMB.

почему?