Новости

Эта книга предназначена для тех, кому поручено администрировать сетевую инфраструктуру практически любого рода. Если вам интересно досконально узнать, как все работает в вашей сети, — эта книга для вас. Она также будет полезна, если вы часто теряетесь в догадках, как оснастить сеть различными службами, которые нужны вашей организации, но у вас нет бюджета на коммерческие продукты. Мы подробно разберемся, как работает каждая из представленных в книге служб Linux, а также как настраивать эти службы в типичной среде.

Наконец, если вас беспокоит, что злоумышленники точат зубы на ваши сетевые активы, книга поможет бороться и с этой проблемой. Мы обсудим, как злоумышленники и вредоносные программы атакуют различные сетевые службы и как их защищать.

Поскольку внимание здесь сосредоточено на Linux, вы обнаружите, что бюджет как для развертывания обсуждаемых служб, так и для их защиты выражается скорее в вашем энтузиазме и времени для изучения новых интересных вещей, чем в долларах и центах!

Службы DHCP в Linux

В этой главе мы рассмотрим несколько тем, связанных с протоколом DHCP (Dynamic Host Control Protocol, протокол динамической настройки узла). Как можно догадаться по названию, DHCP используется, чтобы предоставлять базовую информацию, которая необходима узлу для подключения к сети, а в некоторых случаях и сведения о том, где найти дополнительную конфигурацию, что делает DHCP ключевым компонентом большинства инфраструктурных решений.

В этой главе мы рассмотрим основы того, как устроен этот протокол, а затем перейдем к настройке служб DHCP и устранению их неполадок. Мы обсудим такие вопросы:

• Как работает DHCP
• Как защищать службы DHCP
• Установка и настройка сервера DHCP

Давайте приступим!

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

Для начала разберемся, как на самом деле функционирует DHCP. Мы начнем с того, как устроены пакеты в запросах и ответах DHCP: какую информацию запрашивает клиент, что предоставляет сервер и как все это работает. Затем мы обсудим, чем полезны параметры DHCP во многих реализациях.

Базовые принципы DHCP

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

Процесс DHCP начинается, когда клиент отправляет широковещательный пакет DISCOVER («Обнаружение»), по сути, спрашивая: «Тут есть какие-нибудь серверы DHCP?» Затем сервер DHCP отправляет в ответ пакет OFFER («Предложение») с подробной информацией. Клиент отвечает пакетом REQUEST («Запрос»), название которого выбрано не вполне удачно: по сути, клиент отправляет информацию, которую он только что получил от сервера, просто в качестве подтверждения. В свою очередь, сервер отправляет клиенту финальный пакет ACKNOWLEDGEMENT («Подтверждение»), снова с той же информацией, еще раз удостоверяя ее.

Эту процедуру часто называют DORA (Discover, Offer, Request, Acknowledgement) и обычно изображают так:


Это все пакеты UDP, а мы помним, что в протоколе UDP нет встроенной информации о сеансе. Так что же связывает эти четыре пакета в один «сеанс»? Для этого в исходном пакете Discover есть идентификатор транзакции, который совпадает в трех последующих пакетах: это иллюстрирует трассировка с помощью программы Wireshark:

ВАЖНОЕ ПРИМЕЧАНИЕ

До того, как получен четвертый пакет, у клиента фактически нет адреса, поэтому пакеты Discover и Request идут от MAC-адреса клиента с IP-адресом 0.0.0.0 на широковещательный адрес 255.255.255.255 (т. е. по всей локальной сети).

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

Запросы DHCP из других подсетей (перенаправляющие серверы, ретрансляторы или помощники)

Но позвольте, скажете вы: во многих корпоративных сетях серверы находятся в своей собственной подсети; разделять серверы и рабочие станции — довольно распространенная практика. Как этот механизм DHCP работает в таком случае? Первые три пакета последовательности DORA отправляются на широковещательный адрес, поэтому они могут достигать других узлов только в той же VLAN.

