Комментарии 11
Вот интересная уязвимость . Интересна как раз тем, что известном ip6 адресе в глобальной сети - присутствует. А если сеть только ip4 использует за Nat . То врядли уязвимость возможна.
В эпоху виртуализации всего и вся, физический сервер вряд ли будут выставлять голой жопой в инет
ICMP пакеты обычно маршрутизируются маршрутизаторами до сервера, нужно лишь иметь реальный белый айпи на сетевом интерфейсе, а это много реальных серверов.
А оно точно нужно на физическом сервере белый IP иметь?
Если вы арендуете выделенный сервер или место в стойке под ваш физический сервер, который принимает входящие соединения (да хотя бы публичный почтовый сервер плюс корпоративный VPN), как вы собираетесь работать без белого айпи? Когда у нашей компании была стойка с серверами в Германии, у нас были белые айпи на серверах.
Вот только в арендную схему PXE не укладывается. Ну точнее можно, но это какой-то очень нишевый случай.
Я рассматриваю вариант, когда используется PXE. А это с высокой вероятностью собственный ДЦ с собственными серверами и тут белый IP на железном сервере даже вреден.
Думаю часто серверы грузятся сначала по pxe, потом переходят к локальной загрузке, если админ при установке не поленился поменять boot order. Кроме того, такая последовательность загрузки скорее всего основная в датацентрах с удаленным провижингом. Плюс, существует класс бездисковых серверов, всегда грузящих ось по сети.
Да, только в этот момент сервер еще не имеет IP адреса (никто же статику в BIOS прописывать не будет, если PXE не используется). OS не загружена, DHCP в сети нет (PXE ж не используем, зачем он?). Тут ICMP просто некуда посылать.
Проблема в том, что атакующему нужно доставить не на конкретный айпи, а unicast-пакет ICMP error на тот адрес, который клиент получил при загрузке. Обычно это адрес из DHCP. Белый он или серый, решает только то, кто может до него достучаться. Например, скомпрометированная машина в этой сети или другой загружающийся сервер, если в нём уже есть чужой код. Адрес клиента ему знать не обязательно: DHCP-обмен частично идёт broadcast'ом, а можно просто рассылать ICMP по всей подсети в цикле, пока идёт загрузка. А если атакующий поднимет свой (rogue) DHCP, он сам выдаст клиенту адрес. Серый адрес не защищает от того, кто находится внутри корпоративной сети или ЦОД, если провижининг-сегмент маршрутизируется и ICMP туда не фильтруется.
Отдельно - IPv6. Здесь серых адресов и NAT часто нет. При PXE по IPv6 клиент может получить глобальный адрес через DHCPv6 или SLAAC. Если на периметре нет фильтрации входящего трафика, атака из интернета становится вполне реальной. У некоторых провайдеров сервер получает белый адрес уже на этапе PXE. Тогда и по IPv4 атака возможна извне.
В IPv6 есть ULA адреса. Для технологической сети (а загрузка по PXE - это технологическая сеть, которая должна быть изолирована от инета) вполне подойдет.
Моё понимание мира - если используется PXE, то интерфейсы серверов должны быть в изолированной сети, без доступа из инета. Приватные адреса или файрвол, наглухо блокирующий все внешние запросы - не так важно.
Если PXE не используется, то его лучше отключать вообще, но тут вы правы, скорее всего мало кто это делает, а по-дефолту оно вроде бы включено.
Так же, если PXE не используется, то скорее всего (но это не точно) в сети нет и DHCP. Выдавать белые адреса по DHCP конечно можно, но тут я хз как в области аренды bare metal это устроено.
А вот если атакующий пробрался внутрь технологической сети, то проблемы уже гораздо хуже, чем уязвимость в PXE.
А про бездисковые сервера... Мой первый коммент был про то, что сейчас на железном сервере скорее всего грузится гипервизор. Т.е. на самом железном сервере белый IP не нужен (белые адреса будут у ВМ в гипервизоре).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Раскрыта уязвимость CVE-2026-97631, позволяющая выполнить произвольный код в прошивке UEFI серверных материнских плат