Что делать после покупки VPS первая настройка сервера на Ubuntu 26.04 LTS

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

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

1. Подключиться к серверу по SSH и обновить пакеты.
2. Настроить имя сервера и часовой пояс.
3. Создать отдельного пользователя с правами sudo.
4. Добавить SSH-ключ и проверить вход под новым пользователем.
5. Отключить прямой вход под root и парольную авторизацию.
6. Настроить UFW и открыть только действительно нужные порты.
7. Установить Fail2ban для защиты от перебора учётных данных.
8. Включить автоматическую установку обновлений безопасности.
9. Проверить открытые порты, загрузку CPU, RAM и диска.
10. Настроить внешние бэкапы или убедиться, что услуга резервного копирования уже подключена.

Особенно важно соблюдать порядок при настройке SSH. Нельзя отключать root-login или вход по паролю, пока подключение по ключу под новым пользователем не проверено в отдельной сессии. Иначе можно потерять доступ к серверу.

Firewall также не должен открывать все порты «на всякий случай». Для первого этапа обычно достаточно SSH, а порты HTTP и HTTPS можно добавить перед запуском веб-сервера. Базы данных, панели и внутренние сервисы не следует выставлять в интернет без необходимости.

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

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

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

Первый вход и обновление системы

Подключение к VPS по SSH

После создания VPS провайдер обычно присылает IP-адрес сервера, имя пользователя и способ авторизации. В зависимости от образа это может быть пользователь root, ubuntu или другая учётная запись с правами sudo.

Для подключения из Linux, macOS или Windows Terminal используется команда: ssh root@SERVER_IP

Если провайдер создал другого пользователя: ssh ubuntu@SERVER_IP

Вместо SERVER_IP нужно указать публичный IP-адрес VPS. При первом подключении SSH покажет fingerprint сервера и попросит подтвердить его добавление в список известных узлов. По возможности fingerprint стоит сверить с данными в панели провайдера.

После входа полезно проверить версию системы и основные сведения о сервере:

cat /etc/os-release

hostnamectl

uptime

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

Обновление пакетов и перезагрузка

Образ VPS мог быть подготовлен несколько дней, недель или даже лет назад, поэтому после первого входа нужно обновить индекс пакетов и установить доступные обновления:

apt update

apt upgrade -y

Если подключение выполнено не под root, команды запускаются через sudo:

sudo apt update

sudo apt upgrade -y

После обновления можно удалить пакеты, которые больше не требуются: sudo apt autoremove -y

Проверить, требуется ли перезагрузка, можно так: test -f /var/run/reboot-required && echo "Reboot required"

Если система сообщает о необходимости перезапуска: sudo reboot

SSH-соединение закроется. Через несколько секунд или минут к серверу нужно подключиться повторно и убедиться, что он работает: uptime

Теперь система обновлена, но перед созданием пользователей и настройкой защиты стоит привести в порядок базовые параметры самого сервера.

Настройка часового пояса и имени сервера

Корректный часовой пояс нужен для логов, cron-задач, мониторинга и расследования инцидентов. Сначала следует проверить текущие настройки: timedatectl

Список доступных часовых поясов можно вывести командой: timedatectl list-timezones

После этого выбирается подходящий регион, например: sudo timedatectl set-timezone Europe/Berlin

Для серверной инфраструктуры также часто используют UTC: sudo timedatectl set-timezone UTC

Имя сервера лучше заменить на понятное обозначение, связанное с его ролью. Например: sudo hostnamectl set-hostname web-01

После изменения стоит проверить результат:

hostnamectl

hostname

Если сервер будет использовать полное доменное имя, можно задать FQDN: sudo hostnamectl set-hostname web-01.example.com

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

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

Создание отдельного пользователя и защита SSH 

Пользователь с правами sudo

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

Создать пользователя можно командой: adduser admin

Вместо admin можно указать другое понятное имя. Система попросит задать пароль и предложит заполнить дополнительную информацию — необязательные поля можно пропустить.

Затем пользователя нужно добавить в группу sudo: usermod -aG sudo admin

Если команда выполняется не под root, перед ней добавляется sudo. Проверить группы нового пользователя можно так: groups admin

После этого стоит открыть отдельную SSH-сессию и проверить вход: ssh admin@SERVER_IP

Права администратора проверяются командой: sudo whoami

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

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

Вход по SSH-ключу вместо пароля

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

Если ключа ещё нет, его нужно создать на локальном компьютере: ssh-keygen -t ed25519

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

Передать открытый ключ на сервер проще всего командой: ssh-copy-id admin@SERVER_IP

Если используется Windows-среда без ssh-copy-id, содержимое файла с расширением .pub можно вручную добавить на сервере в файл: ~/.ssh/authorized_keys

Для каталога и файла должны быть установлены корректные права:

chmod 700 ~/.ssh

chmod 600 ~/.ssh/authorized_keys

