Безопасность Linux VPS: слои, угрозы, hardening

Ты только что создал Linux VPS. Уже через 90 секунд автоматические сканеры его обнаружили. В течение первого часа SSH-логи покажут сотни попыток брутфорса от ботнетов, перебирающих стандартные логины и пароли.

Это не гипотетический сценарий. Так происходит с каждым публичным сервером.

Большинство руководств по безопасности VPS дают тебе пронумерованный список из 20+ советов без структуры и приоритетов. Этот гайд устроен иначе. Безопасность здесь организована как концентрические слои, каждый из которых сужает поверхность атаки. Ты поймёшь, какие атаки реально бьют по серверу и какие защиты их останавливают.

Если настраиваешь первый VPS — начни с первых 5 шагов безопасности. Только этот раздел блокирует более 90% автоматизированных атак.

Если ты опытный админ — используй быстрые ссылки, чтобы перейти прямо к нужному слою.

Руководство охватывает Debian 12 и Ubuntu 24.04. Все команды протестированы на обеих системах.

Какие атаки нацелены на свежий Linux VPS?

Свежий VPS с публичным IP сталкивается с автоматизированными атаками уже через секунды после запуска. Ботнеты непрерывно сканируют весь диапазон IPv4-адресов. Самые частые атаки — credential stuffing через SSH, сканирование портов в поисках открытых сервисов и эксплуатация известных уязвимостей в непропатченном ПО.

Понимание модели угроз делает каждую рекомендацию этого гайда очевидной. Вот что происходит на самом деле:

Автоматизированное сканирование

Ботнеты постоянно сканируют весь диапазон IPv4-адресов. Проекты вроде Shodan и Censys индексируют каждый доступный порт. Твой сервер не является конкретной целью. Его находят просто потому, что он существует.

В течение первого часа после создания жди:

200+ попыток SSH-входа с распределённых IP
Сканирования портов в поисках баз данных (3306, 5432), веб-серверов (80, 443) и панелей администратора
Запросов по известным уязвимым путям (/wp-admin, /phpmyadmin, /.env)

Credential stuffing и брутфорс

Атакующие используют базы утёкших учётных данных, чтобы перебирать комбинации логин/пароль против твоего SSH-сервиса. Они поочерёдно пробуют root, admin, ubuntu, deploy и другие распространённые имена. Если парольная аутентификация включена с слабым паролем — компрометация занимает минуты.

Supply chain и действия после компрометации

Попав внутрь, атакующие устанавливают криптомайнеры, добавляют SSH-бэкдоры или используют твой сервер как relay для дальнейших атак. Некоторые устанавливают руткиты, которые выживают после перезагрузки. Скомпрометированный VPS может использоваться для атак на другие серверы, что делает тебя ответственным за этот трафик.

Также растёт тренд supply chain-атак, нацеленных на репозитории пакетов и install-скрипты. Паттерн curl | bash, распространённый во многих setup-гайдах, выполняет произвольный код из интернета без проверки. Избегай этого. Скачай скрипт, проверь контрольные суммы, затем выполни.

Разведка через раскрытие версий

Атакующие снимают fingerprint ПО сервера, чтобы найти подходящие эксплойты. Веб-сервер, отвечающий Server: nginx/1.24.0, или SSH-баннер с точной версией OpenSSH говорит атакующему ровно то, какие CVE стоит попробовать. Скрытие версии — небольшой шаг, но он убирает атаки с минимальными усилиями. В этом гайде и связанных туториалах ты увидишь, как отключить раскрытие версий для каждого сервиса.

Что это означает для твоей защиты

Каждый слой в этом гайде закрывает конкретные векторы атак:

Вектор атаки	Слой защиты
SSH брутфорс	SSH key auth, Fail2Ban
Сканирование портов	Firewall (UFW/nftables)
Credential stuffing	Отключение парольной аутентификации, non-root пользователь
Непропатченные уязвимости	Автоматические обновления безопасности
Несанкционированный доступ к admin-сервисам	VPN (WireGuard/Tailscale)
Повышение привилегий	Права пользователей, sudo

Какие первые 5 шагов безопасности на новом VPS?

