[solved]Защитить сеть от постороннего dhcp сервера

Здравствуйте!

Заранее прошу прощения если вопрос глупый, но ответа я на него пока нигде не нашел.
Имеется:
группа локальных сетей с действующим в них dhcp сервером (используется dhcpd), все адреса такого вида - 10.10.хх.ххх, адреса раздаются автоматически, сети имеют выход в интернет (используются VPN соединения), vpn сервер находится за локальным маршрутизатором, который соединяет все подсети между собой

Опишу ситуацию поподробнее, проблема в следующем:
Бывает такое, что какое нибудь скудоумное создание подсоединяя интернет-роутер к сети путает разъемы и кабель из общей сети втыкают за место WAN в LAN порт! А потом сидит и чешет репу, почему же у них PPTP соединение на нем не поднимается, а пока он думает - вся подсеть лежит, т.к. все получают адреса от dhcp на его интернет-роутере (как правило че-нибудь типа 192.168.0.ххх) VPN подключение естессно при таких настройках не поднимется т.к. нет маршрута до vpn сервера, да и связи с другими подсетями нет, потому что опять же маршрута нет. И побороть такую проблему довольно тяжело, т.к. сеть большая и полдня бегаем, отрубая дом за домом и квартиру за квартирой, пока не вычислим где живет негодяй и не надаем ему по шапке. Пробовали поднимать алиасы и даже физические хосты на типовых адресах (192.168.0.1, 192.168.1.1) но этим роутерам пофигу мороз - работают вопреки всему и внаглую раздают адреса! Если кто сталкивался с такой проблемой подскажите пожалуйста как можно защититься от таких вот левых dhcp серверов

Вполне может быть, что данную

Вполне может быть, что данную задачу можно решить только с помощью установки программируемых свитчей. Чесно говоря даже не представляю, каким образом можно назначить макс приоритет ответу от вашего dhcp без подобного железа.
Мой провайдер решил эту проблему так - назначает стат адреса и пишет их в договоре.

Резать весь мусор на

Резать весь мусор на маршрутизаторах последней мили.

Не грусти, товарищ! Всё хорошо, beautiful good!

а их там может просто не

а их там может просто не быть, и этот роутер хотябы то что с ним в свич воткнуто завалит

имхо только разбивать сеть -

имхо только разбивать сеть - управляемыми свичами или по vlan'ам или ещё как.

Не сильно дорогие свитчи

Не сильно дорогие свитчи (D-link DES-3028) умеют фильтровать трафик на порту. На офф сайте www.dlink.ru в faq есть примеры как настроить, чтобы клиент ходил ТОЛЬКО на заданный dhcp-сервер (Включается DHCP-Relay) и как заблокировать левые dhcp-ответы

Указанная технология

Указанная технология испытывалась на тестовом стенде и показала отличную работу (тестился еще opt 82)
Левые dhcp стабильно курят в сторонке, обращение идет только к главному dhcp

в качестве маршрутизатора

в качестве маршрутизатора используем В-Link DGS-3627:4, но он только маршрутизатор и делает dhcp_relay на dhcp сервер, а за ссылку спасибо, изучу

3028

Heggi написал(а):
Не сильно дорогие свитчи (D-link DES-3028) умеют фильтровать трафик на порту. На офф сайте www.dlink.ru в faq есть примеры как настроить, чтобы клиент ходил ТОЛЬКО на заданный dhcp-сервер (Включается DHCP-Relay) и как заблокировать левые dhcp-ответы

3526 стоит на самом деле не намного дороже (максимум на 1000 р), но эфективней в плане тех же acl 800 шт, вместо 256 на 3028. да и пасивное охлаждение еще не известно как скажется летом, когда в коммутационном шкафу будет температура 50С..

з.ы.
http://www.dlink.ru/technical/faq_hub_switch_66.php

Значит резать левый трафик

Значит резать левый трафик маршрутизаторами последней мили...

Не грусти, товарищ! Всё хорошо, beautiful good!

У нас бОльшая часть

У нас бОльшая часть оборудования - управляемая. Все сегменты разбиты на виланы. Все равно проблема очень актуальна и для нас. При появлении такого dhcp ложится весь сегмент (который в одном вилане с клиентским dhcp). Пусть и не вся сеть, но все равно не айс.

Проблема действительно копия

Проблема действительно копия нашей, ложится именно 1 сегмент а не вся сеть, как и было отмечено в первом посте

Защититься можно

