Чек-лист безопасности VPS
В работе с VPS есть одна неприятная особенность: пока всё работает, о нём не думают. Но как только что-то ломается, то начинается паника. Причём ломается обычно не само по себе. В 2026 году атаки стали тише, дольше и гораздо скучнее на первый взгляд. Сейчас никто уже не «ломает сайт» в лоб. Чаще просто находят слабое место и сидят там неделями.
Если пропустили эту эволюцию атак, можно глянуть статью Как изменились кибератаки и почему хостинг теперь в зоне риска — там хорошо разобрана сама логика изменений. А здесь будет практическая часть, без философии, просто чек-лист, который можно открыть и пройтись по своему серверу проверив его базовую безопасность.
И да, часть пунктов покажется вам банальной, но вот обычно именно их и пропускают, после чего долго восстанавливают свой сайт из бекапа… если он сохранился.
1. Базовая защита доступа
Первое, с чего ломают VPS — это доступ. Не контейнеры, не приложения, а старый добрый SSH.
Если у вас всё ещё открыт стандартный порт 22 и разрешён вход по паролю — сервер уже в зоне риска, так как брутфорс из сети идёт постоянно. Не иногда, а прямо всегда.
Что делаем:
— меняем порт SSH (не спасает полностью, но убирает шум);
— отключаем вход по паролю (`PasswordAuthentication no`);
— оставляем только ключи;
— запрещаем root-доступ (`PermitRootLogin no`);
— ограничиваем доступ по IP, если есть такая возможность;
Мелочь, но работает. Большинство массовых атак отваливаются уже на этом этапе.
Отдельно стоит упомянуть настройку fail2ban. Его ставят многие, но редко настраивают нормально. Так что озаботьтесь и этим, банить стоит агрессивно, так как нет смысла быть вежливым к сканерам.
2. Обновления системы и пакетов
Удивительно, сколько серверов живут годами без обновлений. Потом появляется эксплойт под старую версию OpenSSL или ядра — и всё, приплыли.
Автообновления, конечно, достаточно спорная тема, так как иногда ломают зависимости. Но критические патчи безопасности игнорировать просто нельзя.
Необходимый минимум:
— регулярный `apt update && apt upgrade`;
— включённые security-репозитории;
— отслеживание CVE для ключевых сервисов (nginx, openssh, docker).
Ну а если вы используете Kubernetes или Docker, то следить надо и за базовыми образами. Старый образ = старая уязвимость внутри контейнера.
3. Настройка файервола
Сервер без файервола — это как квартира без двери. Формально жить можно, но вопрос в том — как долго, до того момента пока вас не вынесут ночью прямо с вашей кроватью.
Выбирайте что использовать, UFW или iptables, тут не принципиально. Главное, чтобы было правило: открыто только то, что нужно и только тому, кому можно.
Пример базовой логики:
— разрешить SSH (лучше с ограничением по IP);
— открыть HTTP/HTTPS;
— закрыть всё остальное.
И всё. Никаких там «на всякий случай оставлю порт открытым». Эти ваши «на всякий случай» потом благополучно находят боты.
Ну а если сервер используется под специфические задачи (например, база данных), тогда доступ к портам должен быть разрешен только из внутренней сети.
4. Изоляция сервисов
Многие до сих пор ставят всё в одну систему и nginx и базу и backend и Redis в добавок. Да, это конечно будет работать, но пока не появляется уязвимость в одном из сервисов.
Контейнеризация, конечно, решает часть проблем, а Docker или Kubernetes дают некую изоляцию, но не магическую защиту.
Поэтому важно:
— не запускать контейнеры от root;
— использовать отдельные сети;
— ограничивать доступ между сервисами;
— не хранить секреты внутри образов.
Ну и вообще, даже внутри VPS не должно быть ощущения одной большой системы, лучше дробите. Так меньше шансов, что вашу систему ломанут всю сразу.
5. Контроль логов и мониторинг
Вот тут начинается скучная часть, которую наиболее часто игнорируют.
Но послушайте, логи — это единственный способ понять, что происходит у вас на сервере. Если вы не смотрите логи, вы не знаете, взломали сервер или нет.
Что стоит отслеживать:
— попытки входа по SSH;
— ошибки веб-сервера;
— неожиданные рестарты сервисов;
— рост нагрузки без причины.
Как минимум стоит настроить централизованный сбор логов. Даже обычный `rsyslog` с отправкой на отдельный сервер уже даёт больше контроля и возможность анализировать логи централизованно.
Лучше, конечно, Prometheus + Grafana, но это уже следующий уровень, да и не каждому это нужно.
6. Резервное копирование
Бэкапы. Ох, больная тема. Ну большая часть моих коллег попадались на том, что система «прилегла», по той или иной причине, а бекапы… лежали на том-же сервере.
Причём важен не сам факт наличия бэкапа, а возможность его быстро восстановить.
Поэтому вот что стоит проверять:
— бэкапы делаются регулярно;
— они хранятся вне VPS;
— восстановление реально работает (да, блин, это нужно тестировать);
Классическая ситуация, когда бэкап есть, но восстановить нельзя. То ли формат не тот, то ли архив битый, то ли доступ потерян. Всякое бывает.
7. Защита веб-приложений
Если VPS используется под сайт или API, то тогда основная атака может идти через приложение, а не через SSH. В таком случае частыми становятся такие типичные проблемы:
— устаревшие CMS (WordPress, Joomla);
— открытые админки;
— слабые пароли пользователей;
— отсутствие rate limiting.
Поэтому минимальный набор того, что нужно сделать в первую очередь выглядит как-то так:
— обновления CMS и плагинов;
— защита админки (IP whitelist или хотя бы нестандартный URL);
— WAF (Cloudflare или аналог);
— HTTPS везде.
Даже простой reverse proxy с фильтрацией уже снижает количество мусора, иногда на порядки.
8. Работа с пользователями и правами
На сервере часто создают пользователей «на всякий случай» или для тестов, а потом благополучно забывают их удалить. У кого-то остаётся доступ через SSH, у кого-то даже sudo.
Это надо чистить, безоговорочно. Что делать:
— регулярно мониторить и удалять неиспользуемые аккаунты;
— ограничивать sudo;
— не использовать один и тот же ключ для всех (прикиньте, и такое встречается).
И да, один разработчик равно один доступ, так как иначе, в случае какой-то проблемы, потом невозможно понять, кто что сделал.
9. Сетевые атаки и DDoS
VPS сам по себе редко выдерживает серьёзный DDoS, да он и не должен этого делать. Тут нужна защита на уровне провайдера или внешнего сервиса.
Но базовые меры, которые можно принять, всё равно есть:
— rate limiting на nginx;
— ограничение соединений;
— использование CDN (тот-же банальный CloudFlare)
И ещё один важный момент, что часто DDoS выглядит как просто выросла нагрузка. И без мониторинга это сложно отличить от реального роста трафика. Поэтому мониторинг и ещё раз мониторинг.
Вывод
Итак, безопасность VPS — это не одна волшебная кнопка «сделать очень секурно». Это привычка, это процесс, это набор действий, которые должны повторяться с определенной периодичностью.
Самое неприятное, что большинство проблем не выглядят как атака, ведь сервер продолжает работать. Да, чуть медленнее, иногда падает, где-то появляются странные процессы. Вот это и есть современный сценарий компрометации системы.
Простой чек-лист приведенный выше, конечно, не сделает ваш сервер неуязвимым, да мы такой цели и не ставили. Но он убирает самые очевидные дыры, которые по статистике чаще всего приводят к взлому. Ну а дальше уже вопрос дисциплины и дополнительных изысканий, в зависимости от серьезности и важности вашего сервиса.
Всем удачи и берегите свои серверы.
Если пропустили эту эволюцию атак, можно глянуть статью Как изменились кибератаки и почему хостинг теперь в зоне риска — там хорошо разобрана сама логика изменений. А здесь будет практическая часть, без философии, просто чек-лист, который можно открыть и пройтись по своему серверу проверив его базовую безопасность.
И да, часть пунктов покажется вам банальной, но вот обычно именно их и пропускают, после чего долго восстанавливают свой сайт из бекапа… если он сохранился.
1. Базовая защита доступа
Первое, с чего ломают VPS — это доступ. Не контейнеры, не приложения, а старый добрый SSH.
Если у вас всё ещё открыт стандартный порт 22 и разрешён вход по паролю — сервер уже в зоне риска, так как брутфорс из сети идёт постоянно. Не иногда, а прямо всегда.
Что делаем:
— меняем порт SSH (не спасает полностью, но убирает шум);
— отключаем вход по паролю (`PasswordAuthentication no`);
— оставляем только ключи;
— запрещаем root-доступ (`PermitRootLogin no`);
— ограничиваем доступ по IP, если есть такая возможность;
Мелочь, но работает. Большинство массовых атак отваливаются уже на этом этапе.
Отдельно стоит упомянуть настройку fail2ban. Его ставят многие, но редко настраивают нормально. Так что озаботьтесь и этим, банить стоит агрессивно, так как нет смысла быть вежливым к сканерам.
2. Обновления системы и пакетов
Удивительно, сколько серверов живут годами без обновлений. Потом появляется эксплойт под старую версию OpenSSL или ядра — и всё, приплыли.
Автообновления, конечно, достаточно спорная тема, так как иногда ломают зависимости. Но критические патчи безопасности игнорировать просто нельзя.
Необходимый минимум:
— регулярный `apt update && apt upgrade`;
— включённые security-репозитории;
— отслеживание CVE для ключевых сервисов (nginx, openssh, docker).
Ну а если вы используете Kubernetes или Docker, то следить надо и за базовыми образами. Старый образ = старая уязвимость внутри контейнера.
3. Настройка файервола
Сервер без файервола — это как квартира без двери. Формально жить можно, но вопрос в том — как долго, до того момента пока вас не вынесут ночью прямо с вашей кроватью.
Выбирайте что использовать, UFW или iptables, тут не принципиально. Главное, чтобы было правило: открыто только то, что нужно и только тому, кому можно.
Пример базовой логики:
— разрешить SSH (лучше с ограничением по IP);
— открыть HTTP/HTTPS;
— закрыть всё остальное.
И всё. Никаких там «на всякий случай оставлю порт открытым». Эти ваши «на всякий случай» потом благополучно находят боты.
Ну а если сервер используется под специфические задачи (например, база данных), тогда доступ к портам должен быть разрешен только из внутренней сети.
4. Изоляция сервисов
Многие до сих пор ставят всё в одну систему и nginx и базу и backend и Redis в добавок. Да, это конечно будет работать, но пока не появляется уязвимость в одном из сервисов.
Контейнеризация, конечно, решает часть проблем, а Docker или Kubernetes дают некую изоляцию, но не магическую защиту.
Поэтому важно:
— не запускать контейнеры от root;
— использовать отдельные сети;
— ограничивать доступ между сервисами;
— не хранить секреты внутри образов.
Ну и вообще, даже внутри VPS не должно быть ощущения одной большой системы, лучше дробите. Так меньше шансов, что вашу систему ломанут всю сразу.
5. Контроль логов и мониторинг
Вот тут начинается скучная часть, которую наиболее часто игнорируют.
Но послушайте, логи — это единственный способ понять, что происходит у вас на сервере. Если вы не смотрите логи, вы не знаете, взломали сервер или нет.
Что стоит отслеживать:
— попытки входа по SSH;
— ошибки веб-сервера;
— неожиданные рестарты сервисов;
— рост нагрузки без причины.
Как минимум стоит настроить централизованный сбор логов. Даже обычный `rsyslog` с отправкой на отдельный сервер уже даёт больше контроля и возможность анализировать логи централизованно.
Лучше, конечно, Prometheus + Grafana, но это уже следующий уровень, да и не каждому это нужно.
6. Резервное копирование
Бэкапы. Ох, больная тема. Ну большая часть моих коллег попадались на том, что система «прилегла», по той или иной причине, а бекапы… лежали на том-же сервере.
Причём важен не сам факт наличия бэкапа, а возможность его быстро восстановить.
Поэтому вот что стоит проверять:
— бэкапы делаются регулярно;
— они хранятся вне VPS;
— восстановление реально работает (да, блин, это нужно тестировать);
Классическая ситуация, когда бэкап есть, но восстановить нельзя. То ли формат не тот, то ли архив битый, то ли доступ потерян. Всякое бывает.
7. Защита веб-приложений
Если VPS используется под сайт или API, то тогда основная атака может идти через приложение, а не через SSH. В таком случае частыми становятся такие типичные проблемы:
— устаревшие CMS (WordPress, Joomla);
— открытые админки;
— слабые пароли пользователей;
— отсутствие rate limiting.
Поэтому минимальный набор того, что нужно сделать в первую очередь выглядит как-то так:
— обновления CMS и плагинов;
— защита админки (IP whitelist или хотя бы нестандартный URL);
— WAF (Cloudflare или аналог);
— HTTPS везде.
Даже простой reverse proxy с фильтрацией уже снижает количество мусора, иногда на порядки.
8. Работа с пользователями и правами
На сервере часто создают пользователей «на всякий случай» или для тестов, а потом благополучно забывают их удалить. У кого-то остаётся доступ через SSH, у кого-то даже sudo.
Это надо чистить, безоговорочно. Что делать:
— регулярно мониторить и удалять неиспользуемые аккаунты;
— ограничивать sudo;
— не использовать один и тот же ключ для всех (прикиньте, и такое встречается).
И да, один разработчик равно один доступ, так как иначе, в случае какой-то проблемы, потом невозможно понять, кто что сделал.
9. Сетевые атаки и DDoS
VPS сам по себе редко выдерживает серьёзный DDoS, да он и не должен этого делать. Тут нужна защита на уровне провайдера или внешнего сервиса.
Но базовые меры, которые можно принять, всё равно есть:
— rate limiting на nginx;
— ограничение соединений;
— использование CDN (тот-же банальный CloudFlare)
И ещё один важный момент, что часто DDoS выглядит как просто выросла нагрузка. И без мониторинга это сложно отличить от реального роста трафика. Поэтому мониторинг и ещё раз мониторинг.
Вывод
Итак, безопасность VPS — это не одна волшебная кнопка «сделать очень секурно». Это привычка, это процесс, это набор действий, которые должны повторяться с определенной периодичностью.
Самое неприятное, что большинство проблем не выглядят как атака, ведь сервер продолжает работать. Да, чуть медленнее, иногда падает, где-то появляются странные процессы. Вот это и есть современный сценарий компрометации системы.
Простой чек-лист приведенный выше, конечно, не сделает ваш сервер неуязвимым, да мы такой цели и не ставили. Но он убирает самые очевидные дыры, которые по статистике чаще всего приводят к взлому. Ну а дальше уже вопрос дисциплины и дополнительных изысканий, в зависимости от серьезности и важности вашего сервиса.
Всем удачи и берегите свои серверы.
