Первые действия после покупки VPS: чек-лист настройки с нуля

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

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

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

Эта статья — практический чек-лист: последовательность конкретных действий от момента получения данных доступа до состояния «сервер готов к установке сайта». Каждый пункт снабжён обоснованием, почему он важен, и командой, которую можно скопировать и выполнить.

Шаг 1. Первое подключение и проверка сервера

Данные для первого подключения — IP-адрес, логин (обычно root) и пароль или ключ — приходят на почту или доступны в панели управления сразу после создания сервера. Подключение выполняется по протоколу SSH из терминала на Linux и macOS или через клиент вроде PuTTY на Windows.

ssh root@203.0.113.10

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

cat /etc/os-release
free -h
df -h
ping -c 3 8.8.8.8

Если что-то из этого не совпадает с тем, что было заказано — например, объём диска меньше ожидаемого, — разумнее обратиться в поддержку провайдера сразу, до того как на сервере появятся какие-либо данные и настройки, которые придётся переносить при пересоздании.

Шаг 2. Смена пароля и обновление системы

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

passwd

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

apt update && apt upgrade -y

Обновления системы безопасности следует применять как можно быстрее после выпуска, особенно для пакетов, обращённых к сети, — задержка в днях уже даёт злоумышленникам используемое окно.

Общая рекомендация из руководств по защищённой эксплуатации Linux-серверов

На CentOS, AlmaLinux и других дистрибутивах на основе RPM аналогичная операция выполняется командой dnf update -y или yum update -y в зависимости от версии системы. После крупного обновления ядра имеет смысл перезагрузить сервер в удобное время, чтобы изменения вступили в силу полностью.

Шаг 3. Создание пользователя с sudo вместо постоянной работы под root

Работа напрямую под root на постоянной основе — плохая практика по двум причинам: любая опечатка в команде выполняется с максимальными правами без каких-либо ограничений, а при компрометации единственной учётной записи атакующий сразу получает полный контроль над системой. Создание отдельного пользователя с правами sudo решает обе проблемы, не усложняя повседневную работу.

adduser deploy
usermod -aG sudo deploy

После создания пользователя стоит сразу же в новой сессии терминала (не закрывая текущую с root) проверить, что вход под новым пользователем работает и команды с sudo выполняются корректно. Только после успешной проверки имеет смысл переходить к следующим шагам, связанным с ограничением доступа под root.

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

Шаг 4. Базовая настройка firewall

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

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

Важный нюанс, из-за которого новички иногда теряют доступ к серверу: правило для SSH обязательно должно быть добавлено и подтверждено до включения firewall командой ufw enable, иначе следующее подключение может просто не пройти. Если используется нестандартный порт SSH, в правило нужно подставить именно его, а не порт 22 по умолчанию.

Подробный разбор разницы между ufw и iptables, логики цепочек правил и типичных сценариев настройки — в отдельной статье «Firewall на Linux: ufw и iptables простыми словами». Для базового чек-листа достаточно того, что firewall включён и пропускает только реально используемые порты.

Шаг 5. Часовой пояс, локаль и системное время

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

timedatectl set-timezone Europe/Moscow

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

timedatectl set-ntp true\ntimedatectl status

Шаг 6. Установка веб-сервера, PHP и базы данных

Выбор веб-сервера — Nginx или Apache — стоит делать осознанно: у каждого свои сильные стороны, и для типичного сайта на современной CMS оба варианта справляются с задачей, но отличаются подходом к конфигурации и обработке высокой нагрузки. Подробное сравнение — в статье «Nginx vs Apache: что выбрать для сайта», а практическая настройка связки Nginx с PHP-FPM — в отдельном руководстве.

После веб-сервера устанавливается PHP нужной версии с необходимыми расширениями — конкретный набор расширений зависит от CMS и её требований, но чаще всего нужны как минимум mysqli или pdo_mysql, gd или imagick для работы с изображениями, mbstring, curl и zip.

apt install php8.3-fpm php8.3-mysql php8.3-gd php8.3-mbstring php8.3-curl php8.3-zip -y

Выбор системы управления базами данных — MySQL/MariaDB или PostgreSQL — тоже стоит делать под конкретную задачу, а не по умолчанию: разница в производительности, особенностях SQL и совместимости с конкретными CMS разобрана в статье «MySQL vs PostgreSQL: что выбрать». Для большинства популярных CMS вроде WordPress или 1С-Битрикс стандартным выбором остаётся MySQL или его форк MariaDB.

Шаг 7. Направление домена на сервер и SSL-сертификат

Как только выбран IP-адрес сервера, в панели управления доменом нужно создать A-запись, указывающую этот домен на IP сервера. Распространение изменений DNS по всему интернету — не мгновенное: обычно занимает от нескольких минут до нескольких часов в зависимости от значения TTL у предыдущей записи и кэширующих DNS-серверов провайдеров у конечных пользователей.

dig +short example.ru\nnslookup example.ru 8.8.8.8

Низкое значение TTL, выставленное заранее перед миграцией, — это разница между «изменения применятся за пять минут» и «изменения применятся когда-нибудь в течение суток».

Практическая рекомендация из руководств по администрированию DNS

Подробный разбор типов DNS-записей (A, CNAME, MX, TXT) и их назначения — в статье «DNS-записи: A, CNAME, MX, TXT — что за что отвечает». Как только домен указывает на новый сервер и веб-сервер отвечает на запросы к этому имени, можно выпускать бесплатный SSL-сертификат Let's Encrypt — процесс подробно описан в статье «SSL: бесплатный сертификат Let's Encrypt», обычно это занимает не больше пяти минут при уже настроенном Nginx или Apache.

