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

Новый VPS-сервер сразу после создания уязвим: открыт 22-й порт, root-доступ по паролю, отсутствует фильтрация трафика. Боты сканируют сеть непрерывно, и незащищенная машина попадает под автоматические атаки в течение минут после запуска. Эта инструкция дает готовый чек-лист, который закрывает базовые векторы атак за 10–15 минут. Все команды проверены на Ubuntu Server 24.04 LTS и Debian 12, но логика применима к любому дистрибутиву Linux.

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

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

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

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

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

Мы последовательно устраним каждую из этих проблем. Если вы арендовали сервер для хостинга приложений, следующий логичный шаг после этой инструкции - изучить полный гайд по 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 немедленно - пароли, передаваемые по email или отображаемые в веб-интерфейсе, считаются скомпрометированными:

passwd

Система запросит текущий пароль и дважды попросит ввести новый. Используйте генератор случайных паролей или менеджер паролей - минимальная длина 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 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: в PowerShell (начиная с Windows 10) доступны те же команды ssh-keygen и ssh-copy-id. Альтернативный вариант - клиент PuTTY с утилитами puttygen и pageant.

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

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

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

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

Откройте конфигурацию SSH-сервера в редакторе:

sudo nano /etc/ssh/sshd_config

Найдите и измените следующие директивы. Если строка закомментирована (# в начале) - раскомментируйте и задайте значение. Если строка отсутствует - добавьте в конец файла:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

Что означают эти настройки:

• PermitRootLogin no - запрещает прямой вход под root по SSH. Теперь для административных задач нужно сначала зайти под обычным пользователем и использовать sudo.
• PasswordAuthentication no - отключает вход по паролю. Аутентификация возможна только по ключу.
• PubkeyAuthentication yes - явно разрешает ключевую аутентификацию (в большинстве дистрибутивов включена по умолчанию, но лучше указать явно).

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

sudo sshd -t

Если команда не вывела ошибок - конфигурация корректна. Перезапустите SSH-сервер:

sudo systemctl restart sshd

Критически важно: не закрывайте текущую SSH-сессию до проверки. Откройте второй терминал и попробуйте подключиться заново:

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

Если подключение по ключу работает - настройка выполнена. Если нет - вы остаетесь в первой сессии и можете исправить ошибку. Закрытие единственной работающей сессии при неверной конфигурации sshd_config приведет к полной потере доступа. Восстановление потребует либо консоли провайдера (VNC/KVM), либо переустановки сервера.

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

Шаг 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-порт в sshd_config (что рекомендуется для production-серверов), укажите свой порт вместо 22.

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

sudo ufw enable

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

sudo ufw status verbose

Вывод покажет активный статус, политики по умолчанию и список правил. Убедитесь, что порт 22/tcp присутствует в списке ALLOW.

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

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

UFW доступен не на всех дистрибутивах. В минимальных установках Debian, CentOS или Rocky Linux может присутствовать только iptables. Приведем эквивалентную конфигурацию для iptables:

# Очистить существующие правила
sudo iptables -F
sudo iptables -X

# Политика по умолчанию: запретить входящие, разрешить исходящие
sudo iptables -P INPUT DROP
sudo iptables -P FORWARD DROP
sudo iptables -P OUTPUT ACCEPT

# Разрешить loopback-интерфейс
sudo iptables -A INPUT -i lo -j ACCEPT

# Разрешить установленные и связанные соединения
sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Разрешить SSH (порт 22)
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT

Правила iptables сбрасываются при перезагрузке. Для сохранения установите пакет iptables-persistent (Debian/Ubuntu) или iptables-services (RHEL/CentOS):

sudo apt install iptables-persistent -y
sudo netfilter-persistent save

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

Новый VPS часто поставляется с часовым поясом 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
# PubkeyAuthentication yes
sudo sshd -t
sudo systemctl restart sshd

# 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

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

Сервер получил базовую защиту: 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 с готовыми командами и конфигурациями.