Комментарии 31
Отличный материал! Спасибо автору!
Самая частая "атака" на dhcp сервер, это когда сотрудник втихаря принес для личного удобства и воткнул в локалку свой домашний tp-link, тем самым подняв в сети второй dhcp сервер и тем самым передав привет админу).
Было бы интересно почитать про использование dhcp опций: для чего существуют, как применяются, типовые решения.
сотрудник втихаря принес для личного удобства и воткнул в локалку свой домашний tp-link, тем самым подняв в сети второй dhcp сервер
Для этого ещё нужно, чтобы в сетку роутер был воткнут именно LAN-портом. Если в сетку включен WAN-порт, то никакого второго DHCP в сети не появится.
С вариантом роутера LAN-портом тоже есть простой метод борьбы. Да, роутер DHCP-сервер подымает, но у него у самого назначение своего LAN-адреса - статическое. И администратору всего-то и надо, что включить на клиентских портах коммутаторов DHCP Snooping. В этом случае роутер никуда и никогда не выйдет, ибо коммутатор его просто не выпустит.
Я же написал для чего они используются: для передачи параметров от сервера к хосту о сети. На скринах с трафиком можно увидеть что они из себя предоставляют
Так вот самое интересное, это как раз не описание протокола и перенасыщение сервера dhcp, это известно достаточно хорошо. А вот опции (их много и они имеют применение) и кейсы - это было очень интересно.
Я вас не понимаю. Я вам сказал, что я написал о них: Server Identifier, Option Overload, Requested IP Address, Host Name... Также на скриншотах можно видеть обилие опций. Этого вполне достаточно для формирования понимания того, что такое опции и для чего нужны. Подробнее можете почитать о них в RFC 2132 (ссылка в используемой литературе)
Вы не туда смотрите. Я постараюсь передать своими словами. Протокол dhcp имеет "стандартные опции", которые вы перечислили. А также в него была заложена дополнительная функциональность, так называемые, dhcp опции, которые на клиентской стороне позволяют реализовывать интересные фичи. Я вам как раз о них говорю. Именно возможность их применения в корпоративных сетях дает особенную тех изюминку.
3.5 Работа DHCP при статической адресации
А что, любой клиент, которому адрес назначен ручками, всё одно обращается к DHCP-серверу? или большинство клиентов по этому поводу вообще не заморачиваются? В общем, возникает два нерассмотренных в статье, но достаточно важных, вопроса.
Первый - как именно настраивается обращение клиента к DHCP-серверу за параметрами сети? это штатная настройка, или необходимо наличие хитровывернутого драйвера или даже специализированного ПО? Дополнительно - как настраивается то, что из переданного сервером клиент примет, а что проигнорирует.
Второй - как поступает DHCP-сервер в случае, если им инициативно обнаружено, что адрес из его пула присутствует в сети от клиента со статическим назначением? причём как в случае, когда у сервера адрес значится как неиспользуемый, так и в случае, когда он выдан и срок аренды не истёк. Кстати, тот же вопрос и по клиенту - что делает клиент с динамическим адресом, если обнаруживает дублирование адреса от клиента со статическим назначением.
Первый - обычно штатная, трудно сейчас найти TCP/IP стек который бы это не умел, поэтому обычно это достаточно просто включить в конфигурации, в embedded может быть запустить соответствующий процесс/тред итд.
Второй - никак, он этим не занимается, в контексте DHCP как минимум. И клиент обычно не обнаруживает. Всевозможные intrusion detection системы этим могут заниматься, если установлены
трудно сейчас найти TCP/IP стек который бы это не умел
ну вот как пример - я, скажем, на обычном Windows 10 хочу назначить адрес и маску статически, а адрес дефолтного шлюза взять с DHCP-сервера. Признаться, я лично не в курсе, как это сделать штатной настройкой IP-протокола на интерфейсе.
это врядли получится, потому что шлюз передается через option, а если статический адрес уже назначен то скорее всего система и не будет пытаться по dhcp запрос делать. Раньше в windows во всяком случае так было, сейчас не знаю, лет 20 не заглядывал.
Не понял... вы хотите сказать, что во фразе
DHCPINFORM – запрос от клиента, который уже имеет IP-адрес, параметров сети.
на самом деле должно быть что-то вроде "запрос от клиента, который уже получил IP-адрес от этого DHCP-сервера"?
да, обычно это так, DHCPINFORM используется в основном для того чтобы клиент после ребута мог продолжать использовать уже полученный адрес и проинформировать об этом dhcp сервер. Например для всевозможных принтеров, чтобы пользователям не искать их в сети после каждого перезапуска.
При изначально статических настройках IP обращения к dhcp серверу обычно не произходит.
вот, несколько обьяснений если интресно:
https://stackoverflow.com/questions/1545273/sending-dhcpinform-message-from-non-dhcp-client
Изза того что этот тип пакета был введён позже, его логика несколько дублирует изначально предусмотренную для DHCPREQUEST в этом случае, поэтому результат будет зависеть от реализации сервера. Проблем тут несколько:
1) при статической конфигурации никто не обязывает клиента вообще dhcp поддерживать, поэтому DHCPINFORM полностью опционален. Обычно так и подразумевается, что если пользователь внёс статический адрес, то dhcp там в сети и нет, зачем тогда заморачиваться.
2) запрос DHCPREQUEST после ребута показывает что клиент просит динамический адрес, и сервер может легко решить выдать новый. DHCPINFORM сообщает серверу что клиент намерен сохранить имеющийся
3) если клиент имеет часы и после ребута уверен что его lease еще не истекла, он может отправлять DHCPINFORM, по принципу что так всем проще, всё равно сервер не мог заметить его отсустствие и освободить или передать lease. Насколько я помню, во времена win-xp она именно так делала. Если не путаю конечно, давно это было.
Это что вообще у вас за конфигурация сети такая, что шлюз может внезапно поменяться, но гарантированно останется в той подсети, которую вы статически себе назначили?
не знаю как у него, но думаю элементарно, несколько wifi точек в одной подсетке
И что дальше? Как из наличия нескольких wifi точек следует возможность изменения основного шлюза без изменения сети?
не знаю что люди думают, там по dhcp каша должна быть та ещё. Но, тем не менее, могли ведь? - купили, поставили, все на одну подсетку настроили...
Хотя не факт что у них подсетки друг друга видят, может они меж собой и изолированные, всё равно наверх NAT идёт. Ну вот хочется человеку всегда иметь за собой один адрес, быть узнаваемым, может чтоб коллегам сказать, мало ли, сервис какой локальный. Может он и не админ там, чтоб самому сеть конфигурировать
Так что именно они смогли-то? Я знаю несколько способов полставить много wifi точек в одной сети, но ни один из них не будет одновременно позволять статически настраивать свой IP, но требовать получать адрес основного шлюза по DHCP.
не то что требовать, но вот представьте: была у них основная сеть со своим шлюзом, теперь купили на отдел по wifi точки, с настройками не разбирались, как были так и воткнули, только наверх dhcp клиента настроили (а вниз сервер). По дефолту будет NAT наверх на каждом, интернет работать будет, друг друга отделы не видят даже если подсетки совпадают. Теперь человек ходит между отделами, видит у себя всегда 192.168.0.0/24 подсетку, и хочет выставить какой-то локальный сервис, мало ли, шару или еще что, и обьявить всем отделам чтобы они про этот IP знали и могли обращаться когда он у них находится. А gateway у него в зависимости от дефолта в маршрутизаторе может меняться, как производитель поставил - когда .1 а когда .250 например. Грязно, но могут ведь?
Нет, просто шлюз - это наиболее "яркая" характеристика из параметров сети. Как пример.
каким-то скриптом после получения динамического адреса перенастроить на статический ещё можно наверное, хотя костыль будет тот ещё
Второй - как поступает DHCP-сервер в случае, если им инициативно обнаружено, что адрес из его пула присутствует в сети от клиента со статическим назначением?
В общем случае - сервер даже не проверяет ничего. Но некоторые реализации (например, DHCP-сервер в микротиках) умеют проверять наличие адреса в сети и в случае его занятости выдают другой.
Кстати, тот же вопрос и по клиенту - что делает клиент с динамическим адресом, если обнаруживает дублирование адреса от клиента со статическим назначением.
Скорее всего, клиент в таком случае глючит и не работает. Но некоторые могут детектировать конфликт адресов и сообщить об этом пользователю.
Каждому такому интерфейсу назначен свой MAC-адрес. Когда пользователь захочет выйти в Интернет по беспроводной сети, то получит один IP-адрес, а когда захочет выйти через проводную сеть, то получит совершенно иной IP-адрес, так как MAC-адреса на двух интерфейсах разнятся.
Каждому сетевому устройству присвоен свой MAC-адрес. Ну да для проводной сети и беспроводной сети разные ip-адреса, но чему и кому это мешает не понятно? Любой роутер использует технологию NAT, соответственно пофиг какой ip-адреса был и будет у клиента, если MAC-адрес остался прежний, клиент получит ответ на свой запрос, так работает любая "серая сеть" и офиса и дома.
Для реализации атаки будем использовать три виртуальные машины в Virtual Box с типом сетевого подключения «Внутренняя Сеть». При таком типе подключения машины изолированы от внешней сети и соединены между собой виртуальным коммутатором. Первая из машин будет являться DHCP-сервером, вторая – пользователем сети, последняя – хакером.
Если "хацкер" находится с вами в одной сети, это уже максимальное упущение и меньшее, что он сможет сделать это заполнить пул адресов. Опять же это лечится легко, присвоением статики машинам в сети, правильной настройкой коммутатора, настройка тайминга раздачи адресов и резервным отключение старых доступов при переполнении пула.
В итоге мы исчерпали весь пул свободных адресов на сервере и сделали его неспособным выдавать адреса новым клиентам. Если бы клиент попытался получить, свой сетевой адрес, то у него ничего бы не получилось, как можно видеть на gif-файле ниже.
Если клиенты уже были прописаны в сетке никто этого не поймет, опять же хороший коммутатор решает все эти проблемы.
И я сталкивался не с хакером, а с пользователями, которые в сетевую розетку включали свой роутер с включенным dhcp, вот это отлично убивало всю сеть до ближайшего коммутатора, а если коммутатор был один то всю сеть предприятия и решалось отключением портов и надругательством над пользователем.
Каждому сетевому устройству присвоен свой MAC-адрес.
Не, всё ещё хуже. К одному сетевому устройству (скажем, проводной сетевой карте) может быть привязана хренова гора логических интерфейсов. И каждый может (и скорее всего будет) иметь свой собственный оригинальный МАС.
Наиболее показательный пример - виртуальные машины, подключаемые к одному сегменту сети через один проводной физический интерфейс и один логический сегмент виртуального коммутатора гипервизора, работающий в режиме моста.
Знатоки может кто задавался таким вопросом
1) если подключить новый компьютер к роутеру ему выдаётся IP и он доступен в локалке по имени машины или IP
2) если подключить виртуальную машину в режиме BRIDGE (это когда выдается IP от роутера) , то он доступен в локалке по имени машины или IP
3) если подключить docker образ в режиме MACVLAN (это когда выдается IP от роутера) , то он доступен в локалке только по IP , но не по машин нейму. Если зайти в роутер, то там напротив IP в машиннейме будет прочерк. В чём проблема?
Очевидно, проблема в том, что DHCP клиент от докера (он же DHCP IPAM driver) не передаёт имя машины.
Кстати, доступность хоста по имени машины обычно с DHCP никак не связана, за разрешение этих имён в IP адреса отвечают протоколы NetBIOS и mDNS. Хотя некоторые DHCP сервера и правда умеют интегрироваться с DNS серверами, но роутеры так не умеют.
Хорошая статья! В начале есть опечатка "DHCPDISOCVER", нужно заменить на "DHCPDISCOVER".
Устройство протокола DHCP в технических подробностях/недостатки DHCP. Атака DHCP Starvation