Я изучил пример трафика STUN на своем контроллере. Похоже, что это стандартный трафик STUN, о котором подробнее можно почитать в RFC3498. Судя по тому, что я увидел в своем примере трафика, тому, что написано в RFC и тому, что UBNT написал на своем сайте поддержки, STUN просто используется для передачи информации о сетевом подключении от устройства к контроллеру, когда задействован NAT. По моему опыту, если STUN не работает, то некоторые функции, например подключение к консоли устройства через админку, просто не работают.

Причина, по которой я копался в этой теме — я искал посты, касающиеся защиты портов UniFi на контроллере, запущенном в облаке. Я не видел, чтобы кто-то выкладывал скрипт, ограничивающий доступ к контроллеру по IP-адресу, так что решил написать свой. Подробнее здесь: https://community.ui.com/questions/c70e5596-1ee5-4456-92fa-a73bf67cede1

--Klint

@greggmh123

Моя главная проблема с портом 3478 в том, что Ubiquiti вообще не документировал его, кроме как заявил, что это STUN, и «откройте этот порт, иначе может работать неправильно». Для 8080 все довольно прозрачно, я выкладывал ссылки по этому поводу ранее в теме, но по сути, хоть соединение и http, данные там зашифрованы. Единственная потенциальная уязвимость — в процессе первоначального подключения, но можно просто подключить устройство локально перед тем, как запускать точку доступа в работу.

По поводу 3478/STUN — я не знаю, какой именно трафик там передаётся и шифруется ли он, не было времени перехватить пакеты и проверить. Я тоже выкладывал ссылки на эту тему, но вся информация по STUN — это в основном про VoIP или видеозвонки. Там всё не зашифровано и не защищено. STUN изначально придумали, чтобы две машины с динамическими IP и без проброса портов могли общаться между собой. Они обращаются к третьему серверу (STUN серверу) с постоянным IP и открытым портом 3478, спрашивая: «какой у меня внешний IP и какой порт используется на WAN стороне моего роутера?» — потом STUN сервер отвечает, и эти две машины обмениваются информацией между собой.

Моя первая проблема в том, что, кажется, STUN в прошлом использовали вредоносные программы. Серверу STUN это не вредило, кроме увеличения трафика, но это помогало вредоносу лучше понять свою сетевую конфигурацию, чтобы эффективнее выполнять свою задачу.

Вторая моя проблема — мне не очень понятно, как STUN вообще вписывается в работу UniFi контроллера. Контроллер выступает одновременно и как один из двух хостов, и как STUN сервер, что вроде бы не нужно — контроллер уже имеет статический IP (или DDNS) и порт 8080 с пробросом, так зачем тогда вообще STUN? Я не думаю, что команда UniFi стала бы использовать что-то лишнее, так что, видимо, они применяют STUN иначе, чем в VoIP сценариях, что я встречал. Но это только возвращает меня к тому, что я совершенно не понимаю, зачем открыт этот порт и какой трафик по нему идёт.

В конце концов, я не слышал, чтобы как-то эксплуатировали уязвимости UniFi контроллера или точек доступа через STUN, так что наверняка с этим всё в порядке. И я считаю, что ваша практика открывать эти порты только для клиентов — вполне безопасна. Просто я слишком параноик и у меня есть клиенты с часто меняющимися динамическими IP — вот почему я этот порт и оставил закрытым.

@Deleted Account, есть какая-то причина, по которой ты боишься оставлять 3478 открытым, если у тебя уже открыт 8080? Я пытаюсь понять, почему ты не оставляешь 3478 тоже открытым. Он более уязвим, чем 8080? Я не переживаю, потому что оба порта открыты только для IP-адресов моих удалённых клиентов, будь то статические или динамические.  
Gregg

По первому пункту, входящий STUN-порт действительно должен иметь доступ к контроллеру, если не хочешь видеть ошибки STUN на точках доступа в контроллере. Я как раз заменил UAP на UAP-AC-PRO и назначил ему прежний LAN-IP старого UAP через резервирование DHCP, а сам оригинальный UAP поставил в другую часть площадки, где нужна была минимальная скорость. Забыл добавить новый LAN-IP в исходящее правило WatchGuard для UniFi, и понадобилось время, чтобы понять, почему не могу избавиться от ошибки STUN… их файрвол блокировал выходящий трафик на WAN-IP моего контроллера. Как только я добавил новый IP в алиас для исходящего правила UniFi, ошибка STUN в контроллере пропала. Так у меня уже было несколько раз… казалось бы, надо же было запомнить проверять! По второму пункту, «прямой доступ» — это управление контроллером, если ОП не понял. По третьему, безопасность еще выше, если включить двухфакторную аутентификацию в аккаунте UBNT перед входом через Cloud Access. По четвертому — я тоже! Я, кажется, раза два десятка скидывал питание с моего CK (версии 1) без проблем, то отсоединял кабель, то забывал, что он подключен, когда перезагружал PoE-коммутатор. У меня 17 удалённых точек доступа, которые нормально «звонят домой» на порты 3478 и 8080 (только с разрешённых IP клиентов), и 8443, если я сначала вхожу в свой файрвол с любого места, кроме стран, которые он блокирует. Если вдруг понадобится зайти в контроллер, могу использовать Cloud Access, если решу поехать в Казахстан или на юго-восток Ботсваны. Грегг