
Иногда после запуска VDS/VPS проходит всего несколько минут, как в логах появляются десятки попыток входа или перебора паролей. В этом случае на защиту провайдера надеяться нельзя, потому что он отвечает только за изоляцию гипервизора, а всё, что происходит внутри гостевой ОС, — это ваша зона ответственности. Под катом собрал десять базовых правил по безопасности VDS, но лучше всего они работают в связке.
1. Ставим пароли, а лучше SSH-ключи

Главное правило защиты — это аутентификация. Слабые пароли вроде «admin123» — вкусный подарок для ботов и скрипт-кидди, которые перебирают комбинации тысячами в секунду. Если уж используете пароль, то он должен быть действительно крепким: не меньше 12 символов, с разным регистром, цифрами и спецзнаками.
Однако гораздо надёжнее подключаться по SSH-ключу — это связка публичного (на сервере) и приватного (на ПК пользователя) ключей. Взломать или угадать его практически невозможно, и в отличие от пароля его перебор просто не сработает.
Кроме того, в SSH весь трафик шифруется, поэтому перед хакерами появляется ещё один слой защиты. О том, как сгенерировать ключ через PuTTY, можно прочитать тут.
Стоит помнить и о базовой гигиене. Не используйте один и тот же пароль для разных систем и сервисов. А если в панели есть двухфакторка, её лучше подключить сразу.
2. Отказываемся от root по SSH

На Linux чаще всего пытаются взломать root. У учётки нет каких-то ограничений, поэтому боты в первую очередь подбирают пароль именно от неё. Решение тут простое — не давать им такой возможности.
Создайте отдельного пользователя для администрирования и выдайте ему права через sudo, а после запретите вход под root по SSH. Сделать это можно в конфиге /etc/ssh/sshd_config. Для этого в строке PermitRootLogin поменяйте значение на «no».
Только не забудьте сначала завести нового пользователя с нужными правами, иначе потом будут трудности со входом. Но если так уже случилось, есть запасной вариант — подключение к root с консоли.
После такой настройки логин под root будет заблокирован, а значит, лишний канал атаки для злоумышленников просто исчезнет.
3. Меняем стандартный SSH-порт и сужаем IP-доступ

Каждый день тысячи сканеров прощупывают порты в надежде найти уязвимый сервер. К слову, почти любой бот начинает атаку с привычного 22-го. Чтобы усложнить им задачу, нужно просто вынести SSH на другой порт (например, из диапазона 49152–65535). После смены не забудьте открыть порт в файерволе и прописать -p ключ в клиенте SSH.
Следующий уровень защиты — ограничение доступа только для своих IP-адресов. Обычно это делается через правила iptables или ufw. В этом случае вы разрешаете только конкретные подключения, например, только из офиса или только из дома. Все остальные адреса режутся.
В целом на сервере должны быть открыты только те порты, которые реально нужны для работы. Остальные нужно закрыть без сожаления.
4. Настраиваем файрвол и закрываем ненужные порты

Здесь работает золотое правило: «Что не разрешено — то запрещено». На практике это значит, что в файрволе должны быть открыты только те порты, которые реально нужны сервисам.
Однако начинать нужно не с настройки, а с уборки. Удалите все ненужные вам службы и демоны, чтобы они не занимали порты. Проверить активные помогут команды netstat -ntulp и ss -ntulp. Всё лишнее смело убирайте через iptables, ufw или другой инструмент.
Также хорошая практика — не держать на VDS ничего, что может стать точкой риска. Лишние CMS-плагины, утилиты и модули могут выступить дырами для взлома, поэтому чем меньше на сервере ненужного кода, тем выше его надёжность.
После можно перейти к настройке файрвола. У большинства провайдеров уже имеется свой фильтр трафика, но на уровне операционки стоит всё равно задействовать iptables, nftables, firewalld или хотя бы ufw. Тут сначала нужно задать правило DROP для всех входящих TCP/UDP-соединений, а затем вручную разрешить только нужные IP и порты.
В результате, даже если мошенник угадает ваш новый SSH-порт, без доступа из разрешённого списка подключиться он не сможет.
5. Устанавливаем Fail2Ban или аналог