Эту проблему можно решить, если разместить процесс перенаправления (forwarder) или ретрансляции (relay) DHCP на узле в клиентской подсети. Этот процесс принимает локальные широковещательные рассылки, а затем пересылает их на сервер DHCP в одноадресном режиме. Когда сервер DHCP отправляет ответ (как одноадресное сообщение перенаправляющему узлу), перенаправляющий сервер преобразует этот пакет обратно в широковещательный ответ, которого ожидает клиент. Почти всегда это перенаправление выполняется на IP-адресе маршрутизатора или коммутатора, который находится в клиентской подсети, другими словами, на интерфейсе, который в конечном итоге станет шлюзом клиента по умолчанию. Формально эта функциональность не обязана быть именно на этом интерфейсе, но размещать ее там удобно: как правило, это интерфейс, в доступности которого мы уверены, так что перенаправление тоже будет доступно практически всегда. Кроме того, если принять это за неписаное правило, то нужную команду будет проще найти, если впоследствии ее понадобится изменить. На маршрутизаторе или коммутаторе Cisco эта команда выглядит так:

interface VLAN <x>
     ip helper-address 10.10.10.10

Здесь 10.10.10.10 — это IP-адрес нашего DHCP-сервера.

На практике при этом к простой широковещательной операции, которая используется в большинстве домашних сетей, добавляется одноадресная ветвь, которая расширяет протокол до сервера DHCP, расположенного в другой подсети:


Как это меняет последовательность DORA? Если коротко, то при этом не изменяется содержимое DHCP ни в одном из пакетов. Зато в пакетах изменяются поля IP-адреса верхнего уровня: в измененных пакетах, которые передаются между маршрутизатором и сервером, фигурируют настоящие IP-адреса отправителя и получателя. Однако содержимое пакета, которое видит клиент, остается прежним. Если вы углубитесь в данные пакетов DHCP, то увидите, что как с ретранслятором, так и без него MAC-адрес клиента DHCP и IP-адрес сервера DHCP фактически включены в поля данных протокола DHCP на уровне 7.

Теперь у нас есть все необходимое, чтобы начать настраивать сервер DHCP для основных операций. Но прежде чем мы перейдем к этому, давайте рассмотрим, что потребуется для устройств специального назначения, таких как iPhone, точки беспроводного доступа (WAP) или даже устройства с PXE (Pre eXecution Enviroment), которые способны загружать всю свою операционную систему на основе данных DHCP.

Параметры DHCP

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

• Маска подсети.
• Роутер (шлюз по умолчанию).
• Список серверов DNS.
• Доменное имя DNS.

