Security baseline для нового VPS: чек-лист из 20 пунктов

Новый VPS похож на квартиру сразу после получения ключей. Формально все уже ваше: можно заносить мебель, запускать сайт, поднимать базу данных, подключать домен. Но сначала стоит поменять замки, проверить окна и понять, где находится электрощиток. С сервером та же история. Пока вы настраиваете проект, боты уже могут сканировать открытые порты, проверять SSH, искать старые версии пакетов и пробовать типовые пароли. Хорошая новость в том, что базовая защита VPS не требует недели работы. Достаточно пройти понятный security baseline - минимальный набор действий, который закрывает самые очевидные риски. Ниже - практичный чек-лист из 20 пунктов для нового VPS. Он не делает сервер неуязвимым, но дает нормальную стартовую позицию: меньше шума в логах, меньше случайных ошибок, больше контроля над тем, что происходит внутри системы.

Что такое security baseline и зачем он нужен

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

• кто может войти на сервер

• какие порты доступны извне

• как быстро устанавливаются обновления

• есть ли резервные копии

• видно ли подозрительную активность

понятно ли, что делать при инциденте. Особенно важен этот подход для новых проектов. В первые дни владелец обычно занят приложением, доменом, SSL, деплоем, базой данных и платежами. Без чек-листа безопасность легко откладывается “на потом”. А “потом” часто наступает уже после первого брутфорса, заражения или случайно открытой базы.

Перед началом: зафиксируйте исходную точку

Прежде чем менять настройки, полезно понять, что именно вы получили после создания VPS. Проверьте версию ОС, доступы, открытые порты, установленные сервисы и способ подключения. Это займет несколько минут, зато потом будет ясно, какие изменения были сделаны вручную, а какие уже шли в стандартном образе. Для Linux-сервера можно начать с простых команд:

cat /etc/os-releasehostnamectlip ass -tulpnsystemctl --type=service --state=running

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

Чек-лист безопасности нового VPS

1. Обновите систему сразу после первого входа

Первое действие после подключения к новому VPS - обновление пакетов. Даже свежий образ ОС может быть собран не сегодня. Между сборкой образа и вашим запуском могли выйти исправления для ядра, OpenSSL, sudo, SSH, веб-сервера или системных библиотек. Для Debian и Ubuntu базовый набор выглядит так:

sudo apt updatesudo apt upgrade -ysudo reboot

Для AlmaLinux, Rocky Linux или CentOS-подобных систем: sudo dnf update -ysudo reboot Да, перезагрузка в самом начале иногда кажется лишней. Но лучше сделать ее до запуска сайта, чем потом переносить maintenance window из-за обновленного ядра или системной библиотеки. Практическое правило простое: новый сервер без обновлений - это не “чистый сервер”, а сервер в неизвестном состоянии.

2. Создайте отдельного пользователя для работы

Работать постоянно под root удобно, но опасно. Root может сделать с системой все: удалить файлы, изменить права, остановить сервисы, сломать firewall. Одна ошибка в команде - и последствия будут намного серьезнее, чем при работе через обычного пользователя. Лучше создать отдельного пользователя и дать ему права sudo: adduser deployusermod -aG sudo deploy После этого подключайтесь под этим пользователем, а root используйте только как аварийный доступ или вообще отключите прямой вход по SSH. Аналогия простая: root - это мастер-ключ от всего здания. Носить его каждый день в кармане не лучшая идея. Для повседневной работы достаточно ключа от нужных помещений.

3. Настройте SSH-ключи вместо паролей

Пароль можно подобрать, украсть, случайно сохранить в истории или отправить не в тот чат. SSH-ключ устроен надежнее: на сервере хранится публичная часть, а приватная остается у вас. Без приватного ключа войти не получится. На локальном компьютере создайте ключ: ssh-keygen -t ed25519 -C "your_email@example.com" Затем добавьте публичный ключ на сервер: ssh-copy-id deploy@your_server_ip Или вручную поместите содержимое публичного ключа в файл: ~/.ssh/authorized_keys Права должны быть строгими: chmod 700 ~/.sshchmod 600 ~/.ssh/authorized_keys Мини-кейс: на сервере с паролем в 10 символов боты могут делать тысячи попыток входа в сутки. После перехода на ключи и отключения парольного входа эти попытки превращаются в фоновый шум, а не в реальный риск.

4. Отключите прямой вход root по SSH

