Шифрование беспроводного канала связи точки доступа? (вариация атаки с отключением точки доступа)

Шифрование беспроводного канала связи точки доступа? (вариация атаки с отключением точки доступа), wifiman

hein.foo

Guest

01.03.2025 21:29:00

Пытаюсь обновить существующую сетевую конфигурацию в кондоминиуме без прокладки новых кабелей. У меня есть медяная Ethernet-линия от места расположения моего облачного шлюза к патч-панели, к которой имеют доступ мои соседи, а оттуда медяная Ethernet-линия к точке доступа (AP); таким образом, облачный шлюз и AP находятся в безопасных местах, но провод проходит через незащищенное место. Поэтому я бы очень хотел иметь зашифрованное (проводное) соединение между облачным шлюзом и AP. Есть ли способ сделать это в мире Ubiquiti? AP закреплен на стене и нуждается в питании через PoE, так как поблизости нет розетки. Это похоже на вариант атаки отключения AP? Как-то уму непостижимо, что это было бы просто, если бы соединение шлюза-AP было беспроводным, но увы, это для меня не вариант. Заранее спасибо за любые советы

Хейн

hein.foo

Guest

02.03.2025 13:47:00

Спасибо за все твои содержательные и тонкие ответы 😊 Я бегло посмотрел на Mikrotik hex poe — VPN-endpoint, питающийся по PoE и обеспечивающий питание по PoE, но не уверен, что готов к дополнительной сложности и хрупкости. И да, вопросы конфиденциальности данных и т.п. должны решаться уже на уровне приложения. Тем не менее, я все еще защищаю пароль своей WLAN, и, похоже, хорошая гигиена и лучшая практика — иметь некую защитную стену вокруг IoT-устройств и подобных вещей, таких как принтеры или Sonos, которые осуществляют контроль доступа на основе того, кто находится в их сети.

its3am

Guest

02.03.2025 12:51:00

Точки доступа Aruba могут туннелировать весь трафик через IPsec к своему WLC, проводя только локальный DHCP в открытом виде (и, возможно, немного DNS-запросы, чтобы найти этот контроллер). UniFi вообще ничего подобного предложить не может, начиная с того, что они предлагают только локальный breakout. Но, конечно, они в своей собственной ценовой категории. Определённо не для дома.

waterside

Guest

02.03.2025 03:35:00

Перед тем, как мы слишком углубимся в дебри, отмечу комментарий в исходном посте (выделено мной): Да, существуют устройства, которые шифруют трафик между собой. Они не дешевые. Это можно сделать программно, и тогда придется мириться с падением производительности. IPsec и VPN тоже попадают в эту категорию. На самом деле, существует почти бесконечное количество возможностей для такого сценария, но это вряд ли применимо к ситуации в исходном посте. MACsec между двумя коммутаторами, поддерживающими его, был бы вариантом. Но всё равно потребуется дополнительная инфраструктура для управления ключами, и поддержка MACsec обычно добавляет стоимость (даже косвенно) к коммутаторам. AP обычно не поддерживают MACsec, равно как и любое оборудование UniFi, чтобы вернуться к исходному вопросу. Из описания в исходном посте не совсем понятно, какая именно требуется функция, но кажется, что оба сценария учтены.

tgl123

Guest

02.03.2025 02:25:00

Интересно, а нет ли каких-нибудь "зашифрованных мостов", как, например, мосты PtP wifi: доверенная LAN <-> 802.1ae мост <-> незащищенный кабель <-> 802.1ae мост <-> доверенная LAN. Возможно, для задачи автора это избыточно, но я могу представить себе много случаев, где это было бы полезно.

waterside

Guest

02.03.2025 01:12:00

Я, честно говоря, не уловил эту часть из исходного поста, но, возможно, это и было задумано. Я постоянно вижу подобные запросы, и обычно цель в том, чтобы не дать кому-то подключить своё устройство. Вот где применяется supplicant 802.1x на AP. Если проблема в конфиденциальности данных, то шифрование должно быть сквозным. HTTPS, например, уже зашифрован. SSH тоже зашифрован. DNS можно зашифровать. SMB уже зашифрован. 802.1ae нужен для очень специфических целей, требует дополнительной инфраструктуры и сетевых устройств, которые все это поддерживают, что, как ты и отметил, встречается нечасто.

waterside

Guest

02.03.2025 00:48:00

Замки на RJ45 разъемах универсальны, потому что у каждой модели используется один и тот же "ключ". Их все равно довольно легко обойти при наличии желания и определенных навыков. Ключи тоже легко достать. В некоторых ситуациях они могут быть достаточно эффективны. Замки на разъемах, скорее всего, не подойдут для точки доступа (AP), по крайней мере, со стандартной установкой. Для AP существуют корпуса, которые могут быть более эффективными. Для автора вопроса, если патч-панель — единственная часть с недоверенным доступом, то шкаф с замком (как предлагалось выше) может быть эффективным решением. Это часть физической защиты от доступа со стороны неавторизованных лиц.

dlow

Guest

02.03.2025 00:40:00

Не поддерживается в Unifi или даже во многих решениях "корпоративной Wi-Fi". Проводной 802.1x + шифрование буквально называется 802.1ae MACsec. https://en.m.wikipedia.org/wiki/IEEE_802.1AE Когда люди беспокоятся о том, что их прослушивают (перерезанием кабеля AP, перехватом провода у AP или, в вашем случае, на патч-панели), я им говорю, что нужно это.

Akr1800 Guest	#9 02.03.2025 00:22:00 Люди обычно так поступают с уличными точками доступа? Замок, скорее всего, универсальный, да?

kanewolf Guest	#10 01.03.2025 22:23:00 Купите шкафчик с замком для патч-панели. Просто и недорого. Они также делают RJ45 с замками и Keystone-аудиолокаторы. Это ещё дешевле, чем шкафчик. Просто потребуется перетерминировать.

waterside Guest	#11 01.03.2025 21:51:00 Судя по вашему описанию, вам нужен AP, который поддерживает роль клиента 802.1x. Порт коммутатора должен требовать аутентификацию 802.1x, и AP должен аутентифицировать себя. Сейчас UniFi AP могут работать в роли аутентификаторов, но не в роли клиентов. Это давно стоящий в списке запросов функционал, и поиск по этому вопросу покажет вам немало тем. Например, вот эта: Feature Request: 802.1x supplicant capability for UniFi Access Points. К сожалению, пока что единственная возможность — физическая защита: сам AP (чтобы его нельзя было убрать и отключить кабель) и сам кабель должны быть недоступны для кого-либо, кому нельзя доверять.

Читают тему (гостей: 1)