Хакер - Атаки на DHCP. Разбираем техники DHCP Starvation и DHCP Spoofing и защиту от них

Хакер - Атаки на DHCP. Разбираем техники DHCP Starvation и DHCP Spoofing и защиту от них

hacker_frei

https://t.me/hacker_frei

Alexander Mikhailov

Содержание статьи

  • Теория
  • Сообщения DHCP
  • Структура заголовка DHCP
  • Тестируем DHCP на стойкость
  • Лабораторный стенд
  • DHCP Starvation
  • Rogue DHCP или DHCP Spoofing
  • Нейтрализуем атаки на DHCP-протокол
  • Trusted- и Untrusted-порты
  • Limit Rate
  • Verify MAC-Address
  • Port Security
  • Выводы

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

WARNING

Статья име­ет озна­коми­тель­ный харак­тер и пред­назна­чена для спе­циалис­тов по безопас­ности, про­водя­щих тес­тирова­ние в рам­ках кон­трак­та. Автор и редак­ция не несут ответс­твен­ности за любой вред, при­чинен­ный с при­мене­нием изло­жен­ной информа­ции. Рас­простра­нение вре­донос­ных прог­рамм, наруше­ние работы сис­тем и наруше­ние тай­ны перепис­ки прес­леду­ются по закону.

ТЕОРИЯ

При защите сети от атак на 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-адре­сов.

С основны­ми сооб­щени­ями разоб­рались. Теперь под­ведем неболь­шой итог: сооб­щения типа DHCPOFFERDHCPACK и DHCPNAK отправ­ляют­ся толь­ко сер­вером в адрес кли­ента. Запом­ним. Эта информа­ция нам при­годит­ся чуть поз­же.

Структура заголовка 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-сер­веров, адрес шлю­за по умол­чанию, вре­мя арен­ды адре­са).

Ду­маю, тут все понят­но. Теперь погово­рим о поле CHADDR, на котором я акценти­ровал осо­бое вни­мание выше. Логич­но пред­положить, что зна­чение в полях CHADDR заголов­ка DHCP и MAC-адре­са источни­ка в Ethernet-заголов­ке (сооб­щений от кли­ента к сер­веру) будут иден­тичны­ми.

При нор­маль­ном вза­имо­дей­ствии кли­ента с сер­вером так и есть. Взя­ли на заметоч­ку и дви­гаем­ся к прак­тичес­кой час­ти.

ТЕСТИРУЕМ 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-сооб­щений от сер­вера. Пом­нишь про сооб­щения DHCPOFFERDHCPACK и 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.

Читайте ещё больше платных статей бесплатно: https://t.me/hacker_frei



Report Page