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

Теория

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

С основны­ми сооб­щени­ями разоб­рались. Теперь под­ведем неболь­шой итог: сооб­щения типа DHCPOFFER, DHCPACK и 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, она уме­ет ата­ковать и нес­коль­ко дру­гих про­токо­лов каналь­ного уров­ня.