Даже если у root стоит сложный пароль, сам факт открытого root-login делает сервер удобной целью. Ботам не нужно угадывать имя пользователя - они уже знают, что root существует почти везде. Откройте конфигурацию SSH: sudo nano /etc/ssh/sshd_config Проверьте или добавьте строки: PermitRootLogin noPasswordAuthentication noKbdInteractiveAuthentication noPubkeyAuthentication yes Перед перезапуском SSH обязательно проверьте конфигурацию: sudo sshd -t Затем перезагрузите сервис: sudo systemctl reload ssh Важный момент: не закрывайте текущую SSH-сессию, пока не проверите вход в новой вкладке терминала. Это как менять замок на двери: сначала убедитесь, что новый ключ работает, и только потом выбрасывайте старый.

5. Ограничьте доступ к SSH

Отключить пароли и root - уже хорошо. Следующий шаг - сократить поверхность атаки. Можно изменить стандартный порт SSH, например с 22 на другой свободный порт. Это не полноценная защита, но хороший способ убрать большую часть автоматического мусора из логов. В файле /etc/ssh/sshd_config: Port 2222AllowUsers deploy После изменения не забудьте открыть новый порт в firewall и только потом перезагружать SSH. sudo ufw allow 2222/tcpsudo systemctl reload ssh Смена порта не заменяет ключи, firewall и fail2ban. Это скорее фильтр от уличного шума. Дверь все равно должна быть крепкой, но нет смысла оставлять ее прямо на самой оживленной улице.

6. Включите firewall по принципу “запрещено все, кроме нужного”

Firewall - один из самых недооцененных пунктов базовой защиты VPS. Многие владельцы серверов вспоминают о нем только после того, как случайно открывают наружу базу данных, Redis, панель администрирования или тестовый сервис. Для Ubuntu и Debian часто используют UFW: sudo ufw default deny incomingsudo ufw default allow outgoingsudo ufw allow 2222/tcpsudo ufw allow 80/tcpsudo ufw allow 443/tcpsudo ufw enablesudo ufw status verbose Логика должна быть жесткой: наружу открыты только те порты, которые действительно нужны пользователям. Обычно это SSH, HTTP и HTTPS. Все остальное - только локально, через VPN или через закрытую административную сеть. Пример: база данных PostgreSQL почти никогда не должна слушать весь интернет. Если приложение находится на том же сервере, достаточно 127.0.0.1. Если база на отдельном сервере, лучше ограничить доступ конкретным IP.

7. Закройте ненужные сервисы

Новый VPS часто быстро обрастает сервисами: веб-сервер, база данных, кеш, очереди, панель управления, агенты мониторинга. Через месяц уже сложно вспомнить, что было установлено “на тест”. Проверьте активные сервисы: systemctl --type=service --state=runningss -tulpn Если сервис не нужен - остановите и отключите автозапуск: sudo systemctl stop service_namesudo systemctl disable service_name Здесь помогает простое правило: каждый открытый сервис - это еще одна дверь. Даже если дверь крепкая, ее нужно обслуживать, обновлять и контролировать. Лишние двери лучше не строить.

8. Настройте Fail2Ban для защиты от перебора

Fail2Ban отслеживает логи и временно блокирует IP-адреса, которые ведут себя подозрительно. Чаще всего его используют для SSH, но можно добавить фильтры для Nginx, Apache, Postfix и других сервисов. Установка на Ubuntu или Debian: sudo apt install fail2ban -ysudo systemctl enable --now fail2ban Пример минимальной настройки для SSH: sudo nano /etc/fail2ban/jail.local [sshd]enabled = trueport = 2222filter = sshdlogpath = /var/log/auth.logmaxretry = 5bantime = 1hfindtime = 10m Затем: sudo systemctl restart fail2bansudo fail2ban-client status sshd Fail2Ban не заменяет ключи и отключение паролей. Он работает как охранник на входе: если кто-то слишком настойчиво дергает ручку двери, охранник просит его уйти.

9. Включите автоматические security-обновления

Обновлять сервер вручную раз в несколько месяцев - плохая стратегия. Уязвимости не ждут удобного времени, а критические исправления иногда нужны быстро. На Ubuntu и Debian можно использовать unattended-upgrades: sudo apt install unattended-upgrades -ysudo dpkg-reconfigure unattended-upgrades Проверьте настройки: cat /etc/apt/apt.conf.d/20auto-upgrades Обычно для базового уровня достаточно, чтобы security-обновления устанавливались автоматически. Для production-систем стоит дополнительно продумать политику перезагрузок: когда можно reboot, кого уведомлять, как проверить приложение после обновления. Пример из жизни: небольшой интернет-магазин месяцами работал без обновлений, потому что “все же стабильно”. Потом вышел публичный exploit для старой библиотеки, и стабильность закончилась за один вечер. Автообновления не решают все, но они сильно снижают шанс попасть в такую ситуацию.

