Ошибки при настройке VPS: root, пароли, открытые порты и устаревшие пакеты

Новый сервер с публичным IP начинает получать автоматические запросы почти сразу после запуска. Боты перебирают учётные данные SSH, ищут открытые базы данных и проверяют сервисы на известные уязвимости. Такие проверки идут круглосуточно и не зависят от масштаба проекта. Начинаются они ещё до публикации сайта.

Для успешной атаки не всегда нужна сложная цепочка эксплойтов, иногда достаточно слабого пароля или забытого порта. Поэтому защищать VPS нужно начинать с ограничения доступа, а не с установки приложения. Материал рассчитан на тех, кто впервые арендует сервер, а также на junior DevOps-инженеров и backend-разработчиков. Для Ubuntu и Debian базовая защита сводится к четырём задачам: ограничить привилегии, настроить SSH, закрыть лишние порты и вовремя обновлять систему.

Почему безопасная настройка VPS важнее, чем кажется

Публичный адрес виден не только пользователям проекта. Автоматические сканеры обходят диапазоны адресов, находят SSH, панели и базы данных, после чего проверяют стандартные логины, пароли и уязвимые версии. Целью может стать даже пустой сервер: злоумышленнику нужны его CPU, канал и IP для майнинга, проксирования трафика, рассылки спама или участия в ботнете.

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

Безопасность VPS-сервера зависит от нескольких независимых мер: отдельной учётной записи администратора, входа по ключу, запрета лишних подключений, своевременных обновлений и резервных копий. Сетевой файрвол провайдера полезен, но не заменяет правила внутри ОС. Бэкап не предотвращает атаку, зато сокращает ущерб и время восстановления.

Ошибка 1. Работа и вход под root

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

На некоторых образах провайдер уже создаёт пользователя вроде ubuntu или debian. Если вы получили только root-доступ, войдите первый раз, установите sudo и заведите отдельную учётную запись. Имя admin в примере замените своим.

apt update
 apt install -y sudo
 adduser admin
 usermod -aG sudo admin
 id admin

Первая команда обновляет индекс пакетов, вторая устанавливает sudo. adduser создаёт домашний каталог и просит задать пароль, usermod добавляет пользователя в административную группу, а id показывает итоговые группы. На минимальном Debian пакет sudo может отсутствовать, поэтому пропускать второй шаг не стоит.

После настройки ключа запретите удалённый вход root. В Ubuntu и Debian локальные параметры удобно хранить в отдельном файле, не меняя штатную конфигурацию пакета:

# /etc/ssh/sshd_config.d/00-hardening.conf
 PermitRootLogin no

Имя начинается с 00, потому что OpenSSH обрабатывает включаемые файлы по алфавиту и обычно использует первое найденное значение параметра. Перед перезагрузкой службы проверьте синтаксис. Текущий сеанс не закрывайте, пока новый пользователь не войдёт в отдельном окне.

sudo sshd -t
sudo systemctl reload ssh
sudo sshd -T | grep permitrootlogin

Запрет относится к SSH. Локальная консоль, режим восстановления и повышение прав через sudo остаются доступны для аварийных работ. Это безопаснее, чем полностью блокировать root без проверенного способа восстановления.

Ошибка 2. Слабые пароли и отсутствие SSH-ключей

Короткий пароль, слово из словаря или повтор пароля от другого сервиса упрощают перебор и использование паролей из утечек. Если парольный вход пока нужен, используйте уникальную длинную фразу и храните её в менеджере паролей. Ограничение числа попыток полезно, но не делает слабый пароль безопаснее.

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

ssh-keygen -t ed25519 -a 100 -C "vps-admin"
ssh-copy-id admin@203.0.113.10
ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 admin@203.0.113.10

Первая команда создаёт пару и предложит защитить приватный ключ паролем. Вторая добавляет открытый ключ в authorized_keys, третья проверяет вход именно с ним. Адрес 203.0.113.10 замените IP своего VPS. Сохраните приватный ключ в защищённой резервной копии, но не отправляйте его на сервер или в репозиторий.

После проверки ключа остаётся отключить парольный вход.

# /etc/ssh/sshd_config.d/00-hardening.conf
 PermitRootLogin no
 PubkeyAuthentication yes
 PasswordAuthentication no
 KbdInteractiveAuthentication no

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

sudo sshd -t
sudo systemctl reload ssh
sudo sshd -T | grep -E 'permitrootlogin|pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication'

Дополнительно: Fail2Ban и смена порта SSH

Fail2Ban читает сообщения о неудачных входах и временно блокирует адреса через файрвол. Он уменьшает поток перебора и объём журналов, но не заменяет ключи. Установите пакет и создайте локальный файл настроек, чтобы обновление пакета не затёрло изменения.

sudo apt update
 sudo apt install -y fail2ban python3-systemd
 sudoedit /etc/fail2ban/jail.d/sshd.local