Следующий уровень безопасности — защита от брутфорс-атак. Для этого лучше всего использовать Fail2Ban (устанавливается через пакетный менеджер). Он следит за логами аутентификации и автоматом блокирует айпишники, с которых пытаются угадать пароль.
На машинах с Windows этой утилиты нет. В этом случае для её установки нужно использовать WSL2 (работа демонов тут не всегда стабильна) или выбрать аналоги. Например, подойдут F2B или Fail2Ban4Win.
Отмечу, после установки Fail2Ban настойку лучше делать в отдельном файле jail.local (обычно находится в /etc/fail2ban/). Там включаются нужные правила — как минимум стоит активировать защиту для sshd.
6. Своевременно обновляемся

«Свежий» VDS важно держать в актуальном состоянии с первого дня. Любое ПО (ядро, пакеты, сервисы) имеет уязвимости, поэтому разработчики регулярно выпускают патчи при их обнаружении. Чем новее версия, тем сложнее злоумышленнику эксплуатировать баг.
Чтобы каждый раз не проверять всё руками, обновления лучше автоматизировать. Например, cron-задачу, которая раз в сутки обновляет сигнатуры антивируса или проверяет список пакетов. Однако инструменты тут не так важны, как дисциплина.
7. Удаляем ненужное ПО

В связи с предыдущим пунктом, не устанавливайте всё подряд. Каждый лишний сервис или библиотека — потенциальная дверь для взлома. Если вы, скажем, не используете почтовый сервер или языковой интерпретатор Perl (а только Nginx+PHP+MySQL), не устанавливайте их вообще.
Кроме того, если на VDS уже есть куча предустановленных программ и расширений, оставьте только то, что действительно требуется. Лишние службы также лучше отключить, а порты на них вовсе закрыть.
8. Регулярно создаём резервные копии

Надёжная стратегия бэкапов — не столько прямая мера защиты, сколько подстраховка на случай взлома или других бед. В идеале подключить автоматические бэкапы (раз в сутки). Для этого можно использовать конфигурации rsync, скрипты на cron, или сервисы хостинга.
Кстати, многие провайдеры автоматически делают снимки или бэкапы файлов VDS (примерно раз в неделю), но рассчитывать только на них рискованно. Лучше всего дублировать базы и файлы и на удалённом хранилище (облако или другой сервер) и стационарно, на своём ПК.
9. Шифруем каналы и данные

Шифровать данные нужно вообще на всех уровнях, где это можно сделать. Начнём с очевидного: старый FTP использовать нельзя — он очень легко перехватывается из-за того, что передаёт всё в открытом виде. Вместо него лучше выбрать SFTP (по SSH) или FTPS. Оба варианта шифруют и сами файлы, и учётки.
Если на сервере опубликованы сайты или API, сразу включайте HTTPS/SSL, даже для внутренних сервисов. TLS не только шифрует данные, но и защищает от подмены контента — это критично для панелей управления и админок.
Для особенно чувствительной информации можно дополнительно зашифровать каталоги или целые диски через LUKS.
10. Мониторим систему и логи

Наконец, постоянно следите за состоянием VDS. Поставьте себе привычку хотя бы раз в неделю просматривать логи — там хранятся записи об авторизациях, ошибках сервисов, сетевых событиях. Это поможет вовремя заметить подозрительные попытки (многочисленные неудачные логины, странные запросы и т.п.).
На уровне панели/крона можно настроить оповещения (например, почтовые уведомления о фатальных ошибках или выходе из строя сервисов). В продакшене часто настраивают инструменты вроде Zabbix, Prometheus+Alertmanager или простые Logwatch, которые раз в день присылают краткий отчёт о логах.
В крайнем случае можно просто запускать tail -f /var/log/auth.log или dmesg для того, чтобы хотя бы визуально отслеживать, нет ли постоянного потока ошибок.
Резюмирую
Все эти правила безопасности VDS — это не набор «фишек для параноиков», а ваша уверенность в сохранности ваших данных. SSH-ключи, запрет root-доступа, закрытые порты, свежие пакеты, резервные копии и мониторинг логов не требуют сверхусилий, но именно они определяют, будет ли ваш сервер тихо работать годами или превратится в лёгкую цель для злоумышленников.
Делитесь своими правилами и лайфхаками по безопасности VDS в комментариях.
© 2025 ООО «МТ ФИНАНС»
dburmistrov
Вот, все знают про
/etc/ssh/sshd_config
, но мало кто вспоминает про/etc/ssh/sshd_config.d
. А как раз туда-то хостер и может напихать всякого.nevergotoro
Вот-вот. Например там может храниться правило PermitRootLogin и вы будете долго не понимать почему рут все ещё может авторизоваться даже после запрета в основном файле.