Перейти к содержимому
Калькуляторы

Как обезопаситься от левых DHCP серверов Как провайдеру защитится от нелигитывных DHCP

Мелкий телеком. Сеть построянная на управляемых коммутаторах 2-го уровня которые умеют почти всё кроме DHCP Snooping. Используется Option 82 + DHCP-Relay, подмена ip или MAC не возможна. Реализована схема VLAN per User. Казалось бы всё прекрасно, но портит жизнь вероятная возможность запуска с клиентской стороны DHCP. Прошу поделиться мыслями каким образом можно выявлять эти DHCP сервера. Если узнать ip подлеца то выключить порт не составляет никакого труда. Осталось только узнать этот злополучный IP.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А на чём вланы то терминируются?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

На L2 коммутаторах установленых в локальных центрах, ещё конечно существуют L3 коммутаторы которые разруливают трафик между сегментами (микрорайонами). Эти L3 - являются шлюзами для всех клиентов (на них подняты все ip интерфейсы). Планируем очень скоро устанавливать L3 в микрорайоны, т.е. на них будут терминироваться Vlan-ы. Это всё не суть проблемы как и куда свести трафик и Vlan-ы, это может и будет меняться. Важно как выловить DHCP и узнать с какого он IP?

Изменено пользователем Alex158

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

если схема vlan-per-user то dhcp-броадкаст дальше вилана клиента никуда не уйдёт. в чём опасения?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

+1

Сомневаюсь что у него вообще работает вышеописаная схема. Иначе бы таких вопросов не задавал.

Изменено пользователем ma4o

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

На L2 коммутаторах установленых в локальных центрах, ещё конечно существуют L3 коммутаторы которые разруливают трафик между сегментами (микрорайонами). Эти L3 - являются шлюзами для всех клиентов (на них подняты все ip интерфейсы). Планируем очень скоро устанавливать L3 в микрорайоны, т.е. на них будут терминироваться Vlan-ы. Это всё не суть проблемы как и куда свести трафик и Vlan-ы, это может и будет меняться. Важно как выловить DHCP и узнать с какого он IP?
На агрегации включается DCHP snopping, но это при вашей схеме не актуально. Мне лично ваш вопрос не понятен, о каких поддельных DHCP серверах идёт речь, когда пользователи напрямую друг друга не видят ?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

если схема vlan-per-user то dhcp-броадкаст дальше вилана клиента никуда не уйдёт. в чём опасения?

 

+1

Сомневаюсь что у него вообще работает вышеописаная схема. Иначе бы таких вопросов не задавал.

Еще как будет работать при использовании IP-Unnumbered и насколько я понимаю тогда и вполне возможно dhcp-броадкаст уйдет дальше вилана

 

Пожалуй оно спасибо!

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

если это делинк с ACL ТО:

create access_profile ip udp src_port_mask 0xFFFF profile_id 20

config access_profile profile_id 20 add access_id 1 ip udp src_port 67 port 26 permit

config access_profile profile_id 20 add access_id 2 ip udp src_port 67 port 25 permit

config access_profile profile_id 20 add access_id 3 ip udp src_port 67 port 1 deny

config access_profile profile_id 20 add access_id 4 ip udp src_port 67 port 2 deny

config access_profile profile_id 20 add access_id 5 ip udp src_port 67 port 3 deny

config access_profile profile_id 20 add access_id 6 ip udp src_port 67 port 4 deny

config access_profile profile_id 20 add access_id 7 ip udp src_port 67 port 5 deny

config access_profile profile_id 20 add access_id 8 ip udp src_port 67 port 6 deny

config access_profile profile_id 20 add access_id 9 ip udp src_port 67 port 7 deny

config access_profile profile_id 20 add access_id 10 ip udp src_port 67 port 8 deny

config access_profile profile_id 20 add access_id 11 ip udp src_port 67 port 9 deny

config access_profile profile_id 20 add access_id 12 ip udp src_port 67 port 10 deny

config access_profile profile_id 20 add access_id 13 ip udp src_port 67 port 11 deny

config access_profile profile_id 20 add access_id 14 ip udp src_port 67 port 12 deny

config access_profile profile_id 20 add access_id 15 ip udp src_port 67 port 13 deny

config access_profile profile_id 20 add access_id 16 ip udp src_port 67 port 14 deny

config access_profile profile_id 20 add access_id 17 ip udp src_port 67 port 15 deny

config access_profile profile_id 20 add access_id 18 ip udp src_port 67 port 16 deny

config access_profile profile_id 20 add access_id 19 ip udp src_port 67 port 17 deny

config access_profile profile_id 20 add access_id 20 ip udp src_port 67 port 18 deny

