Защита от ручного ввода IP-адреса

[ARTIsshoque]

Каким образом можно защитить сеть, в которой имеется DHCP-сервер с привязкой адресов к портам коммутаторов, от "умных" пользователей, назначающих своим сетевым интерфейсам IP-адрес вручную? Можно ли предотвратить конфликт IP-адресов в случае установки пользователем существующего адреса или адреса шлюза? Особенно интересно, можно ли реализовать такую защиту с помощью опций ACL, DHCP relay и DHCP snooping на коммутаторах D-Link.

[mcdemon]

На коммутаторах длинк есть функция IP-MAC-PORT-BINDING

[Дятел]

Или влан на порт

[dsk]

Выкинуть с доступа релеи, снупинги и иже сними, и забабахать vlan per user.

[Дятел]

Ну, это же можно совместить...

[ARTIsshoque]

Привязка IP к MAC-у не нужна, т.к. пользователю должен быть гарантирован доступ независимо от MAC-адреса. Городить десятки вланов тоже не хочется. Вопрос не об этом. Меня интересует, как с помощью ACL ограничить возможность пользователя своими неосторожными действиями создавать проблемы всей подсети, не ограничивая его при этом одним MAC-адресом. Принцип такой: в квартиру к абоненту заводится кабель, который абонент волен подключать к чему угодно, и это "что угодно" должно либо получить IP-адрес по DHCP, если он включен, либо вообще не обнаруживаться в сети и не создавать конфликтов.

[motorhunter]

DHCP Snooping + ARP Inspection.

[Antares]

Городить десятки вланов тоже не хочется.

А в чём же проблема? За то раз и навсегда избавитесь от подмен!

[megahertz0]

IP Source Guard и подобного рода фичи, которые строят привязку ip к портам на основе данных dhcp snooping. Ну и максимум три адреса на порт на случай, если пользователь сменит железку со своей стороны. По-моему сейчас есть во всех свитчах за исключением ультрадешманских.

[Saab95]

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

[msh_1]

как-то так

#разрешаем arp replay только со своим IP

create access_profile packet_content offset_0-15 0x0 0x0 0x0 0xffff0000 offset_16-31 0x0 0x0 0x0 0xffffffff offset_32-47 0x0 0x0 0x0 0x0 profile_id 20

config access_profile profile_id 20 add access_id 1141 packet_content offset 12 0x8060000 offset 28 0xa071210 port 15 permit

 

#запрещаем dhcp reply

create access_profile ip udp dst_port 0xFFFF profile_id 30

config access_profile profile_id 30 add access_id 1 ip udp dst_port 68 port 1-24 deny

 

#разрешаем отправлять данные только со чвоим IP адресом

create access_profile ip source_ip 255.255.255.255 profile_id 40

config access_profile profile_id 40 add access_id 1141 ip source_ip 10.7.18.16 port 15 permit

 

#блокирунм все остальное

create access_profile ethernet source_mac 00-00-00-00-00-00 profile_id 200

config access_profile profile_id 200 add access_id 1 ethernet source_mac 00-00-00-00-00-00 port 1-24 deny

[biox]

VLAN PER CASTOMER (поддержу сааба), обеспечит желаемое без лишнего гемороя.

[srg555]

ARTIsshoque

В самом деле, ваш вопрос несколько более глобален, чем просто "защита от ip-спуфа". Единственный верный вариант это использование bras(sw или hw, не суть) и изоляция межабонентского L2-трафика на доступе(либо vlan-per-user(желательно), либо vlan-per-switch+segmentaion(проблемы если и будут, то только в пределах одного свитча))

 

Про IPMB не слушайте. шаг влево, шаг вправо и получите cpu 100% или сложнообъяснимые вещи из-за глючного ПО на свитчах

[Negator]

Про IPMB не слушайте. шаг влево, шаг вправо и получите cpu 100% или сложнообъяснимые вещи из-за глючного ПО на свитчах

Давно уже все работает как надо.

Да и вообще - не надо всем советовать одно и то же. Vlan per user не панацея от всех бед

 

Мы давно используем следующую схему:

1. Влан на подсеть/24 (3-4 дома). Внутри traffic_segmentation. В последнее время влан на дом.

2. IP-MAC-PORT Binding DHCP Snooping + Relay option82 на свичах.

