Защитить Plex-сервер через Raspberry Pi и HTTPS

Важно: этот материал предназначен для домашних и малых сетей. Не используйте чужие домены или IP без разрешения.

Фотография сетевого медиасервера Plex на домашнем компьютере

Проблема: почему обычный Plex остаётся уязвимым

Plex позволяет хранить медиатеку дома и транслировать её на устройствах по сети. Для удалённого доступа многие пользователи открывают на роутере порт 32400 и делают проброс (port forwarding) на машину с Plex. Адрес доступа выглядит как your.public.ip.address:32400.

Проблема в том, что трафик к отдельному IP и нестандартному порту может быть незашифрован и легко обнаруживается массовыми сканерами (например, MASSCAN). Кроме того, Plex периодически получает исправления безопасности; если сервер не обновлён, злоумышленник может воспользоваться известной уязвимостью и получить контроль над хостом.

Кратко о рисках

Перехват логинов и сессий при незашифрованном соединении (MITM — Man-in-the-Middle).
Уязвимости в старых версиях Plex, позволяющие выполнить удалённый код или эскалацию прав.
Массовые сканеры находят открытый порт 32400 за считанные минуты.

Изображение злоумышленника за ноутбуком, перехватывающего трафик

Почему доступ через домен и TLS лучше

Стандартные HTTPS-сервисы работают через порты 80 (HTTP) и 443 (HTTPS). Если вы проксируете ваш Plex через 443, простой сканер портов не выдаст, что внутри — это Plex. HTTPS использует TLS, который защищает от большинства MITM-атак и шифрует трафик между клиентом и точкой терминальной связи (реверс-прокси).

Преимущества подхода с доменом + TLS:

Трафик шифруется — пароли и токены не передаются в открытом виде.
Можно получать бесплатные сертификаты от Let’s Encrypt с автоматическим обновлением.
Порт 32400 остаётся закрытым и невидимым для внешних сканеров.
Гибкость: легко добавить другие сервисы (Nextcloud, Home Assistant) за тем же прокси.

Стоимость: домен можно купить дешёвый или взять бесплатный у некоторых провайдеров; Raspberry Pi Zero W стоит недорого и потребляет мало электроэнергии.

Решение: реверс‑прокси на Raspberry Pi — пошаговая методология

Ниже — компактный SOP (пошаговая инструкция), адаптированный для домашнего пользователя.

DNS: в панели регистратора создайте A‑запись на ваш публичный IP.
- Хост: @
- Значение: ваш.public.ip.address
- TTL: минимально возможный (например, 300 с).
Настройки роутера: пробросьте порты 80 и 443 на локальный IP Raspberry Pi. Закройте прямой доступ к порту 32400 снаружи.

Снимок экрана админки роутера с настройками проброса HTTP и HTTPS

Установите Raspberry Pi OS, подключитесь по SSH:

ssh pi@your.pi.local.ip

Обновите систему:

sudo apt update
sudo apt upgrade -y

Установите Apache (или другой веб‑сервер):

sudo apt install apache2 -y
sudo systemctl start apache2
sudo systemctl enable apache2

Установите Certbot для получения сертификатов Let’s Encrypt (вариант для Apache):

sudo add-apt-repository ppa:certbot/certbot -y
sudo apt update
sudo apt-get install python3-certbot-apache -y

Создайте конфигурацию виртуального хоста, проксирующую ваш домен на Plex (файл plex.conf):

sudo nano /etc/apache2/sites-available/plex.conf

Вставьте:


    ServerName your-domain-name.tld
    ProxyPreserveHost On
    ProxyPass / http://your.plex.server.local.ip:32400/
    ProxyPassReverse / http://your.plex.server.local.ip:32400/
    RewriteEngine on
    RewriteCond %{HTTP:Upgrade} websocket [NC]
    RewriteCond %{HTTP:Connection} upgrade [NC]

Сохраните (Ctrl+O) и закройте (Ctrl+X).

Активируйте сайт и перезапустите Apache:

sudo a2ensite plex.conf
sudo systemctl restart apache2

Запустите certbot и получите сертификат:

sudo certbot --apache

Следуйте подсказкам: введите email, согласитесь с условиями, выберите домен.

Проверьте HTTPS доступ из внешней сети: https://your-domain-name.tld
Закройте проброс порта 32400 в настройках роутера и убедитесь, что локальные устройства в вашей домашней сети продолжают получать медиа от Plex напрямую (через локальный IP) или через прокси в зависимости от конфигурации.

Примечание: если Plex и Raspberry Pi находятся в одной локальной сети, проксирование внешнего трафика через Pi не должно мешать локальной работе Plex внутри сети.

Правильные команды и отладка

Если certbot сообщает о проблемах с проверкой домена, проверьте:

DNS‑запись действительно указывает на ваш публичный IP (используйте dig или nslookup).
Маршрутизация роутера: порт 80/443 проброшены на Pi.
Нету активного файрвола, блокирующего входящие соединения на Pi.

Полезные команды:

# Проверка DNS
dig +short your-domain-name.tld

# Проверка открытых портов на публичном IP (из внешней сети)
nc -vz your.public.ip.address 80
nc -vz your.public.ip.address 443

