[pppoetest]

а чтобы реализовать только защиту шлюза достаточно запретить в ARP Reply на всех портах одну цифру уникальную в Sender IP(шлюзы обычно заканчиваются на конкретную цифру .254 и .1 в общих случаях) и IP протокол так же.

для этого достаточно два профиля и два правила PCF, и на 24 порта это ест 48 правил(в 3028).

Не могли бы продемонстрировать?

[Negator]

+1 нужная вещь.

[mrsaygo]

А если просто traffic_segmentation? Каждый пусть видит только шлюз и ничего более. Настроить очень быстро можно и без раздумий.

[Negator]

Я сейчас как раз тестирую схему

что настроил

1-статиком мак шлюза на аплинк (25 порт)

2-traffic segmentatioт все порты на 25

3-Arp spoofing prevention

4. ACL -ы привязывающие IP к порту. разрешаем нужный ип и запрещаем все остальные.

5- ну там по мелочи еще чего то

 

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

Абоненты поставившие себе неверные IP - ничего не видят.

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

 

Проблемы начинаются когда абонент подставляет IP соседа. Конфликтов IP нет.

Работать у такого взломщика ничего не будет, НО - у валидного клиента тоже.

 

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

Тут как повезет - какой мак на циске будет соответсвовать -того и тапки.

 

Что с этим делать -пока непонятно. Привязываться к мак -адресу очень не хочется - у абонента может быть любой мак.

Надо как то защищать клиентов друг от друга.

 

Any Ideas?

Изменено 3 февраля, 2012 пользователем Negator

[Ivan_83]

по ацл фильтровать арп анонсы/ответы с IP отличным от положенного на порту.

[vurd]

//Разрешаем анонса адреса для 192.168.0.1 на порту 1
create access_profile packet_content_mask offset_16-31  0xFFFF0000  0x0  0x0  0x0 offset_32-47  0xFFFFFFFF  0x0  0x0  0x0 profile_id 1
config access_profile profile_id 1 add access_id 1 packet_content_mask offset_16-31  0x8060000  0x0  0x0  0x0 offset_32-47  0xC0A80001  0x0  0x0  0x0 port 1 permit
//Запрещаем всё ARP
create access_profile packet_content_mask offset_16-31  0xFFFF0000  0x0  0x0  0x0 profile_id 2
config access_profile profile_id 2 add access_id 1 packet_content_mask offset_16-31  0x8060000  0x0  0x0  0x0 port 1 deny

[Alexandr Ovcharenko]

vurd все правильно написал.

Только время прошло немало с начала топика :) , длинк допилил таки IMPB + dhcp-snooping до нормально работающего состояния. Этого абсолютно достаточно чтобы обрезать любые арп/спуфинг-шалости со стороны абонента. Все, что необходимо к этому добавить - броадкаст/мультикаст штормконтроль и LBD.

АЦЛ в общих случаях практически и не нужны теперь.

[Negator]

дык не работает оно, блочит правильные связки.

[vurd]

дык не работает оно, блочит правильные связки.

 

Какие правильные связки? Пример дайте

[Shiva]

У нас тут у юриков началась параноя, ставят цыцко, с проксиарпом включённым... Решается просто, PCF на ARP-Reply только его IP c порта.

[ingress]

У нас тут у юриков началась параноя, ставят цыцко, с проксиарпом включённым...

 

этой бай дефолт на младшших включено.

[Shiva]

Это понятно, я к тому, что юрики на цицко переходить начали...

[martini]

Тут как повезет - какой мак на циске будет соответсвовать -того и тапки.

ну так на циску включи Дхцп-снупинг или релей

[xcme]

дык не работает оно, блочит правильные связки.

А подробнее? Сейчас тоже откатываем как раз для борьбы с:

Проблемы начинаются когда абонент подставляет IP соседа. Конфликтов IP нет.

Видели такое из-за proxy arp на стороне клиента. IMPb v3.8 + DHCP Snooping порешали проблему. Для клиента (у него IP ручками вбит) сделал статическую запись.

Пока все работает прекрасно. Proxy arp включен до сих пор (выключить некому :) ), свич в лог ругается, но и валидные и невалидные клиенты работают.

 

Теперь собираемся тестить IMPb на баги...

[Negator]

Какие правильные связки? Пример дайте

 

Примеры тут.

http://forum.dlink.ru/viewtopic.php?f=2&t=145944

 

Видели такое из-за proxy arp на стороне клиента. IMPb v3.8 + DHCP Snooping порешали проблему. Для клиента (у него IP ручками вбит) сделал статическую запись.

Пока все работает прекрасно. Proxy arp включен до сих пор (выключить некому :) ), свич в лог ругается, но и валидные и невалидные клиенты работают.

 

Теперь собираемся тестить IMPb на баги...

 

какой нафиг проксиарп у меня на стенде?

 

Хз какая у меня версия. Но свичи напоминаю 3526. По всей вероятности на других моделях оно лучше работает.

Если у кого работает -приведите пожалуйста полный конфиг свича 3526.

Замучился уже. И вроде как работает, но нестабильно. Может какие ACL добавить из того что vurd написал?

Изменено 6 февраля, 2012 пользователем Negator

[xcme]

какой нафиг проксиарп у меня на стенде?

На стенде просто эмулируется поведение вот и все. Это когда "от абонента прилетает пакет со своим маком и IP соседа".

 

Свичи 3200, в названии тему модель не заметил, пардон.

[Negator]

полазил по веб морде свича с новой прошивкой и нашел Arp-inspection в разделе IP-MAC-Binding DHCP Snooping

похоже это то что нужно

 

настроил в очередной раз IP-MAC-Binding + DHCP Snooping + DHCP Relay + ARP Inspection - пока все работает как надо на стенде и на 10 абонентах.

продолжаю тесты.