Безопасность Ubuntu VPS

Ubuntu на VPS часто воспринимают как «поставил сервер – открыл SSH – дальше разберусь». Проблема в том, что интернет разберется быстрее: автоматические сканеры и боты приходят на новый публичный IP в течение короткого времени, и дальше начинается шум из перебора паролей, попыток уязвимых логинов и поиска неправильно настроенных сервисов.

Эту статью я пишу как редактор, который регулярно видит последствия компрометации VPS: от тихой установки криптомайнера до «внезапного» попадания IP в спам-листы из-за рассылки через взломанный веб-сайт. Если вы только выбираете площадку под сервер, удобно воспользоваться VPS.house – здесь можно арендовать виртуальный сервер и быстро развернуть актуальную Ubuntu для практики и последующей эксплуатации.

Ниже будет настройка защиты «с нуля» – но не в формате бесконечного списка «включите всё». Мы начнем с модели угроз и будем добавлять меры защиты только там, где они реально снижают риск. Это важно: в безопасности ценится не количество галочек, а управляемость и предсказуемость.

1. Сначала модель угроз, потом команды

Большинство провалов безопасности на VPS – не из-за «хакеров уровня кино», а из-за несогласованной конфигурации. Поэтому первый шаг – определить, от чего мы защищаемся:

• Удаленный вход: brute force по SSH, кража ключей, попытки залогиниться в root
• Уязвимости сервисов: веб-сервер, панели, базы данных, приложения
• Ошибки администрирования: открыли порт «на время», забыли; дали sudo без пароля; оставили тестовый аккаунт
• Посткомпрометация: злоумышленник уже внутри и пытается закрепиться, спрятать следы, расширить доступ

Из этого сразу вытекает базовый принцип: уменьшаем поверхность атаки (меньше доступных извне сервисов), усиливаем контроль доступа (SSH, права, ключи), делаем обнаружение и восстановление (логи, контроль целостности, бэкапы). Эту логику используют и в индустриальных бенчмарках вроде CIS Benchmarks для Linux: там важна воспроизводимость, а не «секретные твики».

2. Шаг 0 – подготовка до первого входа

2.1. Генерируем ключи SSH локально. Не делайте это на сервере, который еще не укреплен. На рабочей машине:

ssh-keygen -t ed25519 -a 64 -C "admin@yourdomain" 

Параметр -a увеличивает «стоимость» перебора (KDF). Пароль на ключ (passphrase) обязателен, если ключ хранится на ноутбуке или в домашней системе.

2.2. Домен и DNS. Если вы планируете веб, лучше сразу завести доменное имя и A/AAAA записи. Это не «про безопасность» напрямую, но дисциплинирует: вы меньше будете ходить по IP и быстрее заметите, что что-то «не то» (например, сертификат не выдается или порт не доступен).

3. Первые минуты после выдачи VPS: обновления и базовая гигиена

Золотое правило: сначала обновления, потом конфигурация. Сразу после входа под выданным пользователем (или временным root, если так устроено у провайдера) делаем:

sudo apt update

sudo apt -y full-upgrade

sudo reboot 

Почему это важно: многие атаки используют не «нулевой день», а известные уязвимости, где патч уже существует. На свежевыданных образах Ubuntu обычно всё неплохо, но «обычно» – не гарантия.

3.1. Автоматические обновления безопасности. На сервере без автоматизации вы почти гарантированно пропустите окно, когда патч уже вышел, а эксплойты уже в публичном доступе.

sudo apt -y install unattended-upgrades

sudo dpkg-reconfigure --priority=low unattended-upgrades 

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

4. Пользователи и права: «минимум привилегий» без фанатизма

Идеальная картина: один обычный пользователь для входа и администрирования, повышение прав через sudo, root по SSH – запрещен.

sudo adduser admin

sudo usermod -aG

sudo admin 

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

5. SSH: укрепляем главный входной шлюз

SSH – первая цель для автоматических атак. Здесь важны не «трюки», а дисциплина.

5.1. Копируем публичный ключ (с локальной машины):

ssh-copy-id -i ~/.ssh/id_ed25519.pub admin@SERVER_IP 

5.2. Настраиваем sshd. Открываем /etc/ssh/sshd_config и приводим к аккуратным значениям:

# Запрет root-логина PermitRootLogin no # Только ключи PasswordAuthentication no KbdInteractiveAuthentication no # Ограничиваем пользователей AllowUsers admin # Ограничиваем попытки и время MaxAuthTries 4 LoginGraceTime 30 # Уточняем, что публичные ключи – в стандартном месте PubkeyAuthentication yes 

Применяем:

sudo sshd -t

sudo systemctl reload ssh 

Про смену порта SSH. Это не мера «безопасности», а мера снижения шума в логах. Боты всё равно сканируют диапазоны портов. Если меняете – делайте это только вместе с остальными шагами, и обязательно откройте новый порт в firewall до перезагрузки SSH, иначе можно запереть себя снаружи.

5.3. Двухфакторная аутентификация. Для административного доступа (особенно если сервер критичный) имеет смысл добавить второй фактор. Варианты – FIDO2/U2F ключи или TOTP через PAM. Это усложняет жизнь и вам, и злоумышленнику, поэтому вводите 2FA там, где цена компрометации высока.

6. Firewall: «запрещено всё, кроме нужного»

На VPS нельзя полагаться на «внешний периметр». Ваш сервер торчит в интернет напрямую, и именно вы решаете, какие порты доступны.

Если нужен простой и прозрачный старт – используйте UFW (он управляет правилами, а внутри работает через nftables/iptables в зависимости от системы).

sudo apt -y install ufw

sudo ufw default deny incoming

sudo ufw default allow outgoing # Разрешаем SSH (если порт стандартный)

sudo ufw allow 22/tcp # Если будет веб

sudo ufw allow 80/tcp

sudo ufw allow 443/tcp

sudo ufw enable

sudo ufw status verbose 

Важно: сначала разрешите SSH, потом включайте UFW.

Точечная жесткость. Если администрируете с фиксированного IP, лучше разрешить SSH только с него:

sudo ufw delete allow 22/tcp

sudo ufw allow from YOUR_ADMIN_IP to any port 22 proto tcp 

Это сразу срезает огромный класс атак. Если IP меняется – можно использовать VPN или bastion-хост, но это отдельная архитектурная тема.

7. Защита от перебора: fail2ban и лимиты на уровне системы

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

sudo apt -y install fail2ban

sudo systemctl enable --now fail2ban 

Создайте локальный конфиг /etc/fail2ban/jail.d/sshd.local:

[sshd] enabled = true maxretry = 5 findtime = 10m bantime = 1h 

Перезапуск:

sudo systemctl restart fail2ban

sudo fail2ban-client status sshd 

Почему это работает: fail2ban банит по событиям в логах. Это не «панацея», но хорошо уменьшает поток ботов и помогает держать систему в порядке.

8. Убираем лишнее: открытые порты, сервисы, пакеты

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

Проверяем, что слушает сеть:

sudo ss -tulpn 

Дальше честно отвечаем: каждый порт вам действительно нужен? Если нет – отключаем сервис:

sudo systemctl disable --now SERVICE_NAME 

И удаляем пакеты, если это не часть инфраструктуры:

sudo apt -y purge PACKAGE_NAME

sudo apt -y autoremove 

Отдельный комментарий про «панели управления сервером». Панели экономят время, но расширяют поверхность атаки, потому что это сложные веб-приложения с собственными апдейтами и зависимостями. Если вы не готовы обслуживать панель как продукт – лучше администрировать без нее.

9. AppArmor: встроенная страховка, которую часто игнорируют

В Ubuntu по умолчанию есть AppArmor – механизм мандатного контроля доступа, который ограничивает, что может делать процесс даже при наличии уязвимости. Это не «антивирус», но очень полезный слой, особенно для сетевых сервисов.

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

sudo aa-status 

Если профили для Nginx, OpenSSH и других сервисов в режиме enforcing – это хороший знак. Не отключайте AppArmor «чтобы не мешал», лучше потратьте время и разберитесь, что именно блокируется и почему.

10. Сетевые sysctl-настройки: осторожно, но полезно

Тюнинг sysctl часто превращают в магию из копипасты. Делайте только то, что понимаете и можете объяснить. Но несколько настроек действительно типичны для базового hardening.

Файл /etc/sysctl.d/99-hardening.conf (пример, адаптируйте под свою роль сервера):

# Игнорируем ICMP redirect и source route

net.ipv4.conf.all.accept_redirects = 0

net.ipv4.conf.default.accept_redirects = 0

net.ipv4.conf.all.accept_source_route = 0

net.ipv4.conf.default.accept_source_route = 0

# Не отправляем redirect