config access_profile profile_id 20 add access_id 21 ip udp src_port 67 port 19 deny

config access_profile profile_id 20 add access_id 22 ip udp src_port 67 port 20 deny

config access_profile profile_id 20 add access_id 23 ip udp src_port 67 port 21 deny

config access_profile profile_id 20 add access_id 24 ip udp src_port 67 port 22 deny

config access_profile profile_id 20 add access_id 25 ip udp src_port 67 port 23 deny

config access_profile profile_id 20 add access_id 26 ip udp src_port 67 port 24 deny

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Можно это сделать покороче:

create access_profile ip udp src_port_mask 0xFFFF profile_id 20

config access_profile profile_id 20 add access_id 1 ip udp src_port 67 port 26 permit

config access_profile profile_id 20 add access_id 2 ip udp src_port 67 port 25 permit

config access_profile profile_id 20 add access_id 3 ip udp src_port 67 port 1-24 deny

 

Точно таким же методом рубим эту дрянь.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

если схема vlan-per-user то dhcp-броадкаст дальше вилана клиента никуда не уйдёт. в чём опасения?

 

+1

Сомневаюсь что у него вообще работает вышеописаная схема. Иначе бы таких вопросов не задавал.

Еще как будет работать при использовании IP-Unnumbered и насколько я понимаю тогда и вполне возможно dhcp-броадкаст уйдет дальше вилана

 

Пожалуй оно спасибо!

 

 

все равно ничего не понял, зачем вам это при технологии vlan per-user.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

если схема vlan-per-user то dhcp-броадкаст дальше вилана клиента никуда не уйдёт. в чём опасения?
Еще как будет работать при использовании IP-Unnumbered и насколько я понимаю тогда и вполне возможно dhcp-броадкаст уйдет дальше вилана

Ну-ка, ну-ка, куда оно может уйти?

Броадкасты и мультикасты при "вилан-на-юзера" заперты между юзером и BRAS'ом.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Возможно я не правильно понимаю концепцию ip-unnumbered? Хочу это использовать, поэтому боюсь ошибиться. Суть то в том что я использую общее адресное пространство для пользователей которые в разных VLAN. Предположим у нас сеть 10.10.0.0/24 в ней 253 юзверя , так вот от L3 до свитча доступа трафик идет к каждому в персональном VLAN'е, но с одного общего IPIF, т.е. с 10.10.0.1 (ip на L3), т.е. этот IPIF видит всех клиентов сети 10.10.0.0/24 из разных вланов. Таким образом юзвери не коммутируются непосредственно друг с другом на ближайшем свитче, а коммутируются только через центр. Так я понял концепцию ip-unnumbered.

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

Изменено пользователем Alex158

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Если влан на пользователя, то пока он неполучит адрес, а получит он его тока в от основного dhcp, он не увидит тачки в дургом влане.

 

Вроде так.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Юзвери находятся в одной подсети, а не каждый в своей, поэтому я опасаюсь dhcp-броадкаста. Прошу меня поправить если я ошибаюсь!
То, что у юзеров одна IP-сеть не означает что Ethernet-сеть тоже общая.

Юзеры при этом не коммутируются, они маршрутизируются.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Т.е. мне нечего бояться при описанной схеме. Спасибо всем участникам дискуссии. IP-unnumbered все же привлекательно из за возможности не упираться в кол-во ip-интерфейсов и не выделять каждому свою подсеть. Но есть и минус, возможен подмен ip и поэтому возникает необходимость проверять истинность клиентских настроек.

 

Вопрос к знатокам: я не допустил ошибок в описании концепции IP-unnumbered?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Подмена тоже невозможна.

Вернее она бессмысленна: юзер может чего-нибудь наслать от чужого IP, только ответы ему не придут, т.к. маршрут в интерфейс создаётся при выдаче IP-адреса, либо прописывается статически...

 

PS. URPF можно ещё попробовать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Можно проше по крайней мере мне было

блочиться на глухо левые dhcp

#разрешаем наш DHCP
#user's group

create access_profile ip source_ip_mask 255.255.255.255 udp src_port_mask 0xFFFF profile_id 3
config access_profile profile_id 3 add access_id 1 ip source_ip xx.x.x.x udp src_port 67 port 1-24 permit
#где xx.x.x.x айпишник нашего DHCP
#Запрешаем все чужие DHCP
create access_profile ip source_ip_mask 0.0.0.0 udp src_port_mask 0xFFFF profile_id 7 
config access_profile profile_id 7 add access_id 1 ip source_ip 0.0.0.0 udp src_port 67 port 1-24 deny

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.