Устройство протокола DHCP в технических подробностях/недостатки DHCP. Атака DHCP Starvation
Привет, Хабр, в данной статье мы в технических подробностях рассмотрим протокол DHCP 4 версии, поговорим о его недостатках, а также проведем атаку DHCP Starvation.
1 Теоретические сведения о протоколе DHCP
1.1 Общие сведения
DHCP (англ. Dynamic Host Configuration Protocol — протокол динамической настройки узла) — сетевой протокол прикладного уровня, обеспечивающий предоставление IP-адресов и сведений о сети для хостов, которые хотят подключиться к сети. После получения данных параметров хост становится полноправным узлом сети и может обмениваться пакетами в сети.
Ниже представлен заголовок протокола DHCP и дано краткое описание каждого поля.
Рисунок 1 — Заголовок DHCP
op — тип сообщения. 1 = BOOTREQUEST, 2 = BOOTREPLY;
htype — тип аппаратного адреса. Например, 1 для Ethernet;
hlen — размер аппаратного адреса. Например, 6 для Ethernet;
hops — число ретрансляторов, которые переслали DHCP-сообщение;
xid — идентификатор транзакции. Случайное число, однозначно определяющее диалог между клиентом и сервером;
secs — число секунд с начала процесса получения или обновления адреса, указываемое клиентом;
flags — флаги;
ciaddr — текущий IP-адрес клиента;
yiaddr — IP-адрес, который DHCP-сервер предлагает клиенту;
siaddr — IP-адрес сервера, для следующего сервера в процессе конфигурации. Обычно используется для загрузки образа операционной системы;
giaddr — адрес ретранслятора, передавшего DHCP-сообщение;
сhaddr — аппаратный адресс клиента;
sname — имя следующего сервера в процессе конфигурации;
file — имя файла, запрашиваемое клиентом с сервера, к примеру, файла операционной системы;
options — список параметров.
Первые 4 байта поля options содержат 4 десятичных значения 99, 130, 83 и 99 (OREO в кодировке ASCII). Данная последовательность называется magic cookie. Она нужна, чтобы отличать сообщения DHCP от сообщений BOOTP, которые имеют идентичный формат заголовка. Поле options содержит список параметров (опций), которые клиент и сервер сообщают друг другу. Все параметры начинаются с кода параметра, который занимает один байт. С помощью данного значения можно однозначно определить параметр. Далее один байт занимает длина параметра, а после содержится непосредственное значение параметра. В параметрах может быть, например, IP-адрес, который клиент желает получить, или маска подсети, которую сервер сообщает клиенту. Конец же опций обозначается байтом 0xff, который называется опцией end. При необходимости поля sname и file также могут использоваться для хранения параметров. Для этого в options должен присутствовать праметр Option Overload, в котором могут содержаться десятичные значения 1, 2 или 3, которые соответственно обозначают, что поле file используется для опций, поле sname используется для опций или оба этих поля используются для опций. В таком случае опции в полях file и sname должны начинаться с их первого байта и кончаться опцией end. Оставшиеся неиспользование байты должны быть равны нулю, так называемой опции pad. Для корректной обработки заголовка поле options должно обрабатываться перед полями sname и file.
DHCP инкапсулирует свои дейтаграммы в протокол UDP. Клиент при этом слушает порт 67, а сервер 68. Выбор в сторону UDP был сделан, так как сообщение DHCP не превышает максимально возможный размер полезной нагрузки в UDP, следовательно, не нужно решать проблему поставки пакетов в нужном порядке, а также потому что у DHCP есть механизм повторной отправки пакета, если он не дошел до получателя.
Поле op каждого сообщения клиента содержит значение 1 (BOOTREQUEST), а 2 (BOOTREPLY) содержится в каждом сообщении сервера. В каждом DHCP-сообщении содержится опция DHCP Message Type, которая указывает на тип сообщения:
DHCPDISCOVER — широковещательное сообщение клиента, который хочет начать процесс выделения IP-адреса;
DHCPOFFER — отклик от сервера на DHCPOFFER, содержащий предоставляемую им информацию;
DHCPREQUEST — сообщение от клиента для (a) подтверждения полученных параметров от сервера (б) подтверждения права на использование ранее выделенного адреса (в) продление срока аренды;
DHCPACK — отклик сервера на DHCPREQUEST, подтверждающий выделенный ранее IP-адрес и параметры сети;
DHCPNACK — отклик сервера на DHCPREQUEST, сообщающий о том, о непригодности запрашиваемого IP-адреса;
DHCPDECLINE — сообщение от клиента о том, что выданный в DHCPOFFER адрес занят;
DHCPRELEASE — сообщение клиента об освобождении сетевого адреса;
DHCPINFORM — запрос от клиента, который уже имеет IP-адрес, параметров сети.
1.2 Получение сетевого адреса
Рисунок 2 — Обмен сообщениями между клиентом и сервером при выделении сетевого адреса
В самом начале клиент находится в состоянии INIT. Для начала получения IP-адреса клиент передает широковещательное сообщение DHCPDISOCVER, сообщая серверам о том, что он хочет стать сетевым узлом данной сети. После этого пользователь переходит в состояние SELECTING.
Каждый сервер, слыша DHCPDISOCVER, отправляет в ответ на него DHCPOFFER, в который включает необходимые параметры сети в поле options и предлагаемый IP-адрес в поле yiaddr.
Клиент, получив одно или несколько сообщений DHCPOFFER, выбирает предпочитаемый сервер, исходя из предложенных параметров, и после отправляет широковещательный DHCPREQUEST, указывая в опции server identifier IP-адрес выбранного сервера, извещая тем самым выбранный сервер о том, что он согласен с параметрами, и остальные сервера о том, что он отклоняет их предложения. В опции requested ip клиент также указывает значение yiaddr из сообщения DHCPOFFER. После этого пользователь переходит в состояние REQUESTING.
Сервера получают запросы DHCPREQUEST. Если сервер, IP-адрес которого находится в опции DHCP Server Identifier, может предоставить предложенный IP-адрес клиенту, то он отправляет в ответ на DHCPACK, в котором указывает выделенный IP-адрес в поле yiaddr и те же параметры, что и при DHCPOFFER, и сохраняет запись в хранилище о том, что он предоставил клиенту предлагаемый IP-адрес. Если же сервер не может выделить предложенный ранее IP-адрес (например, если в он назначил его кому-то ещё), то он отправляет DHCPNACK.
Сервера, IP-адрес которых не соответствует адресу в requested ip, воспринимают сообщение как уведомление об отказе.
Клиент получает сообщение DHCPACK и выполняет настройку сетевых параметров хоста в соответствии с предоставленными данными в DHCPACK. После этого клиент переходит в состояние BOUND.
При получении DHCPNACK клиент начинает процесс получения IP-адреса заново.
Если клиент хочет отказаться от IP-адреса, он отправляет сообщение DHCPRELEASE.
3.3 Детали получения сетевого адреса
3.3.1 Сообщение DHCPDISCOVER
Если клиент не в состоянии принимать unicast-кадры без настроенного IP-адреса, то в таком он записывает в первый байт поля flags единицу (остальное байты зарезервированы и должны быть нулевыми). Данный флаг еще называют флагом широковещания. В таком случае сервер будет передавать сообщения DHCPOFFER в широковещательном режиме. Для того, чтобы клиент понял, что DHCPOFFER предназначается ему, он проверяет поле xid. Если оно идентично тому, которое было в DHCPDISCOVER, то клиент идентифицирует данный DHCPOFFER как предназначенный для него.
Не всякий клиент нуждается во всех параметрах, которые может предоставить DHCP-сервер. Поэтому применяется два подхода для уменьшения числа параметров. В первом подходе, если сервер не передал клиенту некоторые параметры, то клиент может использовать значения по умолчанию, определенные в Host Requirements RFC. Во втором методе клиент включает в опцию Parameter Requested List, в которой передает список желаемых к получению параметров. Также клиент может предложить желаемый IP-адрес и срок аренды используя опции Requested IP Adress и IP Adress Lease Time соответственно.
Клиент заполняет поле ciaddr нулевыми байтами, так как не имеет сетевого адреса.
При получении сообщения DHCPDISCOVER сервер выделяет клиенту IP-адрес руководствуясь следующим порядком:
Адрес клиента, имеющийся в текущей для него (клеинта) записи;
Предыдущий адрес клиента (освобожденный клиентом или истекший);
Адрес, указанный клиентом в Requested IP Adress;
Новый адрес из пула доступных адресов. Если giaddr равно нулю, то используется пул подсети, в которой находится сервер, иначе используется пул из подсети ретранслятора.
Перед тем, как отправить DHCPOFFER серверу следует проверить, что данный адрес не занят, используя ICMP-запрос к выделяемому адресу.
Также серверу нужно указать срок аренды сетевого адреса, руководствуясь следующими правилами:
a) Если у сервера есть запись о том, что клиент уже имеет сетевой адрес, и клиент не указал желаемый срок аренды в параметрах, то сервер возвращает срок до окончания аренды этого адреса;
б) Если у сервера нет записи о наличии у клиента IP-адреса, и клиент не указал желаемый срок аренды, то сервер возвращает время по умолчанию;
в) Если клиент указал срок аренды, то сервер может вернуть желаемое пользователем значение.
3.3.2 Сообщение DHCPOFFER
Клиенту стоит ждать некоторое время, чтобы собрать сообщения DHCP от всех серверов. Если значение поля xid в сообщение DHCPOFFER не соответствует значению xid в предыдущем сообщении DHCPDISCOVER, то клиент отбрасывает данное сообщение. Ретрансляторы, увидев DHCPOFFER, отправляют его DHCP-серверам. Если клиент не получил ни одного сообщения DHCPOFFER, то он отправляет сообщение DHCPDISCOVER по тайм-ауту.
3.3.3 Сообщение DHCPREQUEST
Если клиент включил список желаемых параметров в DHCPDISCOVER, то он должен включить идентичный список параметров в DHCPREQUEST. Поле ciaddr должно быть равно нулю, так как клиент ещё не получил окончательно IP-адрес. Если клиент не получил желаемый IP-адрес, то он может повторить передачу сообщения DHCPDISCOVER. Серверам в таком случае не стоит снова использовать предложенные ранее адреса.
3.3.4 Сообщение DHCPACK
Параметры в DHCPACK обязаны соответствовать параметрам в DHCPOFFER.
Если поле xid в сообщении DHCPACK не соответствует значению в предыдущих сообщениях, то такое сообщение нужно отбросить.
При получении DHCPACK клиенту следует проверить, что предложенный сервером адрес не занят, используя ARP-probe. Если адрес является свободным, то клиент отправляет широковещательный ARP-announcement, сообщая тем самым, что он является владельцем данного адреса, чтобы другие участники сети обновили свои ARP-таблицы. Если же данный адрес оказывается занятым, то клиент отправляет серверу сообщение DHCPDECLINE.
3.3.5 Сообщение DHCPDECLINE
При получении DHCPDECLINE сервер должен пометить сетевой адрес, предложенный клиенту, как недоступный.
3.3.6 Сообщение DHCPRELEASE
При получении DHCPRELEASE сервер должен пометить IP-адрес как свободный. Серверу следует сохранить запись о том, что клиент раньше использовал данный адрес, для повторного назначение его клиенту.
3.3.7 Повторная отправка сообщений
В ходе взаимодействия клиента и сервера клиент отвечает за повторную отправку сообщений при длительном отсутствии ответа от сервера (сообщений DHCPOFFER или DHCPACK). Клиент должен выбрать стратегию, которая бы учитывала характеристики соединения между клиентом и сервером. Например, в Fast Ethernet изначальную задержку стоит выбирать равную 4 секундам, а затем увеличивать вдвое до 64. При каждом новом повторе следует добавлять случайное значение из отрезка о -1 до 1.
3.3.8 Идентификация пользователя
DHCP-сервер должен закреплять каждый используемый IP-адрес в одной подсети за конкретным пользователем. Делается это с помощью идентификатора пользователя. В протоколе нет обязательных указаний по тому, каким образом должен выбраться идентификатор пользователя, но на практике используется два подхода. Во-первых, сервер может использовать пару тип протокола канального уровня/MAC-адрес пользователя. Для этого пользователь может указать его явно в опции Client Identifier. При отсутствии оной сервер может использовать данные из поля htype и MAC-адреса из заголовка канального уровня. Также пользователь может указывать добавить опцию Host Name, в которую записать свой идентификатор в виде ASCII-строки.
3.3.9 Аренда адресов
Сервер предоставляет каждому пользователю время, в течение которого он может пользоваться IP-адресом, указывая его в опции IP Address Lease Time. Значение, равное 0xffff, означает бессрочную аренду. Также сервер отсылает параметры Renewal Time Value и Rebinding Time Value, которые определяют параметры T1 и T2.
Параметры T1 и T2 определяют момент, когда пользователь должен продлить срок аренды. Значения для T1 вычисляется как 0,5*lease_time, T2 вычисляется как 0.875*lease_time .
В момент T1 клиент переходит в состояние RENEWING и пытается продлить аренду, посылая сообщение DHCPREQUEST серверу, который выдал ему IP-адрес. Клиент устанавливает в поле ciaddr свой текущий сетевой адрес. Поле server identifier пользователь оставляет пустым, так как оно используется в только DHCPREQUEST-сообщениях, которые являются ответом на DHCPDISCOVER.
В момент T2 клиент переходит в состояние REBINDING и отправляет широковещательное сообщение DHCPREQUEST для продления срока аренды.
После получения от сервера DHCPACK-сообщения (с идентичным xid) клиент рассчитывает новый срок аренды и переходит обратно в состояние BOUND.
В состояниях RENEWING клиенту стоит выждать половину времени от T2 перед повторной передачей DHCPREQUEST, а в состоянии REBINDING половину от времени аренды.
Если клиент так и не получает сообщение от сервера о продлении аренды и время аренды вышло, то клиент должен прекратить работу с выделенным ранее сетевым адресом, перейти в состояние INIT и начать процедуру получения адреса по-новому.
3.4 Повторное использование сетевого адреса
Если у клиента есть запись о ранее использованном сетевом адресе, и он хочет использовать его снова (например, после перезагрузки), то он может спросить разрешение у сервера об использовании прежнего IP-адреса. Соответствующие этапы представлены ниже.
Рисунок 3 — Обмен сообщениями между клиентом и сервером для продления сетевого адреса
В начале клиент находится в состоянии INIT-REBOOT. Он предает широковещательное сообщение DHCPREQUEST, в котором указывает прежний IP-адрес в опции Requested IP Adress. Поле ciaddr остается пустым, так как мы не можем утверждать, что мы владельцы нашего прежнего IP-адреса, так как DHCP-сервер мог выделить его кому-то ещё. Клиент обязан использовать ту же схему идентификации, какая была использована при начальном получении IP-адреса.
Сервер, получив DHCPREQUEST, сверяется со своей базой данных и, если подтверждает использование клиентом запрашиваемого IP-адреса, отправляет сообщение DHCPACK. В ином случае (например, клиент оказался в другой подсети или указал неверный адрес) сервер отправляет DHCPNACK. Если giaddr = 0, то серверу стоит отправить сообщение в широковещательном формате, так как клиент может не принимать unicast-сообщения, потому что у него может быть неверно настроен сетевой адрес. Если же giaddr отличен от нуля, то сервер передает сообщение ретранслятору. Сервер не проверяет незанятость IP-адреса с помощью ICMP, так как на это запрос может ответить его прежний владелец
После получения клиентом DHCPACK он окончательно проверяет свободность IP-адреса с помощью ARP-Probe, и если он свободен, то объявляет всем о том, что он его новый владелец, используя ARP-announcement. Если же выясняется, что адрес занят, то клиент отправляет серверу DHCPDECLINE и начинает конфигурационный процесс заново, переходя в состояние INIT.
Если же пользователь не получает ответа на свое сообщение, то повторяет отправку по тайм-ауту.
3.5 Работа DHCP при статической адресации
В DHCP присутствует механизм позволяющий работать с клиентами, которые получили свой сетевой адрес извне и нуждаются лишь в параметрах сети. В таком случае клиент должен отправить широковещательный запрос DHCPINFORM. DHCP-серверы отвечают на данное сообщение DCHPACK, включая запрашиваемые клиентом параметры, но не выделяя, не передавая срок аренды, не заполняя yiaddr и не проверяя существующую привязку IP-адреса клиента.
3.6 Анализ трафика DHCP
Клиент захотел попросить разрешение DHCP-сервер об использовании прежнего IP-адреса, указав его в опции Requested IP Address, который нашел у себя в локальном хранилище. На Linux это хранилище можно найти по пути /var/lib/dhcp/dhclient.leases.
Рисунок 4 — Запись о динамически выделенном IP-адресе в Linux
Рисунок 5 — Попытка запроса прежнего IP-адреса
Сервер отвечает клиенту DHCPNACK, так он не нашел записи о его принадлежности клиенту, так как клиент был перемещен в новую подсеть.
Рисунок 6 — Отказ сервера о выдачи IP-адреса
Получив отказ, клиент перешел в состояние INIT и начал процесс получения IP-адреса с нуля. В опции Host Name он указал имя хоста, которое сервер должен использовать для идентификации пользователя, а в опции Parameter List указал список желаемых параметров. Также наш клиент не способен принимать индивидуальный трафик без настроенного IP-адреса, потому он устанавливает широковещательный флаг в единицу.
Рисунок 7 — DHSPDISCOVER-запрос пользователя
Сервер, видя DHCPDISCOVER, отправляет широковещательный DHSCPOFFER (так как в запросе клиента был установлен флаг широковещания), в который включает предлагаемый IP-адрес в поле yiaddr и отправляет список параметров, которые он способен удовлетворить.
Рисунок 8 — DHCPOFFER-ответ сервера
Проверив xid и убедившись, что DHCPOFFER предназначен для него, клиент шлет ответный DHCPREQUEST с идентичными параметрами, что и в DHCPDISCOVER.
Рисунок 9 — DHCPREQUEST-запрос пользователя
Получив DHCREQUEST от пользователя, сервер отсылает DHCPACK, параметры которого идентичны параметрам в DCHPREQUEST.
Рисунок 10 — DHCPACK-ответ сервера
Рассмотрим алгоритм продления сетевого адреса.
Наш клиент (в этот раз другой) отправляет сообщение DHCP-серверу, выдавшему ему IP-адрес, включая в ciaddr свой сетевой адрес, так как время аренды ещё не истекло, и он является его полноправным владельцем.
Рисунок 11 — DHCPREQUEST-запрос клиента
Сервер получает DHCPREQUEST и продляет время аренды, отправляя клиенту значения для обновления T1 и T2.
Рисунок 12 — DHCPACK-ответ сервера
Наш клиент захотел отказаться от использования сетевого адреса и потому отправил сообщение DHCPRELEASE. В параметрах он указал минимум информации, нужную для того, чтобы сервер мог его идентифицировать и пометить адрес как свободный. Ответа от сервера не последовало, так как, согласно протоколу, клиент может отказаться от использования IP-адреса без разрешения сервера.
Рисунок 13 — Отказ от использования IP-адреса
3.7 Пара слов о ретрансляторах
В некоторых случаях DHCP-клиент и сервер могут находиться в разных сегментах сети. В такой ситуации DHCP-запросы клиента не смогут достичь сервера, поскольку широковещательные сообщения не передаются за пределы локальной сети. Для решения этой проблемы используются ретрансляторы DHCP.
Рисунок 14 — Пример конфигурации сети с ретранслятором
Ретранслятор DHCP — это устройство, которое принимает DHCP-запросы от клиентов в одной подсети и пересылает их на DHCP-серверы в других подсетях. Ретранслятор выступает посредником, обеспечивая взаимодействие между клиентами и серверами, которые не могут взаимодействовать напрямую.
Как работают ретрансляторы DHCP?
Клиент отправляет DHCPDISCOVER: При включении клиент отправляет широковещательный запрос DHCPDISCOVER для поиска DHCP-сервера.
Ретранслятор перехватывает запрос: Ретранслятор DHCP, настроенный на прослушивание DHCP-запросов, перехватывает DHCPDISCOVER.
Ретранслятор пересылает запрос: Ретранслятор добавляет в запрос информацию о себе (в поле giaddr) и отправляет его на DHCP-сервер, используя unicast-адресацию.
Сервер отправляет DHCPOFFER: DHCP-сервер обрабатывает запрос и отправляет unicast-сообщение DHCPOFFER на адрес ретранслятора, указанный в поле giaddr.
Ретранслятор пересылает ответ: Ретранслятор DHCP получает DHCPOFFER и отправляет его клиенту.
Клиент выбирает предложение и отправляет DHCPREQUEST: Клиент принимает предложение от сервера (переданное через ретранслятор) и отправляет широковещательный DHCPREQUEST.
Ретранслятор перехватывает и пересылает DHCPREQUEST: Ретранслятор перехватывает DHCPREQUEST и пересылает его на DHCP-сервер.
Сервер подтверждает выделение адреса: DHCP-сервер отправляет сообщение DHCPACK ретранслятору.
Ретранслятор пересылает DHCPACK клиенту: Ретранслятор DHCP пересылает DHCPACK клиенту, завершая процесс настройки IP-адреса.
4 Недостатки протокола DHCPv4
Одна из проблем протокола DHCPv4 заключается в идентификации клиента. Множество клиентов передают в качестве своего идентификатора пару тип оборудования/MAC-адрес, что создает проблему для клиентов, использующий несколько сетевых интерфейсов для выхода в сеть. Возьмем, к примеру, ноутбук, у которого наличествуется ethernet-интерфейс и беспроводной интерфейс. Каждому такому интерфейсу назначен свой MAC-адрес. Когда пользователь захочет выйти в Интернет по беспроводной сети, то получит один IP-адрес, а когда захочет выйти через проводную сеть, то получит совершенно иной IP-адрес, так как MAC-адреса на двух интерфейсах разнятся. Данная проблема может быть решена, если в качестве своего идентификатора клиент будет передавать имя хоста. Но если в сети будут клиенты с одинаковыми именами, то это будет создавать коллизии, в результате которых DHCP-сервер будет воспринимать запросы от разных клиентов как от одного хоста. В таком случае два хоста могут иметь один и тот же IP-адрес, что приведет к ошибкам в сети.
Также проблема DHCPv4 в том, что он использует огромное количество широковещательного трафика, который создает дополнительную нагрузку на другие узлы в сети.
Также может статься так, что два хоста могут выбрать одинаковый xid, в результате чего будут принимать ответы от DHCP-сервера, предназначенные не для них.
Так как DHCP использует незащищенные протоколы нижележащих уровней и не содержит механизма аутентификации, то имеет место спуфинг.
Примером эксплуатации незащищенности протокола IP может стать отправка поддельных ICMP-echo-ответов на ICMP-echo-запросы сервера. Перед отправкой клиенту IP-адреса в сообщении DHCPOFFER серверу следует проверить, является ли адрес занят кем-то ещё. Если сервер получит ICMP-echo-ответ, то пометит адрес как занятный и проделает то же самое с другими адресами, которые попытается выделить клиенту. Таким образом злоумышленник сможет полностью истощить пул свободных IP-адресов.
Пример эксплуатации незащищенности протокола похож на предыдущий. После получения предложения об IP-адресе в DHCPOFFER клиенту следует проверить незанятость адреса с помощью ARP-probe. Если он окажется занят, то клиент должен отослать серверу сообщение DHCPDECLINE, после которого сервер должен пометить предложенный этому клиенту адрес как недействительный и предложить новый. Данная атака также может исчерпать все свободные адреса у сервера.
Самой популярной атакой на DHCP, эксплуатирующую возможность спуфинга — DHCP Starvation. Смысл атаки заключается в том, чтобы отправлять огромное количество DHCPDISCOVER-сообщений DHCP-серверу и отправлять DHCPREQUEST-сообщения в ответ на сообщения DHCPOFFER от сервера. Обязательным условием является отличие идентификаторов клиента, для того чтобы сервер воспринимал запросы, как запросы от разных клиентов. Таким образом мы добьемся полного истощения пула IP-адресов DHCP-сервера и новые клиенты не смогут получить IP-адрес.
Существует атака под названием DHCP Spoofing. Суть её состоит в том, чтобы, маскируясь под DHCP-сервер, отправлять от его лица пользователю ложные данные о сети. Например, можно передать в качестве шлюза по умолчанию свой сетевой адрес и пропускать весь трафик клиента через себя. Обычно такая атака проводится после вывода из строя легального DHCP-сервера путем его истощения.
5 Реализация атаки DHCP Starvation
Для реализации атаки будем использовать три виртуальные машины в Virtual Box с типом сетевого подключения «Внутренняя Сеть». При таком типе подключения машины изолированы от внешней сети и соединены между собой виртуальным коммутатором. Первая из машин будет являться DHCP-сервером, вторая — пользователем сети, последняя — хакером.
На DHCP-сервере будет работать сервер isc-dhcp-server.
Записи на следующем скриншоте определяют конфигурацию нашего сервера.
Рисунок 14 — Конфигурация DHCP-сервера
Для атаки DHCP Starvation будет использована утилита dhcpig. Для начала атаки нужно прописать sudo dhcpig <имя интерфейса>.
Рисунок 15 — Логи в консоли после начала атаки
Как видно из логов в консоли, атакующий скрипт начал отсылать DHC_DISCOVER запросы и отвечать DHCPREQUEST сообщениями на DHCPOFFER. То же самое можно наблюдать в Wireshark.
Рисунок 16 — Взгляд на атаку через Wireshark
После того, как пул свободных адресов закончился сервер перестал отвечать на наши сообщения, что можно видеть ниже на скриншоте.
Рисунок 17 — Момент истощения сервера
Если заглянуть в логи сервера, то можно увидеть сообщение о том, что он не может предоставить свободный адрес.
Рисунок 18 — Логи сервера
В итоге мы исчерпали весь пул свободных адресов на сервере и сделали его неспособным выдавать адреса новым клиентам. Если бы клиент попытался получить, свой сетевой адрес, то у него ничего бы не получилось, как можно видеть на gif-файле ниже.
Отказ в обслуживании со стороны клиента
В данном случае мы пытались получить запустить процесс получения IP-адреса с состояния INIT на машине ничего не подозревающего клиента, используя утилиту dhclient, но так как нам не приходил DHCPOFFER, то утилита так и не выполнила свою работу.
6 Используемая литература
Ralph Droms, Ted Lemon The DHCP Handbook. Indianapolis: Sams Publishing, 2002;
RFC 2131: сайт. — URL: https://www.rfc-editor.org/rfc/rfc2131.html (дата обращения: 23.03.2024);
RFC 2132: сайт. — URL: https://www.rfc-editor.org/rfc/rfc2132.html (дата обращения: 23.03.2024).