net.ipv4.conf.all.send_redirects = 0

net.ipv4.conf.default.send_redirects = 0

# Включаем защиту от SYN flood

net.ipv4.tcp_syncookies = 1

Применяем:

sudo sysctl --system 

Важно: если VPS используется как роутер, VPN-шлюз или сложный сетевой узел, настройки нужно подбирать аккуратнее. Универсальных «всем включить всё» здесь нет.

11. Логи, аудит и «заметить проблему раньше, чем позвонит клиент»

Без наблюдаемости безопасность превращается в гадание. Минимальный набор:

• journald и ротация логов (logrotate) – чтобы не закончился диск
• централизация логов (хотя бы отправка на отдельный сервер или в облачный лог-стек)
• аудит действий для административных команд, если сервер важный

11.1. auditd. Это не самый легкий инструмент, но он полезен для расследований. Установка:

sudo apt -y install auditd audispd-plugins

sudo systemctl enable --now auditd 

Правила лучше брать из проверенных профилей (например, ориентироваться на CIS), но не включать «всё подряд», иначе утонете в событиях.

11.2. Контроль целостности. Если злоумышленник получил доступ, один из его шагов – менять бинарники, конфиги и крон. Для базового контроля подходит AIDE:

sudo apt -y install aide

sudo aideinit

sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db 

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

12. Защита прикладного уровня: веб, базы, TLS

Сервер редко живет одним SSH. Чаще там Nginx/Apache, PHP/Node/Python, база данных и очереди. Общие правила:

• База не должна слушать публичный интерфейс, если к ней не должен ходить интернет. Для PostgreSQL/MySQL обычно достаточно bind на 127.0.0.1 или приватную сеть
• TLS обязателен для любых админок и пользовательских данных
• Разделение ролей: отдельные системные пользователи под сервисы, минимум прав на каталоги

Для веб-сервера добавьте лимиты на запросы и защиту от простого abusive-трафика (rate limiting), но помните: от DDoS на уровне канала VPS не защитит только конфиг Nginx – тут нужна внешняя инфраструктура.

13. Резервное копирование и восстановление: часть безопасности, а не «потом»

С точки зрения практики инцидентов, бэкап – это не удобство, а последняя линия обороны. Если сервер зашифровал шифровальщик, если данные испорчены из-за ошибки деплоя, если вы сами «не туда нажали» – выигрывает тот, кто умеет восстановиться.

Минимальная адекватная схема – 3-2-1: три копии данных, на двух разных носителях, одна – вне сервера. Для VPS это обычно означает: локальные снапшоты + выгрузка бэкапа в отдельное хранилище или на отдельную машину.

Удобный практический подход – поднять тестовый виртуальный сервер и один раз «прогнать» восстановление как учение. Не на словах, а руками: подняли чистую Ubuntu, развернули бэкап, проверили, что сервис стартует и данные целы. Такой прогон часто обнаруживает, что «бэкапы есть», но ключи шифрования хранятся на том же сервере, или инструкция восстановления не работает.

14. Небанальный чек-лист: что реально проверять раз в месяц

• SSH: вход только по ключам, root запрещен, список AllowUsers актуален
• Firewall: открыты только нужные порты, нет временных правил
• Обновления: security-апдейты приходят, перезагрузки ядра по регламенту
• Пользователи: нет забытых аккаунтов, sudo выдан только тем, кому нужно
• Сервисы: слушают только нужные интерфейсы, нет тестовых панелей/демонов
• Логи: ротация работает, место на диске не утекает в бесконечный журнал
• Fail2ban: живой, банит, не ломает легитимный доступ
• AppArmor: включен, профили не переведены в complain «на время» навсегда
• Бэкапы: свежие, восстанавливались хотя бы на тесте
• Секреты: нет ключей и паролей в репозиториях и world-readable файлах

Вывод

Защита Ubuntu на VPS – это не набор заклинаний. Это последовательность решений: закрыть лишнее, укрепить вход, контролировать изменения, наблюдать за системой и уметь восстановиться. Если вы выстроите этот цикл, взлом станет либо существенно сложнее, либо быстро обнаружится, а ущерб будет ограничен.

Самое полезное, что можно сделать после прочтения – открыть терминал и пройти шаги по порядку, фиксируя изменения в виде «инфраструктуры как кода» или хотя бы в виде собственного плейбука. Тогда безопасность перестанет быть разовой задачей и станет нормальной частью администрирования.

***