Ошибки безопасности VPS и как их исправить

Опубликовано:
Безопасность VPS — обязательный первый шаг. Реальный эксперимент показал сотни попыток взлома в первый час работы нового сервера. Готовые решения для Ubuntu: закрыть доступ root, настроить SSH-ключи, включить фаервол UFW, защититься от брутфорса через Fail2ban и настроить автономные бэкапы. Начните с чек-листа на 10 минут, затем перейдите к детальной настройке для долговременной защиты.

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

Jan 21 10:15:23 vps-ubuntu sshd[12345]: Invalid user admin from 103.207.38.123 port 54321
Jan 21 10:15:25 vps-ubuntu sshd[12346]: Invalid user administrator from 103.207.38.123 port 54322
Jan 21 10:15:27 vps-ubuntu sshd[12347]: Invalid user root from 103.207.38.123 port 54323
Jan 21 10:15:29 vps-ubuntu sshd[12348]: Failed password for invalid user test from 103.207.38.123 port 54324
Jan 21 10:15:31 vps-ubuntu sshd[12349]: Failed password for invalid user guest from 103.207.38.123 port 54325
Jan 21 10:15:34 vps-ubuntu sshd[12350]: Invalid user user from 103.207.38.123 port 54326
Jan 21 10:15:37 vps-ubuntu sshd[12351]: Failed password for invalid user admin from 45.142.120.200 port 47891
Jan 21 10:15:39 vps-ubuntu sshd[12352]: Invalid user ubuntu from 45.142.120.200 port 47892
Jan 21 10:15:42 vps-ubuntu sshd[12353]: Failed password for invalid user deploy from 45.142.120.200 port 47893
Jan 21 10:15:45 vps-ubuntu sshd[12354]: Invalid user test from 185.231.59.150 port 31234
Jan 21 10:15:48 vps-ubuntu sshd[12355]: Failed password for invalid user oracle from 185.231.59.150 port 31235
Jan 21 10:15:51 vps-ubuntu sshd[12356]: Invalid user postgres from 185.231.59.150 port 31236
Jan 21 10:15:54 vps-ubuntu sshd[12357]: Failed password for invalid user nagios from 103.207.38.123 port 54327
Jan 21 10:15:57 vps-ubuntu sshd[12358]: Invalid user ftp from 103.207.38.123 port 54328
Jan 21 10:16:02 vps-ubuntu sshd[12359]: Failed password for invalid user pi from 45.142.120.200 port 47894
Jan 21 10:16:05 vps-ubuntu sshd[12360]: Invalid user student from 45.142.120.200 port 47895
Jan 21 10:16:08 vps-ubuntu sshd[12361]: Failed password for invalid user teacher from 185.231.59.150 port 31237
Jan 21 10:16:12 vps-ubuntu sshd[12362]: Invalid user webmaster from 185.231.59.150 port 31238
Jan 21 10:16:15 vps-ubuntu sshd[12363]: Failed password for invalid user mysql from 103.207.38.123 port 54329
Jan 21 10:16:18 vps-ubuntu sshd[12364]: Invalid user info from 103.207.38.123 port 54330
Jan 21 10:16:21 vps-ubuntu sshd[12365]: Failed password for invalid user sales from 45.142.120.200 port 47896
Jan 21 10:16:24 vps-ubuntu sshd[12366]: Invalid user support from 45.142.120.200 port 47897
Jan 21 10:16:27 vps-ubuntu sshd[12367]: message repeated 3 times: [ Failed password for invalid user admin from 103.207.38.123 port 54331]
Jan 21 10:16:30 vps-ubuntu sshd[12368]: Connection closed by authenticating user root 103.207.38.123 port 54332 [preauth]
Jan 21 10:16:33 vps-ubuntu sshd[12369]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=45.142.120.200
Jan 21 10:16:36 vps-ubuntu sshd[12370]: Failed password for root from 185.231.59.150 port 31239 ssh2
Jan 21 10:16:39 vps-ubuntu sshd[12371]: Received disconnect from 103.207.38.123 port 54333:11: Bye Bye [preauth]
Jan 21 10:16:42 vps-ubuntu sshd[12372]: Invalid user git from 45.142.120.200 port 47898
Jan 21 10:16:45 vps-ubuntu sshd[12373]: Failed password for invalid user jenkins from 185.231.59.150 port 31240
Jan 21 10:16:48 vps-ubuntu sshd[12374]: Invalid user deployer from 103.207.38.123 port 54334
Jan 21 10:16:51 vps-ubuntu sshd[12375]: Failed password for invalid user www-data from 45.142.120.200 port 47899
Jan 21 10:16:55 vps-ubuntu sshd[12376]: Connection reset by 185.231.59.150 port 31241 [preauth]

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

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

Если нет времени: сделайте это за 10 минут прямо сейчас

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

# 1. Обновить всё
sudo apt update && sudo apt upgrade -y

# 2. Создать пользователя без прав root
adduser deployer && usermod -aG sudo deployer