Если ты не сделаешь ничего другого — сделай эти пять вещей. Они занимают менее 15 минут и блокируют подавляющее большинство автоматизированных атак: 1) обновить все пакеты, 2) создать non-root пользователя с sudo, 3) настроить SSH key-аутентификацию и отключить пароли, 4) включить firewall, 5) установить Fail2Ban.

Вот быстрый старт. Каждый шаг ссылается на подробный туториал.

1. Обновить все пакеты

apt update && apt upgrade -y

Это закрывает известные уязвимости. На свежем VPS базовый образ может отставать от security patches на недели или месяцы.

2. Создать non-root пользователя

adduser deploy
usermod -aG sudo deploy

Работа под root означает, что любая ошибка или эксплойт имеет полный доступ к системе. sudo-пользователь требует явного повышения привилегий.

3. Настроить SSH key-аутентификацию

На локальной машине сгенерируй пару ключей Ed25519, если её ещё нет:

ssh-keygen -t ed25519 -C "your-email@example.com"

Скопируй на сервер:

ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@your-server-ip

Затем на сервере отредактируй /etc/ssh/sshd_config:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

Перезапусти SSH. На Ubuntu 24.04 SSH использует socket-based activation:

# Ubuntu 24.04
sudo systemctl restart ssh.socket

# Debian 12
sudo systemctl restart sshd

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

4. Включить firewall

# Установить UFW (предустановлен на Ubuntu, на Debian нужна установка)
sudo apt install ufw -y

# Разрешить SSH до включения firewall
sudo ufw allow ssh

# Включить firewall
sudo ufw enable

# Проверить
sudo ufw status

Должен увидеть SSH (порт 22) со статусом ALLOW. Всё остальное запрещено по умолчанию.

5. Установить Fail2Ban

sudo apt install fail2ban -y

Создай локальную конфигурацию jail:

sudo tee /etc/fail2ban/jail.d/sshd.conf > /dev/null << 'EOF'
[sshd]
enabled = true
maxretry = 3
findtime = 600
bantime = 1800
EOF

На Debian 12 Fail2Ban нужно читать из journald вместо auth.log:

# Только Debian 12
echo "sshd_backend = systemd" | sudo tee -a /etc/fail2ban/paths-debian.conf

Запусти и включи сервис:

sudo systemctl enable --now fail2ban

Проверь, что работает:

sudo systemctl status fail2ban
sudo fail2ban-client status sshd

Должен видеть jail sshd как активный с 0 заблокированных IP. Через несколько часов баны начнут появляться.

Как SSH hardening защищает сервер?

SSH — это парадный вход на сервер и цель номер один для автоматизированных атак. SSH hardening означает замену парольной аутентификации на криптографические ключи, отключение входа под root и ограничение пользователей и алгоритмов, которые сервер принимает. Эти изменения сужают поверхность атаки SSH от «попробуй любой пароль» до «предъяви этот конкретный приватный ключ».

Помимо основ из первых 5 шагов, hardened конфигурация SSH включает:

Только Ed25519 ключи. Быстрее и безопаснее RSA. Ключ 256 бит, но обеспечивает 128-битную безопасность, эквивалентную RSA-3072.
Таймаут бездействия. Отключай неактивные сессии, чтобы брошенные терминалы не перехватили:

ClientAliveInterval 300
ClientAliveCountMax 2

Ограничение пользователей. Ограничь SSH-доступ конкретными аккаунтами:

AllowUsers deploy

Отключение неиспользуемых методов аутентификации:

KbdInteractiveAuthentication no
X11Forwarding no

Скрытие SSH-баннера версии. OpenSSH не позволяет полностью подавить версию протокола, но можно убрать кастомные баннеры и ограничить утечку информации:

Banner none
DebianBanner no

После любого изменения в sshd_config проверь синтаксис перед перезапуском:

sudo sshd -t

Если команда не выдала вывод — конфигурация валидна. Затем перезапусти SSH и убедись, что всё ещё можешь войти из второго терминала. Всегда тестируй из второй сессии. Если конфиг сломан — у тебя ещё есть активное соединение.

Полный walkthrough по SSH hardening с протестированными конфигами для Debian 12 и Ubuntu 24.04 смотри в .

Зачем VPS нужен firewall?

Firewall контролирует, какой сетевой трафик достигает сервера. Без него каждый запущенный сервис доступен из интернета. База данных на порту 5432, dev-сервер на порту 3000, экземпляр Redis на порту 6379 — всё доступно любому. Firewall гарантирует, что доступны только явно открытые порты.