Сразу после выпуска сертификата стоит проверить, что сайт настроен на принудительное перенаправление с HTTP на HTTPS, а не просто отвечает по обоим протоколам одновременно — иначе часть трафика и поисковых роботов продолжит обращаться к незащищённой версии сайта.

Шаг 8. Автоматические обновления безопасности

Ручное обновление системы время от времени — лучше, чем ничего, но легко забывается в текучке повседневных задач. Для пакетов, критичных с точки зрения безопасности, разумно настроить автоматическую установку обновлений без вмешательства человека — на Debian/Ubuntu для этого существует готовый пакет unattended-upgrades.

apt install unattended-upgrades -y\ndpkg-reconfigure --priority=low unattended-upgrades

Стоит понимать границы этой меры: unattended-upgrades по умолчанию устанавливает только обновления, помеченные как security, а не любые обновления пакетов подряд — это осознанный компромисс между безопасностью и стабильностью, поскольку обновление версий, скажем, PHP или базы данных в фоновом режиме без контроля может сломать работающий сайт.

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

Шаг 9. Резервное копирование — до, а не после первого инцидента

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

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

Частое наблюдение в статьях о resilience-инженерии

Минимальная разумная схема — ежедневное автоматическое резервное копирование базы данных и файлов сайта с хранением копий за последние 7–14 дней в отдельном месте, не на том же физическом диске, что и сам сервер: в объектном хранилище, на другом сервере или через встроенный сервис бэкапов провайдера. Подробная методика — в статье «Backup сайта и базы данных: как настроить и не потерять данные».

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

Шаг 10. Базовый мониторинг и уведомления

Сервер без мониторинга сообщает о проблемах единственным способом — переставая отвечать на запросы, что пользователи и поисковые системы замечают раньше администратора. Базовый мониторинг доступности и ключевых метрик занимает 10–15 минут настройки и полностью меняет то, как быстро становится известно о проблеме.

Минимальный набор для старта — внешняя проверка доступности сайта по HTTP с уведомлением при недоступности (подойдёт как простой self-hosted инструмент вроде Uptime Kuma, так и внешний сервис) и базовый мониторинг загрузки CPU, RAM и диска на самом сервере через встроенную панель провайдера или лёгкий агент.

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

Типичные ошибки при первичной настройке VPS

Установка сайта и открытие его для публики до того, как настроен firewall и закрыт прямой вход под root по паролю — типичная последовательность действий «сначала запустить, потом защитить», которая оставляет сервер уязвимым именно в первые дни, когда внимание полностью сосредоточено на самом сайте, а не на его защите.

Игнорирование обновлений системы под предлогом «не хочу сломать то, что уже работает» — риск от устаревших пакетов с известными уязвимостями почти всегда выше, чем риск от штатного обновления безопасности, особенно если обновляются только пакеты с пометкой security, а не вся система целиком.

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

Установка избыточного количества пакетов и сервисов «на всякий случай» без понимания, зачем они нужны, — каждый дополнительный сервис на сервере это дополнительная потенциальная точка входа для атаки и дополнительный процесс, конкурирующий за CPU и RAM с реально нужными задачами.

Финальная проверка перед тем как объявить сайт готовым

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

Проверьте, что сайт открывается по HTTPS без предупреждений браузера о сертификате, а обращение по HTTP автоматически перенаправляется на защищённую версию. Отправьте тестовую заявку или сообщение через все формы на сайте и убедитесь, что письмо действительно приходит на нужный адрес, а не теряется из-за неверных настроек SMTP.

Проверьте вход в административную панель CMS под обычным (не техническим) аккаунтом, загрузку изображений и корректность отображения сайта на мобильном устройстве. Убедитесь, что автоматическое резервное копирование действительно создало хотя бы одну копию и что она доступна в хранилище, а не только запланирована.

curl -I https://example.ru
curl -I http://example.ru

Пошаговый чек-лист: от подключения до готовности к запуску

Шаг 1. Подключитесь по SSH, проверьте версию системы, объём памяти и диска. Шаг 2. Смените пароль root и обновите систему командой apt update && apt upgrade. Шаг 3. Создайте отдельного пользователя с правами sudo и проверьте вход под ним в новой сессии терминала.

Шаг 4. Настройте вход по SSH-ключу, смените порт SSH и отключите прямой вход под root — подробности в статье про SSH. Шаг 5. Включите firewall с минимально необходимым набором открытых портов. Шаг 6. Настройте часовой пояс и синхронизацию времени по NTP.

Шаг 7. Установите веб-сервер, PHP с нужными расширениями и систему управления базой данных под выбранную CMS. Шаг 8. Направьте домен на сервер и выпустите SSL-сертификат. Шаг 9. Включите автоматические обновления безопасности.

Шаг 10. Настройте регулярное резервное копирование в отдельное место и проверьте восстановление хотя бы раз. Шаг 11. Настройте базовый мониторинг доступности сайта с уведомлением о простое и пройдите финальную проверку перед запуском. Только после выполнения этих одиннадцати шагов сервер готов к тому, чтобы на нём появлялись реальный сайт, база данных и, при необходимости, платёжные данные клиентов.

Сколько всего это займёт по времени

При наличии этого чек-листа под рукой базовая часть — подключение, обновление, пользователь, SSH-ключ, firewall и часовой пояс — занимает 20–40 минут даже без специального опыта администрирования. Установка веб-сервера, PHP и базы данных добавляет ещё 15–30 минут в зависимости от выбранного стека и того, устанавливаются ли готовые сборки или компоненты собираются вручную.

Настройка бэкапов и мониторинга — ещё 15–20 минут, если используются готовые инструменты вроде встроенных бэкапов провайдера или простых self-hosted решений. В сумме весь чек-лист укладывается в час-полтора активной работы — это разумная плата за сервер, который не станет источником проблем в первую же неделю эксплуатации.

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

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

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

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