Как защитить VPS после развёртывания

Краткий ответ: как защитить VPS

Чтобы защитить VPS после развертывания, обновите операционную систему, создайте отдельную учетную запись администратора, настройте аутентификацию по SSH-ключам, ограничьте доступ root и включите межсетевой экран, разрешающий только необходимый сетевой трафик. Также следует удалить ненужные службы, настроить защиту от вторжений, обезопасить приложения и базы данных, включить HTTPS, организовать мониторинг и создавать изолированные резервные копии. Регулярные проверки безопасности и тестирование восстановления помогают поддерживать защиту сервера на протяжении всего срока его эксплуатации.

Обновите операционную систему и установите последние доступные исправления безопасности.
Создайте отдельную учетную запись администратора и применяйте принцип минимальных привилегий.
Настройте аутентификацию по SSH-ключам и ограничьте удаленный административный доступ.
Включите межсетевой экран и разрешите только порты, необходимые для работы приложений.
Удалите ненужное программное обеспечение, службы, пакеты и учетные записи.
Настройте обнаружение и предотвращение вторжений, например Fail2ban, если это необходимо.
Защитите веб-приложения, базы данных, API-эндпоинты и секреты приложений.
Включите HTTPS, используйте действительные TLS-сертификаты и защитите конфигурацию домена и DNS.
Настройте мониторинг системы, централизованное хранение журналов, оповещения и аудит безопасности.
Создавайте изолированные резервные копии и регулярно проверяйте процесс восстановления.
Документируйте настройки безопасности и пересматривайте их при каждом изменении конфигурации сервера.

Содержание

Понимание рисков безопасности VPS
Первичная оценка безопасности
Обновление операционной системы
Защита учетных записей и привилегий
Усиление безопасности SSH
Настройка межсетевого экрана
Отключение ненужных служб и портов
Настройка защиты от вторжений с помощью Fail2ban
Защита приложений и баз данных
Настройка HTTPS и TLS
Обнаружение подозрительной активности и вредоносного ПО
Защита Windows VPS
Настройка безопасного резервного копирования
Мониторинг активности и производительности сервера
Защита VPS от DDoS-атак
Автоматизация обслуживания безопасности
Чек-лист безопасности VPS
Распространенные ошибки при защите VPS
Часто задаваемые вопросы
Заключение

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

Защита VPS требует многоуровневого подхода. Усиление безопасности операционной системы сокращает количество потенциальных точек входа, контроль доступа ограничивает возможности пользователей и приложений, фильтрация сетевого трафика блокирует нежелательные подключения, а мониторинг помогает обнаруживать подозрительную активность. Резервное копирование и процедуры восстановления снижают последствия инцидентов, которые невозможно полностью предотвратить.

В этом руководстве описано, как защитить VPS после развертывания с помощью практических примеров настройки. Инструкции для Linux в первую очередь предназначены для Ubuntu Server и дистрибутивов на базе Debian. Рекомендации для Windows приведены отдельно. Команды и конфигурационные файлы могут различаться в зависимости от версии операционной системы, поэтому перед применением изменений на рабочем сервере проверьте доступные параметры.

1. Понимание рисков безопасности VPS

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

К наиболее распространенным рискам относятся:

Атаки методом перебора: автоматизированные попытки подобрать пароли SSH, RDP, панели управления или приложений.
Неисправленные уязвимости: устаревшие операционные системы, библиотеки, плагины и серверные приложения с известными недостатками безопасности.
Открытые службы: общедоступные базы данных, административные интерфейсы, инструменты разработки и неиспользуемые сетевые порты.
Повышение привилегий: уязвимости или ошибки конфигурации, позволяющие злоумышленнику с ограниченным доступом получить расширенные права.
Компрометация учетных данных: украденные SSH-ключи, повторно используемые пароли, утекшие API-токены и учетные данные в исходном коде.
Атаки на веб-приложения: эксплуатация небезопасной аутентификации, уязвимостей внедрения кода, механизмов загрузки файлов и уязвимых зависимостей.
Потеря данных: случайное удаление, программы-вымогатели, сбои оборудования или хранилища и разрушительные действия администратора.
Атаки типа «отказ в обслуживании»: вредоносный трафик, потребляющий доступную пропускную способность сети, ресурсы CPU, память или вычислительные ресурсы приложения.

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

