VPN-сервер: чек-лист hardening безопасности

MAATRIX

Вы подняли WireGuard или OpenVPN, всё работает — и на этом обычно останавливаются. А зря: голый VPN-сервер с открытым SSH на 22 порту и default-конфигом — это не защита, а просто ещё одна точка входа для ботов, которые сканируют интернет круглосуточно. Ниже — рабочий чек-лист hardening, который закрывает типовые дыры за один вечер, без параноидального оверинжиниринга.

Firewall: разрешайте только то, что реально нужно

Базовое правило — политика по умолчанию «запретить всё», и точечные разрешения поверх неё. На Ubuntu/Debian проще всего через UFW:

ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp comment 'SSH'
ufw allow 51820/udp comment 'WireGuard'
ufw enable

Для OpenVPN добавьте свой порт (обычно 1194/udp) — и по возможности смените его на нестандартный, это не защита от целенаправленной атаки, но отсекает автоматическое сканирование ботами.

Проверьте, что не слушает наружу лишнее — панели управления, Redis, exporter'ы метрик:

ss -tulpn | grep LISTEN

Всё, чего нет в списке разрешённых портов, либо переводите на 127.0.0.1, либо явно блокируйте. Не забудьте про IPv6 — частая дыра в том, что правила пишут только для IPv4, а v6-трафик идёт мимо. Для более сложных сценариев (несколько интерфейсов, NAT между VPN-подсетями) со временем стоит перейти на nftables напрямую, но для одиночного сервера UFW обычно достаточно.

fail2ban: автоматический бан за перебор

Firewall пропускает трафик к SSH и VPN-порту, а fail2ban следит за логами и банит IP, которые перебирают пароли или долбят хендшейками:

apt install fail2ban
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Минимальный jail для SSH в /etc/fail2ban/jail.local:

[sshd]
enabled = true
port = 22
maxretry = 4
findtime = 600
bantime = 3600

Для OpenVPN есть готовый фильтр — проверьте, что секция [openvpn] включена и указывает на реальный путь лога. WireGuard же fail2ban защищать не от чего: это UDP без классического хендшейка — пакет с неверным ключом сервер просто молча дропает, здесь работает сама криптография протокола плюс firewall.

Проверить статус:

fail2ban-client status sshd

Растущий список забаненных IP — нормальная картина для любого сервера с публичным SSH, значит защита реально нужна. Есть и альтернатива с общей базой репутации IP между серверами — fail2ban или CrowdSec.

Отключение неиспользуемых протоколов и сервисов

Каждый работающий сервис — лишняя поверхность атаки. Посмотрите, что включено на старте:

systemctl list-unit-files --state=enabled

Типичные кандидаты на отключение: avahi-daemon (mDNS для локальной сети, серверу не нужен), cups (печать), rpcbind.

systemctl disable --now avahi-daemon cups rpcbind

Если когда-то тестировали второй VPN-протокол, а сейчас работает только один — не оставляйте демон «на всякий случай», а полностью убирайте:

systemctl disable --now openvpn@server
apt purge openvpn

Отдельно проверьте локальный DNS-резолвер, если он поднят для клиентов VPN (например, unbound): убедитесь, что он не отвечает на recursive-запросы с любого IP — иначе сервер превращается в open resolver и его начинают использовать для DNS-амплификации в чужих атаках. В конфиге access-control ограничьте ответы только подсетью VPN.

Обновления: автоматические, но контролируемые

Большинство реальных взломов VPS — не эксплойт нулевого дня, а известная уязвимость в софте, который не обновляли полгода. Настройте автообновления безопасности:

apt install unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades

В /etc/apt/apt.conf.d/50unattended-upgrades ограничьте область только security-обновлениями, а автоматический reboot лучше отключить и следить за флагом /var/run/reboot-required вручную:

Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
};
Unattended-Upgrade::Automatic-Reboot "false";

Сервер с активными VPN-туннелями, который сам ушёл в перезагрузку в 3 часа ночи, роняет соединения у всех пользователей одновременно — предупреждайте об этом заранее или планируйте окно вручную.

Сам VPN-софт тоже стоит проверять отдельно: WireGuard встроен в ядро с версии 5.6, OpenVPN и его зависимости идут из репозитория. Раз в квартал сверяйте версии:

openvpn --version
apt list --upgradable | grep -i openvpn

SSH: ключи, отключение root-логина, лимиты

SSH — самый частый вектор атаки на VPS, потому что он есть всегда и легко сканируется. Базовый набор в /etc/ssh/sshd_config:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
X11Forwarding no
MaxAuthTries 3
AllowUsers deploy

PasswordAuthentication no включайте только после того, как залили публичный ключ в ~/.ssh/authorized_keys и проверили вход в отдельной сессии — не разрывайте текущее подключение до этой проверки, иначе рискуете остаться без доступа. Подробная настройка — в статье SSH-ключи вместо пароля.

Дополнительный слой — 2FA на SSH через PAM-модуль, а в жёстком варианте можно закрыть 22 порт наружу полностью и пускать только через сам VPN-туннель. У схемы есть проблема курицы и яйца при сбое VPN, поэтому держите резервный канал доступа — обычно веб-консоль провайдера.

Мониторинг и резервные копии конфигов

Hardening без наблюдения за результатом — разовая настройка, которая тихо деградирует. Минимальный набор:

• Логи авторизации — периодически просматривайте journalctl -u ssh -f, не полагайтесь только на fail2ban.
• Доступность сервера — если о падении VPN вы узнаёте от пользователей, это слишком поздно; настройте внешний мониторинг вроде Uptime Kuma.
• Аномальная нагрузка — внезапный скачок CPU на VPN-сервере часто означает не рост легитимного трафика, а майнинг, спам-рассылку или сканирование чужой сети через ваш сервер. Лишний процесс обычно виден в htop за пару минут наблюдения.

Отдельно позаботьтесь о резервной копии самих настроек безопасности — конфигов WireGuard/OpenVPN с ключами, правил firewall, jail.local, sshd_config:

tar czf vpn-config-backup-$(date +%F).tar.gz \
  /etc/wireguard /etc/openvpn /etc/fail2ban/jail.local /etc/ssh/sshd_config

Храните архив не на том же сервере — иначе бэкап бесполезен именно в момент, когда сервер недоступен.

Частые вопросы