Вместо IP-MAC-PORT BINDING чаще используем правила описанные msh_1 - все железобетонно работает с ними. Но IMPB тоже работает в другом районе без проблем.

Все автоматизировано из биллинга. Проблем нет никаких.

[xcme]

Привязка IP к MAC-у не нужна, т.к. пользователю должен быть гарантирован доступ независимо от MAC-адреса. Городить десятки вланов тоже не хочется. Вопрос не об этом. Меня интересует, как с помощью ACL ограничить возможность пользователя своими неосторожными действиями создавать проблемы всей подсети, не ограничивая его при этом одним MAC-адресом. Принцип такой: в квартиру к абоненту заводится кабель, который абонент волен подключать к чему угодно, и это "что угодно" должно либо получить IP-адрес по DHCP, если он включен, либо вообще не обнаруживаться в сети и не создавать конфликтов.

IMPB трэш и в ряде случаев неприменим. Например в вашем, т.к. "абонент волен подключать к чему угодно", т.е. предполагается возможность использовать дома коммутатор. При очистке по тем или иным причинам таблицы IMPB на коммутаторе (например, он перезагрузился) линки до абонентского оборудования не падают (т.к. в квартире еще один свичик), и коммутатор блокирует всех "неизвестных". Это недопустимо. Можно, конечно, использовать очень маленькое время аренды адреса, но это тоже неудобно, т.к. создает повышенную нагрузку на сервера DHCP/MySQL. Ну и плюс глюки самого функционала IMPB в 9-й, 19-й и 29-й день Луны. Без них никак. Одно время поигрались и отказались.

 

Vlan-per-user вариант, но не удобно в настройке. Хотя, может и есть способы все делать быстро и красиво, но у нас сейчас в сети больше 3k железок на доступе, так что вланов и без VpU хватает.

 

Если можете переделать внутреннюю адресацию, то есть неплохое решение при помощи ACL. Суть: выдаете на порт пул адресов по некоторой закономерности, которую описываете правилом, разрешающим ARP. Остальной ARP режете. Дополнительно на доступе включаете traffic segmentation. В результате абонент все еще может выставить IP вручную, но только из своего пула. Соответственно, шлюз он не подменит и ARP-спуфингом заниматься не сможет.

 

Например, при схеме vlan-на-коммутатор мы выдаем 8 серых адресов на порт (на коммутаторах не более 24-х портов), начиная с 8-го адреса. Абонентская сеть имеет размер /24. При этом получается, что левая граница пула (4-й октет) равна №_порта*8, а правая - №_порта*8+7. Соответственно и наоборот: целая часть от делении 4-го октета на 8 однозначно указывает на номер порта. Это удобно и для ТП и для составления ACL.

 

Пример ACL:

Профиль 1 (опционально)

#Разрешаем служебные вланы (управление, VIP-клиенты и пр.) с 0 по 15-й (обратите внимание на маску профиля)

create access_profile packet_content_mask c_tag 0xFFF0 offset1 l2 0 0x0 profile_id 1

config access_profile profile_id 1 add access_id auto_assign packet_content c_tag 0x0000 port all permit

 

Профиль 2, 3 - режем "нехорошие порты" TCP 135,139,445,2869,3587,5357,5358 и deny UDP 135,213,445,3540,3587,5355 (как пример) (опционально)

 

Профиль 5

#Разрешаем ARP-ответы с корректным 4-м октетом (между port*8 и port*8+7) (обратите внимание на маску профиля)

create access_profile packet_content_mask offset1 l2 0 0xFFFF offset2 l3 16 0xF8 profile_id 5

config access_profile profile_id 5 add access_id auto_assign packet_content offset1 0x0806 offset2 0x08 port 1 permit

config access_profile profile_id 5 add access_id auto_assign packet_content offset1 0x0806 offset2 0x10 port 2 permit

config access_profile profile_id 5 add access_id auto_assign packet_content offset1 0x0806 offset2 0x18 port 3 permit

config access_profile profile_id 5 add access_id auto_assign packet_content offset1 0x0806 offset2 0x20 port 4 permit

config access_profile profile_id 5 add access_id auto_assign packet_content offset1 0x0806 offset2 0x28 port 5 permit

config access_profile profile_id 5 add access_id auto_assign packet_content offset1 0x0806 offset2 0x30 port 6 permit