# 3. Настроить базовый файрвол
sudo apt install ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow ssh
sudo ufw enable

# 4. Защититься от брутфорса
sudo apt install fail2ban
sudo systemctl enable fail2ban

# 5. Заблокировать вход для root
sudo passwd -l root

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

Жёсткий контроль доступа

Цель — закрыть все очевидные двери, через которые могут проникнуть автоматические скрипты и злоумышленники.

Вход под пользователем root

root может всё. Одна опечатка в команде или компрометация сессии — и система может быть необратимо повреждена или полностью захвачена.

Решение:

  1. Создайте обычного пользователя с привилегиями:

    adduser deployer
    usermod -aG sudo deployer

  2. Выйдите из сессии root, войдите как deployer и убедитесь, что sudo работает.

  3. Позже мы полностью отключим вход для root.

Использование пароля для SSH

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

Решение:

  1. Сгенерируйте ключ на своей локальной машине (если его нет):

    ssh-keygen -t ed25519 -C "your-email@example.com"

  2. Скопируйте его на сервер:

    ssh-copy-id deployer@your-server-ip

  3. Настройте SSH, запретив небезопасные методы входа. Отредактируйте /etc/ssh/sshd_config:

    PermitRootLogin no          # Главное! Запрещаем вход root
    PasswordAuthentication     no   # Отключаем аутентификацию паролем
    PermitEmptyPasswords     no
    MaxAuthTries 3              # Ограничиваем попытки
    AllowUsers     deployer         # Разрешаем вход только конкретному пользователю

  4. Перезагрузите службу SSH: sudo systemctl restart sshd

Отсутствие защиты от брутфорса

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

Решение: Установите Fail2ban — он превратит ваш сервер из пассивной жертвы в активного защитника.

  1. Установите пакет: sudo apt install fail2ban

  2. Создайте локальный конфиг: sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

  3. В файле /etc/fail2ban/jail.local настройте блок [sshd]:

    [sshd]
    enabled = true
    port = ssh
    maxretry = 3   # Количество неудачных попыток
    bantime = 3600 # Время блокировки в секундах (1 час)
    findtime = 600 # Окно для подсчёта попыток (10 минут)

    Проще говоря: 3 неудачных попытки за 10 минут = блокировка на час.

  4. Перезапустите: sudo systemctl restart fail2ban && sudo systemctl enable fail2ban

Сокращаем периметр атаки

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

Отсутствие файрвола

Без файрвола каждый порт на вашем сервере потенциально доступен из интернета для сканирования и атак.

Решение: Настройте простой, но эффективный файрвол ufw.

sudo apt install ufw
sudo ufw default deny incoming  # Блокировать всё входящее по умолчанию
sudo ufw default allow outgoing # Разрешить всё исходящее
sudo ufw allow ssh              # Разрешить SSH (порт 22)
sudo ufw allow 80/tcp           # Разрешить HTTP, если нужен веб-сервер
sudo ufw allow 443/tcp          # Разрешить HTTPS
sudo ufw enable                 # Включить и активировать правила

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

Запуск ненужных служб

Каждая активная служба — это дополнительный код, который может содержать уязвимости.

Решение:

  1. Посмотрите, что слушает сетевые порты: sudo ss -tulpn

    Обратите внимание на столбец Local Address:Port. Запись 0.0.0.0:xxxx означает, что служба доступна из любой сети, а 127.0.0.1:xxxx — только локально.

  2. Остановите и отключите автозапуск для служб, которые не используете (например, cups — сервер печати):

    sudo systemctl stop cups
    sudo systemctl disable cups

Задайте себе вопрос: Действительно ли мне необходима эта служба?

Надёжный фундамент и план на случай провала

Безопасность — это не только стены, но и их прочность, а также умение восстановить то, что внутри.

Необновлённое программное обеспечение

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

Решение:

  1. Прямо сейчас: sudo apt update && sudo apt upgrade -y

  2. На постоянной основе: Включите автоматические обновления безопасности.

    sudo apt install unattended-upgrades
    # Или для детальной настройки: sudo dpkg-reconfigure unattended-upgrades

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

Отсутствие резервных копий

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

Решение: Настройте регулярное автономное резервное копирование.

  1. Храните бэкапы на отдельном сервере или в облаке, а не на том же VPS.

  2. Простой скрипт для начала (/usr/local/bin/backup.sh):

    #!/bin/bash
    BACKUP_DIR="/backup"
    DATE=$(date +%Y-%m-%d)
    tar -czf $BACKUP_DIR/backup-$DATE.tar.gz /home /etc /var/www 2>/dev/null
    # Команда для отправки в облако (например, rclone или S3 CLI) добавится здесь
    find $BACKUP_DIR -name "backup-*.tar.gz" -mtime +7 -delete

  3. Добавьте задание в планировщик (sudo crontab -e):

    0 2 * * * /usr/local/bin/backup.sh  # Каждый день в 2 ночи

Полный чек-лист для нового VPS

Для каждой новой виртуальной машины пройдите по списку. Особое внимание уделите пунктам, выделенным жирным — они блокируют самые распространённые атаки:

Что дальше

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

  1. Нестандартный порт SSH: Измените порт по умолчанию (22) на другой в файле /etc/ssh/sshd_config (директива Port). Это значительно снизит уровень шума в логах. Важно: после смены порта не забудьте указывать его при подключении: ssh -p <новый_порт> deployer@your-server-ip, а также обновить правило файрвола ufw.
  2. Мониторинг логов: Настройте простой мониторинг с помощью утилит вроде logwatch или просто регулярно проверяйте ключевые логи: sudo tail -f /var/log/auth.log.
  3. Углублённая настройка под ваши сервисы: Если вы используете Nginx, WordPress или другое ПО — изучите и примените рекомендации по его безопасной настройке. Например, настройте fail2ban для защиты веб-интерфейсов.

FAQ: Частые вопросы и проблемы

Я выполнил все шаги, включая отключение паролей и root. Теперь я не могу зайти на сервер! Что делать?

Самая вероятная причина — ошибка при копировании SSH-ключа или некорректные права на файлы ключей.

  1. Проверьте подключение с ключом вручную, указав путь к нему: ssh -i ~/.ssh/id_ed25519 deployer@your-server-ip.
  2. Если это не помогло, и у вас ещё есть открытая сессия, проверьте логи SSH на сервере: sudo tail -f /var/log/auth.log. Попробуйте подключиться заново и посмотрите, что пишет лог.
  3. Если сессия потеряна, вам придётся использовать восстановление (рекавери) через панель управления вашего VPS-провайдера (например, VNC-консоль). Это экстренная мера, которая лишний раз подтверждает важность тестирования новой сессии перед закрытием старой.
Команда sudo apt upgrade требует перезагрузки. Это обязательно?

Если среди обновлений было ядро (linux-image-*) или критичные системные библиотеки (например, glibc), то да, перезагрузка необходима для полного применения обновлений. Система может работать, но будет использовать устаревшую, потенциально уязвимую версию ядра. После upgrade выполните sudo reboot в удобное время.

Fail2ban забанил мой собственный IP-адрес. Как разблокировать?

Это обычная ситуация, если вы несколько раз ошиблись с паролем или ключом.

  1. Подключитесь к серверу через консоль восстановления от провайдера (VNC/Rescue).
  2. Разблокируйте IP командой: sudo fail2ban-client set sshd unbanip <ваш_ip>.
  3. Чтобы избежать этого в будущем, добавьте свой IP в «белый список». В файле /etc/fail2ban/jail.local в секцию [sshd] добавьте строку: ignoreip = 127.0.0.1/8 <ваш_постоянный_ip>.
Я открыл порты 80 и 443 для веб-сервера, но подключиться по-прежнему нельзя. В чём дело?

Файрвол ufw разрешает подключения, но это не значит, что на сервере есть служба, которая «слушает» эти порты.

  1. Убедитесь, что ваш веб-сервер (Nginx/Apache) установлен, запущен и настроен: sudo systemctl status nginx.
  2. Проверьте ещё раз, что служба слушает нужные порты: sudo ss -tulpn | grep :80. Если список пуст — проблема в настройке веб-сервера, а не файрвола.
Насколько безопасно включать автоматические обновления (unattended-upgrades)? Они не сломают что-нибудь?

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

Где лучше хранить бэкапы? «Отдельный сервер» — это сложно.

«Отдельный сервер» — это принцип. На практике для начала подойдут:

  • Объектное хранилище вашего же хостинг-провайдера (например, S3-совместимое).
  • Специализированный сервис бэкапов (BorgBase, rsync.net).
  • Другой, более дешёвый VPS у другого провайдера (принцип географического и инфраструктурного разделения).
  • Локальный компьютер (но это не защитит от физического повреждения сервера дата-центра). Главное — автоматизация и проверка восстановления.
Я сделал всё из чек-листа. Мой сервер теперь неуязвим?

Нет, и ни один сервер не может быть «неуязвимым».

Вы закрыли базовый, обязательный минимум, который защищает от 99% автоматических атак методом «подбора по шаблону». Безопасность — это процесс, а не состояние. Новые уязвимости обнаруживаются постоянно, а целевые атаки (на вас лично) требуют более глубоких мер. Данное руководство — прочный фундамент, на котором уже можно строить дальнейшую защиту (например, из раздела «Что дальше?»).

Эти инструкции подойдут для CentOS/RHEL или Debian?

Принципы — универсальны. Конкретные команды (менеджер пакетов apt, имена пакетов ufw, fail2ban) предназначены для дистрибутивов на основе Debian/Ubuntu. Для RHEL/CentOS/Fedora потребуется использовать yum/dnf, firewalld вместо ufw, а некоторые пакеты могут иметь другие имена. Логика шагов (пользователь, SSH-ключи, файрвол, обновления) остаётся точно такой же.

Заключение

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

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

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

Сделайте это до того, как это станет необходимо. Не после.

Комментарии


Предыдущая Статья

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