Новый VPS оказывается под прицелом автоматизированных атак уже через несколько минут после запуска — этот чек-лист проведёт вас через первый час настройки защиты, который позволит серверу остаться действительно вашим.
Каждый новый сервер начинает жизнь с одинаковыми слабыми местами: стандартный вход под root, SSH-доступ только по паролю, полностью открытый файрвол и отсутствие автоматических обновлений. Боты непрерывно сканируют всё пространство IPv4, поэтому фраза «мой IP ещё никто не знает» никогда не соответствует действительности.
Это руководство — упорядоченный чек-лист по настройке защиты, готовый к копированию команд. Пройдите его сверху вниз на новом сервере Debian или Ubuntu — и вы закроете именно те лазейки, которыми реально пользуются злоумышленники, а не те, вокруг которых поднимают шум сторонники показной «безопасности для галочки».
Прежде чем прикасаться к серверу
Два решения, принятые до первого входа на сервер, сэкономят вам часы времени в дальнейшем: подготовьте SSH-ключ и выберите имя пользователя, отличное от root.
- 1
Сгенерируйте современный SSH-ключ
На своей машине выполните ssh-keygen -t ed25519 -C "you@device". Ключи Ed25519 короче, быстрее и надёжнее устаревшего стандарта RSA-2048.
- 2
Никогда не храните приватный ключ на сервере
Приватная часть ключа никогда не покидает ваш ноутбук — на серверы копируется только файл .pub. Нарушение этого правила — самая частая причина, по которой люди сами себя блокируют и вынуждены переустанавливать сервер заново.
- 3
Запишите данные для первого входа
Большинство провайдеров присылают временный пароль root по почте либо встраивают ваш ключ на этапе создания сервера. Если ключ уже встроен, можно сразу переходить к созданию пользователя.
Если ваш провайдер встраивает SSH-ключ уже на этапе развёртывания, окно для входа по паролю не появляется вовсе — самая большая поверхность атаки исчезает ещё до первой загрузки сервера.
Шаг 1 — Обновите всё и поддерживайте актуальность обновлений
Неисправленное ядро или уязвимая версия OpenSSL — это единственная брешь, которую не закроет ни одно правило файрвола. Обновите систему прежде, чем настраивать что-либо ещё.
- Debian/Ubuntu: apt update && apt full-upgrade -y, затем перезагрузите сервер, если обновилось ядро.
- Включите unattended-upgrades, чтобы обновления безопасности устанавливались автоматически: apt install unattended-upgrades && dpkg-reconfigure unattended-upgrades.
- Перезагружайте сервер по контролируемому вами расписанию — задайте Unattended-Upgrade::Automatic-Reboot на спокойный час, вместо того чтобы оставлять обновления ядра наполовину применёнными.
Шаг 2 — Создайте отдельного пользователя и откажитесь от root
Вход под root означает, что одна скомпрометированная сессия отдаёт злоумышленнику всю машину целиком и не оставляет журнала действий. Вместо этого заведите себе именованную учётную запись с правами sudo.
- 1
Добавьте пользователя
adduser deploy, затем usermod -aG sudo deploy (в системах семейства RHEL используйте группу wheel).
- 2
Установите ключ для этого пользователя
Со своего ноутбука выполните: ssh-copy-id deploy@your-server-ip. Эта команда запишет ваш публичный ключ в ~/.ssh/authorized_keys с корректными правами доступа.
- 3
Проверьте доступ, прежде чем закрывать дверь
Откройте второй терминал и убедитесь, что вы можете выполнить ssh deploy@server и sudo -v. Никогда не отключайте root или вход по паролю, пока не убедитесь, что новая сессия работает.
Золотое правило настройки SSH: держите текущую сессию открытой и убедитесь, что новый вход работает во втором окне, прежде чем менять любые настройки аутентификации. Одна эта привычка предотвращает почти все случаи блокировки доступа.
Шаг 3 — Настройка SSH: самая важная часть
SSH — это входная дверь любого VPS, и именно по ней бьёт основная масса автоматизированных попыток входа. Отредактируйте /etc/ssh/sshd_config (или добавьте отдельный файл в /etc/ssh/sshd_config.d/) и задайте следующие параметры.
Примените изменения, сначала проверив синтаксис командой sshd -t, затем выполните systemctl restart ssh. Если sshd -t сообщает об ошибке, исправьте её до перезапуска — иначе демон может не подняться.
Смена порта SSH с 22 на другой — это необязательный шаг, который лишь снижает шум в логах: это «security through obscurity», а не реальная защита. Как только PasswordAuthentication отключён, ботам, сканирующим порты, просто нечего подбирать, поэтому лучше вкладывать усилия в ключи, а не в игры с портами.
Шаг 4 — Включите файрвол с политикой «запрещено по умолчанию»
Даже защищённый демон SSH делит машину со всеми остальными прослушивающими сервисами. Файрвол делает правилом по умолчанию «закрыто, пока я сам это не открыл».
- 1
Задайте базовую политику
В ufw: ufw default deny incoming и ufw default allow outgoing.
- 2
Разрешайте только то, что реально нужно
ufw allow OpenSSH, а также ufw allow 80,443/tcp — но только если этот сервер действительно обслуживает веб-трафик.
- 3
Включите и проверьте
ufw enable, затем ufw status verbose. Всё, что не указано в списке, теперь недоступно из интернета.
Добавьте разрешающее правило для SSH до включения ufw. Если включить файрвол с политикой «запрещено по умолчанию» без разрешающего правила для собственного порта, вы обрубите себе текущую сессию.
Шаг 5 — Замедлите перебор паролей с помощью Fail2ban
Даже при отключённом входе по паролю боты продолжают стучаться и раздувают ваши логи. Fail2ban банит злостных нарушителей на уровне файрвола.
- apt install fail2ban — встроенная тюрьма (jail) для sshd работает сразу же из коробки.
- Скопируйте jail.conf в jail.local и настройте под себя: увеличьте bantime (например, до 1h) и уменьшите maxretry (например, до 3).
- Проверьте работу командой fail2ban-client status sshd, чтобы увидеть количество забаненных IP-адресов.
Шаг 6 — Сократите поверхность атаки
Самый безопасный сервис — тот, который не запущен. Проверьте, что именно слушает порты, и уберите всё лишнее.
Проверьте открытые порты
ss -tulpn выводит список всех прослушивающих сокетов и процессов за ними. Разберитесь с каждым, что вы не запускали намеренно.
Удалите неиспользуемые пакеты
Отключите или удалите сервисы, которыми вы не пользуетесь — работающая без дела база данных или почтовый агент — это чистый риск.
Изолируйте сервисы
Привязывайте внутренние демоны, например базы данных, к 127.0.0.1, чтобы они не оказались доступны извне, даже если файрвол даст сбой.
Закройте лишние права доступа
Убедитесь, что права на ~/.ssh — 700, а на authorized_keys — 600. При неправильных правах sshd молча проигнорирует ваш ключ.
Шаг 7 — Ведите журналы, мониторьте и знайте свою базовую линию
Настройка защиты — это не разовое действие. Вам нужно замечать, когда что-то меняется.
- Просматривайте журнал аутентификации командой journalctl -u ssh или lastb для проверки неудачных попыток входа.
- Рассмотрите использование auditd для защищённого от подделки журнала привилегированных действий.
- Храните резервную копию /etc и ваших данных вне сервера, чтобы скомпрометированную машину можно было пересобрать с нуля, а не доверять ей задним числом.
Где важна сама инфраструктура хостинга
Настройка защиты на уровне ПО охраняет операционную систему, но именно провайдер определяет, что находится уровнем ниже — фильтрацию трафика, платёжный след и то, привязывается ли вообще личность к серверу. В ChainVPS каждый тариф включает фильтрацию от DDoS и безлимитный трафик, а оплата серверов производится с предоплаченного крипто-баланса в 21 монете, включая Monero, без KYC. Если ваша модель угроз предполагает, что сервер не должен быть привязан к вашей личности, наши offshore-тарифы VPS созданы именно для этого.
Расположение сервера — тоже часть защиты: шесть из наших пятнадцати регионов относятся к юрисдикциям privacy-уровня (NL, CH, RO, IS, MD, LU). Сочетание защищённой ОС с offshore-выделенным сервером держит закрытой как программную, так и юридическую поверхность.
Сжатый чек-лист на один час
- Полное обновление системы + включены автоматические патчи безопасности
- Создан именованный пользователь с sudo, установлен ключ, вход проверен
- Отключены вход root по SSH и аутентификация по паролю
- Конфигурация SSH проверена командой sshd -t и перезагружена
- Активен файрвол с политикой «запрещено по умолчанию», открыты только нужные порты
- Запущен Fail2ban для тюрьмы (jail) sshd
- Проверены открытые порты, удалены неиспользуемые сервисы
- Настроены резервное копирование вне сервера и проверка логов
Стоит ли менять порт SSH с 22 на другой?
Это необязательно и лишь снижает шум в логах, но не реальный риск. Когда аутентификация по паролю отключена и требуются ключи, смена порта добавляет лишь «security through obscurity», а не настоящую защиту — в первую очередь стоит отключить пароли.
Безопасно ли отключать аутентификацию по паролю, если у меня всего один ключ?
Да, при условии что вы протестировали вход по ключу в отдельной сессии и храните резервную копию приватного ключа. Многие провайдеры также предлагают веб-консоль или режим восстановления, так что вы никогда по-настоящему не потеряете доступ к оборудованию.
Нужен ли файрвол, если SSH — единственный сервис?
Да. Файрвол с политикой «запрещено по умолчанию» защищает вас от сервисов, о которых вы забыли, что установили, а также от всего, что в будущем незаметно начнёт слушать порты после установки какого-нибудь пакета. Это ничего не стоит и закрывает неприятные сюрпризы.
Как часто нужно пересматривать настройки защиты?
Автоматические обновления безопасности выполняют повседневную работу, но проверяйте прослушиваемые порты и логи аутентификации после установки любого крупного ПО и как минимум раз в месяц. Относитесь к защищённой базовой конфигурации как к тому, что нужно регулярно проверять, а не настроить один раз и забыть.