Debian 12 и Ubuntu 24.04 используют nftables как фреймворк фильтрации пакетов на уровне ядра. UFW (Uncomplicated Firewall) сидит поверх как удобный интерфейс. Для большинства VPS-задач UFW — правильный выбор.

UFW vs nftables: когда что использовать

	UFW	nftables
Лучше для	Одиночные серверы, веб-приложения	Несколько серверов, сложная маршрутизация
Кривая обучения	Минуты	Часы-дни
По умолчанию на	Ubuntu (предустановлен)	Debian 12 (бэкенд)
Синтаксис правил	`ufw allow 443/tcp`	Tables, chains, rule expressions
Когда переходить	N/A	Нужно per-packet logging, rate limiting, сложный NAT

Типичный firewall веб-сервера с UFW:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow ssh
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

Проверь правила:

sudo ufw status numbered

Каждый открытый порт — потенциальная точка входа. Открывай только то, что нужно приложению. Убрал сервис — убери и правило firewall.

Подробную конфигурацию firewall, включая правила nftables, rate limiting и per-port контроль доступа, смотри в .

Как Fail2Ban останавливает брутфорс-атаки?

Fail2Ban мониторит лог-файлы (или journald на Debian 12) на повторяющиеся неудачные попытки аутентификации и временно банит нарушающие IP с помощью правил firewall. Он превращает брутфорс-атаку из «попробуй 10 000 паролей» в «попробуй 3 пароля, получи бан на 30 минут, начни заново с другого IP».

Как это работает

Fail2Ban следит за SSH-логами аутентификации
После maxretry неудач в течение findtime создаётся правило firewall, блокирующее этот IP
После истечения bantime правило удаляется
Упорные атакующие перебирают IP, но rate limit делает credential stuffing нецелесообразным

Как права пользователей сужают поверхность атаки?

Запуск сервисов под root даёт атакующему полный доступ к системе при компрометации этого сервиса. Принцип наименьших привилегий означает, что каждый процесс работает с минимумом необходимых прав. Компрометация веб-сервера не должна давать доступ к базе данных, SSH-ключам или системной конфигурации.

Ключевые практики

Никогда не запускай прикладные сервисы под root. У веб-серверов, баз данных и application runtime должны быть собственные системные пользователи:

sudo useradd --system --shell /usr/sbin/nologin --home-dir /opt/myapp myapp

Флаг --system создаёт пользователя без входа в home-директорию. --shell /usr/sbin/nologin запрещает интерактивный вход. Этот пользователь может запускать приложение, но не может войти по SSH или выполнять произвольные команды.

Ограничь sudo-доступ. Повышенными привилегиями должны обладать только пользователи в группе sudo. Проверь, у кого есть sudo:

getent group sudo

Правильно выстави права на файлы. Конфигурационные файлы с паролями или API-ключами не должны быть readable для всех:

# Ограничить конфиг-файл только для владельца
sudo chmod 600 /etc/myapp/config.env
sudo chown myapp:myapp /etc/myapp/config.env

# Проверить
ls -la /etc/myapp/config.env

Должен видеть права -rw-------, то есть только владелец может читать и писать.

Используй env-файлы для секретов. Вместо хардкода учётных данных в конфигах создай выделенный env-файл с ограниченными правами:

sudo tee /etc/myapp/env > /dev/null << 'EOF'
DB_PASSWORD=your-generated-password
API_KEY=your-api-key
EOF

sudo chmod 600 /etc/myapp/env
sudo chown myapp:myapp /etc/myapp/env

Ссылайся на него в systemd units через EnvironmentFile=/etc/myapp/env. Генерируй пароли с помощью openssl rand -base64 32, а не придумывай вручную.

Полный гайд по управлению пользователями Linux, настройке sudo и моделям прав смотри в .

Зачем автоматизировать обновления безопасности?

Непропатченное ПО — один из самых эксплуатируемых векторов атак. Когда раскрывается уязвимость, атакующие начинают сканировать непропатченные серверы уже через несколько часов. Ручные обновления означают, что сервер уязвим с момента раскрытия до следующего раза, когда ты вспомнишь запустить apt upgrade. Автоматические обновления безопасности закрывают это окно.