Более полную информацию о параметрах DHCP можно найти на сайте IANA (https://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml) или в соответствующем документе RFC: tools.ietf.org/html/rfc2132.

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

• В какой VLAN мне нужно находиться? В современных сетях этот параметр используется реже; вместо этого на коммутаторах просто идентифицируется VOICE VLAN с помощью протокола обнаружения канального уровня (LLDP). На коммутаторах Cisco для этого нужно просто добавить ключевое слово voice в определение VLAN.
• Какой IP-адрес у АТС, к которой я буду подключаться?
• К какому серверу TFTP или HTTP нужно подключиться, чтобы получить конфигурацию моего оборудования?

Если у сервера есть запрошенная информация, он отправит ее в DHCP-пакете Offer.
Чаще всего встречаются такие параметры DHCP, но если вы используете телефон другого поставщика, данные могут отличаться:


Обратите внимание, что телефоны Mitel и Shortel используют один и тот же параметр DHCP, но немного разный синтаксис.

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

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

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

Защита служб DHCP

Интересная особенность DHCP заключается в том, что почти во всех случаях защита службы осуществляется на сетевых коммутаторах, а не на самом сервере DHCP. По большей части сервер DHCP получает анонимные запросы, а затем отвечает соответствующим образом; при такой схеме остается мало возможностей защитить эту службу без особых сложностей (используя подписи и PKI, к которым мы еще вернемся) или с помощью списка разрешенных MAC-адресов (что значительно усложняет конфигурацию). Оба этих подхода в значительной степени противоречат сути службы DHCP, которая должна «автомагически» обеспечивать сетевую настройку рабочих станций, телефонов и других подключенных к сети устройств, не добавляя слишком много сложности или административных издержек.

Так как же обезопасить нашу службу? Давайте рассмотрим несколько сценариев атак, а затем изучим наиболее распространенные средства защиты от них.

Подменный сервер DHCP

Прежде всего, посмотрим на возможность использования подменного (rogue) сервера DHCP. На сегодняшний день это самая распространенная атака, и в большинстве случаев она даже не преднамеренная. Чаще всего она проявляется, когда человек приносит из дома неавторизованный беспроводной маршрутизатор или проводной коммутатор, на котором включен стандартный сервер DHCP. В большинстве случаев это домашнее устройство будет настроено для сети 192.168.1.0/24 или 192.168.0.0/24, которая почти всегда отличается от того, что мы настроили в организации. Поэтому как только это устройство подключится к сети, рабочие станции начнут получать адреса в этой подсети и потеряют связь с реальной корпоративной сетью.

Как можно защититься от этого? Все дело в настройках сетевых коммутаторов. На каждом коммутаторе следует оценить топологию и решить, от каких портов можно допустить прием DHCP-пакетов Offer, — другими словами, какие порты ведут к DHCP-серверу. А канал, который ведет к серверам, — это почти всегда восходящая линия коммутатора.

Как только мы определим это на коммутаторе, мы включим механизм, который называется DHCP Snooping («досмотр DHCP») и предписывает коммутатору проверять пакеты DHCP. Это делается для каждой VLAN по отдельности, и в большинстве сред мы просто перечисляем все доступные VLAN. Затем мы настраиваем наши восходящие порты, чтобы они считались доверенными для пакетов DHCP от отправителя. Обычно это очень простое изменение конфигурации, которое будет выглядеть примерно так (показана конфигурация оборудования Cisco):

ip dhcp snooping vlan 1 2 10
interface e1/48
     ip dhcp snooping trust

Если DHCP-пакет Offer получен на любом порте или IP-адресе, кроме тех, которые мы настроили как доверенные, по умолчанию этот порт отключается и отправляется уведомление (хотя можно настроить систему так, чтобы просто отправлять уведомление). После этого порт будет находиться в так называемом состоянии отключения при ошибке, и обычно требуется вмешательство сетевого администратора, который выявит основную причину проблемы и устранит ее. Поэтому ведение журнала и настройка уведомлений очень важны. Если эта тема крайне актуальна для вашей организации, вы можете сразу перейти к главе 13 «Системы предотвращения вторжений в Linux».

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

dhcp-snooping
dhcp-snooping vlan 1 2 10
dhcp-snooping authorized-server <IP-адрес сервера>

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

Когда мы добираемся до серверных VLAN и коммутаторов центра обработки данных, то сталкиваемся с тем, что наш сервер DHCP, скорее всего, является виртуальной машиной. Это оставляет нам только два варианта: либо мы настраиваем параметры доверия DHCP на всех восходящих каналах, которые подключаются к нашим серверам гипервизора, либо на коммутаторах серверов мы вообще не настраиваем DHCP Snooping и параметры доверия. Оба варианта допустимы, и честно говоря, второй встречается чаще всего. Во многих случаях сетевые администраторы могут быть уверены, что серверный коммутатор находится в запертой комнате или шкафу, и это обеспечивает уровень защиты для служб DHCP. Это также означает, что администраторам сервера и гипервизора не нужно уделять столько внимания физической сети, сколько они уделяют изменениям на стороне сервера. Во многих случаях вообще не понадобится привлекать сетевых администраторов.

Мы упоминали, что «случайный сервер DHCP» — наиболее распространенный тип атаки подменного сервера. Но как насчет преднамеренных атак на сервер DHCP? Как они выглядят? Первая ситуация — сервер DHCP, который добавляет вредоносный узел (обычно самого себя) в качестве шлюза по умолчанию. По мере получения пакетов вредоносный узел будет проверять трафик на наличие информации, которую он хочет украсть, перехватить или изменить, а затем перенаправлять ее на подлинный маршрутизатор (шлюз по умолчанию для этой подсети):


Другая ситуация происходит, когда вредоносный сервер DHCP предоставляет клиенту всю правильную информацию, но добавляет немного «лишней» информации к аренде DHCP — параметр DHCP 252. Это текстовая строка, которая указывает на файл автоматической настройки прокси-сервера (PAC) и представляет собой URL вида http://<вредоносный сервер>/путь/<имя файла.pac>. Злоумышленник составляет файл PAC так, чтобы трафик для целевых сайтов шел через вредоносный прокси-сервер, а трафик для остальных сайтов маршрутизировался обычным образом. Цель обеих этих махинаций, называемых атакой посредника (Machine in the Middle, MiTM), состоит в том, чтобы украсть учетные данные: когда вы посещаете целевой сайт, такой как PayPal, Amazon или сайт своего банка, у злоумышленника наготове поддельный сайт, который пытается получить ваше имя пользователя и пароль. Это обычно называют атакой WPAD (автоматическое обнаружение прокси-сервера Windows) из-за того, что ей особенно подвержены клиенты Windows, которые по умолчанию доверяют серверу DHCP по части настроек прокси-сервера. В большинстве случаев злоумышленники предпочитают атаку WPAD, потому что им не приходится возиться с расшифровкой HTTPS, SSH или любого другого зашифрованного трафика:


В обеих ситуациях с вредоносным сервером DHCP наша защита с настройкой параметров доверия DHCP работает очень хорошо.

Еще одна защита конкретно от атаки WPAD заключается в том, чтобы добавить запись DNS для WPAD на ваш DNS-сервер — yourinternaldomain.com. Польза от этого проявляется, когда атаку WPAD комбинируют с другими атаками (в частности, против любого многоадресного протокола DNS, такого как LLMNR). Если для этого имени узла есть запись DNS, то такие атаки легко нейтрализуются. Кроме того, заносить в журнал все запросы DNS для подозрительных имен узлов, таких как WPAD, — это отличная практика, которая помогает выявлять и локализовать атаки по мере их возникновения.

А что насчет защиты от атак с другой стороны — что делать с недобросовестными клиентами?

Подменный клиент DHCP

Менее распространенная форма атаки — подменный клиент DHCP. Атака заключается в том, что злоумышленник приносит свой сервер из дома и подсоединяет его к неиспользуемому порту Ethernet на работе или подключает крошечный, специально созданный атакующий ПК (часто называемый pwnplug) к сети через неиспользуемый порт Ethernet в приемной или в любом другом доступном месте. Излюбленное место для таких устройств — за растениями, принтерами или прочими предметами.

Старая школа защиты от этой атаки заключается в том, чтобы хранить базу всех авторизованных MAC-адресов в вашей компании и либо настраивать их как авторизованные клиенты в DHCP, либо конфигурировать для каждого из них статическое резервирование DHCP. Оба подхода не идеальны для современного предприятия. Во-первых, это требует существенных административных усилий. Мы добавляем задачу ручной инвентаризации в рабочие процессы команды по обслуживанию серверов. Поскольку сервер DHCP обычно является серверным компонентом с низкими издержками, никто этому не обрадуется. Во-вторых, если вы выберете подход статического резервирования, вам потребуется добавить резервирование для каждой VLAN, беспроводного SSID или возможного расположения, к которому клиенту может потребоваться подключиться. Излишне говорить, что большинство организаций не будут в восторге ни от одного из этих подходов.

Более современный метод выявлять неавторизованных клиентов заключается в том, чтобы использовать аутентификацию 802.1x, при которой клиент должен пройти проверку подлинности в сети, прежде чем ему будет разрешен доступ. При этом используются службы RADIUS в Linux (глава 9) и службы сертификатов в Linux (глава 8). Сертификаты применяются, чтобы обеспечить доверие: клиенты должны доверять серверу RADIUS и, что более важно, сервер RADIUS должен доверять подключающимся клиентам, чтобы аутентификация работала безопасно. Как вы наверняка догадались, мы рассмотрим это решение позже в этой книге (в главе 8 «Службы сертификатов в Linux» и в главе 9 «Службы RADIUS в Linux»).
Когда мы разобрались со всей теорией и усвоили ее, давайте приступим к настройке сервера DHCP.

Установка и настройка сервера DHCP

Мы разобьем задачи настройки на три группы:

• Базовая конфигурация сервера DHCP и областей.
• Статическое резервирование для аренды DHCP, например для серверов или принтеров.
• Использование журналов DHCP для сетевой аналитики и проверки оборудования.

Давайте приступим!

Базовая конфигурация

Как и следовало ожидать, мы начнем разговор с команды apt, установив сервер ISC DHCP на наш учебный узел:

$ sudo apt-get install isc-dhcp-server

После установки можно настроить основные параметры сервера. Установите время аренды и все, что не привязано к областям: например, мы настроим центральные серверы DNS. Кроме того, обратите внимание, что мы добавляем проверку пинга: перед тем как предоставить аренду, этот узел пингует адрес-кандидат, чтобы убедиться, например, что кто-то другой не назначил его статически. Это отличный способ избежать дублирования IP-адресов, которые не включены по умолчанию. В нашем примере время ожидания пинга установлено на 2 секунды (по умолчанию оно составляет 1 секунду). Учтите, что для некоторых серверов dhcpd параметр ping-check можно сократить просто до ping.

Также обратите внимание на переменные времени аренды. Они определяют, как долго действует аренда DHCP и когда клиент начнет запрашивать продление аренды. Они важны по нескольким причинам:

• Хотя мы и стремимся отделить IP-адреса от различных диагностических инструментов, при реагировании на инциденты полезно иметь возможность более-менее полагаться на то, что адреса не меняются слишком часто. Например, если вы устраняете неполадку и узнаете IP-адрес узла, с которого начались проблемы, очень полезно, когда вы уверены, что он не изменится в течение 3–4 ближайших дней. Это значит, что все поиски по адресам можно выполнять только один раз во всех соответствующих журналах. По этой причине аренду DHCP для внутренних рабочих станций часто настраивают так, чтобы учитывать 4-дневные длинные выходные, а в некоторых случаях даже отпуска на 2–3 недели, сохраняя аренду DHCP активной в течение этого времени.
• Конечно, исключением являются гостевые сети, а особенно беспроводные гостевые сети. Если вы не связываете гостевые адреса с личностью того, кто входит в сеть, то короткий срок аренды может быть полезен. Кроме того, гостевые сети больше сталкиваются с «текучкой» пользователей, которые приходят и уходят, поэтому короткое время аренды в некоторой степени защищает вас от исчерпания пула адресов. Если вам когда-либо придется реагировать на инциденты в анонимной гостевой сети с коротким временем аренды, то ваша «псевдоидентификация», скорее всего, будет основана на MAC-адресах, а не на IP-адресах (и таким же образом вы будете блокировать подозрительные узлы).

Доступны следующие три переменные времени аренды:

• default-lease-time: продолжительность аренды, если клиент не запрашивает время аренды.
• max-lease-time: самый длительный срок аренды, который может предложить сервер.
• min-lease-time: заставляет клиента брать более длительный срок аренды, если запрошенная продолжительность короче этого интервала.

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

Давайте отредактируем основную конфигурацию сервера DHCP — /etc/dhcp/dhcpd.conf. Обязательно используйте sudo, чтобы иметь нужные права при редактировании этого файла:

default-lease-time 3600;
max-lease-time 7200;
ping true;
ping-timeout 2;
option domain-name-servers 192.168.122.10, 192.168.124.11;

Раскомментируйте параметр authoritative чуть ниже в этом файле:

# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
authoritative;

В конце файла добавьте сведения о своей области. Обратите внимание: если вы развертываете новые подсети, старайтесь не использовать 192.168.0.0/24 или 192.168.1.0/24. Эти подсети часто фигурируют в домашних сетях, поэтому их использование в организации может сбить с толку людей, которые работают удаленно из дома. Если они подключатся к VPN, у них окажутся две разные сети 192.168.1.0, с которыми придется бороться, потому что какая-то одна из них, скорее всего, будет недоступна.

# Specify the network address and subnet-mask
     subnet 192.168.122.0 netmask 255.255.255.0 {
     # Specify the default gateway address
          option routers 192.168.122.1;
     # Specify the subnet-mask
     option subnet-mask 255.255.255.0;
     # Specify the range of leased IP addresses
     range 192.168.122.10 192.168.122.200;
}

Сюда же можно добавить любые другие параметры DHCP, о которых мы говорили ранее в этой главе, например параметры для поддержки VoIP-телефонов, узлов PXE или точек беспроводного доступа.

Наконец, перезапустите сервер DHCP:

$ sudo systemctl restart isc-dhcp-server.service

Ради интереса, если вы хотите, чтобы клиенты пытались обновить сервер DNS своими данными, можно добавить следующее:

ddns-update-style interim;
# Если у вас есть записи с фиксированными адресами, имеет смысл использовать динамический DNS
update-static-leases on;

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

Статическое резервирование

Чтобы задать статический IP-адрес для узла, мы добавляем раздел host в файл dhcpd.conf. В самой простой конфигурации мы назначаем фиксированный IP-адрес, когда видим определенный MAC-адрес:

host PrtAccounting01 {
     hardware ethernet 00:b1:48:bd:14:9a;
     fixed-address 172.16.12.49;}

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

host LTOP-0786 {
     hardware ethernet 3C:52:82:15:57:1D;
     option host-name "LTOP-0786";
     option domain-name "coherentsecurity.com";
     ddns-hostname "LTOP-786";
     ddns-domain-name "coherentsecurity.com";
}

Или, чтобы добавить статические определения для группы узлов, выполните такие команды:

group {
     option domain-name "coherentsecurity.com";
     ddns-domainname "coherentsecurity";
     host PrtAccounting01 {
          hardware ethernet 40:b0:34:72:48:e4;
          option host-name "PrtAccounting01";
          ddns-hostname "PrtAccounting01";
          fixed-address 192.168.122.10;
     }

     host PrtCafe01 {
          hardware ethernet 00:b1:48:1c:ac:12;
          option host-name "PrtCafe01";
          ddns-hostname "PrtCafe01";
          fixed-address 192.168.125.9
     }
}

Теперь, когда мы настроили и запустили DHCP, давайте посмотрим, какие инструменты есть в нашем распоряжении, чтобы устранять неполадки, если что-то пойдет не так. Hачнем с просмотра информации об аренде DHCP, а затем углубимся в журналы службы dhcpd.

Простое ведение журналов DHCP и устранение неполадок при повседневном использовании

Чтобы просмотреть текущие адреса аренды DHCP, используйте команду dhcp-lease-list, которая должна предоставить вам такой список (обратите внимание, что текст перенесен). Каждая строка в этом выводе соответствует одной аренде устройства:

$ dhcp-lease-list
Reading leases from /var/lib/dhcp/dhcpd.leases
MAC IP hostname valid until manufacturer
================================================================================
e0:37:17:6b:c1:39 192.168.122.161 -NA- 2021-03-22 14:53:26 Technicolor CH USA Inc. Обратите внимание, что эта команда извлекает OUI из каждого MAC-адреса, поэтому ее можно использовать, например, чтобы искать подозрительные типы сетевых карт. Они должны сразу выделяться в ваших подсетях VoIP или в подсетях, в которые преимущественно входят мобильные устройства. Даже в стандартной VLAN, предназначенной для передачи данных, OUI часто позволяет легко обнаружить странные типы устройств. Я постоянно сталкиваюсь с такими ситуациями: допустим, клиент пользуется стандартной моделью телефона, однако увидев информацию об OUI, замечает в ней телефон другой марки. Или, например, пользователь представляет магазин для устройств под управлением Windows, а видит в отчете компьютер Apple, которого там быть не должно.

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

$ dhcp-lease-list | sed -n '3,$p' | tr -s " " | cut -d " " -f 1,3 > output.txt

На простом языке это означает: запустить команду dhcp-lease-list, напечатать весь список, начиная со строки 3, удалить повторяющиеся пробелы, а затем взять столбцы 1 и 3, используя один пробел в качестве разделителя столбцов.

Если вам нужна более подробная информация или если вы расследуете инцидент, случившийся в прошлом, вам могут понадобиться дополнительные или совсем другие данные — для этого нужны журналы. Журналы DHCP хранятся в файле /var/log/dhcpd.log и содержат довольно подробные сведения. Например, из них можно собрать всю последовательность DORA для любого конкретного MAC-адреса:

cat dhcpd.log | grep e0:37:17:6b:c1:39 | grep "Mar 19" | more
Mar 19 13:54:15 pfSense dhcpd: DHCPDISCOVER from e0:37:17:6b:c1:39 via vmx1
Mar 19 13:54:16 pfSense dhcpd: DHCPOFFER on 192.168.122.113 to e0:37:17:6b:c1:39 via vmx1
Mar 19 13:54:16 pfSense dhcpd: DHCPREQUEST for 192.168.122.113 (192.168.122.1) from e0:37:17:6b:c1:39 via vmx1
Mar 19 13:54:16 pfSense dhcpd: DHCPACK on 192.168.122.113 to e0:37:17:6b:c1:39 via vmx1

Можно пойти еще дальше и спросить: «У кого был такой-то IP-адрес в такой-то день?» Мы соберем данные за весь день на тот случай, если этот адрес могли использовать несколько узлов. Чтобы получить окончательные назначения адресов, нам нужны только пакеты Acknowledgement (DHCPACK):

cat /var/log/dhcpd.log | grep 192.168.122.113 | grep DHCPACK | grep "Mar 19"
Mar 19 13:54:16 pfSense dhcpd: DHCPACK on 192.168.122.113 to e0:37:17:6b:c1:39 via vmx1
Mar 19 16:43:29 pfSense dhcpd: e0:37:17:6b:c1:39 via vmx1
Mar 19 19:29:19 pfSense dhcpd: e0:37:17:6b:c1:39 via vmx1
Mar 19 08:12:18 pfSense dhcpd: e0:37:17:6b:c1:39 via vmx1
Mar 19 11:04:42 pfSense dhcpd: e0:37:17:6b:c1:39 via vmx1

Можно еще больше сузить список, чтобы собрать MAC-адреса, которые использовались для этого IP-адреса в этот день:

$ cat dhcpd.log | grep 192.168.122.113 | grep DHCPACK | grep "Mar 19" | cut -d " " -f 10 | sort | uniq
e0:37:17:6b:c1:39

Теперь, когда мы научились извлекать MAC-адреса как из таблицы аренды, так и из журналов, вы можете использовать эти методы, чтобы устранять неполадки, обновлять инвентаризацию оборудования или искать неучтенные или подозрительные узлы в своей сети. Мы рассмотрим порядок устранения неполадок далее в разделе «Вопросы для самопроверки» этой главы (и ответах на эти вопросы).

Итоги

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

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

Об авторе