- PVSM.RU - https://www.pvsm.ru -
Сервис, выдающий IP-адреса устройствам в локальной сети, кажется одним из самых простых и всем знакомых. Тем не менее у моих младших коллег до сих пор временами всплывают вопросы вроде «компьютер что-то получает какой-то странный адрес», а появление второго DHCP-сервера в одном сетевом сегменте вызывает некоторый трепет или проблемы в работе сети.
Чтобы у прочитавших этот материал такие вопросы не возникали, мне хотелось бы собрать в кучу основную информацию про работу механизмов выдачи адресов IP, особенности и примеры настройки отказоустойчивых и защищенных конфигураций. Да и возможно матерым специалистам будет интересно освежить нейронные связи.
Немного теории и решения интересных и не очень практических задач — под катом.
В современной локальной сети выдачей адресов обычно занимаются специализированные сервисы с поддержкой протоколов. Самым популярным из них является DHCP (Dynamic Host Configuration Protocol).
В принципе, специально для функционирования небольших сетей был создан стек технологий под названием Zeroconf [1]. Он позволяет обойтись без каких-либо централизованных сервисов и серверов, включая, но не ограничиваясь выдачей IP-адресов. Им закрываются (ну, или почти закрываются) следующие вопросы:
Получение IP-адреса (Automatic Private IP Addressing или APIPA). Система сама назначает себе IP из сети 169.254.0.0/16 (кроме сеток /24 в начале и конце диапазона), основываясь на MAC-адресе и генераторе псевдослучайных чисел. Такая система позволяет избежать конфликтов, а адрес из этой сети называют link-local — в том числе и потому, что эти адреса не маршрутизируются.
Поиск по имени. Система анонсирует свое сетевое имя, и каждый компьютер работает с ним как с DNS, храня записи у себя в кэше. Apple использует технологию mDNS (Multicast DNS), а Microsoft — LLMNR (Link-local Multicast Name Resolution), упомянутую в статье «Домены, адреса и Windows: смешивать, но не взбалтывать [2]».
Поиск сетевых сервисов. Например, принтеров. Пожалуй, самым известным протоколом является UPnP [3], который помимо прочего умеет сам открывать порты на роутерах. Протокол довольно сложен, в нем используется целый набор надстроек вроде использования http, в отличие от второго известного протокола — DNS-SD [4] (DNS Service Discovery), который попросту использует SRV-записи, в том числе при работе mDNS.
При всех плюсах Zeroconf — без каких-либо сакральных знаний можно собрать рабочую сеть, просто соединив компьютеры на физическом уровне, — IT-специалистам он может даже мешать.
Немного раздражает, не так ли?
В системах Windows для отключения автонастройки на всех сетевых адаптерах необходимо создать параметр DWORD с именем IPAutoconfigurationEnabled в разделе HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters и поставить ему значение 0.
Разумеется, Zeroconf подходит разве что для небольших изолированных сетей (например, встретились с приятелем с ноутбуками, соединили их по Wi-Fi и давай играть Diablo II, не тратя время на какие-то сервера), да и выводить локальную сеть в интернет тоже хочется. Чтоб не мучаться со статическими настройками каждого компьютера, были созданы специальные протоколы, включая героя дня — DHCP.
Одна из первых реализаций протокола для выдачи IP-адресов появилась более 30 лет назад и называлась RARP [5] (Reverse Address Resolution Protocol). Если немного упростить принцип его работы, то выглядело это так: клиент делал запрос на широковещательный адрес сети, сервер его принимал, находил в своей базе данных привязку MAC-адреса клиента и IP — и отправлял в ответ IP.
Схема работы RARP протокола.
И все вроде работало. Но у протокола были минусы: нужно было настраивать сервер в каждом сегменте локальной сети, регистрировать MAC-адреса на этом сервере, а передавать дополнительную информацию клиенту вообще не было возможности. Поэтому на смену ему был создан протокол BOOTP [6] (Bootstrap Protocol).
Изначально он использовался для бездисковых рабочих станций, которым нужно было не только выдать IP-адрес, но и передать клиенту дополнительную информацию, такую, как адрес сервера TFTP и имя файла загрузки. В отличие от RARP, протокол уже поддерживал relay — небольшие сервисы, которые пересылали запросы «главному» серверу. Это сделало возможным использование одного сервера на несколько сетей одновременно. Вот только оставалась необходимость ручной настройки таблиц и ограничение по размеру для дополнительной информации. Как результат, на сцену вышел современный протокол DHCP, который является совместимым расширением BOOTP (DHCP-сервер поддерживает устаревших клиентов, но не наоборот).
Важным отличием от устаревших протоколов является возможность временной выдачи адреса (lease) и передачи большого количества разной информации клиенту. Достигается это за счет менее тривиальной процедуры получения адреса. Если в старых протоколах схема была простая, вида запрос-ответ, то теперь схема следующая:
Схема общения клиента с сервером пересылки и сервером.
Подробнее про схему взаимодействия сервера и клиента и про структуру запросов и ответов можно почитать, например, в материале «Структура, формат и назначение DHCP пакетов [7]».
На нескольких собеседованиях меня спрашивали: «А какой транспорт и порт использует DHCP?» На всякий случай отвечаем: «Сервер UDP:67, клиент UDP:68».
С разными реализациями DHCP-сервера сталкивались многие, даже при настройке домашней сети. Действительно, сейчас сервер есть:
Конкретных реализаций довольно много, но, например, на SOHO-маршрутизаторах настройки сервера ограничены. В первую очередь это касается дополнительных настроек, помимо классического «IP-адрес, маска, шлюз, сервер DNS». А как раз эти дополнительные опции и вызывают наибольший интерес в работе протокола. С полным списком можно ознакомиться в соответствующем RFC [11], я же разберу несколько интересных примеров.
В этом разделе я рассмотрю практическое применение опций DHCP на оборудовании MikroTik. Сразу обращу внимание на то, что не все опции задаются очевидно, формат параметров описан в wiki [12]. Следует отметить также то, что опции клиент применяет, только когда сам их попросит. В некоторых серверах можно принудительно отправить настройки: например, в ISC DHCP Server за это отвечает директива dhcp-parameter-request-list, а в Dnsmasq —* *--dhcp-option-force. MikroTik и Windows такого не умеют.
Option 6 и Option 15. Начнем с простого. Настройка под номером 6 — это серверы DNS, назначаемые клиентам, 15 — суффикс DNS. Назначение суффикса DNS может быть полезным при работе с доменными ресурсами в недоменной сети, как я описывал в статье «Как мы сокращали персонал через Wi-Fi [13]». Настройка MikroTik под спойлером.
#Добавляем опцию 15. содержимое — сконвертированный в HEX суффикс.
/ip dhcp-server option
add code=15 name=dns-suffix value=0x57687920616c6c207468697320736869743f
#создаем набор опций
/ip dhcp-server option sets
add name=dns option=dns-suffix
#Добавляем опцию к DHCP-серверу для клиентов.
/ip dhcp-server network
set [find comment="wi-fi client dhcp"] dhcp-option-set=dns
Знание, что сервер DNS — это тоже опция, недавно пригодилось мне, когда разным клиентам нужно было выдать разные серверы DNS. Решение вида «выдать один сервер и сделать разные правила dst-nat на 53 порт» не подходило по ряду причин. Часть конфигурации снова под спойлером.
#настройка опций, обратите внимание, что ip экранирован одинарными кавычками
/ip dhcp-server option
add code=6 name=google value="'8.8.8.8'"
add code=6 name=cloudflare value="'1.1.1.1'"
#настройка клиентов
/ip dhcp-server lease
add address=10.0.0.2 dhcp-option=google mac-address=11:11:11:11:11:11 server=dhcp
add address=10.0.0.3 dhcp-option=cloudflare mac-address=22:22:22:22:22:22 server=dhcp
Option 66 и Option 67. Эти настройки пришли еще с BOOTP и позволяют указать TFTP-сервер и образ для сетевой загрузки. Для небольшого филиала довольно удобно установить туда микротик и бездисковые рабочие станции и закинуть на маршрутизатор подготовленный образ какого-нибудь ThinStation [14]. Пример настройки DHCP:
/ip dhcp-server option
add name="option66" code=66 value="s'192.168.88.1'"
add name="option67" code=67 value="'pxelinux.0'"
/ip dhcp-server option sets
add name="set-pxe" options=option66,option67
Option 121 и Option 249. Используются для передачи клиенту дополнительных маршрутов, что может быть в ряде случаев удобнее, чем прописывать маршруты на шлюзе по умолчанию. Настройки практически идентичные, разве что клиенты Windows предпочитают вторую. Для настройки параметра маршруты надо перевести в шестнадцатеричный вид, собрав в одну строку маску сети назначения, адрес сети и шлюз. Также, по RFC, необходимо добавить и маршрут по умолчанию. Вариант настройки — под спойлером.
Предположим, нам нужно добавить клиентам маршрут вида dst-address=10.0.0.0/24 gateway=192.168.88.2, а основным шлюзом будет 192.168.88.1. Приведем это все в HEX:
Данные для настройки | DEC | HEX |
Маска | 24 | 0x18 |
Сеть назначения | 10.0.0.0 | 0x0A 00 00 |
Шлюз | 192.168.88.2 | 0xc0 a8 58 02 |
Сеть по умолчанию | 0.0.0.0/0 | 0x00 |
Шлюз по умолчанию | 192.168.88.1 | 0xc0 a8 58 01 |
Соберем все это счастье в одну строку и получим настройку:
/ip dhcp-server option
add code=121 name=classless value=0x0A0000c0a8580200c0a85801
Подробнее можно прочитать в статье «Mikrotik, DHCP Classless Route [15]».
Option 252. Автоматическая настройка прокси-сервера. Если по каким-то причинам в организации используется непрозрачный прокси, то удобно будет настроить его у клиентов через специальный файл wpad (pac). Пример настройки такого файла разобран в материале «Proxy Auto Configuration (PAC) [16]». К сожалению, в MiroTik нет встроенного веб-сервера для размещения этого файла. Можно использовать для этого пакет hotspot [17] или возможности metarouter [18], но лучше разместить файл где-либо еще.
Option 82. Одна из полезнейших опций — только не для клиента, а для DHCP-релея. Позволяет передать серверу информацию о порте коммутатора, к которому подключен клиент, и id самого коммутатора. Сервер на основе этой информации в свою очередь может выдать уже клиенту какой-то определенный набор настроек или просто занести в лог — чтобы в случае необходимости найти порт подключения клиента, не приходилось заходить на все свитчи подряд (особенно, если они не в стеке).
После настройки DHCP-Relay на маршрутизаторе в информации о клиентах появятся поля Agent Circuit ID и Agent Remote ID, где первое — идентификатор порта коммутатора, а второе — идентификатор самого коммутатора.
Выдача адресов с option 82.
Информация выдается в шестнадцатиричном формате. Для удобства восприятия при анализе журнала DHCP можно использовать скрипты. Например, решение для решения от Microsoft опубликовано в галерее скриптов Technet под названием «Декорирование DHCP опции 82 [19]».
Также опция Option 82 активно используется в системе биллинга провайдеров и при защите сети от посторонних вмешательств. Об этом чуть подробнее.
Ввиду простоты протокола и присутствия широковещательных запросов есть эффективные атаки на инфраструктуру — в основном типа MITM («человек посередине»). Атаки производятся посредством поднятия своего DHCP-сервера или релея: ведь если контролировать выдачу сетевых настроек, можно запросто перенаправить трафик на скомпрометированный шлюз. Для облегчения атаки используется DHCP starvation (представляясь клиентом или релеем, злоумышленник заставляет «родной» DHCP-сервер исчерпать свои IP-адреса). Подробнее про реализацию атаки можно почитать в статье «Атакуем DHCP [20]», методом же защиты является DHCP Snooping.
Это функция коммутатора, которая позволяет «привязать» DHCP-сервер к определенному порту. Ответы DHCP на других портах будут заблокированы. В некоторых коммутаторах можно настроить и работу с Option 82 при ее обнаружении в пакете (что говорит о присутствии релея): отбросить, заменить, оставить без изменения.
В коммутаторах MikroTik включение DHCP Snooping производится в настройках бриджа:
#Включаем dhcp-snooping и option 82
/interface bridge
add name=bridge
set [find where name="bridge"] dhcp-snooping=yes add-dhcp-option82=yes
#ставим настраиваем доверенный порт
/interface bridge port
add bridge=bridge interface=ether1
add bridge=bridge interface=ether2 trusted=yes
Настройка в других коммутаторах происходит аналогичным образом.
Стоит отметить, что не все модели MikroTik имеют полную аппаратную поддержку DHCP Snooping — она есть только у CRS3xx.
Помимо защиты от злых хакеров эта функция избавит от головной боли, когда в сети появляется другой DHCP-сервер — например, когда SOHO-роутер, используемый как свич с точкой доступа, сбрасывает свои настройки. К сожалению, в сетях, где встречается SOHO-оборудование, не всегда бывает грамотная структура кабельной сети с управляемыми маршрутизаторами. Но это уже другой вопрос.
Красивая коммутационная — залог здоровья.
К другим методам защиты можно отнести Port Security («привязка» определенного MAC-адреса к порту маршрутизатора, при обнаружении трафика с других адресов порт будет блокироваться), Анализ трафика на количество DHCP-запросов и ответов или ограничение их количества, ну и, конечно, различные системы IPSIDS.
Если говорить не только о защите сети, но и о надежности, то не лишним будет упомянуть и про возможности отказоустойчивого DHCP. Действительно, при своей простоте DHCP часто бывает одним из ключевых сервисов, и при выходе его из строя работа организации может быть парализована. Но если просто установить два сервера с идентичными настройками, то ни к чему, кроме конфликта IP-адресов, это не приведет.
Казалось бы, можно поделить область выдачи между двумя серверами, и пусть один выдает одну половину адресов, а второй — другую. Вот только парализованная половина инфраструктуры немногим лучше, чем целая.
Разберем более практичные варианты.
В системах Windows Server начиная с 2012 система резервирования DHCP работает «из коробки», в режиме балансировки нагрузки (active-active) или в режиме отказоустойчивости (active-passive). С подробным описанием технологии и настройками можно ознакомиться в официальной документации [21]. Отмечу, что отказоустойчивость настраивается на уровне зоны, поэтому разные зоны могут работать в разном режиме.
Настройка отказоустойчивости DHCP-сервера в Windows.
В ISC DHCP Server для настройки отказоустойчивости используется директива failover peer, синхронизацию данных предлагается делать самостоятельно — например, при помощи rsync. Подробнее можно почитать в материале «Два DHCP сервера на Centos7... [22]»
Если же делать отказоустойчивое решение на базе MikroTik, то без хитростей не обойтись. Один из вариантов решения задачи был озвучен на MUM RU 18, а затем и опубликован в блоге автора [23]. Если вкратце: настраиваются два сервера, но с разным параметром Delay Threshold (задержка ответа). Тогда выдавать адрес будет сервер с меньшей задержкой, а с большей задержкой — только при выходе из строя первого. Синхронизацию информации опять же приходится делать скриптами.
Лично я в свое время изрядно потрепал себе нервов, когда в сети «случайно» появился роутер, подключенный в локальную сеть и WAN, и LAN интерфейсами.
Расскажите, а вам приходилось сталкиваться с проказами DHCP?
Автор: Tri-Edge
Источник [24]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/informatsionnaya-bezopasnost/329996
Ссылки в тексте:
[1] Zeroconf: http://www.zeroconf.org
[2] Домены, адреса и Windows: смешивать, но не взбалтывать: https://habr.com/ru/company/pc-administrator/blog/330944/
[3] UPnP: https://en.wikipedia.org/wiki/Universal_Plug_and_Play
[4] DNS-SD: http://www.dns-sd.org/
[5] RARP: https://tools.ietf.org/html/rfc903
[6] BOOTP: https://tools.ietf.org/html/rfc951
[7] Структура, формат и назначение DHCP пакетов: https://zametkinapolyah.ru/kompyuternye-seti/9-3-struktura-format-i-naznachenie-dhcp-paketov-soobshhenij-dhcpdiscover-dhcpoffer-dhcprequest-i-dhcpack.html
[8] документации: https://docs.microsoft.com/ru-ru/windows-server/networking/technologies/dhcp/dhcp-deploy-wps
[9] ISC DHCP Server: https://isc.org/dhcp/
[10] Dnsmasq: http://www.thekelleys.org.uk/dnsmasq/doc.html
[11] RFC: https://tools.ietf.org/html/rfc2132
[12] wiki: https://wiki.mikrotik.com/wiki/Manual:IP/DHCP_Server#DHCP_Options
[13] Как мы сокращали персонал через Wi-Fi: https://habr.com/ru/company/pc-administrator/blog/315984/
[14] ThinStation: https://thinstation.github.io/thinstation/
[15] Mikrotik, DHCP Classless Route: https://habr.com/ru/post/239141/
[16] Proxy Auto Configuration (PAC): https://habr.com/ru/sandbox/19972/
[17] hotspot: https://wiki.mikrotik.com/wiki/Manual:Customizing_Hotspot
[18] metarouter: https://habr.com/ru/post/248009/
[19] Декорирование DHCP опции 82: https://gallery.technet.microsoft.com/scriptcenter/Decode-DHCP-82-Option-a986460c
[20] Атакуем DHCP: https://habr.com/ru/company/dsec/blog/333978/
[21] документации: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn338979(v%3Dws.11)
[22] Два DHCP сервера на Centos7...: https://habr.com/ru/post/323984/
[23] автора: http://www.bubnovd.net/2017/07/dhcp-failover-with-routeros.html
[24] Источник: https://habr.com/ru/post/467333/?utm_source=habrahabr&utm_medium=rss&utm_campaign=467333
Нажмите здесь для печати.