Назад | Перейти на главную страницу

Отсутствие DHCP, простое решение?

Я знаю, что существует множество решений для смягчения атак из-за отсутствия DHCP. Но разве не было бы действительно простым решением просто установить пул адресов DHCP на 1.1.1.1 - 254.254.254.254 (или какой-либо другой действительно большой пул), чтобы злоумышленник не мог голодать весь пул в практические временные рамки? Почему этого не сделано?

Рассмотрим это в контексте беспроводной сети без шифрования и без аутентификации (типично для бесплатных общедоступных беспроводных точек доступа).

Использование всего IP-адресного пространства кажется чрезмерным. Предполагая, что вы говорите об изолированной среде (скажем, за NAT), вы можете использовать 10.0.0.0 \ 8 без каких-либо проблем, связанных с маршрутизацией. Если ваша фактическая сеть (то есть количество реальных машин) невелико, тогда общая проблема наличия потенциально огромного широковещательного домена не так актуальна, и если вы установите относительно низкое время аренды (несколько минут), вы можете убедиться, что он просто Было непрактично для одного атакующего фактически исчерпать ваш диапазон. Однако вам все равно придется отбиваться от того, что может быть относительно большим объемом трафика с миллионами поддельных запросов, и это будет широковещательный трафик, помните, чтобы все настоящие устройства в вашей сети тоже его увидели - так много ложного шума для всех на сеть, от которой требуется обрабатывать прерывания. Ваши коммутаторы также начнут отслеживать все эти [поддельные] комбинации MAC / IP-адресов, так что вы позволяете злоумышленнику увеличивать количество потребляемых ресурсов, а они тоже ограничены. Я считаю, что для серьезной атаки код атаки исчерпания DHCP, вероятно, отправляет запросы быстрее, чем могут справиться многие DHCP-серверы, если объем действительно огромен - физические ресурсы (ЦП и ОЗУ, необходимые для обработки ответов и отслеживания таблицы активных аренд) на DHCP-сервер может в конечном итоге просто потребляться, если злоумышленник может генерировать запросы достаточно быстро, и конечный результат может быть для вас хуже - теперь вы заменили атаку отказа в обслуживании против новых подключений атакой, которая может привести к сбою вашего DHCP-сервера и коммутаторов. (и они могут быть использованы).

Если это серьезная проблема, и вы не можете смириться с возможностью DoS против клиентов, вам следует использовать переключатели, у которых есть механизмы для предотвращения этого - существуют определенные механизмы смягчения последствий голодания DHCP, такие как DHCP Snooping, но просто включение элементов управления для ограничения подмены MAC-адресов как правило, помогает в этом, а также при заливке таблиц CAM. Лучшим подходом является включение аутентификации порта, но это сложно реализовать в любой большой контролируемой среде и не использовать в неуправляемом сценарии (например, в точке доступа Wi-Fi). Я не верю, что существует окончательное решение общего назначения, это случай уравновешивания рисков различных доступных вариантов и выбора того, который лучше всего работает в вашей среде.

У такого подхода много проблем.

Прежде всего, если вы сделаете то, что выразили, вы фактически отключите себя от Интернета, поскольку этот диапазон включает (почти) все возможные адреса IPv4.

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

Переключитесь на IPv6!

Особенно, если вы просто используете автосогласование ICMP без DHCP-сервера. :)

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

Нет тривиального решения, потому что это нетривиальная проблема.

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

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

Лучший способ смягчить это - на уровне коммутатора - проверьте здесь подробное объяснение атаки и смягчения: dhcp-голодание-быстро и грязно

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