Первичная настройка VPS: базовая конфигурация и усиление безопасности

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

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

Введение: зачем нужна первичная настройка VPS

Если сервер ещё не создан, один из вариантов для выбора VPS — Timeweb Cloud (партнёрская ссылка). Перед заказом проверьте доступный образ ОС, SSH-ключи и способ доступа к консоли восстановления.

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

Риски стандартной поставки:

• Прямой root-доступ. Любая скомпрометированная сессия или ошибка в команде — и система повреждена без возможности отката.
• Парольная аутентификация. Брутфорс-атаки на SSH идут постоянно. Сложный пароль замедляет подбор, но не исключает его.
• Отсутствие брандмауэра. Все службы, которые вы запустите позже, могут оказаться доступны извне без вашего ведома.
• Несинхронизированные часы. Ошибки системного времени мешают сопоставлять события. UTC является нормальным выбором для серверных логов.

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

Шаг 1: Вход по SSH и первое знакомство с сервером

Откройте терминал на локальной машине и выполните подключение:

ssh root@IP_адрес_вашего_сервера

При первом подключении SSH-клиент покажет fingerprint ключа хоста и запросит подтверждение:

The authenticity of host '192.0.2.10 (192.0.2.10)' can't be established.
ED25519 key fingerprint is SHA256:AbCdEf1234567890AbCdEf1234567890AbCdEf12345.
Are you sure you want to continue connecting (yes/no)?

Сверьте fingerprint с тем, что предоставил провайдер в панели управления. Это защита от атаки «человек посередине». После подтверждения введите пароль root.

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

passwd

При выполнении passwd от root система попросит дважды ввести новый пароль. Используйте генератор случайных паролей или менеджер паролей — минимальная длина 16 символов, буквы разного регистра, цифры и спецсимволы.

Шаг 2: Создание непривилегированного пользователя с sudo-правами

Почему не стоит работать под root

Root не имеет ограничений. Опечатка в пути rm -rf / tmp/ вместо rm -rf /tmp/ уничтожает систему. Каждая программа, запущенная от root, получает полный доступ к оборудованию и файлам. При компрометации сервиса атакующий сразу захватывает всю машину.

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

Создайте пользователя (замените username на осмысленное имя):

adduser username

Система запросит пароль и дополнительную информацию. Пароль задайте отличный от root. Поля Full Name и прочие можно оставить пустыми — нажимайте Enter.

Добавьте пользователя в группу sudo:

usermod -aG sudo username

Проверьте, что пользователь попал в группу:

groups username

Вывод должен содержать sudo среди перечисленных групп. Если парольный SSH-вход уже отключён, сначала перенесите только публичный ключ из шага 3 через рабочую сессию или консоль провайдера; не включайте парольный вход ради проверки. Затем откройте второй терминал и проверьте вход под новой учетной записью:

ssh username@IP_адрес_вашего_сервера

После успешного входа проверьте sudo-доступ:

sudo whoami

Команда должна вернуть root. Первый вызов sudo запросит пароль пользователя и выведет стандартное предупреждение о необходимости ответственного использования привилегий.

Шаг 3: Настройка SSH-ключа и отключение входа по паролю

Генерация и копирование SSH-ключа

Парольная аутентификация — основной вектор атак на SSH. Боты перебирают комбинации root:password, admin:admin и тысячи других круглосуточно. Ключевая аутентификация использует криптографическую пару: приватный ключ хранится у вас, публичный — на сервере. Подобрать ключ вычислительно невозможно при текущих мощностях.

На локальной машине (не на сервере) сгенерируйте ключевую пару Ed25519 — она быстрее и компактнее RSA при сопоставимой стойкости:

ssh-keygen -t ed25519 -C "comment_identifying_this_key"

Утилита предложит путь для сохранения ключа (по умолчанию ~/.ssh/id_ed25519) и парольную фразу. Парольная фраза на ключ обязательна: если приватный ключ украдут, фраза даст время отозвать его до того, как злоумышленник подберет пароль. Нажмите Enter для стандартного пути и введите фразу.

Скопируйте публичный ключ на сервер:

ssh-copy-id username@IP_адрес_вашего_сервера

Команда запросит пароль пользователя на сервере и добавит содержимое ~/.ssh/id_ed25519.pub в ~/.ssh/authorized_keys на удаленной машине.

Пользователи Windows: при установленном OpenSSH Client доступны ssh и ssh-keygen, но ssh-copy-id не входит в стандартный комплект Windows OpenSSH. Скопируйте содержимое публичного файла id_ed25519.pub в ~/.ssh/authorized_keys пользователя на Linux-сервере через рабочую сессию или консоль. Каталог должен иметь права 700, файл — 600, владельцем должен быть этот пользователь. Приватный ключ на сервер не переносите.

Проверьте вход по ключу:

ssh username@IP_адрес_вашего_сервера

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

Отключение аутентификации по паролю

Сначала в отдельном терминале проверьте именно ключевой вход и sudo. Существующую сессию оставьте открытой:

ssh -o PreferredAuthentications=publickey -o PasswordAuthentication=no username@IP_адрес_вашего_сервера
sudo whoami

После успешной проверки сохраните копию каталога конфигурации и откройте основной файл:

sudo cp -a /etc/ssh /root/ssh-before-hardening
sudo nano /etc/ssh/sshd_config

До блока Match задайте следующие параметры. Проверьте подключаемые файлы sshd_config.d: для большинства параметров действует первое найденное значение. Не добавляйте конфликтующие строки вслепую:

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes

PermitRootLogin запрещает прямой root-вход. PasswordAuthentication и KbdInteractiveAuthentication отключают два разных способа парольного входа; этот пример не подходит для настроенного MFA через keyboard-interactive.

sudo sshd -t
sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|kbdinteractiveauthentication|pubkeyauthentication) '
# Продолжайте только при отсутствии ошибок и ожидаемых значениях:
sudo systemctl reload ssh.service

При наличии Match проверьте эффективную конфигурацию для конкретного пользователя и адреса через sshd -T -C по руководству OpenSSH. В новом терминале снова выполните ключевой вход и sudo whoami. Только после успеха закрывайте прежнюю сессию. Если проверка не проходит, в сохранённой сессии восстановите изменённые файлы из /root/ssh-before-hardening, выполните sshd -t и reload ssh.service. При потере всех сессий используйте консоль или rescue-режим провайдера.

Шаг 4: Установка и настройка брандмауэра (UFW)

UFW (Uncomplicated Firewall) — интерфейс к iptables, который упрощает управление правилами фильтрации. На большинстве Ubuntu- и Debian-систем он предустановлен, но неактивен. Проверьте наличие:

sudo ufw status

Если команда не найдена — установите пакет:

sudo apt update && sudo apt install ufw -y

Базовые правила UFW

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

sudo ufw default deny incoming
sudo ufw default allow outgoing

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

sudo ufw allow 22/tcp

Если SSH слушает другой порт, укажите его вместо 22 и проверьте внешний firewall провайдера. Смена порта необязательна и не заменяет ключевую аутентификацию.

Включите брандмауэр:

sudo ufw enable

Подтвердите действие, введя y. Проверьте статус:

sudo ufw status verbose

Вывод покажет активный статус, политики и правила. Убедитесь, что фактический SSH-порт разрешён, и откройте новое SSH-соединение, не закрывая рабочее. При проблеме временно выполните sudo ufw disable в сохранённой сессии или консоли провайдера и исправьте правила.

Позже, когда вы развернете веб-сервер, базу данных или другие службы, вы добавите правила для их портов. Например, для Nginx потребуется sudo ufw allow 80/tcp и sudo ufw allow 443/tcp. Если вы планируете устанавливать панель управления, рекомендую предварительно изучить руководство по безопасной настройке веб-интерфейсов — там разобраны нестандартные порты, ограничение доступа по IP и HTTPS.

Альтернатива: настройка iptables

Для новичка на Ubuntu/Debian проще использовать UFW. Не смешивайте его правила с ручной очисткой iptables: это может нарушить firewall, Docker и другие сетевые службы. Если вы осознанно управляете iptables напрямую, подготовьте полный набор правил под конкретный сервер. Сохраните текущую конфигурацию:

sudo sh -c 'iptables-save > /root/iptables-before.rules'

В копии набора правил предусмотрите loopback, ESTABLISHED/RELATED, фактический SSH-порт и нужные службы до применения запрещающей политики. Не выполняйте по SSH цепочку «очистить всё → INPUT DROP → разрешить SSH»: доступ может оборваться до последней команды. Файл должен быть в формате iptables-save/iptables-restore; универсальный шаблон не учитывает вашу сеть.

Если iptables-apply установлен, применяйте подготовленный и проверенный файл с автоматическим откатом:

# /root/iptables-reviewed.rules — ваш заранее подготовленный файл
sudo iptables-apply -t 120 /root/iptables-reviewed.rules

Пока команда ожидает подтверждения, откройте второй SSH-сеанс и проверьте нужные службы. Подтверждайте изменения только после успешной проверки; без подтверждения iptables-apply восстановит прежние правила по тайм-ауту. Консоль провайдера должна быть доступна заранее. iptables обрабатывает IPv4; IPv6 требует отдельных правил и проверки через ip6tables-apply, включая необходимый ICMPv6. На системах с native nftables используйте их собственный механизм управления.

На Debian/Ubuntu сохранение между перезагрузками можно настроить через iptables-persistent/netfilter-persistent после проверки правил. Не сохраняйте непроверенную конфигурацию. В других дистрибутивах способ сохранения отличается.