10. Настройте время, часовой пояс и синхронизацию

На первый взгляд время не похоже на элемент безопасности. Но когда нужно разбирать инцидент, логи с неправильным временем превращаются в головоломку. Что произошло раньше: подозрительный вход, падение сервиса или изменение конфигурации? Без корректного времени ответить сложно. Проверьте текущие настройки: timedatectl Установите нужный часовой пояс: sudo timedatectl set-timezone Europe/Amsterdam И убедитесь, что синхронизация включена: timedatectl status Для одного сервера это кажется мелочью. Для нескольких VPS, базы данных, CDN, платежной системы и внешнего мониторинга - уже критично. Время должно быть единым языком всей инфраструктуры.

11. Разделите секреты, пароли и конфигурации

Секреты не должны жить в коде. API-ключи, токены, пароли к базе, SMTP-доступы, приватные ключи и webhook-секреты лучше хранить отдельно: в переменных окружения, закрытых конфигурационных файлах или специализированном хранилище секретов.

Минимальные правила

• не храните .env в публичном репозитории

• ограничьте права на файлы с секретами

• не отправляйте пароли в мессенджерах без необходимости

• меняйте секреты после передачи подрядчику или временного доступа

• не используйте один пароль для панели, SSH, базы и почты.

Права для файла конфигурации могут выглядеть так: sudo chown appuser:appuser /opt/app/.envsudo chmod 600 /opt/app/.env Секреты - как запасные ключи от офиса. Если они лежат под ковриком, неважно, насколько хорошая у вас дверь.

12. Включите двухфакторную защиту там, где это возможно

На самом VPS двухфакторная аутентификация для SSH используется не всегда: ее нужно аккуратно настраивать, чтобы не заблокировать себе доступ. Но для панели управления хостингом, почты администратора, Git-репозитория, облачного хранилища бэкапов и DNS-провайдера 2FA должен быть включен обязательно. Почему это важно? Потому что сервер редко взламывают только через сам сервер. Иногда атакующий получает доступ к почте, сбрасывает пароль от панели, меняет DNS или удаляет бэкапы.

Мини-чек

• 2FA на аккаунте хостинг-провайдера

• 2FA на почте владельца аккаунта

• 2FA на GitHub, GitLab или другой системе контроля версий

• 2FA на DNS и доменном регистраторе

• резервные коды сохранены в безопасном месте.

Это пункт, который часто спасает проект не от технической ошибки, а от человеческой.

13. Настройте права файлов и владельцев

Неправильные права доступа - тихая проблема. Сервер может работать нормально, сайт открывается, деплой проходит, но один файл с правами 777 или конфиг, доступный всем пользователям, создает лишний риск. Проверьте критичные директории: ls -la /var/wwwls -la /optfind /var/www -type d -perm -0002find /var/www -type f -perm -0002

Права зависят от приложения, но общая логика такая

• кодом владеет отдельный пользователь или группа

• веб-сервер не должен иметь право менять все файлы проекта

• директории загрузок отделены от исполняемого кода

• конфиги с секретами доступны только нужному пользователю

chmod 777 не используется как универсальное лекарство. Пример: если CMS требует запись в папку uploads, не нужно давать запись на весь сайт. Дайте права только туда, где запись действительно нужна. Это как разрешить курьеру войти в холл, а не выдать ему ключи от бухгалтерии.

14. Изолируйте приложения друг от друга

Если на одном VPS работает несколько сайтов или сервисов, они не должны жить как одна большая общая папка с одинаковыми правами. Ошибка в одном приложении не должна автоматически открывать доступ к другому.

Базовый подход

• отдельный системный пользователь для каждого приложения

• отдельная директория проекта

• отдельные конфиги

• разные базы данных и пользователи БД

• минимальные права на файлы и сокеты

контейнеры там, где они действительно упрощают изоляцию. Например, сайт project-a не должен иметь доступ к .env сайта project-b. Даже если оба проекта ваши, это разные зоны риска. Для небольшого VPS такая дисциплина кажется избыточной. Но она окупается в день, когда один тестовый проект внезапно оказывается слабым звеном.

15. Закройте базы данных от внешнего интернета