Настройка unattended-upgrades

Ubuntu 24.04 включает unattended-upgrades в стандартную установку сервера, но некоторые VPS-провайдеры поставляют минимальные образы без него. Debian 12 тоже требует установки. На любом дистрибутиве установи, если ещё нет:

sudo apt install unattended-upgrades apt-listchanges -y
sudo dpkg-reconfigure -plow unattended-upgrades

Убедись, что активен:

cat /etc/apt/apt.conf.d/20auto-upgrades

Должен видеть:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

"1" означает ежедневно. Списки пакетов обновляются каждый день, security patches устанавливаются автоматически.

Что обновляется

По умолчанию устанавливаются только обновления безопасности из официального репозитория. Это правильная настройка для production-сервера. Обновления фич и смена мажорных версий по-прежнему требуют ручного вмешательства, что защищает от поломки приложения при автоматических обновлениях.

Мониторинг обновлений

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

sudo cat /var/log/unattended-upgrades/unattended-upgrades.log

Настрой email-уведомления об установленных обновлениях, отредактировав /etc/apt/apt.conf.d/50unattended-upgrades:

Unattended-Upgrade::Mail "admin@example.com";
Unattended-Upgrade::MailReport "on-change";

Для автоматической обработки перезагрузки при обновлениях ядра:

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";

Включай автоматические перезагрузки только если приложение корректно обрабатывает рестарты. Для большинства сетапов еженедельная ручная проверка лучше, чем внезапные перезагрузки.

Полный гайд по настройке, мониторингу и troubleshooting смотри в .

Когда добавлять VPN-доступ к VPS?

Добавляй VPN-доступ, когда запускаешь сервисы, которые никогда не должны быть открыты в публичный интернет: панели администратора, базы данных, monitoring dashboards или внутренние API. VPN создаёт зашифрованный туннель, так что эти сервисы доступны только с устройств в твоей приватной сети. Вместо того чтобы открывать порт 3000 всему миру и надеяться на аутентификацию, ты закрываешь его от интернета полностью и заходишь через VPN.

WireGuard vs Tailscale

	WireGuard	Tailscale
Время настройки	15-30 минут на peer	2-5 минут всего
Конфигурация	Ручной обмен ключами, конфиг-файлы	SSO-вход, автоматически
NAT traversal	Ручной проброс портов	Автоматический
Контроль	Полный, управляешь сам	Coordination server у третьей стороны
Стоимость	Бесплатно, self-hosted	Бесплатно до 100 устройств
Лучше для	Фиксированная инфраструктура, полный контроль	Команды, динамические устройства, быстрая настройка

Выбирай WireGuard, когда хочешь полный контроль над сетью, у тебя статичная инфраструктура и ты не боишься управлять парами ключей и конфиг-файлами.

Выбирай Tailscale, когда нужна быстрая настройка на нескольких устройствах, работаешь с командой или хочешь автоматический NAT traversal без проброса портов.

Оба используют протокол WireGuard под капотом. Tailscale — это WireGuard с оркестрацией.

Что прятать за VPN

Порты баз данных (PostgreSQL 5432, MySQL 3306, Redis 6379)
Панели администратора (phpMyAdmin, Adminer, Grafana)
Monitoring endpoints (Prometheus, Node Exporter)
Внутренние API, не предназначенные для публичного использования
SSH-доступ (belt and suspenders: key auth + VPN)

Распространённый паттерн: оставить открытыми порты 80 и 443 для публичного веб-приложения. Всё остальное через VPN. Правила firewall принимают вид:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 51820/udp  # WireGuard
# SSH только из подсети VPN
sudo ufw allow from 10.0.0.0/24 to any port 22

Пошаговую настройку WireGuard и Tailscale на VPS смотри в .

А что насчёт смены SSH-порта?

Многие гайды рекомендуют сменить SSH с порта 22 на порт с большим номером. Это security through obscurity. Останавливает только самых ленивых ботов, которые пробуют только порт 22. Не останавливает никого, кто запускает сканирование портов — а это занимает секунды.

Реальная цена: теперь нужно помнить -p 2222 при каждом SSH-подключении, настраивать это в каждом deploy-скрипте и CI-пайплайне, рискуя заблокировать себя, если забудешь. SSH key-аутентификация с Fail2Ban даёт реальную безопасность. Смена порта добавляет операционную сложность ради минимальной выгоды.

