Базовая защита 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
Основное что нам нужно сделать:
- Поменять стандартный порт SSH (22) на любой другой — во всём мире он известен, и первое что делает всякий внешний мусор — это долбится в этот порт. Смена порта не повышает криптографическую безопасность, но снижает шум в логах и нагрузку.
- Запретить авторизацию от пользователя root.
- Запретить авторизацию по паролю.
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-кошельков там — гуглите дальше. Я лишь показал то, чем пользуюсь сам.