Что делать после первого входа на новый VPS

Если вы арендовали обычный VPS-сервер, а не Управляемый VPS, о котором речь пойдёт в другой раз, то чаще всего он встречает своего владельца довольно скромным набором исходных данных, такими как IP-адрес, логин и пароль. В этот момент, с технической точки зрения, сервер уже работает. Но вот по своей сути это пока нельзя назвать полноценным сервером, так как сейчас это, скорее, заготовка для настоящего сервера.

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

Поэтому в данной статье мы с вами пошагово настроим новый, абсолютно чистый виртуальный сервер с самого нуля, от первого логина и до продуктового состояния. Всё описанное ниже подойдет для большинства VPS с Ubuntu, Debian, AlmaLinux или Rocky Linux.

 

 

 

 

Рекогносцировка

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

cat /etc/os-release
hostnamectl
free -h
df -h
ss -tulpn

 

Последняя команда особенно полезна, так как свежий VPS не обязательно может быть совершенно пуст, ведь образ провайдера может содержать SSH, cloud-init, агент виртуализации или дополнительное ПО. Если какой-то сервис уже доступен из сети, то лучше узнать об этом сейчас.

 

Заодно проверьте и время на сервере, так как в случае неправильно выставленного времени и часового пояса cron начинает работать не тогда, когда это ожидается, а события в журналах перестают совпадать по времени. Делается это командой:

timedatectl

 

 

 

 

 

Проверьте сеть и DNS

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

ip addr
ip route
ping
getent hosts
​

 

Команда ip addr покажет ваши сетевые устройства с выданными им IP адресами. В ip route должен присутствовать маршрут по умолчанию через шлюз провайдера. С помощью команды ping вы можете проверить доступ в сеть, например проверив пинг на какой либо удаленный сервер в интернете. А вот работу DNS проще всего проверить таким запросом:

getent hosts example.com

 

 

 

 

Обновите систему

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

Для Ubuntu и Debian:

apt update && apt upgrade -y

Для AlmaLinux и Rocky Linux:

dnf upgrade -y

 

В Ubuntu и Debian можно проверить, требуется ли перезагрузка после обновления командой:

test -f /var/run/reboot-required && cat /var/run/reboot-required

 

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

Позже будет полезным настроить автоматическую установку обновлений безопасности. В Debian и Ubuntu для этого используется unattended-upgrades, а в RHEL-совместимых системах - инструмент dnf-automatic. В то-же время, полное обновление системы лучше оставлять контролируемой операцией, делать это ручками.

 

 

 

 

Создайте отдельного администратора

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

 

Для создания отдельного пользователя в Ubuntu или Debian используются команды:

adduser adminuser
usermod -aG sudo adminuser

В AlmaLinux и Rocky Linux:

useradd -m adminuser
passwd adminuser
usermod -aG wheel adminuser

 

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

id adminuser

 

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

 

 

 

 

Настройте SSH но будьте осторожны, чтобы не потерять доступ к серверу

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

Для этого, на своем компьютере с которого вы будете подключаться к серверу в будущем, создайте пару RSA ключей с помощью команды:

ssh-keygen -t rsa -b 4096

 

По умолчанию будут созданы два файла:

~/.ssh/id_rsa
~/.ssh/id_rsa.pub

id_rsa - приватный ключ, он остается на вашем компьютере. На сервер нужно перенести только публичный id_rsa.pub:

ssh-copy-id -i ~/.ssh/id_rsa.pub adminuser@SERVER_IP

 

Если ssh-copy-id недоступен, тогда выведите публичный ключ в консоль:

cat ~/.ssh/id_rsa.pub

 

Скопируйте полученную строку и добавьте ее на сервере в файл ~/.ssh/authorized_keys. Если каталога и файла еще нет, тогда выполните команды:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

 

Теперь откройте второй терминал и проверьте вход именно с созданным RSA-ключом:

ssh -i ~/.ssh/id_rsa adminuser@SERVER_IP

После входа проверьте работу sudo:

sudo whoami

 