После добавления ключа нужно открыть ещё одно окно терминала и проверить авторизацию: ssh admin@SERVER_IP

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

Только после успешной проверки можно закрывать наиболее рискованные способы удалённого доступа.

Отключение root-login и парольной авторизации

Для усиления защиты нужно запретить прямой вход под root, обычную парольную авторизацию и интерактивный ввод пароля через SSH. На Ubuntu настройки OpenSSH могут храниться не только в основном файле /etc/ssh/sshd_config, но и в каталоге /etc/ssh/sshd_config.d/.

Чтобы не редактировать большой системный файл, можно создать отдельный конфигурационный фрагмент: sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

В файл добавляются параметры:

PermitRootLogin no

PasswordAuthentication no

KbdInteractiveAuthentication no

PubkeyAuthentication yes

После сохранения нужно проверить конфигурацию на ошибки: sudo sshd -t

Если команда ничего не вывела, синтаксис корректен. После этого OpenSSH можно перечитать без полной перезагрузки сервера: sudo systemctl reload ssh

Старую SSH-сессию пока закрывать нельзя. Сначала нужно ещё раз подключиться в новом окне под отдельным пользователем: ssh admin@SERVER_IP

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

Если авторизация перестала работать, нужно вернуться в сохранённую сессию, исправить конфигурацию, снова выполнить sudo sshd -t и перечитать сервис.

После настройки отдельного пользователя и защищённого SSH-доступа административный вход становится значительно безопаснее. Следующий этап — ограничить сетевой доступ через firewall, установить Fail2ban и проверить, какие порты сервер выставляет в интернет.

Firewall и защита от перебора паролей 

Открываем только нужные порты через UFW

UFW — стандартный интерфейс управления host-based firewall в Ubuntu. По умолчанию он может быть отключён, поэтому перед активацией нужно сначала разрешить текущий SSH-доступ. Иначе после включения firewall можно потерять соединение с сервером.

Если SSH работает на стандартном порту 22, разрешить его можно командой: sudo ufw allow OpenSSH

Либо указать порт явно: sudo ufw allow 22/tcp

После этого задаются базовые политики:

sudo ufw default deny incoming

sudo ufw default allow outgoing

Теперь firewall можно включить: sudo ufw enable

Проверить состояние и действующие правила позволяет команда: sudo ufw status verbose

На первом этапе стоит открывать только те порты, которые уже используются:

• 22/tcp — SSH;
• 80/tcp — HTTP после установки веб-сервера;
• 443/tcp — HTTPS после настройки сайта;
• другие порты — только для конкретных сервисов и при понятной необходимости.

Если SSH перенесён на другой порт, разрешить нужно именно его до включения UFW. Открывать диапазоны портов или использовать правило allow from any to any без причины не следует.

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

Установка и базовая настройка Fail2ban

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

Установить пакет можно командой: sudo apt install fail2ban -y

Локальные настройки лучше хранить отдельно от системного файла jail.conf, чтобы обновление пакета не перезаписало изменения. Для SSH можно создать файл: sudo nano /etc/fail2ban/jail.d/sshd.local

Добавить в него базовую конфигурацию:

[sshd]

enabled = true

maxretry = 5

findtime = 10m

bantime = 1h

Если SSH работает не на стандартном порту, в конфигурацию также добавляется строка с нужным значением, например: port = 2222

После сохранения нужно включить и перезапустить сервис: sudo systemctl enable --now fail2ban

Проверить состояние Fail2ban можно командой: sudo fail2ban-client status

А состояние защиты SSH — так: sudo fail2ban-client status sshd

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

После настройки правил важно проверить не только конфигурацию UFW и Fail2ban, но и то, какие сервисы действительно слушают сетевые порты.

Проверка открытых портов

Открытый порт означает, что какой-либо сервис принимает входящие соединения. Чем больше таких сервисов доступно из интернета, тем шире поверхность атаки.

Посмотреть слушающие TCP- и UDP-порты можно командой: sudo ss -tulpen

Для более короткого вывода без информации о процессах используется: sudo ss -utln

При проверке удобно ориентироваться на следующую схему:

Узнать, какой процесс использует конкретный порт, можно через уже выполненную команду ss -tulpen либо отдельно, например: sudo ss -ltnp 'sport = :3000'

Важно различать слушающий порт и разрешающее правило firewall. Сервис может слушать порт локально, но быть закрытым UFW снаружи. И наоборот, открытое правило UFW не принесёт пользы, если соответствующий сервис не запущен, но позже может случайно выставить его в интернет.

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

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

Автоматические обновления и базовый мониторинг

Unattended upgrades для обновлений безопасности

Регулярные обновления закрывают известные уязвимости в операционной системе и установленных пакетах. Чтобы критические исправления не зависели от ручной проверки, на Ubuntu можно включить автоматическую установку security updates.

Сначала нужно установить необходимые пакеты: sudo apt install unattended-upgrades apt-listchanges -y