2. Проведите первичную оценку безопасности

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

В Ubuntu или Debian выполните следующие команды:

cat /etc/os-release
hostnamectl
uptime
ip -br address
ip route
ss -tulpn
systemctl --type=service --state=running
df -h
free -h

Эти команды выводят информацию об операционной системе, сетевой конфигурации, прослушиваемых TCP- и UDP-сокетах, работающих службах, использовании диска и памяти. Для просмотра некоторых сведений могут потребоваться права администратора.

Затем определите, какие порты должны быть доступны из интернета. Например, типичному публичному веб-серверу могут потребоваться порты 80 и 443, а для администрирования — SSH. Остальные порты следует ограничить, если архитектура приложения не требует иного.

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

Задокументируйте текущую конфигурацию до внесения изменений. Это упростит выявление неожиданного поведения и восстановление подключения, если правило безопасности или настройки службы вызовут проблемы.

3. Обновите операционную систему

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

В Ubuntu или Debian обновите индексы пакетов и установите доступные обновления:

sudo apt update
sudo apt upgrade

Перед подтверждением операции проверьте список изменений, особенно на производственных системах. Более широкая команда apt full-upgrade может устанавливать или удалять пакеты для разрешения зависимостей, поэтому используйте ее только после проверки предлагаемых изменений.

sudo apt full-upgrade

После обновления проверьте, требуется ли перезагрузка:

if [ -f /var/run/reboot-required ]; then
  echo "A reboot is required"
fi

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

Включите автоматическую установку обновлений безопасности

Автоматическая установка обновлений безопасности помогает сократить время между выпуском исправления и его применением. В Ubuntu для автоматизации подходящих обновлений можно использовать пакет unattended-upgrades.

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

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

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

4. Защитите учетные записи и привилегии

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

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

sudo adduser sysadmin
sudo usermod -aG sudo sysadmin

Замените sysadmin на нужное имя пользователя. Членство в группе sudo предоставляет административные возможности, поэтому не добавляйте в нее пользователей, которым такие права не нужны.

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

Применяйте принцип минимальных привилегий

Используйте индивидуальные учетные записи вместо общих административных учетных данных.
Удаляйте ненужные учетные записи, предварительно убедившись, что они не принадлежат необходимым процессам и файлам.
Ограничивайте доступ к конфиденциальным каталогам, конфигурационным файлам, журналам и резервным копиям.
Запускайте приложения от имени выделенных служебных учетных записей, а не root.
Регулярно проверяйте разрешения sudo и другие расширенные привилегии.
Используйте многофакторную аутентификацию для панелей управления и поддерживающих ее административных служб.

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

5. Усильте защиту SSH

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

Настройте аутентификацию по SSH-ключам

Создайте пару SSH-ключей на доверенном локальном компьютере, а не на VPS:

ssh-keygen -t ed25519 -C "[email protected]"

Защитите закрытый ключ парольной фразой и храните его в безопасном месте. На сервер следует устанавливать только открытый ключ.

Если в данный момент для SSH используется аутентификация по паролю, скопируйте открытый ключ с помощью команды:

ssh-copy-id sysadmin@SERVER_IP

Замените SERVER_IP IP-адресом сервера и укажите соответствующее имя административной учетной записи. Если ssh-copy-id недоступна, установите открытый ключ через инструменты управления хостинг-провайдера или добавьте его в файл ~/.ssh/authorized_keys пользователя, установив правильного владельца и права доступа.

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

Отключите прямой вход root и аутентификацию по паролю

После подтверждения того, что административная учетная запись может подключаться по SSH-ключу, проверьте конфигурацию SSH-сервера. Во многих системах Ubuntu и Debian соответствующий файл находится по пути /etc/ssh/sshd_config. На фактические настройки также могут влиять подключаемые конфигурационные файлы.

Укажите следующие директивы в соответствующем разделе конфигурации:

PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
AllowUsers sysadmin

Директива AllowUsers необязательна. Если вы используете ее, добавьте всех пользователей, которым действительно требуется доступ по SSH. Отключение аутентификации по паролю и через интерактивные запросы может нарушить работу некоторых схем входа, поэтому убедитесь, что выбранный метод аутентификации по ключу будет работать с итоговой конфигурацией.

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

sudo sshd -t
sudo sshd -T | grep -E 'permitrootlogin|pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication'

Если проверка синтаксиса прошла успешно, перезагрузите конфигурацию соответствующей службы SSH. В Ubuntu и Debian служба обычно называется ssh, хотя в некоторых дистрибутивах используется имя sshd.

sudo systemctl reload ssh

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

Ограничьте сетевой доступ к SSH

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

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

6. Настройте межсетевой экран

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

В Ubuntu для управления правилами межсетевого экрана на уровне хоста можно использовать UFW.

Настройка UFW в Ubuntu

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

sudo ufw allow OpenSSH
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable
sudo ufw status verbose

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

Для общедоступного сайта разрешите HTTP и HTTPS, если они необходимы:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw status numbered

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

Ограничьте доступ к административным интерфейсам и портам баз данных

Базы данных, внутренние API, интерфейсы мониторинга и панели управления, как правило, не должны быть доступны всему интернету. Предпочтительно использовать частную сеть, VPN, промежуточный сервер для административного доступа или явные ограничения по IP-адресам источников.

Например, чтобы разрешить SSH только с доверенного IPv4-адреса, после проверки адреса и существующей политики межсетевого экрана используйте правило:

sudo ufw allow from 203.0.113.10 to any port 22 proto tcp

Указанный IP-адрес относится к диапазону, предназначенному для примеров в документации, и должен быть заменен фактическим доверенным адресом. Если вы используете правило с ограничением по источнику, проверьте и удалите более широкое правило SSH, которое может свести это ограничение на нет.

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

7. Отключите ненужные службы и порты

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

Выведите список прослушиваемых сокетов:

sudo ss -tulpn

Посмотрите активные службы:

systemctl --type=service --state=running

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

Если подтверждено, что служба не нужна, остановите ее и отключите автоматический запуск:

sudo systemctl disable --now SERVICE_NAME

Замените SERVICE_NAME проверенным именем службы. После каждого изменения тестируйте сервер, чтобы убедиться, что критически важные функции не нарушены.

Проверьте распространенные источники повышенного риска:

Службы баз данных, доступные через публичные сетевые интерфейсы.
Серверы разработки и конечные точки отладки.
Неиспользуемые FTP-службы и другие устаревшие средства передачи файлов.
Незащищенные административные панели.
API управления контейнерами, открытые без надлежащей аутентификации.
Тестовые приложения, временные службы и заброшенное программное обеспечение.

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

8. Настройте защиту от вторжений с помощью Fail2ban

Fail2ban анализирует поддерживаемые журналы на предмет повторяющихся подозрительных попыток аутентификации и может временно блокировать IP-адреса с помощью соответствующих правил межсетевого экрана. Инструмент полезен для ограничения повторных попыток подбора пароля, но не заменяет надежную аутентификацию и ограничения сетевого доступа.

В Ubuntu или Debian установите пакет:

sudo apt update
sudo apt install fail2ban
sudo systemctl enable --now fail2ban
sudo systemctl status fail2ban

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

sudo nano /etc/fail2ban/jail.local

Базовая конфигурация для SSH может выглядеть так:

[DEFAULT]
bantime = 10m
findtime = 10m
maxretry = 5

[sshd]
enabled = true

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

Проверьте конфигурацию и состояние SSH-фильтра:

sudo fail2ban-client -t
sudo systemctl restart fail2ban
sudo fail2ban-client status
sudo fail2ban-client status sshd

Убедитесь, что установленная версия Fail2ban использует ожидаемый источник журналов SSH и соответствующий механизм блокировки. Системам с другой конфигурацией журналирования или другим межсетевым экраном могут потребоваться дополнительные настройки.

