Обо мне Блог Контакты

Базовая защита VPS/VDS сервера

Предисловие

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

Note

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

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


Аренда VPS

Для начала, конечно же, арендуем новый VPS-сервер у любого провайдера. Для нужд Homelab я использую timeweb.cloud. Провайдеров множество, так что не обязательно использовать именно его — смотрите цену и варианты оплаты, чтобы вам подходило.

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

Итак, регистрируем новый VPS и получаем по почте или внутри Dashboard вашего провайдера данные для доступа по SSH (IP-адрес и root-пароль). Заходим на наш VPS-сервер, используя полученные данные, с помощью такой программы как, например, Putty. Тот, кто на Linux — думаю, сам знает что использовать.

ssh root@<IP_ADDRESS>

Обновление пакетов и проверка ТТХ сервера

Первое, что мы обязательно делаем на любом Ubuntu-сервере — обновляем имеющиеся пакеты:

apt update && apt upgrade -y && reboot

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

wget -qO- speedtest.artydev.ru | bash

Запустили, посмотрели что всё в порядке, скорость устраивает. Продолжаем.


Создание и настройка отдельного пользователя

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

Добавляем нового пользователя admin (называть можно как угодно, например vasya) и включаем его в группу sudo. Группа sudo — это группа, которая позволяет пользователям делать что-то от имени root.

adduser admin
usermod -aG sudo admin

Нам нужно установить новый пароль для нашего пользователя. Вводим команду и после этого вас спросят ввести и подтвердить пароль:

passwd admin

Настройка окружения пользователя

Заходим под созданным пользователем в его домашнюю директорию для дальнейшей настройки:

su - admin
cd

Ставим UMASK на все создаваемые им файлы, чтобы максимально ограничить доступ к ним:

echo 'umask 0077' >> .bashrc

Note

Этот шаг опционален. Можно пропустить, если не понимаете, зачем он.


Создание SSH-ключей и настройка подключения

Дальше нам нужно создать SSH-ключи на локальном компьютере (том компьютере, с которого мы планируем подключаться на наш VPS-сервер), если они, конечно, ещё не созданы.

Генерация ключей на локальном компьютере

Для этого на локальном компьютере запускаем терминал (командная строка). Пишем:

ssh-keygen -t ed25519

Tip

Алгоритм ed25519 — более современный и безопасный, чем RSA. Он быстрее и использует более короткие ключи при том же уровне защиты. Для базовых настроек можно дальше нажать несколько раз Enter. По сути там спросят: в каком каталоге сохранить ваши ключи и пароль на ключи как дополнительная защита, если кто-то всё-таки получит доступ к вашим ключам.

Наконец наши SSH-ключи созданы. В каталоге по умолчанию (зависит от вашей операционной системы) у нас есть два ключа:

Файл Описание
id_ed25519 Закрытый ключ
id_ed25519.pub Открытый ключ

Note

Если вы использовали команду ssh-keygen без -t ed25519, то ключи будут называться id_rsa и id_rsa.pub — это тоже рабочий вариант.


Добавление ключа на VPS

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

Добавляем с клиента (локального компьютера, с которого будем подключаться на VPS) SSH-ключи:

ssh-copy-id admin@<IP_ADDRESS>

Info

По сути эта утилита просто копирует содержимое файла id_ed25519.pub на ваш VPS-сервер в файл ~/.ssh/authorized_keys. То есть это можно сделать и вручную, но зачем, если есть прекрасная утилита ssh-copy-id.


Проверка подключения

Подключаемся к серверу юзером admin (сейчас должно подключиться без пароля):

ssh admin@<IP_ADDRESS>

Если подключилось — вы всё сделали правильно. Ставим на всякий случай необходимые права доступа:

chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys

Конфигурация SSH-сервиса

Далее нам нужно сконфигурировать SSH. Открываем конфигурацию:

sudo nano /etc/ssh/sshd_config

Основное что нам нужно сделать:

  1. Поменять стандартный порт SSH (22) на любой другой — во всём мире он известен, и первое что делает всякий внешний мусор — это долбится в этот порт. Смена порта не повышает криптографическую безопасность, но снижает шум в логах и нагрузку.
  2. Запретить авторизацию от пользователя root.
  3. Запретить авторизацию по паролю.

Warning

Те параметры, которые закомментированы в начале знаком #, раскомментируем, убрав этот знак.

Tip

Про выбор порта: лучше выбирать порт выше 1024, но избегать «популярных альтернатив» типа 2222, 22222 — их тоже сканируют. Выбирайте что-то менее очевидное.

Редактируем необходимые параметры:

Port 14144
LoginGraceTime 1m
PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
PermitEmptyPasswords no
KbdInteractiveAuthentication no
AllowUsers admin
ClientAliveInterval 300
ClientAliveCountMax 2
Параметр Описание
Port 14144 Смена стандартного SSH порта
LoginGraceTime 1m Ограничение времени на аутентификацию
PermitRootLogin no Запрещаем логиниться root пользователем
PubkeyAuthentication yes Аутентификация через SSH ключ
PasswordAuthentication no Запрет аутентификации по паролю
PermitEmptyPasswords no Запрет использования пустого пароля
KbdInteractiveAuthentication no Отключаем keyboard-interactive аутентификацию
AllowUsers admin Разрешаем логиниться только юзеру admin
ClientAliveInterval 300 Проверка активности клиента каждые 5 минут
ClientAliveCountMax 2 Разрыв соединения после 2 неудачных проверок

Info

Параметры ClientAliveInterval и ClientAliveCountMax разорвут соединение после 10 минут неактивности — полезно, если забыл закрыть терминал.

Нажимаем Ctrl + S для сохранения и Ctrl + X для выхода.


Перезапуск SSH-сервиса

Для начала проверяем конфиг SSH на ошибки:

sudo sshd -t

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

Можно перезагрузить весь VPS через команду reboot, а можно просто перезапустить SSH-сервис. Даю две команды, так как в разных версиях может отличаться — можно ввести обе по очереди:

sudo systemctl restart ssh
sudo systemctl restart sshd

Warning

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

Теперь с локального компьютера (клиента) мы уже будем подключаться, используя нестандартный порт 14144, который указали в настройках SSH:

ssh admin@<IP_ADDRESS> -p 14144

Если всё сделали правильно — должно успешно подключиться, и ничего у вас не спросить. ✅


Отключение IPv6

Если вы точно уверены, что IPv6 не используется и не будет использоваться — его можно отключить. Это дополнительная поверхность атаки, если он не фильтруется firewall’ом.

Открываем файл:

sudo nano /etc/sysctl.conf

Добавляем в конец:

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1

Применяем изменения:

sudo sysctl -p

Также отключаем IPv6 в UFW. Открываем:

sudo nano /etc/default/ufw

Находим и меняем:

IPV6=no

Настройка Firewall

Далее нам нужно настроить Firewall.

Warning

Первое что нам надо сделать — разрешить наш нестандартный порт SSH. Ведь если мы его не разрешим, то после активации Firewall мы потеряем доступ к нашему VPS-серверу.

sudo ufw allow 14144/tcp

Запрещаем все входящие подключения и разрешаем все выходящие:

sudo ufw default deny incoming
sudo ufw default allow outgoing

Проверяем открытые порты:

sudo ufw status numbered

Включаем Firewall:

sudo ufw enable

Note

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


Установка Fail2Ban

Fail2Ban — это инструмент безопасности для Linux/Unix, который защищает сервер от перебора паролей и атак брутфорсом. Устанавливаем:

sudo apt install fail2ban -y

Дальше нам нужно указать ему, что порт SSH у нас вместо стандартного 22 теперь нестандартный — 14144.


Конфигурация Fail2Ban

Настраиваем конфигурацию в отдельном файле. Для этого создаем в директории /etc/fail2ban/jail.d новый файл sshd.local и открываем новый конфиг для редактирования:

sudo nano /etc/fail2ban/jail.d/sshd.local

Вставляем в этот файл следующий конфиг:

[sshd]
enabled = true
port    = 14144

Тем самым мы указываем Fail2ban, что порт ssh у нас теперь 14144.


Запуск Fail2Ban

Активируем Fail2Ban, добавляем его в автозагрузку и проверяем статус:

sudo systemctl start fail2ban
sudo systemctl enable fail2ban
sudo systemctl status fail2ban

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

sudo systemctl restart fail2ban

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

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

sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure unattended-upgrades

В появившемся диалоге выбираем Yes.

Tip

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


Итоги

Ну вот, наконец, мы настроили базовые защитные параметры нашего VPS-сервера. Эта процедура отсеет большинство атак.

Что мы сделали:

Этап Результат
✅ Создали отдельного пользователя Не работаем от root
✅ Настроили SSH-ключи (ed25519) Авторизация без пароля, современный алгоритм
✅ Сменили порт SSH Избегаем массового сканирования
✅ Настроили таймаут сессий Автоматический разрыв неактивных соединений
✅ Запретили вход root и по паролю Закрыли основные векторы атак
✅ Отключили IPv6 Убрали лишнюю поверхность атаки
✅ Настроили Firewall Закрыли все ненужные порты
✅ Установили Fail2Ban Защита от брутфорса
✅ Настроили автообновления Автоматические патчи безопасности

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