Приступим к защите
Защита сервера – это не «настроить тысячу правил», а закрыть самые частые дыры: слабые пароли, открытые порты и устаревшее ПО. Большинство взломов происходит именно так – бот сканирует интернет, находит открытый SSH/RDP, перебирает пароли или заходит по утёкшим данным, после чего закрепляется (добавляет ключи, пользователей, задания) и начинает использовать сервер под свои задачи.
Ниже – практические меры, которые дают максимальный эффект при минимальной сложности.
С чего начать: доступ к серверу и учётным данным
Первое, что нужно сделать – защитить доступ к панели управления и к самому серверу. Если в панели доступна двухфакторная аутентификация, включите её. Пароль к панели должен быть уникальным и длинным, хранить его лучше в менеджере паролей.
На сервере ключевая цель – чтобы «подбор пароля» стал бесполезным. Для Linux это означает переход на SSH-ключи и отключение входа по паролю. Для Windows – использование сложного пароля администратора и ограничение RDP, чтобы он не был доступен «всем из интернета».
Пароли: какая длина и формат считаются нормой
Для панели, root/Administrator, баз данных и любых админок рекомендуем:
минимум 16 символов, лучше 20–24+
предпочтительный формат – длинная парольная фраза (4–6 случайных слов + разделители), либо полностью случайная строка из менеджера паролей
уникальный пароль на каждый сервис (не использовать один и тот-же)
если сервис требует «сложности» (буквы/цифры/символы) – добавьте 1–2 символа, но не сокращайте длину
Пример безопасной фразы: Kr0na$7&7@Riv@e#r (пример, не используйте его буквально).
Как правильно настроить SSH на Linux (без усложнений)
Самая надёжная базовая схема такая: вы создаёте отдельного пользователя, входите по SSH-ключу, а административные действия выполняете через sudo. Root-логин напрямую не используете, а вход по паролю отключаете. Тогда даже если кто-то будет круглосуточно «стучаться» в SSH, он упрётся в отсутствие паролей как класса.
Дополнительно имеет смысл ограничить доступ к SSH по вашему IP (например, домашний IP или IP офиса) или подключаться к серверу только через ваш VPN. Это простая мера, которая резко снижает шум в логах и риск атак.
1) Создать пользователя и дать ему sudo
2) Сгенерировать SSH-ключ на своём ПК (рекомендуется ed25519)
3) Скопировать ключ на вашем сервер
4) Отключить вход по паролю и запретить root-логин
Открыть конфиг SSH:
Убедиться, что выставлено:
Перезапустить SSH:
Важно: перед отключением пароля обязательно проверьте, что вход по ключу работает во второй сессии (просто запустите ещё одно подключение к серверу в другом терминале или новом termius).
Закройте лишние порты: почему firewall важнее «умных» настроек
Вторая по важности вещь после ключей – фаервол. Логика простая: наружу должны смотреть только те сервисы, которыми реально пользуются. Если у вас сайт – достаточно 80/443. Если только VPN – только порт VPN. Если ничего не обслуживаете снаружи – закрывайте всё, кроме доступа администратора (SSH/RDP) и то желательно по IP.
Это не про «паранойю» – это про сокращение площади атаки. Чем меньше портов торчит в интернет, тем меньше шансов, что вы вообще попадёте под эксплуатацию уязвимости.
Вариант A – UFW (Ubuntu/Debian)
Поставить и включить:
Открыть SSH только с вашего IP (рекомендуется):
Если нужен сайт:
Включить:
Вариант B – firewalld (AlmaLinux/Rocky/CentOS Stream)
Открыть SSH только с вашего IP:
Открыть web (если нужен):
Обновления безопасности: почему это критично
Даже идеально настроенный доступ не спасает, если на сервере старое ПО с известными уязвимостями. Поэтому сервер должен получать обновления безопасности регулярно. Минимум – обновления ОС и критических пакетов. Если вы используете панели управления, CMS или веб-приложения, они тоже должны обновляться, иначе риск взлома растёт в разы.
Защита от перебора и «шума» в логах
Даже при входе по ключам полезно включить защиту от перебора (например, fail2ban или аналог). Это не «магическая броня», но хорошая гигиена: он автоматически блокирует IP, которые пытаются ломиться в SSH/RDP/веб-авторизацию. В итоге меньше мусора в логах, меньше попыток подобрать что-либо и проще заметить настоящую проблему.
Создать локальный конфиг:
Минимальный пример:
Запуск:
Резервные копии: что делать, если доступ всё же потерян
Бэкапы – это страховка, когда всё остальное не сработало. Важно, чтобы копии хранились не на том же сервере (иначе злоумышленник может удалить их вместе со всем остальным). Нормальная практика – хранить резервные копии отдельно и иногда проверять восстановление, иначе в критический момент окажется, что «бэкап есть, но он не работает».
Минимальный итог: что даёт максимальный эффект
Если сделать только три вещи, выберите эти: вход по ключам и отключение паролей (или жёсткая защита RDP), закрытие лишних портов фаерволом и регулярные обновления безопасности. Это базис, который закрывает самую большую долю реальных атак.
