Мда , нет слов одни эмоции ...

+1

2 Wave > Вы читали этот FAQ: http://www.dlink.ru/technical/faq_hub_switch_115.php !?

_________________
С уважением,
Бигаров Руслан.

нет,
спасибо за ссылку
вроде написано доступно и понятно
попробую сегодня воспроизвести у себя в сети

В свичах DES-3526 в прошивке 5.01-b52 реализована функция Arp Spoofing Prevention - это и есть полная защита от описанной выше ситуации.

Вопрос поддержке D-Link - будет ли реализован подобный функционал (packet content ACL) в серии DGS-3100?

Рад слышать! По поводу DGS-31XX к сожалению этого нет в железе.

Мда, и кстати не стоит на роутяре делать статик арп. На рынке появились клиентские роутеры-мыльницы, потребляющие трафик в promiscuous-mode. Они ловят все пакеты на свои ип, вне зависимости от dst mac. Поэтому, когда радостный клиент втыкает такой девайс в сеть, и начинает лить с ближайшей файлопомойки на все 100мбит, то эти 100мбит приходят всему сегменту... Редкий 32х байтный пинг при этом долетит до шлюза... И так до тех пор, пока на шлюзе не пропишете новый мак

Не ждите сказки от этой функции, это модная фича делающая простенький ацл который не позволяет с мас-IP адреса роутера слать кривые арп пакеты. Только АРП, т.е любой другой протокол допустим, а вирусы тут вовсю и протоколы другие используют (я видел 0x1702), и мультикастом распространяются который в обычные ACL при включеном спупинге не попадают. И вообще делают кучу всякой дряни.

Надо писать под каждую клиентскую связку Ip - Мас свои фильтры,
1. Запрещаем все вредные порты 68,135,137,138,445 и тд.
2. Разрешаем с мас и Ip адресом пользователя слать пакеты по IP (0x0800)
3. Разрешаем с мас и Ip пользователя слать арп ответы только со своим MAC (0x0806)
3. разрешаем с 0.0.0.0 на 255.255.255.255:67 для получения адреса(0x0800)
4. запрещаем все в вилане.

Все это громоздко и делать можно только автоматом из билинга, а у каждого он свой. Длинк не может написать фичу для всех и всех сразу обрадовать. Есть SNMP есть CLI надо все это вместе сопрягать.

Так же в случае работающего IPTV надо ограничить возможность входить иные группы мультикаста, чем это возможно. Так же надо ограничивать те вещи, которые пролетают мимо ACL коммутатора:
всякие пакеты протоколов маршрутизации и тд.

Сделано примерно так на 3028 на основе packet content за исключением того, что маки не учитываются, ибо абоненты любят их менять. Просто ограничено через port security количество MAC адресов на абонентском порту.

Этот FAQ хорош, но скажем если у человека ситуация иного плана.

Сеть не полностью построена на управляемом оборудовании, чтобы осуществлять привязку по IP-Mac на порту т.к. на некоторых портах сидят по 100-150 клиентов.

Все шлюзы - это порты соответствующих L3 коммутаторов, mac и ip которых известны. Причем IP шлюзов все назначены как 192.168.XXX.1.

Клиентские адреса соотвественно назначены более чем 192.168.ХХХ.1, т.е. 2, 3 и далее.

Между L3 коммутаторами, являющимися шлюзами сегментов сети, и клиентами, находятся L2 коммутаторы уровня группы домов т.е. с каждого дома один линк на порт L2 коммутатора, а далее с L2 на L3.

Как в таком случае установить запреты на использование ip-mac шлюза L3 клиентскими ПК? Есс-но желательно сделать этот запрет на порту L2 коммутатора, чтобы L3 уже не занимался этой работой.

Вполне понятно, что все, кто что-либо знает, посылают к FAQ, но простенький пример из FAQ легко воспроизводится и выполняется даже без знакомства с FAQ, но вот когда у вас известна только половина данных (ip-mac шлюза и диапазон допустимых ip клиентских адресов), то этот пример уже не помогает.

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

Суть же задачи довольно проста:

- запретить устанавливать клиентам IP вида 192.168.ххх.1
- сделать так чтобы L3 и L2 коммутаторы не обрабатывали входящие пакеты с адресов и портов клиентов, если совпадает mac адрес отправителя с mac адресом шлюза
- запретить клиентам с адресами более чем 192.168.ххх.1 занимать mac адрес коммутатора даже в случае правильно установленного клиентского IP

Конечно же управляющий vlan отделен от клиентских на всех уровнях коммутации и закрыт на доступ как напрямую, так и по маршрутизации на L3, поэтому частично FAQ 115 в качестве совета отпадает.

Если по-хорошему, то и без посыла к FAQ ясно, что копать в сторону acl, а не куда-то еще.

а в 3028 как обстоят дела с подобным функционалом?

http://www.dlink.ru/search/index.php?qu ... prevention и почему на сайте ДЛИНКА нет ничего про эту функцию?

Она появилась только в последних версиях прошивки. Смотрите в манулах на ftp.

а где можно узнать список девайсов,в которых она будет релизована?

ftp://dlink.ru/pub/Switch/DES-3526_3526 ... 20R3.6.pdf по поиску не нашло