Комментарии 21
Не сказать, что сильно надо, но дополнить статью примерами под спойлерами самих файлов, или важных частей из них на мой скромный взгляд не помешало бы.
Или, скажем, если новичок наткнётся на статью — иметь готовую комманду для симлинка.
А в целом спасибо, интересно
Или, скажем, если новичок наткнётся на статью — иметь готовую комманду для симлинка.
А в целом спасибо, интересно
Спасибо. Давно хотел разобраться, как работает resolvconf.
Интересная информация! А как можно уберечься от ситуации, когда злоумышленник получит физический доступ к сети, поднимет свой фиктивный сервер DHCP и начнёт делать разные неприятные штуки?
Вы не поверите как быстро смониторится новый dhcp в сети…
Раз как-то запустил кто-то из коллег виртуалку (bridged) со включенным dhcp — получил по рукам уже через 2 минуты (даже гнездо сетевое назвали, откуда уши торчат).
Злоумышленник должен себя вести тише воды ниже травы (а тут как залезть ночью в супермаркет и начать бить посуду, орать и вообще всеми доступными способами семафорить — я тут, берите меня тепленького).
Раз как-то запустил кто-то из коллег виртуалку (bridged) со включенным dhcp — получил по рукам уже через 2 минуты (даже гнездо сетевое назвали, откуда уши торчат).
Злоумышленник должен себя вести тише воды ниже травы (а тут как залезть ночью в супермаркет и начать бить посуду, орать и вообще всеми доступными способами семафорить — я тут, берите меня тепленького).
теоретически есть штуки типа "port security", но их не используют. Иногда файрволят dhcp на прикладном уровне (т.е. пропускают ack/offer только от авторизованных узлов). В случае обычной неуправляемой сети — с трудом.
Более того, злоумышленника, который дублирует анонсы обычного dhcp-сервера, но отдаёт опцией маршрутизацию на себя (для mitm'а) будет довольно сложно найти (если нет внимательности на местах).
Более того, злоумышленника, который дублирует анонсы обычного dhcp-сервера, но отдаёт опцией маршрутизацию на себя (для mitm'а) будет довольно сложно найти (если нет внимательности на местах).
Про dhclient-script, а именно, про хуки бред написан:
В начале dhclient-script определяются некоторые функции, которые могут быть переопределены в хуках entry.
Эти функции могут быть вызваны в теле dhclient-script после вызовов хуков entry и до вызовов хуков exit, или эти функции могут быть вызваны в хуках exit
А хуки exit предназначены для выполнения дополнительных действий.
В начале dhclient-script определяются некоторые функции, которые могут быть переопределены в хуках entry.
Эти функции могут быть вызваны в теле dhclient-script после вызовов хуков entry и до вызовов хуков exit, или эти функции могут быть вызваны в хуках exit
А хуки exit предназначены для выполнения дополнительных действий.
Поясните насчёт "бред" побдробнее. Зарнее спасибо.
<бред>
Entry вызываются когда dhcp-client только-только получает (получил) аренду, exit, соответственно, когда освободил (или она истекла).
</бред>
<на самом деле>
и entry и exit хуки вызываются и при получении аренды и при освобождении, только первые — в начале скрипта, а последние — в конце
</на самом деле>
Entry вызываются когда dhcp-client только-только получает (получил) аренду, exit, соответственно, когда освободил (или она истекла).
</бред>
<на самом деле>
и entry и exit хуки вызываются и при получении аренды и при освобождении, только первые — в начале скрипта, а последние — в конце
</на самом деле>
Вы хотите сказать, что при release entry-хук тоже будет вызван?
Прочитайте код dhclient-script и/или текст моего сообщения, пожалуйста!
Прочитал. Вы хотите сказать, что при release entry-хук тоже будет вызван?
Вот код вызова enter-hooks из dhcp-4.3.4/client/scripts/linux
if [ -f /etc/dhclient-enter-hooks ]; then
exit_status=0
. /etc/dhclient-enter-hooks
allow the local script to abort processing of this state
local script must set exit_status variable to nonzero.
if [ $exit_status -ne 0 ]; then
exit $exit_status
fi
fi
Перед ним только определение функции make_resolv_conf, то есть, никаких условий кроме наличия файла /etc/dhclient-enter-hooks
Да, я хочу сказать, что хуки вызываются в любом случае, если они есть и если до их вызова не произошла ошибка.
if [ -f /etc/dhclient-enter-hooks ]; then
exit_status=0
. /etc/dhclient-enter-hooks
allow the local script to abort processing of this state
local script must set exit_status variable to nonzero.
if [ $exit_status -ne 0 ]; then
exit $exit_status
fi
fi
Перед ним только определение функции make_resolv_conf, то есть, никаких условий кроме наличия файла /etc/dhclient-enter-hooks
Да, я хочу сказать, что хуки вызываются в любом случае, если они есть и если до их вызова не произошла ошибка.
Red Hat использует свою версию скрипта dhclient-script, весьма обширную и сложную, учитывающую множество настроек из ifcfg-ethXXX, в частности, интересовавшую меня опцию RES_OPTIONS. Debian и Ubuntu используют большей частью апстримовую версию, в которой такие изыски отсутствуют. В Centos 7 одно время в этом скрипте был баг, приводивший к тому, что при наличии строчки 'options' в /etc/resolv.conf при перезагрузке, из него удалялись все остальные строчки, кроме строчки с options, причём новые DNS-сервера в файл не добавлялись.
Со строчкой опшнс все проще. Я не совсем до конца раскопал этот скрипт, но я как я понял — ситуация следующая: Если есть файл /etc/resolv.conf.save — То абсолютно неважно чо у вас там в Ifcfg-xxxx написано — он тупо будет его ресторить. Наличие опции RES_OPTIONS, PEER_DNS и прочих ему по барабану. И собственно почему он его создает только с опшнс (Без резолверов к примеру) — я долго не мог понять, но видимо это связано как-то с изменениями в файле/настройках.
В итоге — после удаления этого .save файла и прописывания опций в resolv.conf — они вполне остаются на своих местах даже при изменении самих серверов (скрипт таки умеет отфильтровывать и оставялть опции)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Взаимоотношения dhcpclient и resolv.conf'а в Linux