[sshd]
 enabled = true
 backend = systemd
 maxretry = 5
 findtime = 10m
 bantime = 1h

Пять неудачных попыток за десять минут приведут к блокировке на час. Механизм systemd читает журнал напрямую, поэтому для него не задают logpath. После сохранения проверьте конфигурацию и состояние защиты sshd:

sudo fail2ban-client -t
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Перенос SSH с порта 22 уменьшает шум автоматических сканеров, но не усиливает аутентификацию. Новый порт нужно сначала разрешить в UFW и сетевом файрволе провайдера, затем указать в OpenSSH и Fail2Ban. Ошибка в последовательности оставит сервер без удалённого доступа, поэтому разумнее сохранить порт 22 и ограничить доступ ключами.

Ошибка 3. Открытые порты и отсутствие файрвола

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

sudo ss -lntup

Для Ubuntu и Debian можно использовать UFW. Сначала разрешите текущий SSH-порт, затем задайте политики по умолчанию и добавьте правила для веб-трафика. После этого активируйте файрвол.

sudo apt install -y ufw
sudo ufw allow 22/tcp
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

Если SSH работает не на порту 22, подставьте фактическое значение до включения UFW. Порты 80 и 443 нужны только публичному веб-сервису. Не открывайте их «на будущее». Привязка к интерфейсам и правила файрвола решают разные задачи, поэтому проверяйте оба уровня.

Понять, удалось ли закрыть порты на сервере, лучше с другой машины. Запускайте сканирование только для своего VPS или узла, на проверку которого у вас есть разрешение.

nmap -Pn -p- 203.0.113.10

Эта команда проверяет все TCP-порты с позиции внешнего клиента, включая результат работы UFW и сетевого файрвола провайдера. UDP-порты она не охватывает: для них требуется отдельное UDP-сканирование. IPv6 также проверяйте отдельно, поскольку правила и доступность двух стеков могут различаться.

Какие сервисы нельзя выставлять наружу

MySQL, PostgreSQL, Redis и MongoDB обычно не должны принимать подключения из всего интернета. Если приложение работает на том же VPS, привяжите сервис к локальному адресу 127.0.0.1. Для отдельного сервера базы используйте приватную сеть, разрешите подключения только с адресов серверов приложений и всё равно настройте аутентификацию и TLS.

# PostgreSQL: postgresql.conf
 listen_addresses = '127.0.0.1'

 # MySQL: mysqld.cnf
 bind-address = 127.0.0.1

 # Redis: redis.conf
 bind 127.0.0.1
 protected-mode yes

Пути к файлам зависят от пакета и версии, поэтому сначала найдите активную конфигурацию в документации установленного сервиса. Локальный адрес внутри контейнера относится к самому контейнеру: публикуйте порт на 127.0.0.1 хоста или не публикуйте его вовсе, если доступ идёт через внутреннюю сеть Docker.

Учтите, что Docker создаёт собственные правила обработки трафика, поэтому опубликованные порты контейнеров могут обходить ограничения UFW. Ограничивайте адрес публикации и обязательно проверяйте доступ с другой машины.

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

Ошибка 4. Устаревшие пакеты и ядро

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

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

sudo apt update
sudo apt upgrade

Для автоматической установки обновлений безопасности используйте unattended-upgrades. Пакет работает через системные таймеры APT и пишет журнал в

/var/log/unattended-upgrades/.
sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades
sudo unattended-upgrade --dry-run

Автоматизация не отменяет контроль. Проверяйте ошибки таймеров, совместимость приложения и свободное место. Для критичных систем сначала тестируйте обновления на отдельном стенде, а развёртывание и перезапуски выполняйте в запланированное окно обслуживания.

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

uname -r
 if [ -f /var/run/reboot-required ]; then
   cat /var/run/reboot-required.pkgs
 fi

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

Чек-лист безопасной настройки VPS за 30 минут

Первичная настройка VPS не заканчивается установкой приложения. Перед публикацией проекта проверьте:

·       Создан отдельный пользователь с sudo, вход root по SSH запрещён.

·       Ключ Ed25519 установлен и проверен в новом сеансе, приватная часть защищена.

·       Парольный вход отключён либо оставлен только по осознанной причине.

·       Если парольный вход оставлен, защита sshd в Fail2Ban включена и проверена.

·       UFW запрещает входящие подключения по умолчанию, открыты только нужные порты.

·       ss и внешний nmap не показывают случайно опубликованные сервисы.

·       Базы данных, Redis и панели доступны через 127.0.0.1, приватную сеть или список доверенных IP.

·       Пакеты обновлены, автоматические обновления безопасности включены и проверены.

·       После обновления ядра запланирована перезагрузка и проверен автозапуск приложения.

·       Настроены бэкапы вне VPS, выполнено тестовое восстановление и проверен доступ к аварийной консоли в панели провайдера.

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