Как защитить VPS-сервер: 8 мер безопасности, которые бизнес откладывает — и зря
Арендованный сервер — не значит защищённый. Провайдер охраняет железо, остальное — ваша задача. Разбираем главные ошибки и как их исправить.
Компания берёт VPS, ставит на него 1С, корпоративную почту или CRM — и считает задачу закрытой. Провайдер надёжный, сервер работает, значит всё хорошо. Это опасное заблуждение.
Провайдер отвечает за работу физического оборудования и изоляцию виртуальных машин. Всё, что происходит внутри вашего сервера — операционная система, приложения, данные — полностью на вашей стороне. Большинство взломов происходят не через дыры в железе, а через незакрытый порт, слабый пароль или давно не обновлённую систему.
1. Замените пароли на SSH-ключи
Брутфорс — самый распространённый способ взлома серверов. Боты непрерывно перебирают пароли на стандартных портах. Парольная аутентификация уязвима по определению: пароли угадывают, перехватывают, утекают из других сервисов.
Переход на SSH-ключи решает проблему радикально. Без приватного ключа, который хранится только у вас, войти на сервер невозможно — даже зная логин и пароль. После настройки ключей отключите парольную аутентификацию в конфигурации SSH.
2. Закройте прямой вход под root
Root — первое, что атакуют. Если злоумышленник получает доступ под root, у него нет никаких ограничений: он может удалить данные, установить вредонос, скопировать всё что угодно.
Создайте отдельного пользователя с правами sudo для повседневных задач. В конфиге SSH (/etc/ssh/sshd_config) установите PermitRootLogin no. Вход под root напрямую станет невозможным.
3. Смените стандартный порт SSH
SSH по умолчанию слушает порт 22. Это знают все, включая автоматизированные сканеры, которые круглосуточно проверяют весь диапазон IP-адресов. Смена порта на нестандартный (например, 2222 или любой выше 1024) не даёт стопроцентной защиты, но убирает 99% автоматических атак и шума в логах.
Если сервер используется только из фиксированных офисных IP — закройте SSH для всех адресов, кроме своих. Это лучшая защита.
4. Настройте файрвол
На свежеустановленном сервере открыты все порты. Веб-сервер, база данных, сервисы мониторинга — всё торчит наружу. Задача файрвола — разрешить только то, что необходимо, и заблокировать всё остальное.
Минимальный принцип: открыт только 80/443 для веба, нужный порт для SSH и ничего лишнего. Порт базы данных (3306 для MySQL, 5432 для PostgreSQL) никогда не должен быть доступен из интернета — только с локального хоста или через VPN.
5. Установите Fail2Ban
Даже с нестандартным портом SSH попытки подбора паролей продолжатся. Fail2Ban отслеживает неудачные попытки входа и автоматически блокирует IP-адреса, с которых идут атаки. После 5–10 неудачных попыток — бан на несколько часов или навсегда.
Настраивается за 15 минут, работает в фоне, существенно снижает нагрузку на сервер и риск взлома методом перебора.
6. Обновляйте систему регулярно
Уязвимости в операционных системах и популярных пакетах публикуются открыто. После публикации патча у злоумышленников есть рабочий эксплойт для тех, кто ещё не обновился. По данным исследований, большинство успешных атак используют уязвимости, для которых патч уже существовал.
Настройте автоматическую установку обновлений безопасности или проверяйте их наличие вручную хотя бы раз в неделю. Для критической инфраструктуры — оповещения о новых CVE для используемого ПО.
7. Сделайте резервные копии внешними
Резервная копия на том же сервере — не резервная копия. При атаке шифровальщика или физическом сбое диска она уничтожается вместе с основными данными. Правило «3-2-1»: три копии, два разных носителя, одна хранится отдельно от инфраструктуры.
Для бизнеса критично: проверяйте восстановление из бэкапа. Обнаружить, что бэкап не восстанавливается, лучше при плановой проверке, а не в момент инцидента.
8. Настройте мониторинг и оповещения
Атака редко происходит мгновенно. Чаще злоумышленник закрепляется в системе, изучает её и действует через некоторое время. Мониторинг логов позволяет обнаружить подозрительную активность до того, как нанесён реальный ущерб.
Минимальный набор: оповещение при нескольких неудачных попытках входа подряд, уведомление о входе с нового IP, контроль изменений в критических системных файлах. Для бизнес-систем — интеграция с SIEM или хотя бы централизованный сбор логов.
Итог
Ни одна из этих мер не требует больших затрат или специальных знаний. Все восемь пунктов закрываются за один рабочий день. Но большинство взломов происходят именно потому, что этого дня никто не выделил.
Если хотите провести аудит текущего состояния серверной инфраструктуры или внедрить системный подход к её защите — свяжитесь с нами. Поможем найти слабые места и устранить их до того, как это сделает кто-то другой.