Открытая база данных - одна из самых болезненных ошибок. MySQL, PostgreSQL, MongoDB, Redis и Elasticsearch не должны торчать наружу “на всякий случай”. Проверьте, какие порты слушают сервисы: ss -tulpn Для PostgreSQL обычно безопаснее слушать localhost: listen_addresses = 'localhost' Для MySQL: bind-address = 127.0.0.1 После изменения конфигурации перезапустите сервис и снова проверьте порты. Если доступ к базе нужен с другого сервера, не открывайте ее для всего мира. Ограничьте IP через firewall или используйте VPN/private network. База данных - это сейф, а не витрина магазина.

16. Настройте HTTPS и базовые параметры веб-сервера

Если VPS обслуживает сайт или API, HTTPS обязателен. Даже для тестового проекта лучше сразу настроить TLS-сертификат, чтобы не приучать команду к небезопасным временным решениям. Для Nginx с Let’s Encrypt часто используют Certbot: sudo apt install certbot python3-certbot-nginx -ysudo certbot --nginx -d example.com -d www.example.com После выпуска сертификата проверьте автообновление: sudo certbot renew --dry-run

Кроме HTTPS, стоит проверить базовые вещи

• отключен ли directory listing

• нет ли публичного доступа к .git, .env, backup-файлам и архивам

• корректно ли настроены redirects с HTTP на HTTPS

• ограничены ли размеры загрузки файлов

нет ли лишних default-site страниц. Мини-пример: разработчик временно положил дамп базы в папку сайта, чтобы быстро скачать его через браузер. Через неделю файл все еще лежал там и индексировался сканерами. Такие истории происходят не из-за сложных атак, а из-за бытовой спешки.

17. Включите AppArmor или SELinux

AppArmor и SELinux - это механизмы дополнительного контроля доступа. Они ограничивают поведение процессов даже в тех случаях, когда обычные Unix-права уже дали программе доступ. Проще говоря, если сервис скомпрометирован, AppArmor или SELinux может помешать ему делать все подряд. На Ubuntu часто используется AppArmor: sudo aa-status На RHEL-подобных системах обычно используется SELinux: sestatus Не стоит бездумно отключать эти механизмы только потому, что приложение не запускается. Правильнее разобраться в причине, настроить профиль или политику. Отключение защиты ради быстрого запуска - как снять дверь с петель, потому что ключ заедает. Для небольших проектов достаточно хотя бы не выключать штатную защиту ОС и понимать, в каком режиме она работает.

18. Настройте резервные копии и проверьте восстановление

Бэкап, который ни разу не восстанавливали, - это не бэкап, а надежда. Для VPS резервное копирование должно быть частью базовой настройки, а не отдельной задачей “когда-нибудь”.

Что нужно копировать

• файлы приложения

• базы данных

• конфиги веб-сервера

• файлы окружения и секреты

• пользовательские загрузки

• важные системные конфиги

инструкции по восстановлению. Хорошая схема - 3-2-1: три копии данных, два разных типа хранения, одна копия вне основного сервера. Для малого проекта это может быть локальный snapshot, удаленный backup-сервер и зашифрованная копия в объектном хранилище. Пример команды для простого архивирования конфигов: sudo tar -czf /root/etc-backup-$(date +%F).tar.gz /etc Но архив на том же VPS не спасет при удалении сервера, компрометации аккаунта или проблемах с диском. Минимум одна копия должна жить вне основного сервера. И главное - периодически делайте тестовое восстановление. Не в production, а в отдельной среде. Это скучная процедура ровно до первого реального сбоя.

19. Включите мониторинг и уведомления

Сервер может быть взломан, перегружен, заполнен логами, остаться без RAM или уйти в swap. Если вы узнаете об этом от клиента, мониторинг уже опоздал.

Минимальный набор метрик

• доступность сайта или API

• загрузка CPU

• использование RAM

• свободное место на диске

• сетевой трафик

• количество ошибок 5xx

• состояние systemd-сервисов

срок действия SSL-сертификата. Даже простой внешний мониторинг с уведомлением в Telegram, email или Slack лучше, чем полная тишина. На самом сервере можно начать с базовых инструментов: df -hfree -mtopjournalctl -p warning -n 100systemctl --failed Практический пример: сайт перестал принимать заказы не из-за атаки, а потому что диск заполнился логами. Мониторинг свободного места предупредил бы об этом заранее. Иногда безопасность - это не только защита от злоумышленников, но и защита от собственной инфраструктурной слепоты.

20. Ведите журнал изменений и план действий при инциденте

Последний пункт звучит не так технически, как SSH или firewall, но он очень важен. Нужно понимать, что было изменено на сервере, кем и зачем.

Достаточно простого файла или страницы во внутренней документации

• дата создания VPS

• версия ОС

• кто имеет доступ

• какие порты открыты

• где хранятся бэкапы

