1. Обновляйте программное обеспечение своевременно

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

Что делать:

• Для Debian/Ubuntu: apt update && apt upgrade -y — запускайте минимум раз в месяц.
• Критические патчи безопасности (помечены CVE) устанавливайте немедленно после выхода.
• Включите автоматические обновления безопасности: apt install unattended-upgrades и настройте /etc/apt/apt.conf.d/50unattended-upgrades.
• Для CentOS/AlmaLinux: yum update -y или dnf update -y.
• Следите за обновлениями CMS (WordPress, Joomla, Drupal) и плагинов — они обновляются независимо от системы.
• Регулярно проверяйте CVE Details или подпишитесь на рассылку уязвимостей используемого ПО.

Важно: рекомендация «обновляться раз в 6 месяцев» устарела. Современные атаки эксплуатируют уязвимости в течение нескольких дней после публикации CVE. Обновляйтесь регулярно.

2. Защитите SSH-доступ

SSH — основной способ управления сервером и главная цель брутфорс-атак. По умолчанию он открыт на порту 22 и принимает парольную аутентификацию — это опасно.

Что сделать сразу после получения сервера:

• Создайте нового пользователя с sudo-правами, отключите вход от root напрямую (PermitRootLogin no в /etc/ssh/sshd_config).
• Включите аутентификацию по SSH-ключу, отключите парольный вход (PasswordAuthentication no).
• Смените стандартный порт 22 на нестандартный (например, 2222) — снизит количество автоматизированных атак.
• Установите Fail2ban: автоматически блокирует IP после нескольких неудачных попыток входа.
  apt install fail2ban
• Используйте AllowUsers в sshd_config, чтобы разрешить SSH только конкретным пользователям.

3. Настройте файрвол и закройте лишние порты

Открытые порты — это открытые двери. Если сервис не нужен снаружи, его порт должен быть закрыт.

• Установите и настройте UFW (Debian/Ubuntu): ufw allow 80/tcp && ufw allow 443/tcp && ufw allow 2222/tcp && ufw enable
• Закройте порты MySQL (3306), Redis (6379), MongoDB (27017) от внешнего доступа — они должны быть доступны только локально (bind-address = 127.0.0.1).
• Регулярно проверяйте открытые порты: ss -tlnp или netstat -tlnp.
• Используйте nmap со стороннего сервера для аудита открытых портов вашего VDS.

4. Не делайте резервные копии на тот же VDS

Это одна из самых распространённых ошибок. Бекап на том же сервере не защищает от трёх реальных сценариев:

• Диск заполнен: системные процессы (MySQL, Nginx, syslog) начинают повреждать файлы при записи — VDS перестаёт работать.
• Взлом или шифровальщик: злоумышленник получает доступ ко всему, включая ваши бекапы.
• Физическая поломка узла: теряются и данные, и резервные копии одновременно.

Правило 3-2-1: 3 копии данных, на 2 разных носителях, 1 из которых — удалённый. Используйте внешний FTP, S3-совместимое хранилище или выделенный бекап-сервер.

5. Используйте SSL/TLS-сертификаты на всех сервисах

• Все сайты должны работать по HTTPS. Используйте бесплатные сертификаты Let's Encrypt (certbot).
• Следите за сроком действия сертификатов — настройте автопродление через certbot renew в cron.
• Отключите устаревшие протоколы SSLv3, TLS 1.0 и TLS 1.1 в конфигурации Nginx/Apache.
• Регулярно проверяйте конфигурацию TLS: SSL Labs Test.

6. Следите за паролями и правами доступа

• Никогда не используйте одинаковые пароли для разных сервисов (SSH, панель, база данных, FTP).
• Для баз данных создавайте отдельных пользователей с минимальными правами — не используйте root-пользователя MySQL для приложений.
• Удаляйте временных пользователей и тестовые учётные записи сразу после использования.
• Проверяйте файлы /etc/passwd и /etc/sudoers на наличие посторонних пользователей.

7. Мониторинг и логи

• Следите за системными логами: /var/log/auth.log (попытки входа), /var/log/syslog, логи Nginx/Apache.
• Настройте уведомления о нештатных ситуациях — высокая нагрузка на CPU, нехватка места на диске, перезапуск сервисов.
• Используйте logwatch или GoAccess для анализа логов веб-сервера.
• Регулярно проверяйте место на диске: df -h — диск не должен быть заполнен более чем на 80%.

8. Не экспериментируйте на рабочем сервере

Если вы не уверены в последствиях команды или изменения конфигурации — не делайте это на продакшн-сервере. Ошибка в iptables, nginx.conf или fstab может заблокировать доступ к серверу или уничтожить данные.

• Тестируйте изменения на отдельном VDS или в staging-окружении.
• Делайте снапшот через Virtualizor перед крупными изменениями.
• Если не знаете как сделать — напишите в нашу поддержку. Мы поможем.