Затем включить автоматические обновления: sudo dpkg-reconfigure -plow unattended-upgrades

Проверить созданные настройки можно в файлах:

/etc/apt/apt.conf.d/20auto-upgrades

/etc/apt/apt.conf.d/50unattended-upgrades

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

Проверить работу механизма без фактической установки пакетов позволяет команда: sudo unattended-upgrade --dry-run --debug

Журналы сохраняются в каталоге: /var/log/unattended-upgrades/

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

Контроль CPU, RAM, диска и доступности

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

Для ручной проверки можно использовать следующие команды:

Для более удобного просмотра процессов можно установить htop: sudo apt install htop -y

После установки он запускается командой: htop

Особенно важно следить за свободным местом. Переполненный диск может остановить базу данных, запись логов, обновление пакетов и создание бэкапов, даже если CPU и RAM почти не загружены, и как следствие сделать невозможным подключение по SSH и придётся использовать консоль провайдера, если она есть.

Минимальный мониторинг должен сообщать хотя бы о следующих событиях:

• Сервер перестал отвечать;
• CPU долго работает под высокой нагрузкой;
• Заканчивается RAM или активно используется swap;
• Диск заполнен до критического уровня;
• Важный сервис остановился;
• Истекает SSL-сертификат.

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

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

Бэкапы до установки сайта

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

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

Обычно в бэкап входят:

• Файлы сайта и пользовательские загрузки;
• Дампы MySQL, MariaDB или PostgreSQL;
• Конфигурация веб-сервера;
• Настройки приложения и переменные окружения;
• Конфигурация Docker Compose и связанные файлы;
• Задания cron и systemd units;
• Список установленных пакетов;
• Важные настройки firewall, SSH и Fail2ban;
• Инструкции по восстановлению.

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

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

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

Где хранить резервные копии

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

Минимальная схема может выглядеть так:

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

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

Но даже внешнее хранение не делает snapshot полноценной заменой резервному копированию.

Почему snapshot не заменяет полноценный бэкап

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

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

Полноценный бэкап отличается тем, что:

• Хранится отдельно от основного сервера;
• Имеет расписание и срок хранения;
• Позволяет восстанавливать отдельные файлы и базы;
• Может быть зашифрован;
• Проверяется тестовым восстановлением;
• Не зависит от существования конкретной виртуальной машины.

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

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

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

Чек-лист первого часа после покупки VPS

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

• Система обновлена и перезагружена;
• Настроены hostname и часовой пояс;
• Создан отдельный пользователь с правами sudo;
• Вход по SSH-ключу успешно проверен;
• Root-login и парольная авторизация отключены;
• UFW включён, открыты только нужные порты;
• Fail2ban установлен и защищает SSH;
• Открытые порты проверены через ss;
• Автоматические security updates включены;
• Настроен базовый мониторинг CPU, RAM, диска и доступности;
• Бэкапы сохраняются вне основного VPS;
• Тестовое восстановление хотя бы один раз выполнено.

После этого можно устанавливать веб-сервер, базу данных, Docker, панель управления и само приложение.

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

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

Работать под root

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

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

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

Оставлять парольный вход по SSH

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

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

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

Открывать все порты

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

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

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

Не обновлять систему

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

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

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

Устанавливать сайт до настройки бэкапов

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

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

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

Заключение

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

Следующий уровень защиты — firewall, Fail2ban и проверка открытых портов. Они помогают сократить поверхность атаки и понять, какие сервисы действительно доступны из интернета. Автоматические security updates и базовый мониторинг позволяют не пропустить уязвимость, перегрузку или нехватку места на диске.

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

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

FAQ

Нужно ли менять стандартный SSH-порт?

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

Гораздо важнее использовать SSH-ключи, отключить парольную авторизацию и root-login, настроить UFW и регулярно обновлять систему. Если порт всё же меняется, новое правило firewall нужно добавить до перезапуска SSH.

Достаточно ли UFW для защиты VPS?

Нет. UFW контролирует сетевой доступ, но не устраняет уязвимости в приложениях и не защищает от всех видов атак.

Его нужно использовать вместе с обновлениями, безопасной конфигурацией SSH, ограничением прав пользователей, мониторингом и резервным копированием. Для публичного сайта также могут потребоваться HTTPS, rate limiting, WAF и защита от DDoS.

Обязателен ли Fail2ban при входе по SSH-ключам?

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

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

Нужно ли включать автоматические обновления?

Автоматическую установку обновлений безопасности обычно стоит включить. Это снижает риск оставить на сервере известную уязвимость из-за пропущенного ручного обновления.

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

Когда можно устанавливать сайт?

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

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

Список источников

1. Ubuntu Server Documentation — Firewall

2. Ubuntu Security Documentation — Security updates

3. Ubuntu Security Documentation — Firewall

4. Ubuntu Manpages — OpenSSH daemon configuration file

5. Fail2ban — Official repository and configuration examples

6. Ubuntu Server Documentation — Package management