Ты наверняка сталкивался с DHCP при настройке роутера. Но знаешь ли ты про опасности, которые может в себе скрывать его неправильная настройка на сервере компании? Воспользовавшись ею, злоумышленник может не только вывести DHCP-сервер из строя, но и реализовать атаку MitM, чтобы перехватить важные данные. В этой статье я покажу два вектора атак на DHCP и дам советы о том, как обеспечить безопасность.
Получив сообщение DHCPDISCOVER от потенциального клиента, DHCP-сервер предлагает свободный IP-адрес. Это сообщение, адресованное от сервера клиенту, называется DHCPOFFER. На время предложения адрес резервируется DHCP-сервером и не предлагается другим клиентам.
Предположим, клиент получил сообщение DHCPOFFER от DHCP-сервера. Тогда он отправляет широковещательное сообщение DHCPREQUEST, в котором содержится IP-адрес сервера, выдавшего предложение. Такое широковещательное сообщение информирует другие DHCP-серверы о том, что клиент уже принял предложение от одного из серверов. В таком случае остальные серверы DHCP освобождают зарезервированные IP-адреса, и в дальнейшем они могут быть предложены другим клиентам.
Когда сервер получает сообщение DHCPREQUEST, он указывает выбранный клиентом IP-адрес в сообщении DHCPACK и отсылает его в сторону клиента.
Клиент получил все необходимые сетевые параметры, и на этом процесс взаимодействия считается завершенным. Но кроме этих основных четырех сообщений, есть еще парочка немаловажных:
Давай пройдемся по наиболее интересным для нас полям заголовка:
При нормальном взаимодействии клиента с сервером так и есть. Взяли на заметочку и двигаемся к практической части.
На маршрутизаторе запустил DHCP с выдачей адресов из пула 192.168.1.2–254. Коммутатор с пустой конфигурацией, как «из коробки».
В качестве инструмента атаки будем юзать Yersinia (тулза названа в честь бактерии). Кроме DHCP, она умеет атаковать и несколько других протоколов канального уровня.
Выберем протокол DHCP, укажем опцию sending DISCOVER packet и запустим отправку ложных пакетов DHCPDISCOVER.
Пока идет флуд пакетами, посмотрим на пул адресов DHCP.
Абсолютно все адреса из диапазона 192.168.1.2–254 были зарезервированы DHCP-сервером, и, пока флудинг продолжается, сервер не сможет выдать адреса из своего пула новым клиентам. Сервер истощен.
Кстати, такой флуд вполне может вызвать отказ в обслуживании сервера DHCP. Посмотрим нагрузку на маршрутизаторе:
Процессор загружен наполовину. И это только от пакетов DHCPDISCOVER (ну ладно, еще STP с CDP каждые пару секунд).
В Yersinia есть функция развертывания такого DHCP-сервера — creating DHCP rogue server. В качестве параметров укажем адрес поддельного сервера, от имени которого будут выдаваться сетевые параметры, диапазон адресов, время их аренды (чем дольше, тем лучше), маску подсети и самое главное — адрес шлюза по умолчанию — ПК, который будет снифать трафик пользователей.
Осталось лишь перевести сетевой интерфейс прослушивающего ПК в режим форвардинга, а дальше — дело техники: клиентские устройства, настроенные на автоматическое получение IP-адресов, будут отправлять широковещательные сообщения DHCPDISCOVER и в ответ получат сетевые параметры от поддельного DHCP-сервера.
А вот так выглядит дамп ICMP-трафика на атакующей машине и схема MitM-атаки в нашей лабораторной сети.
В большинстве своем нейтрализацию атак на DHCP-протокол берет на себя технология DHCP Snooping, а в качестве обязательного дополнения к ней стоит использовать Port Security. Обе технологии применяются на коммутаторах.
Доверенные порты — это те, которые напрямую подключены к DHCP-серверу или которые «смотрят» в его сторону. Соответственно, недоверенные — это все остальные. В нашей лабораторной сети доверенным портом будет только один — G0/1.
После включения DHCP Snooping все порты по умолчанию становятся недоверенными. Поэтому нужно явно указать коммутатору доверенный порт. Но перед этим глобально включим DHCP Snooping и укажем, в каком VLAN она будет работать. Конфигурация коммутатора у меня по умолчанию и все порты принадлежат первому VLAN.
В качестве теста выключим наш DHCP-сервер, откажемся от выданного им адреса и попытаемся получить IP-адрес от поддельного DHCP-сервера. Вот что происходит на атакующей машине: поддельный DHCP видит клиентские сообщения обнаружения и усердно пытается предложить свои ложные сетевые параметры, но клиент никак не реагирует на ответы.
А все потому, что коммутатор дропает сообщения DHCPOFFER на ненадежном порту, из‑за чего клиент и не видит ложное предложение.
Чтобы задействовать эту возможность, выберем весь диапазон ненадежных портов и установим ограничение в десять пакетов в секунду. Cisco рекомендует использовать не более 100 пакетов в секунду, но для нашего тестового стенда хватит и десяти. Важно не урезать безобидный трафик от клиентов.
Снова время экспериментов: запустим DoS-рассылку сообщений DHCPDISCOVER и посмотрим, что будет происходить. Долго ждать не приходится: мгновенно прилетает консольный лог и уведомляет нас, что на порте F0/2 было получено десять DHCP-пакетов и порт переводится в состояние err-disable. Порт F0/2 упал. Далее требуется вмешательство администратора, чтобы восстановить работоспособность порта.
Limit Rate полезен тем, что не дает злоумышленнику выполнить отказ в обслуживании или быстро «выжрать» пул адресов, отправляя большое количество DHCP-запросов.
Раньше я акцентировал внимание на поле CHADDR заголовка DHCP и MAC-адреса источника Ethernet-заголовка и говорил, что при нормальном взаимодействии клиента и сервера значения в этих полях идентичны. При включенной функции Verify MAC-Address коммутатор проверяет эти два поля и, если MAC-адреса различны, дропает их.
Кстати, для проверки MAC-адреса используются ресурсы центрального процессора маршрутизатора, что, конечно же, в разы медленнее, чем при обработке пакетов ASIC-микросхемами. При нормальной работе сети ощутимо это никак не сказывается, но давай смоделируем такую ситуацию: была запущена атака на истощение DHCP, при которой генерируется огромное количество пакетов DHCPDISCOVER. Каждый из них будет проверяться процессором коммутатора на соответствие MAC-адресов.
В течение минуты после начала атаки центральный процессор коммутатора был загружен на 95% из‑за огромного количества пакетов DHCP, которые он должен обработать. Именно для предотвращения таких ситуаций и стоит применять функцию Limit Rate — порт просто уйдет в down, когда допустимое количество пакетов в секунду будет превышено.
Настроим все ненадежные порты на динамическое выучивание только одного MAC-адреса с сохранением их в текущую конфигурацию коммутатора. Режим реагирования на нарушение правил безопасности укажем shutdown — отключение порта. Но перед этим порты нужно перевести в режим Access.
Если же снова запустить флуд сообщениями DHCPDISCOVER, где в каждом Ethernet-кадре значение MAC-адреса источника будет уникальным, то порт мгновенно перейдет в режим err-disable (прямо как при Limit Rate), так как будет нарушено созданное нами правило запоминания только одного разрешенного MAC-адреса на порте коммутатора.
Можно посмотреть таблицу, которую ведет коммутатор, где отображено соответствие заученных MAC-адресов на каждом интерфейсе.
Истощить DHCP-сервер, изменяя MAC-адрес сетевой платы, не представляет труда для злоумышленника. Да, достаточно долго, но результативно. А при включенной защите порта на коммутаторе такая тактика будет обречена на провал.
Описанные в статье технологии защиты сети от атак на протокол DHCP по отдельности не становятся непреодолимой стеной для атакующего. Поэтому именно их комплексное применение даст должную защиту DHCP.
автор alexander_99 Alexander Mikhailov
источник xakep.ru
ТЕОРИЯ
При защите сети от атак на DHCP нам очень важно понимать тонкости взаимодействия DHCP-сервера и клиента. Например, какая связь между значением MAC-адреса в Ethernet-заголовке и значением CHADDR в заголовке DHCP или какие сообщения отправляются только DHCP-сервером в адрес клиента, а не наоборот. Но обо всем по порядку. Сначала быстренько пробежимся по основным сообщениям DHCP и структуре самого DHCP-заголовка.Сообщения DHCP
Для получения IP-адреса и других сетевых параметров клиенту и серверу DHCP достаточно обменяться четырьмя сообщениями. Клиент, настроенный на автоматическое получение IP-адреса, посылает в сеть сообщение DHCPDISCOVER на бродкастовые адреса сетевого (255.255.255.255) и канального (FF:FF:FF:FF:FF:FF) уровней, чтобы обнаружить серверы DHCP. В IP-заголовке в поле адреса источника IP-пакета указывается 0.0.0.0, так как клиент еще не получил этот параметр. В поле источника сообщения на канальном уровне указывается MAC-адрес клиента.
Получив сообщение DHCPDISCOVER от потенциального клиента, DHCP-сервер предлагает свободный IP-адрес. Это сообщение, адресованное от сервера клиенту, называется DHCPOFFER. На время предложения адрес резервируется DHCP-сервером и не предлагается другим клиентам.
Предположим, клиент получил сообщение DHCPOFFER от DHCP-сервера. Тогда он отправляет широковещательное сообщение DHCPREQUEST, в котором содержится IP-адрес сервера, выдавшего предложение. Такое широковещательное сообщение информирует другие DHCP-серверы о том, что клиент уже принял предложение от одного из серверов. В таком случае остальные серверы DHCP освобождают зарезервированные IP-адреса, и в дальнейшем они могут быть предложены другим клиентам.
Когда сервер получает сообщение DHCPREQUEST, он указывает выбранный клиентом IP-адрес в сообщении DHCPACK и отсылает его в сторону клиента.
Клиент получил все необходимые сетевые параметры, и на этом процесс взаимодействия считается завершенным. Но кроме этих основных четырех сообщений, есть еще парочка немаловажных:
- DHCPNACK — сообщение, которое посылается от сервера к клиенту, чтобы известить об отказе в аренде IP-адреса;
- DHCPRELEASE — сообщение от клиента к серверу, которое уведомляет сервер о том, что клиент больше не желает использовать текущий IP-адрес и сервер может «вернуть» этот адрес в пул свободных IP-адресов.
Структура заголовка DHCP
Теперь максимально кратко рассмотрим заголовок DHCP, инкапсулируемый в UDP-дейтаграммы. Кстати, забыл сказать про транспортный уровень: если речь о DHCP, то сервер и клиент используют 67-й и 68-й порты UDP соответственно.
Давай пройдемся по наиболее интересным для нас полям заголовка:
- Op Code — поле, которое указывает на тип сообщения. Если происходит запрос от клиента к серверу, то в данном поле устанавливается значение 0х01, а обратно — 0х02;
- htype — тип адреса, работающего на канальном уровне. Для Ethernet в этом поле устанавливается значение 0х01;
- hlen — указывает длину адреса канального уровня в байтах (0х06 для Ethernet);
- xid — идентификатор транзакции для согласования запросов и ответов между ними;
- sec — отображает время в секундах, прошедшее с момента, когда клиент начал получать либо обновлять IP-адрес;
- CIADDR — IP-адрес клиента. Это поле заполняется в том случае, если клиенту уже назначен IP-адрес и нужно продлить его аренду;
- YIADDR — сервер заполняет это поле значением IP-адреса, который предлагает клиенту;
- SIADDR — IP-адрес DHCP-сервера, при отправке клиенту ответных сообщений DHCPOFFER и DHCPACK;
- GIADDR — IP-адрес агента‑ретранслятора (маршрутизатора), разделяющего сети, в которых находятся клиент и DHCP-сервер;
- CHADDR — поле, указывающее MAC-адрес клиента. На это поле обращаем особое внимание;
- Option — поле переменной длины, в котором задают дополнительные параметры (например, маска подсети, адреса DNS-серверов, адрес шлюза по умолчанию, время аренды адреса).
При нормальном взаимодействии клиента с сервером так и есть. Взяли на заметочку и двигаемся к практической части.
ТЕСТИРУЕМ DHCP НА СТОЙКОСТЬ
Лабораторный стенд
Я собрал все необходимое, что было под рукой:- маршрутизатор Cisco 2821;
- коммутатор Cisco Catalyst 2960;
- клиентский ПК с Kali Linux.
На маршрутизаторе запустил DHCP с выдачей адресов из пула 192.168.1.2–254. Коммутатор с пустой конфигурацией, как «из коробки».
DHCP STARVATION
Перед проведением атаки DHCP Starvation хочется сделать небольшое ревью. Мы знаем, что DHCP-сервер ведет таблицу соответствий выданных клиентам IP-адресов и их MAC-адресов и что уже выданный IP-адрес не может быть предложен другому клиенту повторно. Суть атаки DHCP Starvation — «истощить» сервер DHCP, отправляя ложные пакеты типа DHCPDISCOVER с рандомными MAC-адресами источника. На эти пакет сервер будет реагировать и резервировать свободные IP-адреса из пула, в результате чего некоторое время (пока атака в активной фазе) не сможет выдавать IP-адреса обычным пользователям.В качестве инструмента атаки будем юзать Yersinia (тулза названа в честь бактерии). Кроме DHCP, она умеет атаковать и несколько других протоколов канального уровня.
Выберем протокол DHCP, укажем опцию sending DISCOVER packet и запустим отправку ложных пакетов DHCPDISCOVER.
Пока идет флуд пакетами, посмотрим на пул адресов DHCP.
Абсолютно все адреса из диапазона 192.168.1.2–254 были зарезервированы DHCP-сервером, и, пока флудинг продолжается, сервер не сможет выдать адреса из своего пула новым клиентам. Сервер истощен.
Кстати, такой флуд вполне может вызвать отказ в обслуживании сервера DHCP. Посмотрим нагрузку на маршрутизаторе:
Процессор загружен наполовину. И это только от пакетов DHCPDISCOVER (ну ладно, еще STP с CDP каждые пару секунд).
Rogue DHCP или DHCP Spoofing
Второй вектор атак на DHCP требует развернуть мошеннический DHCP-сервер. Нужно это, чтобы выдавать клиентам поддельные сетевые параметры (в частности — адрес шлюза по умолчанию) и провести MitM. С точки зрения атакующего, для этого лучше всего первым делом «положить» легитимный DHCP-сервер, что мы, собственно, и сделали выше.В Yersinia есть функция развертывания такого DHCP-сервера — creating DHCP rogue server. В качестве параметров укажем адрес поддельного сервера, от имени которого будут выдаваться сетевые параметры, диапазон адресов, время их аренды (чем дольше, тем лучше), маску подсети и самое главное — адрес шлюза по умолчанию — ПК, который будет снифать трафик пользователей.
Осталось лишь перевести сетевой интерфейс прослушивающего ПК в режим форвардинга, а дальше — дело техники: клиентские устройства, настроенные на автоматическое получение IP-адресов, будут отправлять широковещательные сообщения DHCPDISCOVER и в ответ получат сетевые параметры от поддельного DHCP-сервера.
А вот так выглядит дамп ICMP-трафика на атакующей машине и схема MitM-атаки в нашей лабораторной сети.
НЕЙТРАЛИЗУЕМ АТАКИ НА DHCP-ПРОТОКОЛ
Теперь рассмотрим технологии безопасности, предотвращающие атаки на DHCP. Условно их можно поделить на два вектора: защита от DHCP Starvation и от DHCP Spoofing.
В большинстве своем нейтрализацию атак на DHCP-протокол берет на себя технология DHCP Snooping, а в качестве обязательного дополнения к ней стоит использовать Port Security. Обе технологии применяются на коммутаторах.
Trusted- и Untrusted-порты
Забыть о внезапном появлении в сети поддельного сервера DHCP поможет концепция доверенных и недоверенных портов. Доверенный порт разрешает пересылку DHCP-сообщений от сервера. Помнишь про сообщения DHCPOFFER, DHCPACK и DHCPNAK, о которых мы говорили в самом начале? Поддельный DHCP-сервер не сможет предложить клиентам свои ложные параметры отправкой таких сообщений, если будет находиться за ненадежным портом.Доверенные порты — это те, которые напрямую подключены к DHCP-серверу или которые «смотрят» в его сторону. Соответственно, недоверенные — это все остальные. В нашей лабораторной сети доверенным портом будет только один — G0/1.
После включения DHCP Snooping все порты по умолчанию становятся недоверенными. Поэтому нужно явно указать коммутатору доверенный порт. Но перед этим глобально включим DHCP Snooping и укажем, в каком VLAN она будет работать. Конфигурация коммутатора у меня по умолчанию и все порты принадлежат первому VLAN.
В качестве теста выключим наш DHCP-сервер, откажемся от выданного им адреса и попытаемся получить IP-адрес от поддельного DHCP-сервера. Вот что происходит на атакующей машине: поддельный DHCP видит клиентские сообщения обнаружения и усердно пытается предложить свои ложные сетевые параметры, но клиент никак не реагирует на ответы.
А все потому, что коммутатор дропает сообщения DHCPOFFER на ненадежном порту, из‑за чего клиент и не видит ложное предложение.
Limit Rate
Еще одна очень полезная функция DHCP Snooping — ограничение на отправку DHCP-сообщений. Это ограничение допускает отправку через порт коммутатора определенного количества DHCP-трафика в секунду.Чтобы задействовать эту возможность, выберем весь диапазон ненадежных портов и установим ограничение в десять пакетов в секунду. Cisco рекомендует использовать не более 100 пакетов в секунду, но для нашего тестового стенда хватит и десяти. Важно не урезать безобидный трафик от клиентов.
Снова время экспериментов: запустим DoS-рассылку сообщений DHCPDISCOVER и посмотрим, что будет происходить. Долго ждать не приходится: мгновенно прилетает консольный лог и уведомляет нас, что на порте F0/2 было получено десять DHCP-пакетов и порт переводится в состояние err-disable. Порт F0/2 упал. Далее требуется вмешательство администратора, чтобы восстановить работоспособность порта.
Limit Rate полезен тем, что не дает злоумышленнику выполнить отказ в обслуживании или быстро «выжрать» пул адресов, отправляя большое количество DHCP-запросов.
Verify MAC-Address
Функция проверки MAC-адреса по умолчанию активна при включенном DHCP Snooping. Но если по каким‑то причинам она неактивна, то вот синтаксис для включения.
Раньше я акцентировал внимание на поле CHADDR заголовка DHCP и MAC-адреса источника Ethernet-заголовка и говорил, что при нормальном взаимодействии клиента и сервера значения в этих полях идентичны. При включенной функции Verify MAC-Address коммутатор проверяет эти два поля и, если MAC-адреса различны, дропает их.
Кстати, для проверки MAC-адреса используются ресурсы центрального процессора маршрутизатора, что, конечно же, в разы медленнее, чем при обработке пакетов ASIC-микросхемами. При нормальной работе сети ощутимо это никак не сказывается, но давай смоделируем такую ситуацию: была запущена атака на истощение DHCP, при которой генерируется огромное количество пакетов DHCPDISCOVER. Каждый из них будет проверяться процессором коммутатора на соответствие MAC-адресов.
В течение минуты после начала атаки центральный процессор коммутатора был загружен на 95% из‑за огромного количества пакетов DHCP, которые он должен обработать. Именно для предотвращения таких ситуаций и стоит применять функцию Limit Rate — порт просто уйдет в down, когда допустимое количество пакетов в секунду будет превышено.
Port Security
Последняя функция защиты коммутатора, о которой я хочу рассказать. Она не относится к технологии DHCP Snooping, но играет большую роль в защите сети от атак на DHCP-протокол. Port Security позволяет указать MAC-адреса хостов, которым разрешено передавать данные через порт. Для проверки используется MAC-адрес источника в Ethernet-заголовке, и в результате будет принято решение о пропуске через порт.Настроим все ненадежные порты на динамическое выучивание только одного MAC-адреса с сохранением их в текущую конфигурацию коммутатора. Режим реагирования на нарушение правил безопасности укажем shutdown — отключение порта. Но перед этим порты нужно перевести в режим Access.
Если же снова запустить флуд сообщениями DHCPDISCOVER, где в каждом Ethernet-кадре значение MAC-адреса источника будет уникальным, то порт мгновенно перейдет в режим err-disable (прямо как при Limit Rate), так как будет нарушено созданное нами правило запоминания только одного разрешенного MAC-адреса на порте коммутатора.
Можно посмотреть таблицу, которую ведет коммутатор, где отображено соответствие заученных MAC-адресов на каждом интерфейсе.
Истощить DHCP-сервер, изменяя MAC-адрес сетевой платы, не представляет труда для злоумышленника. Да, достаточно долго, но результативно. А при включенной защите порта на коммутаторе такая тактика будет обречена на провал.
ВЫВОДЫ
Может показаться, что атаки DHCP сегодня не так актуальны. По моему мнению, любая атака будет актуальна при отсутствии должного внимания к защите сети, а тем более если сетевое оборудование работает с настройками по умолчанию.Описанные в статье технологии защиты сети от атак на протокол DHCP по отдельности не становятся непреодолимой стеной для атакующего. Поэтому именно их комплексное применение даст должную защиту DHCP.
автор alexander_99 Alexander Mikhailov
источник xakep.ru