Как защитить VPS после установки: SSH, firewall, Fail2Ban и обновления

Вопросы защиты VPS должны стоять на первом месте сразу после его приобретения и развёртывания. Это суровая правда жизни, а не просто формальная рекомендация, поскольку в первые же минуты после создания сервер становится открытой мишенью для атак злоумышленников. Защита VPS должна осуществляться сразу по нескольким направлениям, сочетая изменение значений стандартных настроек сервера с внедрением средств автоматизированной защиты от атак, например, таких, как Fail2Ban или систем обнаружения вторжений AIDE (Advanced Intrusion Detection Environment) для критичных узлов. Рассмотрим базовые подходы, способные значительно повысить безопасность Linux VPS.  

Покупай VPS/VDS сервер!

Быстрые VPS серверы на VZ и KVM с бесплатной админкой 24/7, тестом и ежедневными бэкапами

Почему новый VPS нельзя оставлять с настройками по умолчанию

Практика показывает, что в первую неделю после создания новый VPS атакуется по SSH в среднем более, чем 50 тысяч раз. И это не целенаправленные атаки, а результат «работы» автоматических ботов, брутфорс-скриптов или сканеров, которые непрерывно в режиме 24/7 сканируют Интернет-сеть для поиска уязвимостей в подключенных узлах.     

Более 90 % этих ботов управляется, так называемыми, скрипт-кидди – программами от сторонних разработчиков, в которых по умолчанию выставляются стандартные значения данных для поиска уязвимостей, например, популярные имена администраторов, стандартные порты и т. д.

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

Ниже приведены возможные последствия для VPS после взлома:

Бот в составе одного из ботнетов. Такой сервер становится активным участником DDoS-атак на другие узлы сети по команде взломщика. В результате, его IP-адрес попадает в чёрные списки мировых сервисов, после чего блокируется;

Участник майнинга криптовалют. Это становится возможным, как только на сервер будет установлена одна из скрытых программ для майнинга, например, XMRig или любая другая. После этого все ресурсы виртуального сервера (CPU, RAM) будут уходить на обработку транзакций в сети блокчейна. В результате, производительность VPS падает и он не может полноценно обслуживать ваш проект.

Спамер. Если целью атаки были почтовые сервисы VPS, они в дальнейшем могут использоваться для массовой рассылки фишинговых писем или любого другого вида спама. Однако, рано или поздно IP такого сервера попадёт в чёрные списки спамеров DNSBL (DNS blocklist) и, поэтому, все ваши легитимные письма с него будут блокироваться.

Точка входа. В случае, если VPS является первым звеном во внутренней инфраструктуре проекта, связь с которым осуществляется через SSH или VPN, то после взлома он становится точкой проникновения в другие компоненты системы – сервера, БД и т. д., вплоть до полного уничтожения инфраструктуры 

Хранилище запрещённого контента. Захваченный VPS нередко превращается в место хранения и распространения украденных баз данных, пиратских фильмов и другого запрещённого контента, который может распространяться через торренты, HTTP/FTP или сеть dark web. В результате, его владелец может понести правовую ответственность, например, за нарушение авторских прав. 

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

Чтобы избежать возможных последствий атаки, нужно знать, как защитить VPS сервер. Для этого необходимо изменить настройки VPS, установленные «по умолчанию», после чего перейти к выполнению следующих этапов, которые будут рассмотрены нами ниже.

Обновление ОС и пакетов

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

Обновить локальный кеш данных о доступных пакетах:

$ sudo apt update 

Выполнить полное обновление системы, включая ядро Linux

$ sudo apt full-upgrade -y

Здесь команда full-upgrade используется вместо устаревшей dist-upgrade и способна удалять конфликтующие пакеты, а также устанавливать новые зависимости. Параметр -y обеспечивает автоматическую установку подтверждающего «yes» на все запросы без участия пользователя.

Перезагрузить систему:

$ reboot

После перезагрузки вы войдёте в полностью обновлённую систему.

Отдельный пользователь и отказ от постоянной работы под root

