Васильев Кирилл

Метка: dhcp

  • DHCP FORCERENEW в RouterOS: работа и защита

    DHCP FORCERENEW в RouterOS позволяет серверу запросить у клиента обновление параметров аренды. В статье разобраны сообщения Reconfigure, команды RouterOS и причины не принимать такие запросы без оценки модели угроз.

    Функция появилась в RouterOS 7.19.1. Перед применением проверьте поддержку на клиенте и сервере, а также требования RFC 3203 и RFC 6704 к защите сообщения.

    *) dhcpv4-client/server - added support for DHCPv4 reconfigure messages;

    Помню, в момент самого релиза формулировка была ещё более загадочной: что-то вроде
    *) dhcpv4 - added supported reconfigure
    — ни тебе подробностей, ни разъяснений, только ссылка на номер RFC в документации. Всё как в лучших традициях: хочешь разобраться — копай сам.

    Попытался я на скорую руку вникнуть, как же работает этот новый функционал, но, признаюсь честно, быстро разобраться не удалось. Однако ребятам пообещал: разберусь и обязательно расскажу. Слово держать надо.

    Так что пусть эта статья станет своеобразным закрытием моего технического долга перед всеми, кто проходил у меня обучение на курсе MTCTCE. Надеюсь, теперь мы вместе разберёмся, что же на самом деле скрывается за этим загадочным «reconfigure» в DHCP.

    Принцип работы

    Вся суть этого функционала изложена в лаконичном, но ёмком RFC 3203. Если говорить простыми словами, то теперь DHCP-сервер может инициировать обновление параметров у клиента, не дожидаясь, пока тот сам решит это сделать.

    Как это работает

    1. Сервер отправляет сообщение FORCERENEW
      Представьте: администратор меняет настройки сети или хочет, чтобы определённый клиент получил новый IP-адрес. Вместо привычного ожидания окончания аренды или ручного вмешательства, сервер отправляет специальное DHCP-сообщение типа FORCERENEW на нужный хост.
    2. Клиент получает FORCERENEW и инициирует обновление
      Получив это сообщение, клиент тут же начинает процедуру продления аренды IP-адреса — как если бы он сам решил обновить параметры.
    3. Дальнейшие действия по стандарту DHCP
      Если на сервере для этого клиента изменился IP-адрес или другие параметры, сервер может ответить NAK (отказом), и тогда клиент начинает процесс получения адреса заново — с самого начала, как при первом подключении.

    Опция DHCP номер 53: новый тип сообщения FORCERENEW

    В протоколе DHCP для идентификации типа сообщения используется специальная опция с номером 53 — DHCP Message Type. Именно эта опция сообщает клиенту или серверу, какое действие требуется выполнить: DISCOVER, OFFER, REQUEST, ACK и так далее.

    С появлением поддержки RFC 3203 в список стандартных типов сообщений добавился новый — тип 9, который обозначает FORCERENEW.

    Это и есть тот самый сигнал клиенту: «Пора обновить параметры!»

    Настройки RouterOS для поддержки DHCP FORCERENEW

    В MikroTik RouterOS реализована поддержка механизма FORCERENEW, но для его полноценной работы необходимо правильно настроить как сервер, так и клиента. Всего есть три ключевых места, где можно управлять этим функционалом.

    1. DHCP-Client: разрешение на приём FORCERENEW

    Чтобы устройство на RouterOS могло принимать и корректно реагировать на сообщения FORCERENEW, необходимо явно разрешить эту возможность в настройках DHCP-клиента. Без этого параметра клиент просто проигнорирует подобные запросы.

    Пример настройки:

    [admin@client.dhcp.vasilevkirill.ru] > /ip/dhcp-client/add allow-reconfigure=yes
    • allow-reconfigure=yes — разрешает клиенту принимать и обрабатывать сообщения FORCERENEW.

    2. DHCP-Server: поддержка отправки FORCERENEW

    На стороне сервера также требуется включить поддержку отправки сообщений FORCERENEW. Это делается при создании или редактировании DHCP-сервера.

    Пример настройки:

    [admin@server.dhcp.vasilevkirill.ru] > /ip/dhcp-server/add use-reconfigure=yes
    • use-reconfigure=yes — разрешает серверу отправлять сообщения FORCERENEW клиентам, которые это поддерживают.

    3. Отправка FORCERENEW конкретному клиенту

    RouterOS позволяет отправить сообщение FORCERENEW не всем клиентам сразу, а выборочно — конкретному устройству по его lease. Это удобно, если нужно обновить параметры только у одного клиента.

    Пример команды:

    [admin@server.dhcp.vasilevkirill.ru] > /ip/dhcp-server/lease/send-reconfigure numbers=<lease_number>
    • <lease_number> — номер или идентификатор аренды (lease), который можно узнать через /ip/dhcp-server/lease/print.

    Пример использования:

    [admin@server.dhcp.vasilevkirill.ru] > /ip/dhcp-server/lease/print