Шаг 5: Настройка часового пояса (timezone)

VPS часто использует UTC. Это корректный и удобный вариант для сопоставления логов разных серверов. Часовой пояс меняет отображение времени, а NTP синхронизирует сами часы. Оставьте UTC или выберите нужную зону осознанно; команда ниже — пример для Москвы.

Ротация логов (logrotate) также привязана к системному времени. Если cron-задача настроена на полночь, а часовой пояс не совпадает с вашим — ротация произойдет в неожиданный момент, что может помешать диагностике.

Просмотрите доступные часовые пояса:

timedatectl list-timezones

Список большой, удобнее фильтровать по региону. Например, для Москвы:

timedatectl list-timezones | grep Moscow

Установите нужный пояс:

sudo timedatectl set-timezone Europe/Moscow

Проверьте результат:

timedatectl

Вывод покажет локальное время, универсальное время (UTC), часовой пояс и статус синхронизации NTP. Убедитесь, что строка System clock synchronized: yes присутствует — это означает, что работает синхронизация времени по сети.

Если синхронизация отключена, включите её:

sudo timedatectl set-ntp true

Точное время критично не только для логов. Протоколы аутентификации (Kerberos, TOTP), TLS-сертификаты и распределенные системы (базы данных, кластеры) полагаются на синхронизированные часы. Расхождение даже в несколько секунд может вызывать ошибки валидации токенов и отказы в соединении.

Чек-лист: все команды для быстрой настройки

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

# 1. Первый вход и смена пароля root
ssh root@<IP>
passwd

# 2. Создание пользователя и выдача sudo
adduser <username>
usermod -aG sudo <username>
groups <username>

# 3. Проверка входа под новым пользователем (из второго терминала)
ssh <username>@<IP>
sudo whoami

# 4. Генерация SSH-ключа (на локальной машине)
ssh-keygen -t ed25519 -C "<comment>"
ssh-copy-id <username>@<IP>

# 5. Проверка входа по ключу (из второго терминала)
ssh <username>@<IP>

# 6. Отключение парольной аутентификации и root-входа
sudo nano /etc/ssh/sshd_config
# Строки для изменения:
# PermitRootLogin no
# PasswordAuthentication no
# KbdInteractiveAuthentication no
# PubkeyAuthentication yes
# Сначала сохраните конфигурацию и проверьте Include/Match, как в шаге 3
sudo sshd -t
# При отсутствии ошибок и проверенных эффективных значениях:
sudo systemctl reload ssh.service
# Проверьте новый вход именно по ключу и sudo в отдельном терминале

# 7. Установка и настройка UFW
sudo apt update && sudo apt install ufw -y
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw enable
sudo ufw status verbose

# 8. Настройка часового пояса
timedatectl list-timezones | grep <region>
sudo timedatectl set-timezone <timezone>
sudo timedatectl set-ntp true
timedatectl

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

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

• Блокировка SSH-порта до включения UFW. Всегда добавляйте правило sudo ufw allow 22/tcp перед sudo ufw enable. Восстановление доступа потребует консоли провайдера.
• Закрытие единственной SSH-сессии после изменения sshd_config. Держите резервную сессию открытой, пока не убедитесь, что новая конфигурация работает.
• Потеря приватного SSH-ключа. Храните резервную копию ключа в защищенном месте. Без него и без парольного входа доступ к серверу будет утерян.
• Использование одного и того же пароля для root и пользователя. Компрометация одного пароля не должна открывать доступ ко всем учетным записям.
• Пропуск синхронизации часов. Проверьте NTP; UTC можно оставить. При сопоставлении логов учитывайте указанный часовой пояс.

Заключение: что делать дальше

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

Дальнейшие шаги зависят от роли сервера, но есть универсальные рекомендации:

• Автоматические обновления безопасности. Настройте unattended-upgrades (Debian/Ubuntu) или dnf-automatic (RHEL-семейство). Патчи закрывают известные уязвимости, и задержка с их установкой — прямой риск компрометации.
• Fail2Ban. Сканеры портов и брутфорс-атаки продолжатся, даже если SSH защищен ключом. Fail2Ban блокирует IP-адреса после нескольких неудачных попыток, снижая нагрузку и шум в логах. Подробная настройка описана в статье по hardening Linux-сервера.
• Мониторинг. Настройте сбор и алертинг по логам. Минимальный вариант — logwatch с ежедневным отчетом на email. Продвинутый — связка Prometheus + Grafana или коммерческие агенты вроде Datadog.
• Резервное копирование. Настройте регулярный бэкап конфигурационных файлов (/etc) и данных приложений. Автоматизируйте выгрузку бэкапов на отдельное хранилище — бэкап на том же диске бесполезен при отказе железа.

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