Для безопасной работы на сервере необходимо полностью отказаться от использования учётной записи root с полными правами суперпользователя Linux, которая включена «по умолчанию». Причин тому несколько.

Приведём некоторые из них:

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

Повышается вероятность возникновения случайных ошибок – неограниченные права это всегда опасно из-за повышенного риска, например, внести «не те» изменения или удалить системный файл.

Поэтому единственно правильным решением будет использование учётной записи пользователя с правами sudo.   

Создать её можно при помощи команды:

$ adduser my_vps

где my_vps – имя нового пользователя.

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

Надёжный пароль можно получить прямо в терминале с помощью следующей команды:

$ openssl rand -base64 32

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

После того, как пользователь будет создан, следует назначить ему администраторские права sudo. Это можно сделать с помощью команды:

$ usermod -aG sudo my_vps

Команда поместит пользователя my_vps в администраторскую группу sudo с назначением ему соответствующих полномочий.

Тут же можно переключиться на созданную учётную запись:

$ su -l my_vps

Если всё сделано правильно, в приглашении терминала появится новое имя.

SSH-ключи, ограничение root-доступа и входа по паролю

Авторизация по SSH-ключу

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

Генерация ключей на локальном устройстве:

$ ssh-keygen -t rsa -b 4096 -C "user commentary"

Здесь параметр -C задаёт комментарий пользователя, который облегчает идентификацию ключей; значение 4096 задаёт длину ключа, выраженную в битах; RSA – тип ключа.

Передача публичного ключа на VPS в автоматическом режиме:

$ ssh-copy-id my_vps@<IP-server>

Здесь IP-serverIPv4 адрес сервера.

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

После того, как ключ скопирован, можно авторизоваться на VPS по SSH-ключу:

$ ssh my_vps@<IP-server>

Если всё в порядке, то вы получите доступ к терминалу VPS.

Установка ограничений

Для того, чтобы полностью исключить попытки входа на сервер по паролю и через учётную запись root-пользователя, необходимо выставить соответствующие ограничения в файле sshd_config на VPS:

$ sudo nano /etc/ssh/sshd_config

PermitRootLogin no        //запрещение root-доступа   PubkeyAuthentication yes  //задаёт принудительную авторизацию по ключуPasswordAuthentication no //запрещает авторизацию по паролюPermitEmptyPasswords no   //запрещает пустые пароли

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

$ sudo systemctl restart sshd

Firewall: какие порты обычно нужны

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

Перед тем, как вносить изменения следует проверить текущий статус и настройки файрвола:

$ sudo ufw status

Приведём пример «включения» самых востребованных портов. Это можно сделать с помощью команд firewall для VPS:  

$ sudo ufw allow 8000/tcp  // открываем порт для веб-приложений

$ sudo ufw allow 80/tcp    // для протокола передачи гипертекста HTTP$ sudo ufw allow 443/tcp   // для защищённого варианта HTTP(S) 

Теперь открываем SSH-порт для IP-адреса нашего локального устройства:

$ sudo ufw allow from <IP> to any port 2223

Здесь мы заменили стандартное значение (22) порта на новое (2223), что согласуется с требованиями безопасности, о чём уже шла речь ранее. 

Когда настройки SSH безопасности завершены, включаем файрвол:

$ sudo ufw enable

Проверяем статус:

$ sudo ufw status verbose

Fail2Ban для защиты от перебора паролей

Утилита Fail2Ban или F2B является мощным средством защиты VPS от внешних угроз на основе использования информации из системных журналов Linux. В частности, она позволяет настроить фильтрацию трафика по ряду параметров – количеству попыток авторизации, IP-адресу и многим другим, что способствует повышению уровня безопасности Linux VPS.

С её помощью также можно настроить автоматическое сканирование неудачных попыток авторизации на сервере с блокированием подозрительных IP. Этому способствует её тесная интеграция с брандмауэром iptables.    

Приведём последовательность действий для возможности использования F2B для защиты сервера от брутфорса.