# Найдите нужный lease и используйте его номер:
[admin@server.dhcp.vasilevkirill.ru] > /ip/dhcp-server/lease/send-reconfigure numbers=3

    Аутентификация по RFC 6704

    На первый взгляд всё кажется простым: сервер отправляет FORCERENEW, клиент обновляет параметры — красота! Но тут кроется серьёзная уязвимость: любой, кто находится в одной сети с клиентом, может отправить поддельное сообщение FORCERENEW. Это открывает огромную дыру в безопасности, ведь злоумышленник может массово сбивать клиентов с толку, вызывая хаос в сети.

    Почему это опасно: уязвимость RFC 3203

    Важно! В оригинальном RFC 3203, который впервые (но это не точно) описал механизм FORCERENEW, аутентификация сообщений не реализована. То есть, любой участник сети может сгенерировать и отправить FORCERENEW, и если клиент поддерживает этот механизм, он послушно выполнит команду, не проверяя её подлинность. Это — критическая брешь в безопасности.

    Как решается проблема: RFC 6704 и аутентификация

    На помощь приходит RFC 6704, который обновляет и дополняет описанный в RFC 3203 механизм. Суть решения — одноразовая аутентификация сообщений FORCERENEW. Это позволяет убедиться, что команда на обновление пришла именно от доверенного сервера, а не от злоумышленника.

    Исторический контекст

    • RFC 3118 — описывает общий механизм аутентификации для всех сообщений DHCP (DHCP Authentication), но практически не используется из-за сложности внедрения.
    • RFC 3203 — вводит FORCERENEW, но не реализует аутентификацию для этого типа сообщений.
    • RFC 6704 — уточняет и рекомендует использовать одноразовую аутентификацию именно для FORCERENEW, чтобы закрыть уязвимость.

    Как работает аутентификация FORCERENEW

    1. Клиент сообщает о поддержке аутентификации
      • В DHCP-запросе клиент указывает в опции 145, что поддерживает аутентификацию с использованием алгоритма HMAC-MD5 (значение 1).
      • Опция 145 в DHCP-запросе
    2. Сервер подтверждает поддержку аутентификации
      • В ответе DHCPOFFER сервер также указывает поддержку аутентификации.
      • Ответ сервера с поддержкой аутентификации
    3. Передача ключа аутентификации
      • Когда сервер подтверждает аренду (DHCPACK), он добавляет в сообщение опцию 90 — именно она содержит ключ для аутентификации (HMAC-MD5).
      • Опция 90 в DHCPACK
    4. Где увидеть ключ в RouterOS
      • На клиенте ключ отображается в статусе DHCP-клиента:[admin@client.dhcp.vasilevkirill.ru] > /ip/dhcp-client/print detail ... reconfigure-key="15697dbb1b55b34f63032287c93192da" ...
      • На сервере ключ виден в деталях аренды (lease):[admin@server.dhcp.vasilevkirill.ru] > /ip/dhcp-server/lease/print detail ... reconfigure-key="15697dbb1b55b34f63032287c93192da" ...
    5. Процесс обновления с аутентификацией
      • Когда сервер отправляет FORCERENEW, он использует этот ключ для подписи сообщения.
      • Клиент проверяет подпись и, если всё корректно, с радостью принимает обновление параметров.
      • Процесс обмена FORCERENEW
      • Успешное обновление клиента

    Как проверить результат

    • Сохраните экспорт конфигурации DHCP-клиента и сервера.
    • Отправьте FORCERENEW тестовому клиенту и проверьте журнал и обновление аренды.
    • Убедитесь, что неподтверждённое сообщение не меняет параметры клиента в вашей схеме.

    Источники и связанные материалы

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