config access_profile profile_id 5 add access_id auto_assign packet_content offset1 0x0806 offset2 0x38 port 7 permit

config access_profile profile_id 5 add access_id auto_assign packet_content offset1 0x0806 offset2 0x40 port 8 permit

config access_profile profile_id 5 add access_id auto_assign packet_content offset1 0x0806 offset2 0x48 port 9 permit

config access_profile profile_id 5 add access_id auto_assign packet_content offset1 0x0806 offset2 0x50 port 10 permit

config access_profile profile_id 5 add access_id auto_assign packet_content offset1 0x0806 offset2 0x58 port 11 permit

config access_profile profile_id 5 add access_id auto_assign packet_content offset1 0x0806 offset2 0x60 port 12 permit

config access_profile profile_id 5 add access_id auto_assign packet_content offset1 0x0806 offset2 0x68 port 13 permit

config access_profile profile_id 5 add access_id auto_assign packet_content offset1 0x0806 offset2 0x70 port 14 permit

config access_profile profile_id 5 add access_id auto_assign packet_content offset1 0x0806 offset2 0x78 port 15 permit

config access_profile profile_id 5 add access_id auto_assign packet_content offset1 0x0806 offset2 0x80 port 16 permit

config access_profile profile_id 5 add access_id auto_assign packet_content offset1 0x0806 offset2 0x88 port 17 permit

config access_profile profile_id 5 add access_id auto_assign packet_content offset1 0x0806 offset2 0x90 port 18 permit

config access_profile profile_id 5 add access_id auto_assign packet_content offset1 0x0806 offset2 0x98 port 19 permit

config access_profile profile_id 5 add access_id auto_assign packet_content offset1 0x0806 offset2 0xa0 port 20 permit

config access_profile profile_id 5 add access_id auto_assign packet_content offset1 0x0806 offset2 0xa8 port 21 permit

config access_profile profile_id 5 add access_id auto_assign packet_content offset1 0x0806 offset2 0xb0 port 22 permit

config access_profile profile_id 5 add access_id auto_assign packet_content offset1 0x0806 offset2 0xb8 port 23 permit

config access_profile profile_id 5 add access_id auto_assign packet_content offset1 0x0806 offset2 0xc0 port 24 permit

config flow_meter profile_id 5 access_id 1 rate 64 rate_exceed drop_packet

Благодаря "особенной" маске и описанной выше закономерности мы потратили всего 24 правила, описав 192 адреса. Причем первые 3 октета могут быть любыми, т.е. правила можно использовать на любом коммутаторе, независимо от выдаваемых абоненту IP-адресов.

 

Профиль 6

#Запрещаем остальные ARP на портах с 1 по 24

create access_profile packet_content_mask offset1 l2 0 0xFFFF profile_id 6

config access_profile profile_id 6 add access_id auto_assign packet_content offset1 0x0806 port 1-24 deny

 

Ну и конечно:

config traffic_segmentation 1-24 forward_list 25-28

 

Теперь, если пользователь поставит себе адрес вне отведенного диапазона об этом просто никто не узнает и помешать работе других он не сможет.

[srg555]

Давно уже все работает как надо.

 

Пару раз пробовал, всегда какие-то косяки. Я не отрицаю, что в последних прошивках к определённым моделям оно работает более-менее и может быть даже совсем неплохо. Но тут возникает другая проблема. Вендор прекращает выпуск оборудования, на котором у вас всё отлажено, выпускает новое, с новым ПО и вся свистопляска с IPMB может повториться. По поводу PCF тоже самое, в новых ревизиях его может просто не быть. И кстати, на des3200 pcf аппаратный или с использованием CPU? Используя тривиальные конфигурации коммутатора типа vlan-per-switch+segmentaion или vlan-per-user, вы фактически никак не привязываетесь ни к софту, ни к аппаратным особенностям. Пример из жизни. Вместо des3200 a/b теперь des3200 c. Кто завязал свой дизайн на ACL на доступе теперь должны полностью переписать свои ACL и в общем случае это сделать не получится, придётся что-то где-то менять.

 

Да и вообще - не надо всем советовать одно и то же. Vlan per user не панацея от всех бед

 

Панацея от всех спуфингов(в том числе, порождённых петлями у абонента)