Команда должна вернуть root. Только когда вход по ключу проверен, а значит теперь можно отключать прямой SSH-вход для root и парольную авторизацию. Для этого в файле /etc/ssh/sshd_config или в файлах /etc/ssh/sshd_config.d/*.conf найдите и выставьте эти параметры:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

 

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

sshd -t

 

Эффективные настройки SSH можно посмотреть через команду:

sshd -T

 

Также можно изменить стандартный порт 22, но серьезной защитой это считать не стоит. Конечно, случайных попыток входа станет меньше, однако специализированные сканеры найдут SSH сервис и на другом порту.

Вот куда полезнее настроить вход по ключу и отключить парольную авторизацию, что мы сейчас и сделали.

 

 

 

 

Закройте ненужные порты

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

Сначала стоит определить, какие порты действительно нужны вашему серверу. Например, SSH должен принимать подключения администратора, а будущему веб-серверу понадобятся HTTP и HTTPS. Базе данных, Redis или внутренним сервисам, обычно, публичный доступ вообще не нужен.

Поэтому firewall нового сервера проще всего строить по принципу: запрещено всё, что явно не разрешено.

 

Для Ubuntu и Debian удобно использовать UFW (Uncomplicated Firewall), уже встроенный в систему. Сначала разрешите SSH, чтобы не потерять связь с сервером, и только потом включайте firewall:

ufw allow OpenSSH
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable
ufw status verbose

Если веб-сервер пока не установлен, порты 80 и 443 можно открыть позже.

 

В AlmaLinux и Rocky Linux обычно используется firewalld:

firewall-cmd --permanent --add-service=ssh
firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-service=https
firewall-cmd --reload
firewall-cmd --list-all

 

После настройки снова посмотрите, какие сервисы слушают сеть:

ss -tulpn

Firewall и эта команда показывают разные стороны одной картины. Firewall определяет, какой трафик разрешен, а ss показывает, какие приложения вообще принимают соединения.

 

Для обычного веб-сервера ситуация чаще всего выглядит примерно так:

Сервис	Доступ из интернета
SSH 22	Да
HTTP 80	Да
HTTPS 443	Да
MySQL 3306	Обычно нет
PostgreSQL 5432	Обычно нет
Redis 6379	Нет
Docker API 2375	Нет

Если база данных нужна только приложению на этом же VPS, то очевидно, что открывать ее всему интернету незачем.

Не забывайте также и про IPv6 (если он вообще присутствует в услуге), поэтому если сервис слушает адрес [::], то убедитесь, что правила firewall защищают IPv6 так же, как и IPv4.

 

Проверьте сервер снаружи

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

nmap SERVER_IP

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

 

 

 

 

Нужен ли Fail2ban?

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

Fail2ban следит за системными журналами, выискивая определенные паттерны, и блокирует IP-адреса, с которых за короткое время приходит слишком много неудачных попыток авторизации. Это полезное дополнение к уже настроенным SSH-ключам и firewall, но полагаться только на него не стоит.

 

В Ubuntu и Debian установить Fail2ban можно командой:

apt install fail2ban -y

В AlmaLinux и Rocky Linux пакет доступен через EPEL:

dnf install epel-release -y
dnf install fail2ban -y

 

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

systemctl enable --now fail2ban

 

Теперь проверьте, какие jail активны:

fail2ban-client status

Если среди них есть sshd, посмотрите его состояние отдельно:

fail2ban-client status sshd

 

Там будут видны неудачные попытки входа и заблокированные IP-адреса. Важно, что просто установить Fail2ban недостаточно, так как определенный jail для SSH должен быть включен и действительно работать. Подробнее о настройке Fail2ban читайте в этой статье.

 

 

 

Проверьте память, swap и диск

На небольших VPS, с минимальным объёмом оперативной памяти, часто рекомендуется сразу создать файл подкачки или swap. И иногда это достаточно разумно, так как при кратком скачке потребления памяти он может дать системе дополнительный запас вместо немедленного запуска OOM-killer.

Но, всё таки, создавать swap по умолчанию тоже не стоит и для начала нужно оценить текущее состояние дел с оперативной памятью и диском, а также их использованием с помощью команд:

free -h
swapon --show
df -h
df -i

 

Ориентироваться можно так:

Ситуация	Что делать
Swap отсутствует, RAM мало	Рассмотреть создание swap
Swap есть и почти пуст	Это нормально
Swap постоянно активно используется	Проверить потребление RAM
Процессы убивает OOM-killer	Искать причину или увеличивать RAM

Стоит помнить, что swap не является полноценной заменой оперативной памяти, а является лишь некой страховкой на случай пиковых нагрузок.

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

 

 

 

 

Проверьте ошибки после загрузки

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

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

systemctl --failed
journalctl -p err -b

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

 

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

 

 

 

 

Настройте мониторинг до первой аварии

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

На рабочем сервере стоит следить хотя бы за загрузкой CPU, использованием RAM, свободным местом на диске и доступностью самого VPS. Конечно, для текущей диагностики под рукой уже есть стандартные инструменты Linux, такие как:

systemctl
journalctl
top

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

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

 

 

 

 

 

 

Настройте резервное копирование

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

Что именно сохранять, зависит от конкретного проекта и стека. Для обычного сайта, зачастую, это файлы и база данных, для Docker инфраструктур - volumes и конфигурация контейнеров. Иногда даже имеет смысл делать резервную копию всей виртуальной машины. Кстати, 3v-Hosting делает это для вас совершенно бесплатно, ежесуточно сохраняя моментальный снимок вашего виртуального сервера из которого можно восстановить сервер в случае сбоя или потери данных.

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

Ну и периодически пробуйте восстановить данные из бэкапа, так как успешно созданный архив еще не гарантирует, что из него действительно получится восстановить рабочий проект.

 

 

 

 

Сделайте контрольную перезагрузку и переходите к работе

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

reboot

 

После загрузки снова подключитесь по SSH и быстро проверьте состояние VPS:

uptime
systemctl --failed
ss -tulpn

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

Если же вы не смогли попасть на свой сервер после перезагрузки, тогда вы можете залогиниться на него через noVNC консоль в личном кабинете 3v-Hosting и уже оттуда произвести анализ ситуации и исправить то, что сломалось.

 

После такой проверки VPS уже можно использовать по назначению, например устанавливать веб-сервер, Docker, CMS, VPN или другое нужное вам ПО.

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

 

 

 

 

Чек-лист после первого входа

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

В итоге весь процесс можно свести к короткому чек-листу:

1. Проверить ОС, ресурсы, время, сеть и открытые порты;

2. Установить обновления;

3. Создать отдельного пользователя с sudo;

4. Настроить SSH-ключи и проверить вход во второй сессии;

5. Ограничить root-доступ и парольную авторизацию;

6. Настроить firewall и проверить порты снаружи;

7. При необходимости установить Fail2ban;

8. Проверить RAM, swap, диск и inode;

9. Проверить failed services и системный журнал;

10. Настроить мониторинг и уведомления;

11. Организовать внешние резервные копии;

12. Перезагрузить VPS и убедиться, что всё работает;

13. Только после этого устанавливать рабочие сервисы.

     

 

 

 

 

Частые вопросы о первоначальной настройке VPS

 

Нужно ли менять SSH-порт 22?

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

 

Нужно ли отключать вход root по SSH?

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

 

Нужен ли Fail2ban, если вход по паролю отключен?

Нет, не обязателен, но он может оставаться полезным дополнительным слоем защиты. Вообще его значение заметно ниже, если SSH принимает только ключи.

 

Сколько swap нужно VPS?

Универсальной формулы здесь нет и быть не может, так как его размер зависит от объема RAM и нагрузки на сервер. Важнее не конкретное соотношение RAM и swap, а то, как сервер реально использует память.

 

Какие порты нужно открыть на новом VPS?

Только необходимые конкретному серверу. Для типичного веб-сервера это SSH, HTTP и HTTPS. Порты баз данных, Redis, внутренних API и других служебных компонентов без необходимости наружу лучше не открывать.

 

Нужно ли перезагружать VPS после обновления?

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

 

Можно ли сначала установить Docker или панель, а безопасность настроить потом?

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