Добрый день господа
Feb 11 03:37:53 172.16.0.100 WARN: Unauthenticated IP-MAC address and discarded by ip mac port binding(IP:<0.0.0.0>, MAC:<20-C9-D0-99-C0-24>, Port<1>)
Feb 11 03:37:53 172.16.0.100 WARN: Unauthenticated IP-MAC address and discarded by ip mac port binding(IP:<0.0.0.0>, MAC:<20-C9-D0-99-C0-24>, Port<1>)
Feb 11 03:37:54 172.16.0.100 WARN: Unauthenticated IP-MAC address and discarded by ip mac port binding(IP:<0.0.0.0>, MAC:<20-C9-D0-99-C0-24>, Port<1>)
Feb 11 03:37:55 172.16.0.100 WARN: Unauthenticated IP-MAC address and discarded by ip mac port binding(IP:<172.16.4.2>, MAC:<20-C9-D0-99-C0-24>, Port<1>)
Feb 11 03:38:02 172.16.0.100 WARN: Unauthenticated IP-MAC address and discarded by ip mac port binding(IP:<172.16.4.2>, MAC:<20-C9-D0-99-C0-24>, Port<1>)
Feb 11 03:38:10 172.16.0.100 WARN: Unauthenticated IP-MAC address and discarded by ip mac port binding(IP:<172.16.4.2>, MAC:<20-C9-D0-99-C0-24>, Port<1>)
Feb 11 03:38:26 172.16.0.100 WARN: Unauthenticated IP-MAC address and discarded by ip mac port binding(IP:<172.16.4.2>, MAC:<20-C9-D0-99-C0-24>, Port<1>)
Feb 11 03:38:58 172.16.0.100 WARN: Unauthenticated IP-MAC address and discarded by ip mac port binding(IP:<172.16.4.2>, MAC:<20-C9-D0-99-C0-24>, Port<1>)
Feb 11 03:39:32 172.16.0.100 WARN: Unauthenticated IP-MAC address and discarded by ip mac port binding(IP:<172.16.4.2>, MAC:<20-C9-D0-99-C0-24>, Port<1>)

вот такую хрень увидел на свиче - адрес точки 172.16.1.100 - кто то давит на точку и она выплёвывает левые ип

IMPB настроен

create address_binding ip_mac ipaddr 172.16.1.100 mac_address 20-C9-D0-99-C0-24 ports 1
create address_binding ip_mac ipaddr 172.16.4.2 mac_address 10-40-F3-EB-2B-BC ports 4

устройству у которого 172.16.4.2 сносит крышу сразу

собственно почему IMPB пропускает такую хрень в режиме ACL?

версия прощифки 2.21.B005

IMPB как раз таки блокирует то, что не прописано в связках - и об этом идут сообщения в лог.

отлови пакеты

09:42:28.499154 20:c9:d0:99:c0:24 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 172.16.4.2 tell 172.16.4.2, length 46
0x0000: ffff ffff ffff 20c9 d099 c024 0806 0001
0x0010: 0800 0604 0001 20c9 d099 c024 ac10 0402
0x0020: 0000 0000 0000 ac10 0402 0000 0000 0000
0x0030: 0000 0000 0000 0000 0000 0000
09:42:29.489082 20:c9:d0:99:c0:24 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 172.16.4.2 tell 172.16.4.2, length 46
0x0000: ffff ffff ffff 20c9 d099 c024 0806 0001
0x0010: 0800 0604 0001 20c9 d099 c024 ac10 0402
0x0020: 0000 0000 0000 ac10 0402 0000 0000 0000
0x0030: 0000 0000 0000 0000 0000 0000


закрыл правилами - вроде в сети не видно - но устройство 172.16.4.2 в штопор валится

таки почему то устройство которое пытаюсься проспуфить - валится в штопор - пока порт не очистишь от маков?

а это вам на засыпку

04:50:15.495631 20:c9:d0:99:c0:24 > 3c:07:54:4a:eb:9e, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 172.16.4.2 is-at 20:c9:d0:99:c0:24, length 46
0x0000: 3c07 544a eb9e 20c9 d099 c024 0806 0001
0x0010: 0800 0604 0002 20c9 d099 c024 ac10 0402
0x0020: 3c07 544a eb9e ac10 0903 0000 0000 0000
0x0030: 0000 0000 0000 0000 0000 0000

вот пакет прошёл до моего компа - через ваше хвалённое IMPB

на ночь порт отмирорил и поставил на запись

Safeguard может влияет если включён что CPU не справляется и пропускает?

далее такое ощющение что счётчики отбитых пакетов не работают



Port Number : 1
RX Frames TX Frames
--------- ---------
CRC Error 0 Excessive Deferral 0
Undersize 0 CRC Error 0
Oversize 0 Late Collision 0
Fragment 0 Excessive Collision 0
Jabber 0 Single Collision 0
Drop Pkts 0 Collision 0
Symbol Error 0


так как всё по нулям

ещё один вопрос можно ли вырубить обучение на порту - что бы сравнивал то что есть в IMPB?

сколько не пытался - он всё равное обучается до цифры в Stop Learning Threshold/Mode