Устанавливаем программу Fail2Ban на VPS Linux:

$ sudo apt install fail2ban

Запускаем F2B в качестве сервиса:

$ sudo systemctl start fail2ban

Проверяем версию:

 $ sudo fail2ban-client version

Проверяем статус:

$ sudo systemctl status fail2ban

Настраиваем автоматический запуск сервиса после каждой перезагрузки ОС:

$ sudo systemctl enable fail2ban.service

Перезагружаем rsyslog:

$ sudo service rsyslog restart

Создаём локальный файл конфигурации для утилиты или, как говорят, джейл:

$ nano /etc/fail2ban/jail.local
# Fail2Ban LOCAL conf file

[DEFAULT] bantime  = 3h  // задаёт время блокировки IP в часахfindtime = 9m // задаёт интервал времени для фикс неудачных попыток авторизацmaxretry = 5 // устанавливает допустимое кол неудачных попыток авторизации

ignoreip = 127.0.0.1 193.0.205.170 // разрешённые IP для подключения к VPS

 # JAILS [sshd]enabled = true // включаем сервис sshd

Нами были созданы две секции: DEFAULT и sshd, в которых мы ввели нужные значения параметров.

Вносим изменения и сохраняем файл на диске.

Перезапускаем сервис, чтобы изменения вступили в силу:

$ service fail2ban restart

Настройка программы завершена и теперь мы можем быть уверены, что все попытки авторизации будут круглосуточно контролироваться Fail2Ban на VPS, что обеспечит надёжную защиту сервера от брутфорса.

Регулярные обновления и контроль уязвимостей

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

Это же касается обновлений самой операционной системы.

Проверить список доступных обновлений можно с помощью команды:

$ sudo apt list --upgradable 2>/dev/null | wc -l

Для Linux-серверов рекомендовано автоматизировать установку обновлений безопасности. Для систем на основе Debian/Ubuntu это можно реализовать, установив пакет unattended-upgrades на VPS.

Для этого следует выполнить команды:

$ sudo apt install unattended-upgrades$ sudo dpkg-reconfigure -plow unattended-upgrades

Для включения режима автоматической установки обновлений безопасности, следует подтвердить запрос «Automatically download and install stable updates?», появляющийся при установке указанного пакета.

Контроль уязвимостей

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

Проверим состояние наиболее используемых портов VPS с помощью внешнего сканера:

$ nmap -sS -O vps_ip

Проверить все порты можно так:

$ nmap -p- -sV vps_ip

Проверяем настройки SSH:

$ sudo sshd -T | grep -E "port|permitrootlogin|passwordauthentication"

Команда выведет номер используемого порта, а также информацию о том, разрешены ли доступ root по ssh и авторизация по паролю.

Проверяем статус файрвола и активных на данный момент правил:

$ sudo ufw status verbose$ sudo ufw status numbered

Контроль неудачных попыток авторизации за счёт записей в журнале логов:

$ sudo journalctl --since "24 hours ago" | grep "Failed password" | wc -l

Проверяем статус сервиса защиты и его статистику:

$ systemctl status ufw fail2ban$ sudo fail2ban-client status sshd

Выводим список забаненных IP-адресов:

 $ sudo fail2ban-client get sshd banip

Проверяем открытые порты и текущие подключения:

$ sudo ss -tuln | grep LISTEN$ sudo ss -tunap | grep ESTABLISHED

Автоматизируем контроль системы защиты сервера с помощью скрипта.

Создаём файл скрипта:

$ sudo nano /usr/local/bin/control-security.sh:

#!/bin/bash # Проверка неудачных попыток авторизации по SSH за суткиecho "Failed SSH attempts in last 24h:"sudo journalctl --since "24 hours ago" | grep "Failed password" | wc -l # Вывод состояния сервиса защиты echo "Fail2Ban status:"sudo fail2ban-client status sshd # Вывод активных сетевых соединений на SSH-портуecho "Active connections:"ss -tuln | grep :2223 

Сохраняем файл и устанавливаем права на выполнение:

$ sudo chmod +x /usr/local/bin/control-security.sh

Настраиваем каждодневный запуск скрипта:

$ sudo crontab -e0 7 * * * /usr/local/bin/control-security.sh >> /var/log/control-security.log 2>&1

Скрипт будет запускаться ежедневно в 7 часов утра. Результаты его работы будут передаваться в файл логов с именем control-security.log.

Само собой, в скрипт можно добавить и другие команды – всё зависит от целей проекта и предпочтений админа.

Бэкапы перед критичными изменениями

Рекомендуется периодически создавать резервные копии данных своего сервера или делать снапшоты VPS в зависимости от используемого метода резервирования.

Резервирование также должно выполняться перед любым вмешательством в систему:

Механизмов создания бекапов существует очень много. Выделим основные из них:

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

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

FTP-клиенты. Этот способ подходит для более опытных пользователей и позволяет выполнять любые операции с файлами, находящимися на VPS-хостинге.

Плагины для CMS. Дополнительно можно воспользоваться встроенными средствами резервирования при использовании одной из современных систем управления контентом.

Утилиты dd и tar для Linux VPS. Встроенные в ОС утилиты позволяют создавать копии как в ручном режиме, так и по расписанию с помощью планировщика задач Cron.

Приведём примеры практического использования указанных утилит:

$ dd if=/dev/sda of=/mnt/mybackup/sda.img bs=16M conv=sync,noerror

Здесь параметр if задаёт диск для копирования; of – полное имя копии; bs – задаёт размер кэша для ускорения операции; conv – устанавливает режим копирования.

$ tar -cvpzf mybackup.tar.gz --exclude=/mybackup.tar.gz --one-file-system /

Здесь параметр c устанавливает режим создания нового архива; v – детализация операции; p – сохраняет права доступа к объектам файловой системы; z – режим сжатия; f – задаёт полное имя копии; --exclude – задаёт файлы для исключения; --one-file-system – указание на создание копии только одной fs; «/» – задаёт каталог, который копируется.

Логи и минимальный мониторинг

В Linux, как известно, очень развита система журналирования, позволяющая фиксировать все происходящие в системе события. Это позволяет в реальном режиме времени отслеживать любые события, в том числе и неудачные попытки авторизации, которые записываются в файл логов /var/log/auth.log.

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

$ tail -f /var/log/auth.log

Однако таких записей в файле очень много и, поэтому, целесообразно их фильтровать по какому-либо признаку, например, сообщению Failed password (неудачный ввод пароля).

В этом случае команда будет выглядеть так:

$ tail -f /var/log/auth.log | grep "Failed password"

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

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

Внешние средства мониторинга

Существует немало утилит мониторинга состояния системы безопасности Linux VPS, которые желательно периодически использовать. Наиболее известные из них – Lynis, rkhunter и chkrootkit.

Первая из них выполняет комплексный анализ безопасности, показывая потенциально слабые места в системе защиты. Две другие ориентированы на поиск наиболее известных руткитов (вредоносный код), признаков подмены и заражения. Покажем, как с ними работать. 

Обновляем внутренний индекс пакетов:

$ sudo apt update -y

Устанавливаем утилиту rkhunter:

$ sudo apt install rkhunter

Обновляем её базу сигнатур:

$ sudo rkhunter --update

Запускаем процесс сканирования системы:

$ sudo rkhunter --check --skip-keypress

Устанавливаем утилиту chkrootkit:

$ sudo apt install chkrootkit -y

Активируем процесс сканирования:

$ sudo chkrootkit

Когда лучше передать настройку администратору

Управление VPS-сервером можно осуществлять как с помощью панели управления хостингом, так и непосредственно выполнять настройку средствами ОС. Всё зависит от уровня подготовки и личных предпочтений пользователя. Однако в случае, если для проекта критичны такие характеристики сервера, как гибкость и производительность – лучше передать управление высококвалифицированному специалисту. Это повысит эффективность и поможет избежать возможных проблем.