• какие сервисы запущены

• какие домены привязаны

• как восстановить проект

кого уведомлять при инциденте.

План действий тоже должен быть простым. Например

Ограничить доступ к серверу. Сохранить логи и текущее состояние. Сменить ключи и пароли. Проверить пользователей и cron-задачи. Поднять чистую копию из проверенного бэкапа. Разобрать причину. Закрыть уязвимость. Вернуть сервис в работу. Во время инцидента плохо работает импровизация. Люди нервничают, клиенты пишут, бизнес ждет восстановления. Короткий план помогает действовать спокойно, а не метаться между терминалом, чатом и панелью управления.

Отдельный пункт про DDoS-защиту

DDoS-защита не заменяет security baseline. Она решает другую задачу: помогает выдерживать вредоносный трафик, который пытается перегрузить канал, сервер или приложение. Но DDoS-защита и базовый hardening хорошо дополняют друг друга. Провайдерская защита может отфильтровать большую часть мусорного трафика, а настройки на VPS уменьшают риск того, что слабым местом окажется открытый сервис, плохой пароль или неограниченный endpoint.

Для нового VPS стоит заранее понять

• есть ли защита от DDoS на уровне провайдера

• какие типы атак она покрывает

• что делать при резком росте трафика

• как связаться с поддержкой

• какие лимиты есть у приложения

где включить rate limiting на уровне Nginx или приложения. Пример: если API endpoint без ограничений отправляет тяжелый запрос к базе, даже небольшой поток запросов может создать проблему. Внешняя защита полезна, но приложение тоже должно уметь говорить “слишком часто, попробуйте позже”.

Быстрая проверка после настройки

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

Проверьте

ssh -p 2222 deploy@your_server_ipsudo ufw status verbosess -tulpnsystemctl --failedsudo fail2ban-client statusdf -hfree -mjournalctl -p warning -n 50

Задайте себе несколько вопросов

• могу ли я войти по SSH-ключу

• заблокирован ли вход root

• отключены ли пароли SSH

• открыты ли только нужные порты

• есть ли рабочий бэкап

• знаю ли я, как восстановить сервер

• получу ли я уведомление при проблеме

понятно ли, кто имеет доступ. Если на каждый вопрос есть спокойный ответ, baseline уже дает хороший фундамент.

Частые ошибки при защите нового VPS

“Сначала запущу проект, потом займусь безопасностью”

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

“У меня маленький сайт, меня не будут атаковать”

Автоматические сканеры не выбирают только крупные компании. Они просто перебирают IP-адреса, порты, версии сервисов и типовые ошибки. Для бота маленький сайт и большой портал часто выглядят одинаково: есть открытый SSH, есть веб-сервер, есть шанс найти слабое место. Размер проекта не отменяет базовую гигиену.

“Firewall не нужен, если сервисы настроены правильно”

Нужен. Firewall - это дополнительный слой. Даже если сервис случайно начнет слушать внешний интерфейс, firewall может не пустить трафик извне. Хорошая безопасность строится слоями. Один слой ошибся - второй подстраховал.

“Бэкап есть, но я его не проверял”

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

“Я все держу в голове”

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

Минимальный порядок действий для нового VPS

Если нужно быстро защитить VPS без глубокого погружения, начните в таком порядке: Обновите систему. Создайте отдельного sudo-пользователя. Настройте SSH-ключи. Отключите root-login и парольный вход. Включите firewall. Откройте только нужные порты. Установите Fail2Ban. Включите security-обновления. Закройте базы данных от внешнего доступа. Настройте бэкапы. Включите мониторинг. Зафиксируйте настройки в документации. Это уже не идеальная крепость, но точно не сервер “как из коробки”, оставленный на удачу.

Итог

Security baseline для нового VPS - это не паранойя и не бюрократия. Это нормальная техническая привычка, как пристегнуть ремень перед поездкой или сделать резервную копию перед крупным обновлением. Большинство проблем начинается не с редких сложных атак, а с простых вещей: открытый SSH с паролем, забытый сервис, база данных наружу, старые пакеты, отсутствие бэкапа, нулевая видимость по логам. Именно поэтому чек-лист из 20 пунктов работает: он закрывает не все на свете, а самые частые и неприятные сценарии. Настройте базовую защиту в первый день жизни VPS. Дальше можно развивать проект спокойнее: подключать домены, разворачивать приложения, масштабировать нагрузку, добавлять мониторинг, усиливать инфраструктуру. Хороший baseline не мешает работе - он дает серверу крепкий фундамент, на котором уже можно строить серьезный проект.