Защититься можно исключительно покупкой управляемых свичей и либо, если это крутые свичи типа cisco резать dhcp пакеты прямо на них, либо слушать специальным сервером все широковещательные пакеты и при обнаружении левых запросов отслеживать источник и производить отключение ethernet порта.
Затем клиент понимает, что у него не работает интернет, звонит в техподдержку, ему объясняют, что он, по скудоумию своему, произвел атаку на вашу сеть и полностью нарушил её работоспособность в сегменте. Тем самым он нарушил контракт, который заключал при подключении. Вы готовы на первый раз его простить и подключить интернет после того, как он решит у себя проблему. Если он не в состоянии решить проблему - платный вызов мастера.

Спасет

в этой ситуации ppp-oe сервер. И только он если бюджет ограничен.

pppoe сервер никак не

pppoe сервер никак не поможет. Чтобы гнать ppp через ethernet, нужно настроить ethernet, а его-то сторонние dhcp сервера и валят.
Если бюджет ограничен, то только административные меры: физическое отключение клиентов от сети с последующем промыванием мозгов и объяснением, какие пункты соглашения нарушены, какие кункты уголовного кодекса нарушены (а они есть), сколько лет полагается за это и затем подключение после написания заявления о подключении. Ну и профилактическая работа с напоминаниями, как не надо валить сеть.
Ну или выдавать статические IP адреса. В качестве крайней меры могу предложить валить роутеры через telnet, раз провод воткнут в lan гнездо роутера.

PPPoE работает, даже есть на

PPPoE работает, даже есть на интерфейсе нету IP адреса. У него не тот уровень, чтобы на IP адреса внимание обращать

Согласен, я ошибся.

Согласен, я ошибся.

Пробовали, но по телнет не к

Пробовали, но по телнет не к каждому роутеру подключишся, ктомуже втыкают по скудоумию не только роутеры, а еще и точки доступа и даже ADSL модемы втыкать умудряются :) такой вот у нас сельский народ, договор подписывает нечитая и им хоть на лбу напиши, всеравно непоможет

По-моему, 1-о из самых

По-моему, 1-о из самых грамотных решений + управляемые свитчи, могут потом ещё моного благ предоставить. Конечно всё зависит от бютжета, но из говна конфетку без вложения средств почти невозможно сделать. Можно, сделать чтобы управляемые свитчи стояли по сегментам сети, а от них бы канал разветвлялся на несколько обычных, тогда падала бы не вся сеть, а только её часть.

http://xgu.ru/wiki/DHCP_optio

Вот тут пытаются связать дхцп с длинком. Вероятно их та же проблема заела
http://xgu.ru/wiki/DHCP_option_82

Эх...

KiberGus, спасибо... посмеялся....
Ну зачем очередные велосипеды??? Все равно ведь придете к ppp-oe - проверено на многих домовых сетях... Как отказываются от раздачи IP клиентам и ВСЕХ поголовно на ppp-oe - так сразу счастье и наступает. Подумайте головой... И свичи не надо умные, и искать клиента-муд**а, который dhcp раздает... И статистику в случае необходимости удобно вести... Куча преимуществ...

-_-

Agressor написал(а):
KiberGus, спасибо... посмеялся....
Ну зачем очередные велосипеды??? Все равно ведь придете к ppp-oe - проверено на многих домовых сетях... Как отказываются от раздачи IP клиентам и ВСЕХ поголовно на ppp-oe - так сразу счастье и наступает. Подумайте головой... И свичи не надо умные, и искать клиента-муд**а, который dhcp раздает... И статистику в случае необходимости удобно вести... Куча преимуществ...

Не соглашусь. У нас например инет раздается по ппое, а вот локалка по дхцп. Многие инетом особо не пользуются, качают фильмы из локалки, болтают на местных форумах, джабберах... ппое они вообще не подключают. а вот когда появляется левый дхцп - локалка у них отъезжает. вот и косяк. на работу инета это никак не влияет, конечно. оставлять всегда пппое подключенным неудобно (на него завязана нарезка скорости и др. приблуды).

)

Чем неудобно?? Руками вы его держите что-ли? нарезка скорости и др. приблуды - по сети назначения определяйте что с пакетом делать.

Пускать локалку по pppoe?

Пускать локалку по pppoe? Сейчас в основном используется 100 мегабит последняя миля. Максимум - 1 или 10 гигабит. => pppoe сервер может обслуживать не более 10-100 машин без деградации скорости канала. Для организации нормальной связи в сети на 1000 машин понадобится очень мощный сервер и очень толстый бэкбон. падение сервера - падение всего.
Со свичами у нас от соседних машин трафик ходит по кратчайшему маршруту. А при грамотном использовании роутеров быдут выбираться кратчайшие маршруты и проблема бэкбона не будет такой острой.

P.S. А что, если юзверь pppoe сервер поднимет? А если arp атаку устроит? А если arp flood (сам недавно случайно устроил, маршрут был ошибочный и торенты)? Сеть завалить легко, без управляемых свичей источник будешь искать долго, если атакующий грамотный - то не найдешь.

+1

KiberGus написал(а):
Пускать локалку по pppoe?

P.S. А что, если юзверь pppoe сервер поднимет? А если arp атаку устроит? А если arp flood (сам недавно случайно устроил, маршрут был ошибочный и торенты)? Сеть завалить легко, без управляемых свичей источник будешь искать долго, если атакующий грамотный - то не найдешь.

Вот и я про то. ппое - не выход. мы пока остановились на перловском костыле для поиска левых дхцп. скриптик ищет все дхцп в вилане и убивает те, которые не наши.

А поделиться скриптиком

А поделиться скриптиком можно? :) Был бы очень признателен

:)

_Andrey написал(а):
А поделиться скриптиком можно? :) Был бы очень признателен

он в процессе разработки. если не горит, как-нибудь позаимствую. просто пишу его не я :) icq: 248902363

А вот тут я не соглашусь. Мы

А вот тут я не соглашусь. Мы НАЧИНАЛИ со статических IP адресов и pptp (про pppoe тогда речи не было, сервак был на винде, да и про pppoe никто тогда не знал), соответственно везде неуправляемое железо и прочие прелести пионернета.
Ситуация сейчас практически такая же.
Геморрой, который мы сейчас имеем:
1. Клиенты ЛАМЕРЫ. Они даже IP адрес настроить в винде не умеют, про pptp вообще промолчу.
2. Клиенты СОВСЕМ ЛАМЕРЫ. Даже если под руководством техподдержки они правильно все настраивают, через неделю-другую у них чудесным образом инета нет! (сбились настройки, хз почему)

Вот эти два пункта - примерно 70% всех звонков в ТП.

3. Вводим новый сегмент, нужно сделать статическую маршрутизацию на определенный шлюз, КАК? Идти всем руками прописывать? Или Клиенты опять за%%ут ТП? Или делать хитрую машрутизацию на основном шлюзе? С DHCP все было бы намного проще.
4. Подмена IP адреса. Вот тут и начинается самое страшное. Какой-нить недоумный хакер меняет свой IP на чей-нибудь (добропорядочного гражданина) и начинает ломать чей-нить комп. В результате все стрелки на совершенно не виновного человека (так же можно и MAC поменять и имя компа и все-все-все, так что мониторинг сети не поможет, если хакер будет делать все правильно)

Все эти 4 пункта вполне удачно решают управляемые коммутаторы с DHCP-Relay и opt 82

- привязка IP к порту мутатора.
- блокировка левых dhcp серверов
- маршрутизация назначается через dhcp (и прочие прелести dhcp)
- отсутствие головняков у юзеров и ТП по поводу IP адресов
- на безлимитных тарифах можно раздавать инет просто по IP адресам (без всяких pptp, pppoe), не боясь, что инет кто-нить сопрет.
- возможны еще плюсы, о кторых я пока не подозреваю...

Надеюсь я вполне доходчиво все изложил, Жду комментарии

Опустил всё что выше..не

Опустил всё что выше..не осилил.
в конфиг dhcp
authoritative;
маршруты тоже элементарно раздаются через dhcp.

А фишка с authoritative

А фишка с authoritative сработает? Клиент входит в сеть, посылает запрос. Левый роутер ближе, поэтому он выдает компьютеру левый IP. Затем это обнаруживает правильный dhcp сервер и посылает клиента DHCPNAK. Клиент переходит в состояние INIT, то есть начинает всю процедуру с начала и снова получит ответ от роутера раньше.
Или против этого все-таки есть какие-то средства, которых я не нашел в описании протокола?

А если левый сервер тоже

А если левый сервер тоже будет authoritative?
ИМХО не выход. Как временное решение - может быть

А если БАК рванёт?

А если БАК рванёт?

Имел теже сомнения при

Имел теже сомнения при изучении этой опции, всеже включил ее, как показала практика - непомогло

есть дампы трафика?

есть дампы трафика?

Примерно то же самое у нас

wi написал(а):
Вот тут пытаются связать дхцп с длинком. Вероятно их та же проблема заела
http://xgu.ru/wiki/DHCP_option_82

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

Только и слышу Управляемые

Только и слышу Управляемые свичи!!!
Есть такой протокол ARP-address resolution protocol.
для начала стоит по гуглить эту тему.
А по существу - из портаджа ставь ip-sentinel
Суть-просматриваем сегмент сети на предмет соответствия МАС-IP-
если есть не соответствие - программа сбивает АРП-кеш у данного устройства.
таким образом получить ДХЦП реквест оно не сможет.

Много ручного рабского труда.

Много ручного рабского труда. Лучшее решение - сделать и забыть.

Не грусти, товарищ! Всё хорошо, beautiful good!

Настройки просмотра комментариев

Выберите нужный метод показа комментариев и нажмите "Сохранить установки".