Та же логика применима к отключению IPv6. Если у сервера есть IPv6-адрес, его отключение не уменьшает поверхность атаки. Это ломает совместимость в будущем. Лучше настрой firewall для IPv4 и IPv6 одновременно.

Слои безопасности в одном взгляде

Каждый слой в этом гайде закрывает конкретную часть защиты. Вот как они складываются:

Слой	Что защищает	Приоритет
Обновления системы	Закрывает известные уязвимости	Делай первым
Права пользователей	Ограничивает радиус взрыва при компрометации	Делай первым
SSH hardening	Блокирует несанкционированный удалённый доступ	Делай первым
Firewall	Контролирует сетевую экспозицию	Делай первым
Fail2Ban	Замедляет брутфорс-атаки	Делай первым
Автоматические обновления	Поддерживает patches актуальными долгосрочно	Настрой в первую неделю
VPN-доступ	Скрывает внутренние сервисы	При запуске непубличных сервисов
Kernel hardening	Ограничивает техники эксплуатации	Продвинутый, production-системы
Audit logging	Обнаруживает компрометацию постфактум	Продвинутый, compliance

Первые пять слоёв обязательны для любого сервера, подключённого к интернету. Остальные слои добавляют глубину в зависимости от того, что запускаешь, и твоих compliance-требований.

Ни один слой не достаточен сам по себе. SSH hardening без firewall всё равно оставляет сервисы открытыми. Firewall без автоматических обновлений оставляет известные уязвимости открытыми. Слои работают вместе. Каждый ловит то, что пропустили другие.

Когда стоит использовать managed hosting?

Если управление безопасностью отнимает время от разработки продукта — рассмотри managed hosting. Это не провал. Это решение о распределении ресурсов.

Признаки, что стоит рассмотреть managed hosting:

Ты запускаешь production-сервис, но нет времени следить за security advisories
В команде нет опыта Linux-администрирования
Нужны compliance-сертификации (SOC 2, ISO 27001), но нет ресурсов на аудит
Уже был взлом, а экспертизы для расследования нет

Managed-сервер от провайдера вроде Virtua Cloud берёт на себя OS patching, управление firewall, обнаружение вторжений и бэкапы. Ты занимаешься приложением. Провайдер занимается слоем безопасности инфраструктуры.

Для команд, которым нужна гибкость VPS с частичным покрытием безопасности, есть средний путь: используй unmanaged VPS для разработки и staging, а managed hosting — для production.

Что-то пошло не так?

Проверь SSH-доступ

Если заблокирован после изменения конфига SSH:

Используй веб-консоль или serial-консоль провайдера VPS для доступа к серверу
Проверь синтаксис SSH-конфигурации: sudo sshd -t
Убедись, что ключ есть в ~/.ssh/authorized_keys для правильного пользователя
Проверь SSH-логи: journalctl -u ssh -n 50 (Ubuntu) или journalctl -u sshd -n 50 (Debian)

Проверь firewall

Если сервис недоступен:

sudo ufw status numbered

Убедись, что порт числится как ALLOW. Если только что включил UFW и забыл сначала разрешить SSH — используй веб-консоль провайдера.

Проверь Fail2Ban

Если легитимный IP попал под бан:

# Проверить, забанен ли IP
sudo fail2ban-client status sshd

# Разбанить конкретный IP
sudo fail2ban-client set sshd unbanip 1.2.3.4

Читай логи

Логи скажут, что произошло:

# SSH-аутентификация
journalctl -u ssh -f     # Ubuntu 24.04
journalctl -u sshd -f    # Debian 12

# Активность Fail2Ban
sudo tail -f /var/log/fail2ban.log

# Блокировки firewall (при использовании nftables logging)
journalctl -k | grep nft

# Системные сообщения
journalctl -p err -b

Приучи себя читать вывод логов. Каждый раз, когда что-то ломается, ответ почти всегда в логах.

Следующие шаги

Этот гайд охватывает слои безопасности Linux VPS. Каждый раздел ссылается на подробный практический туториал:

Начни с первых 5 шагов безопасности, если ещё не сделал. Затем проходи туториалы по порядку. Каждый строится на предыдущем.

Безопасность Linux VPS: угрозы, слои защиты и руководство по hardening