The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Программа для тестирования DHCP серверов - dhcdrop

13.07.2009 04:26

Программа dhcdrop предназначена для тестирования DHCP серверов при их настройке, и отслеживания или подавления ложных DHCP серверов в сетях провайдеров. Подавление серверов осуществляется при помощи атаки DHCP starvation.

Возможности программы:

  • поддерживаемые платформы: Linux, FreeBSD, Windows.
  • возможность задания списка игнорируемых DHCP серверов.
  • возможность тестового запуска без активизации атаки DHCP starvation. Осуществляется отправкой запроса DHCPDISCOVER без посылки DHCPREQUEST. В случае обнаружения DHCP сервера выдаётся соответствующее сообщение и программа завершается.
  • возможность автоматизировать поиск и подавление ложных DHCP серверов в сети при помощи простого скрипта использующего код возврата программы.
  • возможность конфигурирования параметров тестирования, атаки DHCP starvation и некоторых опций запросов DHCP.
  • возможность стресс-тестирования DHCP сервера при помощи режима флуда DHCPDISCOVER запросов.


  1. Главная ссылка к новости (http://www.netpatch.ru/dhcdrop...)
Автор новости: RomanCh
Тип: Программы
Ключевые слова: dhcp, test, debug
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (50) Ajax | 1 уровень | Линейный | Раскрыть всё | RSS
  • 1.1, Аноним (-), 08:54, 13/07/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ура, теперь каждый школьник сможет досить DHCP сервера провайдера.
     
     
  • 2.4, аноним (?), 10:08, 13/07/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Ура, теперь каждый школьник сможет досить DHCP сервера провайдера.

    Ага, вон они уже чуть ниже радуются. И заодно спрашивают, что сделать, чтобы их не досили.

     
  • 2.5, настоящий_аноним (?), 10:18, 13/07/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Хуже точно не стало. Потому что раньше "каждый школьник" мог поднять свой дхцп-сервер и тем самым нагадить своему прову. Теперь это стало чревато.

    Вообще сам давно собирался такую прогу написать, да все руки не доходили. Спасибо ребятам.

    В крон, однозначно :)

     
     
  • 3.12, PereresusNeVlezaetBuggy (ok), 12:05, 13/07/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Хуже точно не стало. Потому что раньше "каждый школьник" мог поднять свой
    >дхцп-сервер и тем самым нагадить своему прову. Теперь это стало чревато.
    >
    >
    >Вообще сам давно собирался такую прогу написать, да все руки не доходили.
    >Спасибо ребятам.
    >
    >В крон, однозначно :)

    А оборудование настроить правильно прову что мешает?.. Один костыль другим подправлять, блин. :-\

     
     
  • 4.14, RomanCh (ok), 12:17, 13/07/2009 [^] [^^] [^^^] [ответить]  
  • +/
    > А оборудование настроить правильно прову что мешает?..

    Чаще всего мешает отсутствие денег на умные железяки умеющие делать DHCP snooping ;-)

     
     
  • 5.15, PereresusNeVlezaetBuggy (ok), 12:43, 13/07/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >> А оборудование настроить правильно прову что мешает?..
    >
    >Чаще всего мешает отсутствие денег на умные железяки умеющие делать DHCP snooping
    >;-)

    Ага. Это называется "времени на то, чтобы что-то сделать, вечно не хватает, но зато на переделки время всегда находится".

     
     
  • 6.28, RomanCh (ok), 19:41, 13/07/2009 [^] [^^] [^^^] [ответить]  
  • +/
    > Ага. Это называется "времени на то, чтобы что-то сделать, вечно не хватает, но зато на переделки время всегда находится".

    Что-то вы упорно не желаете меня понимать. "Время" далеко не всегда равно "деньги". Были бы везде умные железки умеющие фильтровать по ACL - ни кто бы с этим не парился. Да вот только что бы перевести не маленькую сеть (десятки тысяч хостов) целиком на умные железки - сами посчитайте сколько надо $$$...

     
     
  • 7.31, PereresusNeVlezaetBuggy (ok), 20:21, 13/07/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >> Ага. Это называется "времени на то, чтобы что-то сделать, вечно не хватает, но зато на переделки время всегда находится".
    >
    >Что-то вы упорно не желаете меня понимать. "Время" далеко не всегда равно
    >"деньги". Были бы везде умные железки умеющие фильтровать по ACL -
    >ни кто бы с этим не парился. Да вот только что
    >бы перевести не маленькую сеть (десятки тысяч хостов) целиком на умные
    >железки - сами посчитайте сколько надо $$$...

    Хех. Я когда на нынешнюю работу пришёл (не-ИТ контора), здесь тоже уже стояло много умных железок. Если б ими ещё и пользовались… Мозги нужны, мозги. Тогда и экономить будут на том, на чём надо. :)

     
     
  • 8.32, RomanCh (ok), 20:57, 13/07/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Согласен Да только вот как вы понимаете - экономика и экономия далеко не всегда... текст свёрнут, показать
     
  • 5.18, Arti (??), 15:01, 13/07/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Вы с чем собираетесь бороться?
    Если с "левыми" DHCP серверами, то  DHCP snooping Вам не нужен. Достаточно ACL способный выделить udp с портом источника 67, остальное по вкусу.
     
     
  • 6.23, настоящий_аноним (?), 15:12, 13/07/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Вы с чем собираетесь бороться?
    >Если с "левыми" DHCP серверами, то  DHCP snooping Вам не нужен.
    >Достаточно ACL способный выделить udp с портом источника 67, остальное по
    >вкусу.

    И все-таки это паллиатив. До появления этой проги единственной эффективной мерой была монтировка... красная :)

     
  • 6.29, RomanCh (ok), 19:44, 13/07/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Пардон, действительно выше написал ерунду про DHCP snooping - просто в голове эта тема вертелась. Конечно в такой ситуации нужен ACL.
     
  • 4.24, настоящий_аноним (?), 15:14, 13/07/2009 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >А оборудование настроить правильно прову что мешает?.. Один костыль другим подправлять, блин.
    >:-\

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

     
  • 3.33, User294 (ok), 21:24, 13/07/2009 [^] [^^] [^^^] [ответить]  
  • +/
    > Потому что раньше "каждый школьник" мог поднять свой дхцп-сервер и тем самым нагадить
    > своему прову.

    А я думал что нормальные провы это уже пролечили - путем установки до юзеров свичей способных применять хотя-бы простейшее фильтрование.Удавить юзерам порт 67 - и все, возможность такого саботажа исключается на корню.А так да - видел как подъем левого DHCP положил админам корпоративную локалку, когда кто-то по головотяпству поднял левый DHCP.Выглядит это и правда прикольно - юзерье начинает отхватеывать левые айпи и после этого плотной стаей идет иметь мозг админу :)

    > Теперь это стало чревато.

    Теперь провы с хреновым оборудованием и школьники будут меряться пиписьками - у кого DHCP сдохнет первым :)

     

  • 1.2, al (??), 09:06, 13/07/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    ну наконец то..
    Искал такую с год назад и не нашел.
    Теперь все в ажуре
     
     
  • 2.9, jy (?), 10:45, 13/07/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Самому написать за пол часа можно.
     
     
  • 3.11, BSA (?), 12:02, 13/07/2009 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Странно, что тогда никто не написал...
     
     
  • 4.50, jy (?), 21:23, 26/07/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Странно, что тогда никто не написал...

    У меня есть заготовки необходимых скриптов. А вот студентам подавай готовое

     

  • 1.3, al (??), 09:16, 13/07/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Тереь вопрос, как защитить "правильный" dhcp сервер от подобных програм??
     
     
  • 2.6, Аноним (-), 10:22, 13/07/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Модуль recent спасет отца русской демократии ;)
     
     
  • 3.8, настоящий_аноним (?), 10:26, 13/07/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Модуль recent спасет отца русской демократии ;)

    А его что, под arptables уже портировали?

    DHCP в iptables не верит :)

     
     
  • 4.10, Аноним (-), 11:25, 13/07/2009 [^] [^^] [^^^] [ответить]  
  • +/
    ebtables вобще-то ;)
    да вобщем-то мы тут обсудили, спасает только MAC-биндинг на порту доступа + DHCP Snooping на аггрегации или на досутпе если есть возможность. все остальное прога обойдет.
     
  • 2.7, настоящий_аноним (?), 10:24, 13/07/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Тереь вопрос, как защитить "правильный" dhcp сервер от подобных програм??

    Глупый вопрос (простите за прямоту).

    У правильного сервера всегда жестко прописан набор обслуживаемых маков, поэтому к такому досу он не чувствителен.

    А те, кто к макам не привязывается, сами такую участь заслужили.

    Вон на днях мой криворукий коллега в соседнем сегменте сети поднял свой сервак. Маками своими ограничиться не озаботился. А для половины моих компов его сервак по сетевой дистанции ближе (такая уж у нас дурацкая система). В результате - пол-сети в ауте. Особенно красиво это выглядело с учетом того, что у них авторизация через новелл-клиент: нет сети - нет компа.

     
     
  • 3.13, Rat (??), 12:13, 13/07/2009 [^] [^^] [^^^] [ответить]  
  • +/
    > авторизация через новелл-клиент: нет сети - нет компа.

    Так в NDS есть же вход на комп локальным пользователем без подключения сетевых ресурсов.

     
     
  • 4.22, настоящий_аноним (?), 15:10, 13/07/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >> авторизация через новелл-клиент: нет сети - нет компа.
    >
    >Так в NDS есть же вход на комп локальным пользователем без подключения
    >сетевых ресурсов.

    Нет. У нас системная авторизация через нетварь идет. Пока в новеле не авторизуешься, до локальной авторизации не допустят.

    Или я что-то упустил?

     
     
  • 5.27, Rat (??), 16:39, 13/07/2009 [^] [^^] [^^^] [ответить]  
  • +/
    > Пока в новеле не авторизуешься, до локальной авторизации не допустят.
    > Или я что-то упустил?

    В окне авторизации можно поставить галку "Только в рабочей станции" и после в "Дополнительно" задать локального пользователя и имя компьютера(либо пользователь и имя домена для AD при смешанной авторизации).Я говорю о полноценном Novell Client 32.
    PS: Это возможно конечно отключить политиками, но на мой взгляд это просто вредительство в данном случае.

     
  • 3.16, Аноним (-), 13:37, 13/07/2009 [^] [^^] [^^^] [ответить]  
  • +/
    А есть какая нибудь нормальная система, что бы однозначно идентифицировать dhcp сервак клиентом, через сертификат например. Что бы он другие dhcp сервера игнорил?
     
     
  • 4.34, User294 (ok), 21:35, 13/07/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >А есть какая нибудь нормальная система, что бы однозначно идентифицировать dhcp сервак
    >клиентом, через сертификат например. Что бы он другие dhcp сервера игнорил?

    Вам не кажется что сие хоронит идею DHCP?Идея то в автоматическом получении параметров клиентами после широковещательного запроса.Т.е. админам достаточно DHCP сервак поднять и клиенты сами получат адреса.А если на каждую машину что-то там предустанавливать - можно просто статичные айпишники вбить.Ничем не лучше особо.Рукоблудство 1 фиг надо на каждой машине.Трабл простой: а кому мы будем доверять по умолчанию при автоконфигурации?Какому DHCP?И почему - именно ему?Чем он лучше иных с точки зрения клиента?Правильно - кому доверять может определить только админ.Ну, если ему это на каждой машине определять придется, чем это так уж лучше прописки статичных айпишников?Автоконфигурации уже все-равно не получается... (какая разница-влить на комп сертификат или просто настройки сети?)

     
     
  • 5.45, Аноним (-), 15:11, 15/07/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Когда машину в домен вводишь, все равно приходится кого нибудь посылать, что бы настроил и ввел логин и пароль. Либо еще както заранее озаботиться и подготовить соответсвующий диск, а значит туда можно и ручками нужный сертификат пихнуть.

    PS. Увы не смог оперативно ответить, а значит и ответа от вас скорее всего не дождусь.

     
  • 5.49, aim (ok), 05:59, 17/07/2009 [^] [^^] [^^^] [ответить]  
  • +/
    не кажется.

    DHCP хороша тем что клиенту не надо пояснять что делать - они комп включили и в сети. а статика - надо чтобы они ещё и правильно сеть настроили.

     
  • 3.17, PereresusNeVlezaetBuggy (ok), 14:08, 13/07/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >>Тереь вопрос, как защитить "правильный" dhcp сервер от подобных програм??
    >
    >Глупый вопрос (простите за прямоту).
    >
    >У правильного сервера всегда жестко прописан набор обслуживаемых маков, поэтому к такому
    >досу он не чувствителен.
    >
    >А те, кто к макам не привязывается, сами такую участь заслужили.

    Лично я руки таким провайдерам отрывать готов, которые до сих пор к MAC'ам привязываются. Жутко неудобно. Особенно если техподдержка не круглосуточная. Да и в корпоративной сети это тоже не всегда приемлемо, к сожалению (уже больше из-за самодурства начальства, но не суть).

     
     
  • 4.20, настоящий_аноним (?), 15:06, 13/07/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Это две стороны одной медали: вы смотрите со стороны пользователя, я смотрю со стороны админа. С точки зрения локалки, дхцп-сервер без привязки к "контингенту" - более чем достаточное основание для кастрации его владельца.

    В сети провайдера, где дхцп должен быть _только один_, это еще в принципе терпимо.

    >Лично я руки таким провайдерам отрывать готов, которые до сих пор к MAC'ам привязываются.

    Впервые вижу человека, которому не нравится белый IP :)

     
     
  • 5.25, PereresusNeVlezaetBuggy (ok), 15:14, 13/07/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Это две стороны одной медали: вы смотрите со стороны пользователя, я смотрю
    >со стороны админа.

    Я стараюсь смотреть с обеих сторон, иначе общий язык находить сложно. Всё-таки компы для людей, а не наоборот.

    > С точки зрения локалки, дхцп-сервер без привязки к
    >"контингенту" - более чем достаточное основание для кастрации его владельца.

    Лишний DHCP-сервер - да, за такое у меня докладная заму генерального по безопасности сразу идёт. А вот "лишний" компьютер - это, порой, приходится терпеть. :(

    >В сети провайдера, где дхцп должен быть _только один_, это еще в
    >принципе терпимо.
    >
    >>Лично я руки таким провайдерам отрывать готов, которые до сих пор к MAC'ам привязываются.
    >
    >Впервые вижу человека, которому не нравится белый IP :)

    Эммм... Не понял. Вы про то, чтобы кто-то другой в сети не начал притворяться моим IP-шником? Так мой пров, например, уже года полтора как научился пользоваться VLAN'ами (другое дело, что долгое время у нас в доме стояло какое-то г***о, которое с ними криво работало, но однажды оно, наконец, сгорело :) ), очень помогает. И на работе сейчас я стараюсь реализовать эту схему.

     
     
  • 6.36, User294 (ok), 21:55, 13/07/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Я стараюсь смотреть с обеих сторон, иначе общий язык находить сложно. Всё-таки
    >компы для людей, а не наоборот.

    Он смотрит с точки зрения "провайдерского" адмна.А вы с точки зрения "корпоративного" ;)

    >Лишний DHCP-сервер - да, за такое у меня докладная заму генерального по
    >безопасности сразу идёт.

    Провайдера мало утешит взбучку юзеру устроить.Как минимум - юзеры сегмента вставшего из-за дятла раком будут осаждать саппорт.А то и бабло за недооказание услуги резонно попросят назад.Ну а долбо...в в локалках спосбных перепутать у своего роутера WAN и LAN, чисто в силу бестолковости - навалом.И их в отличие от сотрудников - не уволишь.И вообще, от "увольнения" юзера, даже тупого, в минусе - прежде всего сам пров.В общем то эзернет никогда не предназначался для крупномасштабного провайдинга, а интернет протоколы делались с иными целями и задачами.А время рассудило иначе.В итоге нормальные провы обученые жизнью и суровыми реалиями нынче просто давят фильтрами на "продвинутых" свичах перед юзерами такие левые DHCP, посему у них просто нет проблем с DHCP.Ну и всякие там плюшки типа отключения юзеру порта ремотным управлением скриптом дернутым из биллинга если юзер не заплатил, etc.Это борьба с теми кто тотально не хочет платить за доступ ... при дерьмовом оборудовании у прова чувак может до упора юзать LAN прова, бесплатно.При том что он за поддержку инфраструктуры оной сети ни копейки не платит а вот прову обслуживание огроменной сети что-то стоит, т.е. при большом числе халявщиков пров оказывается в лузерах.Все эти простые соображения заставляют провов использовать иные подходы нежели у корпоративщиков.

     
     
  • 7.38, PereresusNeVlezaetBuggy (ok), 22:19, 13/07/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >>Я стараюсь смотреть с обеих сторон, иначе общий язык находить сложно. Всё-таки
    >>компы для людей, а не наоборот.
    >
    >Он смотрит с точки зрения "провайдерского" адмна.А вы с точки зрения "корпоративного"
    >;)

    Вы таки думаете, что я не представляю себе масштаб проблем, которые может вызвать у провайдера левый DHCP-сервер? :)

    >[оверквотинг удален]
    >обученые жизнью и суровыми реалиями нынче просто давят фильтрами на "продвинутых"
    >свичах перед юзерами такие левые DHCP, посему у них просто нет
    >проблем с DHCP.Ну и всякие там плюшки типа отключения юзеру порта
    >ремотным управлением скриптом дернутым из биллинга если юзер не заплатил, etc.Это
    >борьба с теми кто тотально не хочет платить за доступ ...
    >при дерьмовом оборудовании у прова чувак может до упора юзать LAN
    >прова, бесплатно.При том что он за поддержку инфраструктуры оной сети ни
    >копейки не платит а вот прову обслуживание огроменной сети что-то стоит,
    >т.е. при большом числе халявщиков пров оказывается в лузерах.Все эти простые
    >соображения заставляют провов использовать иные подходы нежели у корпоративщиков.

    Вы это мне рассказываете? Зачем??? :))

     
     
  • 8.39, User294 (ok), 22:58, 13/07/2009 [^] [^^] [^^^] [ответить]  
  • +/
    А черт вас знает - если вы в курсе то почему вы с вон тем админом спорите Вы б в... текст свёрнут, показать
     
     
  • 9.40, PereresusNeVlezaetBuggy (ok), 23:16, 13/07/2009 [^] [^^] [^^^] [ответить]  
  • +/
    И рассуждаю Почему когда я соглашаюсь, надо пытаться всё равно спорить 8212 ... текст свёрнут, показать
     
  • 9.41, RomanCh (ok), 23:40, 13/07/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Эээ, вы как бы не правы В принципе в IPv4 более 4х миллиардов адресов, но это н... текст свёрнут, показать
     
  • 4.35, User294 (ok), 21:37, 13/07/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Лично я руки таким провайдерам отрывать готов, которые до сих пор к
    >MAC'ам привязываются. Жутко неудобно. Особенно если техподдержка не круглосуточная.

    Эээ а прописать мак адрес - не того?Даже многие soho роутеры по этой причине умеют fake-ить мак на WAN порту.Чтоб юзер мог прикинуться шлангом^W своей старой сетевухой...

     
     
  • 5.37, PereresusNeVlezaetBuggy (ok), 22:17, 13/07/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >>Лично я руки таким провайдерам отрывать готов, которые до сих пор к
    >>MAC'ам привязываются. Жутко неудобно. Особенно если техподдержка не круглосуточная.
    >
    >Эээ а прописать мак адрес - не того?Даже многие soho роутеры по
    >этой причине умеют fake-ить мак на WAN порту.Чтоб юзер мог прикинуться
    >шлангом^W своей старой сетевухой...

    Многие, но не все. Мне ли рассказывать, что сначала обычно приобретается "крутое" железо, а уже потом, когда ничего не получается, зовут специалиста всё это настроить. Это я именно про SOHO.

    И не все сетевухи умеют прикидываться. Более того, если одни могут этот MAC запомнить, то другим его надо вбивать при каждом запуске, что чревато (в клинических случаях, кои наблюдать приходилось) опять же автоматическим отключением порта провайдера - дескать, мелькнул чужой MAC. Более того, я сталкивался с сетевухой, которую смена MAC банально вводила в нестабильный режим — через некоторое время она тупо переставала обрабатывать пакеты, пока ей не сделаешь up/down. Кажется, это было что-то на VIA, но могу и соврать.

    Да, и о чём мы вообще все здесь спорим, если по сути друг с другом согласны? :)

     
     
  • 6.42, User294 (ok), 23:41, 13/07/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Ну да При этом спасибо если человек отличит WAN от LAN D Мне кажется что пров ... текст свёрнут, показать
     
  • 4.46, MNU (?), 10:57, 16/07/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Лично я руки таким провайдерам отрывать готов, которые до сих пор к
    >MAC'ам привязываются. Жутко неудобно. Особенно если техподдержка не круглосуточная. Да и
    >в корпоративной сети это тоже не всегда приемлемо, к сожалению (уже
    >больше из-за самодурства начальства, но не суть).

    В корпоративном секторе привязка MAC к IP и железу больше необходимость, чем паранойя или самодурства начальства. А в некоторых вещах это есть вообще обязаловка И ИМХО это правильно. И эта стратегия на практике остается адекватной когда у тебя в сети более 50 компов, и полюбому найдется 10-30% умников которые будут тыкаться в соседние розетки и менять ИП. Пример из личной практики: в одной конторе когда появился инет он толком кроме админов и 1 отделу никому и даром не нужен был. Но после прошествии некоторого месяца народ эту тему выкурил по полной. Доходило до того что народ обходил бан по IP методом мониторинга тачек которые имели доступ т.е. в случае если эта тачка выключена то на сетевухе менялся IP и оп инет есть. И что самое главное этим промышляла отнють не молодежь ;)

     
     
  • 5.47, PereresusNeVlezaetBuggy (ok), 17:33, 16/07/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >>Лично я руки таким провайдерам отрывать готов, которые до сих пор к
    >>MAC'ам привязываются. Жутко неудобно. Особенно если техподдержка не круглосуточная. Да и
    >>в корпоративной сети это тоже не всегда приемлемо, к сожалению (уже
    >>больше из-за самодурства начальства, но не суть).
    >
    >В корпоративном секторе привязка MAC к IP и железу больше необходимость, чем
    >паранойя или самодурства начальства.

    Про самодурство я говорил как раз в обратном смысле: что начальник хочет таскать на работу ноутбуки, не заботясь ни о чём, и хоть ты тресни.

    >[оверквотинг удален]
    >обязаловка И ИМХО это правильно. И эта стратегия на практике остается
    >адекватной когда у тебя в сети более 50 компов, и полюбому
    >найдется 10-30% умников которые будут тыкаться в соседние розетки и менять
    >ИП. Пример из личной практики: в одной конторе когда появился инет
    >он толком кроме админов и 1 отделу никому и даром не
    >нужен был. Но после прошествии некоторого месяца народ эту тему выкурил
    >по полной. Доходило до того что народ обходил бан по IP
    >методом мониторинга тачек которые имели доступ т.е. в случае если эта
    >тачка выключена то на сетевухе менялся IP и оп инет есть.
    >И что самое главное этим промышляла отнють не молодежь ;)

    Ну так и что? Защитной мерой эта привязка НЕ является. Ну или не выполняет такие функции. Зато создаёт дополнительную нагрузку в обслуживании: каждое перемещение рабочего места будет вызывать необходимость обновления базы IP => MAC. И как раз с ростом количества клиентов этот геморрой будет только расти.

    Вы людей в инет (или куда там ещё) по IP пускаете, и при этом админские права на тачках даёте (а иначе как они IP меняют)? Ну тогда и расхлёбывайте.

    Когда с помощью DHCP делается псевдостатика (как тут уже описывали, и я сам стараюсь по возможности это внедрять) - это лишь удобство обслуживания. Полноценную защиту от подобных приколов вам даст только VPN.

     
     
  • 6.48, MNU (?), 19:02, 16/07/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Ну так и что? Защитной мерой эта привязка НЕ является. Ну или не выполняет такие функции. Зато создаёт дополнительную нагрузку в обслуживании: каждое перемещение рабочего места будет вызывать необходимость обновления базы IP => MAC. И как раз с ростом количества клиентов этот геморрой будет только расти.

    Для некоторых "дядей" проще запретить, чем вникать в тонкости... А про перемещение в пространстве раб. места в таких сетях, а именно перенастройка портов мелочи жизни ... там больше юридического геморроя (разрешения, утверждения, мотивация ....)

    >Вы людей в инет (или куда там ещё) по IP пускаете, и при этом админские права на тачках даёте (а иначе как они IP меняют)? Ну тогда и расхлёбывайте.

    Это был пример ;)

     

  • 1.19, anon (?), 15:02, 13/07/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    а из-за ната можно его запустить?
     
     
  • 2.21, настоящий_аноним (?), 15:08, 13/07/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >а из-за ната можно его запустить?

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

     
     
  • 3.26, PereresusNeVlezaetBuggy (ok), 15:22, 13/07/2009 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >>а из-за ната можно его запустить?
    >
    >Насколько я знаю, DHCP работает в пределах одного хопа, т.е. его нельзя
    >запустить даже из-за перевалочного шлюза без ната. Между сервером и клиентом
    >не должно быть ничего серьезнее свичей и хабов.

    Если по-умному, то IP-броадкасты по определению не выходят за пределы подсети.

     
     
  • 4.43, cosgor (?), 09:21, 14/07/2009 [^] [^^] [^^^] [ответить]  
  • +/
    DHCP запросы пройдут через любую routed сеть главное чтобы первый маршрутизатор умел DHCP relay(ip helper).
     
     
  • 5.44, RomanCh (ok), 18:36, 14/07/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Вы отдаляетесь от начальной темы NAT'а. В данном случае через NAT проходит уже не первичный запрос, а то что генерирует агент пересылки DHCP. То что он есть как сущность - вовсе не факт. Мне кажется что задавший вопрос вообще слабо представлял что он спросил.
     
  • 2.30, RomanCh (ok), 20:14, 13/07/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Limited broadcast используемый DHCP протоколом в принципе может "ходить" только в пределах одного широковещательного Ethernet домена.
     
     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру