Комментарии 33
троллейбус из хлеба, конечно.
isc-dhcp может писать лог, реагировать на записи в котором как-то более удобно/логично чем это.
isc-dhcp может писать лог, реагировать на записи в котором как-то более удобно/логично чем это.
Здравствуйте!
Подскажите, пожалуйста, а что будет, если есть сетка, и вдруг приходят несколько негодяев, которые втыкают в сетку пару-тройку штук роутеров, или чего-либо ещё, которые сами умеют в DHCP-сервер, и адреса раздают из диапазона 192.168.0.xxx -192.168.xxx.xxx соответствено.
Как доверчивой сетевухе понять, чьё предложение принять?
Просто был такой Wi-Fi роутер, NetGear, и были из-за него много проблем.
Подскажите, пожалуйста, а что будет, если есть сетка, и вдруг приходят несколько негодяев, которые втыкают в сетку пару-тройку штук роутеров, или чего-либо ещё, которые сами умеют в DHCP-сервер, и адреса раздают из диапазона 192.168.0.xxx -192.168.xxx.xxx соответствено.
Как доверчивой сетевухе понять, чьё предложение принять?
Просто был такой Wi-Fi роутер, NetGear, и были из-за него много проблем.
Ну… Например, линуксовая утилита для получения адреса, dhclient, имеет ключ (-s ), которым можно явно указать адрес доверенного dhcp-сервера. Вариант.
Или изменить дефолтный порт (68) на другой.
Сложно сказать конкретнее.
Или изменить дефолтный порт (68) на другой.
Сложно сказать конкретнее.
Буква «S» в названии протокола DHCP означает «безопасность».
Никак. RFC 2131 вообще не определяет порядок выбора одного предложения из нескольких, это дело клиента. Но после выбора он шлёт широковещательный DHCPREQUEST с указанием своего решения, и его можно увидеть зондом в том же L2 сегменте. Например, в iptables есть модуль u32, которым можно легко и приятно заглядывать внутрь пакетов (мне был нужен DHCPREQUEST + REBIND, но посыл понятен):
А из лога уже можно подбирать чем угодно и радировать на базу «у нас завёлся злодей».
Никак. RFC 2131 вообще не определяет порядок выбора одного предложения из нескольких, это дело клиента. Но после выбора он шлёт широковещательный DHCPREQUEST с указанием своего решения, и его можно увидеть зондом в том же L2 сегменте. Например, в iptables есть модуль u32, которым можно легко и приятно заглядывать внутрь пакетов (мне был нужен DHCPREQUEST + REBIND, но посыл понятен):
iptables -I INPUT -p udp --sport 68 --dport 67 -d 255.255.255.255 \! -f -m u32 --u32 "0>>22&0x3C@20=0x01:0xFFFFFFFF && 0>>22&0x3C@8&0xFF000000>>24=0x01" -j LOG --log-prefix "DHCP REBINDING detected "А из лога уже можно подбирать чем угодно и радировать на базу «у нас завёлся злодей».
В сети, определенно, появится проблема.
Инструмент решения проблемы: en.wikipedia.org/wiki/DHCP_snooping
Инструмент решения проблемы: en.wikipedia.org/wiki/DHCP_snooping
В управляемых коммутаторах есть опция «DHCP snooping», позволяет определить на каком порту коммутатора находится «доверенный» DHCP сервер и все ответы на других портах отправлять в блок.
роутер это должен присекать. ну и option 82 в помощь ему :)
Хоккей на траве и балет на льду одновременно, вот это я понимаю!
Смотрели ли в сторону events в ISC DHCPD? Если да, чем не понравилось? Я их существование только что нагуглил, так что интересуюсь на будущее, вдруг доведётся в тех же дисциплинах выступать.
Смотрели ли в сторону events в ISC DHCPD? Если да, чем не понравилось? Я их существование только что нагуглил, так что интересуюсь на будущее, вдруг доведётся в тех же дисциплинах выступать.
Необходимая мне настройка производится так: подключаемся напрямую по витой паре к оборудованию, выдаём временный адрес по DHCP, производим настройку уже созданным скриптом. И так десять-двадцать раз подряд.
Многим известный isc-dhcp-server прекрасно справляется со своими обязанностями, но, увы, никак не уведомляет мой скрипт о том, что адрес выдан, поэтому нужно как-то блокировать выполение, пока адрес не выдан.
Да ну? Пример для сервера.
Для клиента dhclient:
-sf script-file
Path to the network configuration script invoked by dhclient when it gets
a lease. If unspecified, the default CLIENTBINDIR/dhclient-script is
used. See dhclient-script(8) for a description of this file.
Хм. Возможно, я плохо гуглил.
Но разве данный способ позволяет передавать какие-то ещё динамические параметры в скрипт (например, новый пароль)?
Но разве данный способ позволяет передавать какие-то ещё динамические параметры в скрипт (например, новый пароль)?
Это инструмент, а как им пользоваться — решать вам.
Вот кусок из моего dhcpd.conf. Решал похожую задачу 6-7 лет назад, работает до сих пор. Единственный нюанс, скрипт после запуска лучше отфоркнуть.
on commit {
set ClientIP = binary-to-ascii(10, 8, ".", leased-address);
set ClientMac = binary-to-ascii(16, 8, ":", substring(hardware, 1, 6));
execute("/usr/bin/perl","/opt/rew/event", ClientIP, ClientMac);
}
Вы не поверите, но уже есть такой на perl.
http://netlab.dhis.org/wiki/ru:software:perl:dhcp_server
Ну перл это полноценный язык программирования, в отличии от.
Поэтому поверим.
Поэтому поверим.
Офтопчег: миллиард раз поднималось, пора в миллиард первый.
Баш, конечно, это оболочка, но по какому критерию это не язык программирования? :) Хоть один аргумент.
Базовый барьер — полноту по Тьюрингу — баш вполне себе проходит.
Баш, конечно, это оболочка, но по какому критерию это не язык программирования? :) Хоть один аргумент.
Базовый барьер — полноту по Тьюрингу — баш вполне себе проходит.
В практическом контексте данной статьи — нет поддержки системных вызовов.
Соответственно — нет работы с сетью и подобным.
Что сильно ограничивает его применение.
Все остальное — религиозные споры.
Соответственно — нет работы с сетью и подобным.
Что сильно ограничивает его применение.
Все остальное — религиозные споры.
Таким же макаром какой-нибудь MATLAB — не язык программирования, что для кого-то потенциально звучит как оскорбление.
С учётом того, что в руках есть GCC + Make — можно всё замечательно «забиндить» в баш.
С учётом того, что в руках есть GCC + Make — можно всё замечательно «забиндить» в баш.
что для кого-то потенциально звучит как оскорбление.Честно говоря, мне плевать на чьи-то розовые сопли :) Если кто-то хочет обидеться — он найдет повод.
Я рассматриваю языки программирования как инструменты для решения задач. Какие-то из них подходят в определенных условиях хуже, какие-то лучше — у каждого своя ниша есть, наверное.
Шелл очень хорош для простых вещей, либо там куда тащить перл\питон неразумно и\или невозможно. Например — в OpenWRT роутеры с 4Мб флеша, половину из которых займет ядро.
Но начинать считать его полноценным языком программирования и пытаться написать что-либо серьезное — путь в никуда.
С учётом того, что в руках есть GCC + Make — можно всё замечательно «забиндить» в баш.Это уже будет не баш, а Си.
Утрированно, по Вашей логике всё что угодно на баше может быть «не баш, а Си». По-крайней мере интерпретаторы баша, написанные не на Си, мне не встречались.
Утрированно, по Вашей логике всё что угодно на баше может быть «не баш, а Си».Нет. Если ты доработаешь баш и добавишь туда требуемый функционал (полноценная работа с сокетами, опять таки) — это одно, это будет частью языка\интерпретатора.
Если же ты просто наколбасишь сбоку какую-то логику на Си для своей программы и будешь ее использовать, это — уже не часть языка. Это как просто вызвать netcat, как у автора данной заметки, и парсить его вывод.
Это все религиозные споры — есть инструмент, есть адекватность его использования в тех или иных условиях. А как его классифицировать — как язык программирования или нет, дело третье.
Есть еще такое понятие как General-purpose programming language и баша\шелла среди них нет. Его относят к Domain-specific language
Всё так — Вы разделили понятия UNIX Tools, UNIX shell и bash. И по DSL всё так, споров 0. Хотя есть один — фор экземпл, если учитывать, что DSL — это не ЯП, то Erlang — это не ЯП. Однако та же вики, на которую Вы ссылаетесь, говорит о том, что Erlang — это ЯП. Взаимоисключающие параграфы? Технически, можно ли использовать Erlang абсолютно без OTP (повторюсь — абсолютно, а не в минимальной мало-мальской его сборке), тем самым отвязав его от термина DSL? Что-то мне подсказывает, что нет. В таком случае Erlang — это ЯП или не ЯП?
Суть в том, что на чистом баше (без использования UNIX Tools) можно написать машину Тьюринга. На нём же можно «распарсить», интерпретировать и выполнить код любого другого языка (конечно, в рамках совместимости с набором команд процессора, на котором это запущено). Это будет сложно, долго, мучительно, бессмысленно из-за скорости работы конечной поделки… но это будет. Возможно, имея что-то минимально-крошечно-юниксовое, способное только запускать баш, читать из /dev/stdin и писать в /dev/stdout и /dev/stderr, можно написать и запустить UNIX/Linux внутри этого на чистом баше. А может даже и Windows, если совсем сойти с ума.
Суть в том, что на чистом баше (без использования UNIX Tools) можно написать машину Тьюринга. На нём же можно «распарсить», интерпретировать и выполнить код любого другого языка (конечно, в рамках совместимости с набором команд процессора, на котором это запущено). Это будет сложно, долго, мучительно, бессмысленно из-за скорости работы конечной поделки… но это будет. Возможно, имея что-то минимально-крошечно-юниксовое, способное только запускать баш, читать из /dev/stdin и писать в /dev/stdout и /dev/stderr, можно написать и запустить UNIX/Linux внутри этого на чистом баше. А может даже и Windows, если совсем сойти с ума.
И я учёл тот факт, что «полноценной работы с сокетами», например, у самого баша нет. Но при написании описанной мной OS полноценную работу с сокетами можно реализовать, скорее всего, внутри этой OS, как и полноценную поддержку оборудования. Или неполноценную поддержку виртуального оборудования, написанного на том же баше. А может и нельзя и я ничего не смыслю в информатике и вычислительной технике. :)
Ладно, я понял Вас. Отсутствие возможности в сисколы (и не только) из коробки превращает баш во всего-лишь админоориентированный UI.
Вы правы, умываю руки.
Вы правы, умываю руки.
В bash есть /dev/tcp и /dev/udp. Это не считается за "работу с сетью"?
Проще было взять Freeradius. Он отлично поддерживает DHCP, а в процессе обработки можно вообще делать все, что угодно, включая вызовы bash и perl.
Легко гуглятся реализации dhcp на perl и python.
За решение проблемы через одно место — плюс :)
Но можно было решить гораздо проще:
© man dnsmasq
Но можно было решить гораздо проще:
-6 --dhcp-script=<path>
Whenever a new DHCP lease is created, or an old one destroyed, or a TFTP file transfer completes, the executable specified by this option is run.
...
© man dnsmasq
Вот шутки про троллейбус шутками, а мне однажды что-то подобное, на ash вообще, для одной эмбеддед железки написанное, спасло серьезное количество времени.
kea-dhcp умеет хуки и еще много чего.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Собственный DHCP-сервер силами bash