# Логи Apache
sudo journalctl -u apache2 -f
sudo tail -n 200 /var/log/apache2/error.log

Альтернативные подходы (когда Raspberry Pi + Apache не подходит)

Nginx в роли реверс-прокси: легче управлять проксированием websocket и кешированием, популярно у продвинутых пользователей.
Caddy server: автоматически управляет TLS от Let’s Encrypt и требует минимальной конфигурации; хорош для быстрого деплоя.
VPN (OpenVPN, WireGuard): доступ к Plex только через VPN — повышенная безопасность, но требует установки клиента на устройствах.
Tailscale или ZeroTier: виртуальная частная сеть, упрощает доступ к устройствам без проброса портов и публичных сертификатов.
Облачный реверс через Cloudflare Tunnel: скрывает публичный IP и упрощает TLS, но требует доверия третьей стороне.

Когда альтернативы уместны:

Если вы не хотите получать публичный сертификат — используйте VPN/Tailscale.
Если хотите минимальной настройки TLS — рассмотрите Caddy.
Если нужно более гибкое управление трафиком и логами — используйте Nginx.

Ментальные модели и эвристики при выборе архитектуры

«Принцип минимальной поверхности атаки»: чем меньше открытых портов и сервисов, тем лучше.
«Разделение ролей»: не держите публичный прокси и медиасервер на одном хосте.
«Обновляй или умирай»: устаревшие версии ПО — главный источник компрометаций.
«Проверяй извне»: имитируй внешний доступ для тестирования (мобильный интернет, VPN на другом конце).

Чек-листы по ролям

Чек-лист для домашнего пользователя:

Зарегистрирован домен и создана A‑запись.
Проброшены порты 80 и 443 на Raspberry Pi.
Порт 32400 закрыт для внешнего доступа.
Получен и установлен сертификат от Let’s Encrypt.
Apache/Nginx/Caddy настроен на проксирование к Plex.
Plex обновлён до последней стабильной версии.

Чек-лист для администратора сети:

Настроены правила файрвола (ufw/iptables) на Pi и на хосте Plex.
Логи прокси собираются и сохраняются минимум 30 дней.
Настроено оповещение о неудачных попытках входа и аномалиях.
Произведено тестирование SSL Labs для проверки конфигурации TLS.

Матрица рисков и меры смягчения

Риск	Вероятность	Влияние	Митигирующие меры
Сканы портов и обнаружение Plex	Высокая	Среднее	Закрыть 32400, проксировать через 443
Перехват учетных данных (MITM)	Средняя	Высокое	Включить TLS, использовать HSTS
Эксплуатация известной уязвимости Plex	Средняя	Высокое	Обновлять Plex, ограничивать доступ по IP при возможности
Скомпрометирован прокси (Pi)	Низкая	Высокое	Минимизировать софт на Pi, ограничить доступ SSH по ключам

Настройка безопасности: жёсткая защита прокси и сети

Настройте SSH под ключи, запретите root‑логин и вход по паролю.
Включите ufw и разрешите только нужные порты:

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

Регулярно обновляйте систему и Plex.
Включите двухфакторную аутентификацию в Plex, где поддерживается.
Рассмотрите использование fail2ban для защиты SSH и веб‑интерфейса.
Настройте автоматическое обновление сертификатов (certbot делает это автоматически при правильной конфигурации).

Когда этот подход не сработает: ограничения и контрпримеры

Если ваш провайдер меняет публичный IP очень часто и вы не используете DDNS, DNS‑записи будут устаревать.
Если у вас ограниченный доступ к роутеру (например, на арендованном жилье), вы можете не иметь возможности пробросить порты.
Если вы не доверяете облачным CA или хотите полностью автономное решение — VPN лучше, чем публичные сертификаты.

Критерии приёмки

Внешний порт 32400 недоступен извне (проверено из мобильного интернета).
https://your-domain-name.tld открывается и показывает Plex UI без предупреждений о сертификате.
Plex обновлён до текущей стабильной версии.
SSH на Raspberry Pi настроен на ключи, файрвол активирован.

Короткий экспертный совет

Хорошая практика — комбинировать подходы: использовать TLS через реверс‑прокси для удобства доступа и Tailscale/WireGuard для административного доступа и резервного способа подключения в случае проблем.

1‑строчный глоссарий

TLS — протокол шифрования, защищающий HTTPS.
Реверс‑прокси — сервер, принимающий внешние HTTP/HTTPS-запросы и пересылающий их внутрь сети.
Certbot — клиент для автоматического получения сертификатов Let’s Encrypt.
DDNS — динамический DNS для обновления домена при изменении IP.

Резюме

Открытый порт 32400 делает Plex уязвимым к сканированию и MITM-атакам.
Схема «домен + TLS + реверс‑прокси» уменьшает поверхность атаки и шифрует трафик.
Raspberry Pi — дешёвый и энергоэффективный вариант для хоста прокси.
Рассмотрите альтернативы (nginx, Caddy, VPN, Tailscale) в зависимости от уровня доверия и требований к доступу.

Короткие шаги напомнить: зарегистрировать домен, пробросить 80/443 на Pi, получить сертификат, проксировать трафик на Plex и закрыть 32400.