Будьте осторожны при проверке блокировок на рабочем сервере. Не допускайте блокировки собственного административного адреса и убедитесь, что у вас есть альтернативный способ восстановления доступа. Fail2ban — вспомогательный инструмент, а не полноценная система обнаружения вторжений.

9. Защитите приложения и базы данных

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

Защитите зависимости приложений

Обновляйте фреймворки, библиотеки, CMS, плагины и темы.
Удаляйте неиспользуемые зависимости и инструменты разработки из производственной среды.
Используйте поддерживаемые версии программного обеспечения и отслеживайте рекомендации по безопасности.
Запускайте приложения от имени отдельных непривилегированных учетных записей.
Проверяйте пользовательский ввод и обеспечивайте безопасную аутентификацию, управление сессиями и разграничение прав.
Ограничивайте загрузку файлов и предотвращайте выполнение загруженного содержимого в качестве кода.

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

Защитите базы данных

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

Для службы базы данных убедитесь, что:

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

Защитите секреты и конфигурационные файлы

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

Проверьте владельцев и права доступа к конфиденциальным файлам Linux. Например, файл окружения приложения, содержащий учетные данные, не должен быть доступен для чтения всем локальным пользователям. Установите права с учетом учетной записи службы и модели развертывания приложения.

Если есть вероятность раскрытия учетных данных, смените их. Простое удаление секрета из последней версии репозитория не удаляет его из истории репозитория и не устраняет последствия предыдущей утечки.

10. Настройте HTTPS и TLS

Если на VPS размещены общедоступный сайт, API или веб-приложение, HTTPS защищает данные при передаче и помогает предотвращать перехват и изменение информации между клиентом и сервером.

Чтобы настроить HTTPS:

Направьте соответствующие DNS-записи на нужный сервер или обратный прокси-сервер.
Установите и настройте веб-сервер или шлюз приложений.
Получите доверенный TLS-сертификат для необходимых доменных имен.
Настройте сервер на использование сертификата и соответствующего закрытого ключа.
При необходимости настройте перенаправление HTTP на HTTPS.
Автоматизируйте продление сертификатов и отслеживайте сроки их действия.
Убедитесь, что приложение не передает конфиденциальные данные по незашифрованным соединениям.

Для Nginx в Ubuntu можно использовать Certbot с совместимым центром сертификации и поддерживаемым способом установки. Следуйте инструкциям, соответствующим вашей операционной системе и конфигурации развертывания.

sudo nginx -t
sudo systemctl reload nginx

Эти команды проверяют конфигурацию Nginx и перечитывают ее после успешной проверки. Сами по себе они не получают и не устанавливают сертификат.

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

HTTPS не заменяет безопасность приложения. По-прежнему необходимы аутентификация, контроль доступа, проверка входных данных, безопасные cookie и правильное управление сессиями.

11. Обнаруживайте подозрительную активность и вредоносное ПО

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

Проверяйте журналы аутентификации и системы

В Ubuntu или Debian изучите недавние события аутентификации и системные ошибки:

sudo journalctl -p warning --since "24 hours ago"
sudo journalctl -u ssh --since "24 hours ago"
sudo last
sudo lastb

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

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

Проверяйте процессы и сетевые соединения

ps aux --sort=-%cpu | head -n 15
sudo ss -tpn
systemctl --failed
sudo journalctl -p err -b

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

Используйте сканирование на вредоносное ПО при необходимости

Такие инструменты, как ClamAV, могут проверять файлы на наличие известных сигнатур вредоносного ПО. Утилиты обнаружения руткитов и системы контроля целостности файлов предоставляют дополнительные данные, но их результаты требуют интерпретации и не доказывают, что система полностью безопасна.

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

12. Защитите Windows VPS

Защита Windows VPS основана на тех же общих принципах, что и усиление безопасности Linux, однако административные инструменты и механизмы настройки отличаются.

Установите обновления Windows

Устанавливайте обновления безопасности и качества для поддерживаемых версий Windows Server через Windows Update или утвержденную корпоративную систему управления обновлениями. При необходимости планируйте перезагрузки и после них проверяйте работоспособность критически важных приложений.