ау??? господа реальная проблема - мне директор мозг вынес!

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

пишу вам на мыло

pcap запоковал в tar.gz

проблема разрешилась методом установки в IMPB Stop Learning Threshold/Mode = 1 на проблемном порту

естественно все клиенты на порту в статике в IMPB

Рад слышать, что удалось разобраться с проблемой!

да, спасибо Артём - навели на нужный момент в переписке.
ещё раз спасибо.

кое что допилил что бы процессору свича было легче - может кому пригодится.

если с мака точки вылетают ип не того формата - тоесть не ип точки

следовательно следует добавить pcf как для свича - так и для cpu свича (стандартные pcf для гейта только в обратную сторону)

create access_profile profile_id 3 packet_content_mask offset_chunk_1 3 0xFFFF offset_chunk_2 7 0xFFFF offset_chunk_3 8 0xFFFF0000
config access_profile profile_id 3 add access_id 1 packet_content offset_chunk_1 0x806 offset_chunk_2 0xAC10 offset_chunk_3 0x1640000 port 1 permit rx_rate no_limit - тут ип точки его разрешаем

и запрещяем другие ип с мака точки по арпу

create access_profile profile_id 4 ethernet source_mac FF-FF-FF-FF-FF-FF ethernet_type
config access_profile profile_id 4 add access_id 1 ethernet source_mac 20-C9-D0-99-C0-24 ethernet_type 0x806 port 1 deny

теперь тоже самое для cpu

create cpu access_profile profile_id 3 packet_content_mask offset_0-15 0x0 0x0 0x0 0xFFFF0000 offset_16-31 0x0 0x0 0x0 0xFFFFFFFF
config cpu access_profile profile_id 3 add access_id 1 packet_content offset_0-15 0x0 0x0 0x0 0x8060000 offset_16-31 0x0 0x0 0x0 0xAC100164 port 1 permit

create cpu access_profile profile_id 4 ethernet source_mac FF-FF-FF-FF-FF-FF ethernet_type
config cpu access_profile profile_id 4 add access_id 1 ethernet source_mac 20-C9-D0-99-C0-24 ethernet_type 0x806 port 1 deny

правило специально от троллей которые не понимают что хотят .

позже выложу график cpu - тоесть нагрузка снизилась в несколько раз.

вопрос к бывалым - кому известны атака - позволяющая загнать не валидный трафик через саму точку - как будто трафик идёт с самой точки? не с клиентов

судя по тому что я отловил - пришлось модифицировать верхний pcf - глюки вообще пропали -

create access_profile profile_id 3 packet_content_mask offset_chunk_1 3 0xFFFF offset_chunk_2 7 0xFFFF offset_chunk_3 8 0xFFFF0000
config access_profile profile_id 3 add access_id 1 packet_content offset_chunk_1 0x806 offset_chunk_2 0xAC10 offset_chunk_3 0x1640000 port 1 permit rx_rate no_limit - тут ип точки его разрешаем
create access_profile profile_id 4 ip source_ip_mask 255.255.255.255
config access_profile profile_id 4 add access_id 1 ip source_ip 172.16.1.100 port 1 permit rx_rate no_limit
create access_profile profile_id 5 ipv6 source_ipv6_mask FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF
config access_profile profile_id 5 add access_id 1 ipv6 source_ipv6 FE80::22C9:D0FF:FE99:C024 port 1 permit rx_rate no_limit
create access_profile profile_id 6 ethernet source_mac FF-FF-FF-FF-FF-FF
config access_profile profile_id 6 add access_id 1 ethernet source_mac 20-C9-D0-99-C0-24 port 1 deny

для cpu

create cpu access_profile profile_id 2 packet_content_mask offset_0-15 0x0 0x0 0x0 0xFFFF0000 offset_16-31 0x0 0x0 0x0 0xFFFFFFFF
config cpu access_profile profile_id 2 add access_id 1 packet_content offset_0-15 0x0 0x0 0x0 0x8060000 offset_16-31 0x0 0x0 0x0 0xAC100164 port 1 permit
create cpu access_profile profile_id 3 ip source_ip_mask 255.255.255.255
config cpu access_profile profile_id 3 add access_id 1 ip source_ip 172.16.1.100 port 1 permit
create cpu access_profile profile_id 4 ipv6 source_ipv6_mask FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF
config cpu access_profile profile_id 4 add access_id 1 ipv6 source_ipv6 FE80::22C9:D0FF:FE99:C024 port 1 permit
create cpu access_profile profile_id 5 ethernet source_mac FF-FF-FF-FF-FF-FF
config cpu access_profile profile_id 5 add access_id 1 ethernet source_mac 20-C9-D0-99-C0-24 port 1 deny

у нас apple техника - пропустил ещё ipv6 local самой точки - что бы сервисы работали.

после этого пропали drop пакеты на интерфейсах компов - что является положительной динамикой

RX packets:22285927 errors:0 dropped:162 -

странный дос - не могу ни где найти описание - что бы проигрывали наш же трафик в эзернет с самой точки
подсобите инфой господа о подобной атаке.