VNC становится популярным вектором атак

VNC остаётся популярным способом удалённого доступа к рабочему столу Linux, но именно простота делает его частой мишенью. Открытый порт 5900, слабый пароль и отсутствие шифрования — типичная комбинация, которую сканеры находят за минуты. Разберём, как защитить VNC и чем его заменить.

Почему VNC опасен

Протокол VNC передаёт изображение экрана и события ввода. В базовой реализации трафик не шифруется, а аутентификация часто сводится к паролю. Если сервер доступен из интернета, злоумышленник может подбирать пароль или эксплуатировать уязвимость в конкретной реализации.

Даже «только на минуту» открытый порт может быть просканирован. Автоматические боты не спят, а список открытых VNC-серверов давно ходит по сети.

Как проверить, что у вас открыто

ss -tulpn | grep -E "5900|5901|vnc"
sudo ufw status verbose
sudo iptables -S | grep 5900

Если VNC слушает 0.0.0.0 или ::, он доступен не только локально. Правильная настройка — слушать 127.0.0.1 и подключаться через SSH-туннель.

# пример для TigerVNC
vncserver -localhost yes :1

SSH-туннель

Самый простой способ защитить VNC — не открывать его в сеть, а прокинуть порт через SSH. Трафик шифруется, а доступ контролируется ключами.

ssh -L 5901:127.0.0.1:5901 user@server
# затем подключайтесь VNC-клиентом к localhost:5901

Убедитесь, что на сервере VNC слушает только localhost. Если он слушает все интерфейсы, туннель не поможет: порт всё равно доступен напрямую.

Пароли и аутентификация

Пароль VNC должен быть длинным и уникальным. Не используйте общий пароль для нескольких серверов. Храните его в менеджере паролей, а не в заметке на рабочем столе.

vncpasswd
# проверьте права на файл пароля
ls -l ~/.vnc/passwd
chmod 600 ~/.vnc/passwd

Некоторые реализации поддерживают TLS и сертификаты. Если ваш сервер это умеет, включите. Но TLS не заменяет сетевую изоляцию: уязвимость в сервере остаётся.

Файрвол и сегментация

Разрешайте VNC только с доверенных адресов. Если доступ нужен извне, используйте VPN, а не прямой проброс порта. Для домашней лаборатории достаточен SSH-туннель из локальной сети.

sudo ufw allow from 192.168.1.0/24 to any port 5901 proto tcp
sudo ufw deny 5900/tcp
sudo ufw status numbered

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

Логи и мониторинг

Следите за неудачными попытками входа. Всплеск подключений с разных адресов — признак перебора. Для SSH и VNC полезно ограничить число попыток.

journalctl -u vncserver@:1 -n 50
grep -i "vnc" /var/log/auth.log | tail -20
sudo apt install fail2ban

Fail2ban не всегда умеет разбирать логи VNC, но для SSH он обязателен. Если VNC доступен только через туннель, перебор VNC становится менее вероятным.

Альтернативы

Для интерактивного доступа к рабочему столу рассмотрите RDP через xrdp с TLS, RustDesk с собственным сервером или Sunshine/Moonlight для низкой задержки. Для администрирования серверов чаще достаточно SSH и веб-панелей.

sudo apt install xrdp
sudo systemctl status xrdp
sudo ufw allow from 192.168.1.0/24 to any port 3389 proto tcp

Любой удалённый доступ требует обновлений. Уязвимость в VNC-сервере может дать выполнение кода до аутентификации — тогда пароль не спасёт.

Если сервер уже был открыт

Проверьте логи, активные сессии и изменения в системе. Смените пароли, обновите пакет VNC, закройте порт. Если был доступ злоумышленника, он мог установить persistence: cron, systemd-юниты, ключи SSH.

last -a | head
crontab -l
systemctl list-units --type=service --state=running
ls -la ~/.ssh/authorized_keys

Не ограничивайтесь удалением подозрительного файла: проверьте, какие учётные данные могли быть украдены, и отзовите их.

Настройка TigerVNC

TigerVNC — распространённая реализация с поддержкой локального режима. Проверьте конфигурацию и запускайте сессию с явным указанием localhost.

cat ~/.vnc/config
vncserver -localhost yes -geometry 1920x1080 -depth 24 :1
vncserver -list

Для systemd-юнита убедитесь, что в команде запуска есть -localhost yes, а в файле окружения нет переменных, отключающих аутентификацию. После изменений перезапустите сервис и проверьте ss -tulpn.

systemctl --user restart vncserver@:1
ss -tulpn | grep 5901

Если используется x11vnc, не запускайте его с -nopw и не оставляйте -forever без ограничения доступа. Для разового подключения запускайте вручную и закрывайте после сеанса.

Двухфакторная защита доступа

VNC сам по себе редко поддерживает MFA. Добавьте второй фактор на уровне SSH: отключите вход по паролю, используйте ключи и, при необходимости, TOTP через PAM. Тогда туннель защищён сильнее, чем пароль VNC.

sudo apt install libpam-google-authenticator
google-authenticator
sudo sshd -T | grep -E "passwordauthentication|kbdinteractiveauthentication"

Проверьте настройки на тестовом подключении, прежде чем закрывать текущую сессию: ошибка в PAM может заблокировать доступ к серверу.

Итог

VNC удобен, но небезопасен по умолчанию. Слушайте только localhost, подключайтесь через SSH-туннель, используйте длинные пароли, ограничьте доступ файрволом и обновляйте сервер. Если нужен постоянный удалённый доступ, выбирайте решение с шифрованием и современной аутентификацией, а не открытый порт 5900.