Защитите удаленный рабочий стол

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

Ограничьте RDP доверенными IP-адресами, VPN или подходящим шлюзом удаленных рабочих столов.
Используйте надежные уникальные учетные данные и многофакторную аутентификацию, если она поддерживается.
Включите проверку подлинности на уровне сети (Network Level Authentication), если она совместима с вашей средой.
Ограничьте членство в группах удаленного доступа и администраторов.
Отслеживайте события аутентификации и расследуйте неожиданные попытки входа.
Отключите RDP, если он не нужен, предварительно убедившись в наличии другого способа административного доступа.

Настройте брандмауэр Защитника Windows

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

Защитите учетные записи и службы

Используйте отдельные административные учетные записи, минимальные привилегии, Microsoft Defender или другое поддерживаемое решение защиты конечных устройств, а также централизованное журналирование событий, если оно доступно. Удаляйте неиспользуемые роли и приложения, защищайте административные операции PowerShell и не допускайте компрометации учетных данных для резервного копирования.

Также проверьте требования к лицензированию и поддержке используемой версии Windows Server и работающих на VPS приложений.

13. Настройте безопасное резервное копирование

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

Используйте стратегию резервного копирования с учетом целевой точки восстановления (RPO), определяющей допустимый объем потери данных, и целевого времени восстановления (RTO), определяющего требуемое время возврата сервиса к работе.

Следуйте принципу резервного копирования 3-2-1

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

Создавайте резервные копии всех данных, необходимых для восстановления сервиса:

Файлов приложений и загруженного контента.
Баз данных с использованием процедур резервного копирования, обеспечивающих согласованность данных приложения.
Конфигурационных файлов операционной системы и приложений.
Манифестов развертывания и конфигурации инфраструктуры.
Сертификатов и необходимой информации для восстановления при условии безопасного хранения.
Важной документации и инструкций по восстановлению.

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

Проверяйте процедуры восстановления

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

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

14. Мониторьте активность и производительность сервера

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

Как минимум следует отслеживать:

Загрузку CPU и средние значения нагрузки.
Использование памяти и активность swap.
Заполнение дисков, задержки хранилища и ошибки файловой системы.
Сетевой трафик, количество соединений и неожиданную исходящую активность.
Доступность служб и время отклика приложений.
События аутентификации, действия с повышенными привилегиями и изменения правил межсетевого экрана.
Результаты резервного копирования, состояние хранения копий и результаты тестов восстановления.
Срок действия TLS-сертификатов и изменения конфигурации домена.

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

uptime
free -h
df -h
systemctl --failed
ss -tulpn
journalctl -p err -b

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

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

15. Защитите VPS от DDoS-атак

Распределенные атаки типа «отказ в обслуживании» (DDoS) направлены на перегрузку сетевой пропускной способности или ресурсов приложения вредоносным трафиком. Межсетевой экран на уровне хоста может блокировать часть нежелательных соединений, но не способен самостоятельно поглотить трафик, который уже полностью занимает сетевой канал сервера.

Выбирайте меры защиты с учетом типа рабочей нагрузки и потенциального масштаба атаки:

Фильтрация на сетевом уровне: используйте фильтрацию со стороны провайдера, чтобы блокировать нежелательный трафик до его поступления на VPS.
Обратные прокси и CDN: направляйте поддерживаемый веб-трафик через сервис, предоставляющий фильтрацию, кеширование и защиту на уровне приложений.
Ограничение частоты запросов: ограничивайте повторные запросы к точкам аутентификации и ресурсоемким операциям приложения.
Контроль ресурсов: настраивайте разумные ограничения количества соединений, времени ожидания запросов и числа рабочих процессов приложения.
Мониторинг: создавайте оповещения о необычном объеме трафика, частоте соединений, задержках и исчерпании ресурсов.
План реагирования: документируйте порядок обращения к хостинг-провайдеру и включения дополнительных мер защиты во время атаки.

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

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

16. Автоматизируйте обслуживание безопасности

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

Рассмотрите возможность автоматизации следующих процессов:

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

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

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