Как защитить новый VPS: первые десять минут

Новый сервер наиболее уязвим в тот момент, когда получает IP-адрес. Автоматические сканеры непрерывно прочёсывают всё пространство IPv4, поэтому первые попытки входа на сервер, развёрнутый минуту назад, обычно приходят раньше, чем вы дочитаете приветственное сообщение. Это не направлено лично против вас — это фоновое излучение интернета, и именно поэтому незащищённый сервер с паролем на root оказывается взломан за часы, а не за месяцы. Хорошая новость в том, что закрыть эти дыры — дело недолгое: десять минут последовательных действий убирают практически весь оппортунистический риск. В этом руководстве — тот самый чек-лист, порядок действий, который не даст вам случайно заблокировать себе доступ, и ещё один момент, о котором почти никто не пишет: личные данные, которые конфигурация по умолчанию незаметно записывает на машину, арендованную специально для того, чтобы её с вами не связывали.

Что даёт защита сервера — и от чего она не спасает

Защищать сервер стоит именно потому, что польза от этого узкая, но настоящая. Чёткое понимание границ убережёт вас от ложного чувства безопасности там, где эти меры не работают.

• Credential-stuffing-боты, перебор паролей по SSH и сканирование открытых админ-панелей бессильны против входа только по ключу и файрвола с запретом по умолчанию.
• Ограничивает масштаб ущерба, если в чём-то из запущенного находится изъян. Сервис, привязанный к localhost за закрытым портом, недоступен постороннему даже в день публикации его CVE.
• Снижает цену ошибки. Непривилегированные пользователи, отдельные ключи и автоматические патчи означают, что одно неудачное решение не отдаёт всю машину целиком.
• Не прячет сервер от вашего хостера. Любой, у кого есть доступ к гипервизору, в принципе может прочитать память работающей машины — вопрос в том, у кого вы арендуете, а не в правилах вашего файрвола.
• Не делает вас анонимным. Харденинг защищает саму машину; а вот привязана ли эта машина к вашему имени, решается при регистрации и оплате — задолго до первого входа.

Именно это последнее различие чаще всего путают местами. Идеально защищённый сервер, купленный по кредитной карте на ваше настоящее имя, — всё равно сервер на ваше настоящее имя. Эти два уровня дополняют друг друга: хостинг без KYC и баланс, пополненный криптовалютой, решают, кому машина принадлежит по документам, а следующие десять минут решают, кто может в неё попасть.

Порядок действий, который не даст вам заблокировать самого себя

Почти все страшные истории о харденинге — это одна и та же история: кто-то отключил вход по паролю, не убедившись, что ключ действительно работает, или включил файрвол, в правилах которого не было SSH, — и остался снаружи машины, до которой больше не может достучаться. Порядок действий ниже существует именно для того, чтобы это стало невозможным. Сначала установите ключ и убедитесь, что он работает, во втором окне. Только потом отключайте пароли. Добавляйте правило файрвола для SSH до включения файрвола — никогда не после.

Стоит также заранее знать свой путь восстановления, пока он ещё не понадобился. У VPS, до которого можно достучаться только по SSH, ровно одна дверь, поэтому консоль в панели управления хостера — это запасной вариант, который превращает блокировку в лёгкое неудобство, а не в пересоздание сервера с нуля. Проверьте, что можете открыть её, пока всё ещё работает как надо.

Шаг за шагом: первые десять минут на новом сервере

1. 01Обновите индекс пакетов и сами пакетыСвежий образ — это снимок системы на момент его сборки. Актуализировать его — самое полезное действие из всего списка, и занимает оно меньше минуты.
2. 02Создайте непривилегированного пользователя с sudoПостоянная работа от root означает, что любая опечатка и любой процесс выполняются с полными правами. Создайте обычного пользователя, добавьте его в группу sudo или wheel и работайте под ним.
3. 03Скопируйте свой публичный ключ этому пользователюЕсли ключа ed25519 ещё нет, сгенерируйте его на своей машине, затем передайте публичную половину через ssh-copy-id. Приватный ключ никогда не покидает ваш ноутбук.
4. 04Откройте второй терминал и убедитесь, что вход по ключу работаетНе пропускайте этот шаг. Войдите новым пользователем по ключу в новом окне, прежде чем менять что-либо в настройках аутентификации.
5. 05Отключите вход по паролю и вход под rootУстановите PasswordAuthentication no и PermitRootLogin prohibit-password, затем перезагрузите sshd. Перебору паролей против этой машины больше нечего угадывать.
6. 06Включите файрвол с запретом по умолчанию и разрешённым SSHЗапретите весь входящий трафик, разрешите свой порт SSH, затем включите файрвол. Порты для собственных сервисов добавляйте потом, по одному.
7. 07Включите автоматические обновления безопасностиunattended-upgrades на Debian и Ubuntu, dnf-automatic в семействе RHEL. Именно это защищает машину на шестой месяц, когда вы уже перестали за ней следить.
8. 08Проверьте, что слушает порты, и закройте лишнееОдна команда ss -tulpn покажет все открытые сокеты. Всё, что вы не открывали осознанно, нужно убрать или привязать к localhost.

SSH: только ключи и настройки, которые реально важны

Аутентификация по ключу — это и есть вся суть харденинга SSH. Как только пароли отключены, злоумышленнику нужен приватный ключ, которого у него нет, а никаким перебором его не получить. Генерируйте ключи ed25519 — они короткие, быстрые и являются современным стандартом по умолчанию — и защитите ключ парольной фразой, чтобы украденный ноутбук не означал украденный сервер. Всё остальное в sshd_config — лишь доработка поверх этого единственного решения.

• PasswordAuthentication no — настройка, которая раз и навсегда останавливает перебор паролей. Сначала убедитесь, что ключ работает, во второй сессии.
• PermitRootLogin prohibit-password — root всё ещё можно восстановить по ключу, но никогда по паролю. Поставьте no, как только убедитесь, что ваш sudo-пользователь работает.
• AllowUsers или AllowGroups — явный список тех, кому вообще разрешён вход, чтобы служебная учётная запись, созданная каким-нибудь пакетом, никогда не могла стать точкой входа по SSH.
• KbdInteractiveAuthentication no — закрывает ещё один интерактивный путь, который в некоторых дистрибутивах может незаметно вернуть запрос пароля.
• Отдельный ключ для отдельного устройства — вместо того, чтобы копировать один и тот же приватный ключ повсюду. Потеря телефона должна означать удаление одной строки из authorized_keys, а не замену всего и сразу.
• Перенос SSH с порта 22 резко сокращает объём логов, но это снижение шума, а не мера безопасности — для того, кто действительно целится в ваш IP, это ничего не меняет.

Если хочется пойти дальше одних только ключей, самый надёжный вариант — вообще не открывать SSH наружу: спрятать машину за туннелем WireGuard и закрыть в файрволе порт 22 так, чтобы он принимал соединения только с адреса туннеля. Тогда ваш SSH-демон становится тем, чего интернет попросту не видит, — а это надёжнее, чем самая тщательная настройка того же демона, если он открыт наружу.

Файрвол: запрет по умолчанию, затем — только то, что реально используется

Файрвол имеет смысл только тогда, когда по умолчанию он отказывает. Разрешать всё и затем блокировать заведомо плохие порты — это подход задом наперёд: вы защищаете сервисы, о которых вспомнили, и оставляете открытыми те, о которых забыли. Запретите весь входящий трафик, разрешите исходящий, а затем открывайте отдельные порты по мере развёртывания того, что их использует. Современный Linux использует под капотом nftables, а ufw или firewalld — вполне достойные интерфейсы поверх него: инструмент здесь куда менее важен, чем настройка по умолчанию.

• Разрешите SSH прежде, чем включать файрвол, а не после. Это второй по популярности способ заблокировать себе доступ.
• Открывайте только те порты, которые сервису действительно нужны снаружи. Веб-серверу нужны 80 и 443; базе данных почти никогда не нужно ничего.
• Привязывайте локальные сервисы к 127.0.0.1, а не к 0.0.0.0. Закрытый порт и сервис, который никогда не слушает публично, — это две независимые защиты, и нужны обе.
• Пишите правила для IPv6 так же, как и для IPv4. Набор правил, покрывающий только v4 на машине с двумя стеками, оставляет тот же сервис нараспашку на её v6-адресе.
• Где возможно, ограничивайте порты управления по адресу источника. Если администрирование всегда идёт с одной точки VPN, так и укажите в правиле.
• Перечитывайте правила после добавления каждого сервиса. Порты, открытые для того, что вы давно удалили, — это то самое тихое накопление, которое сводит на нет чистое начало.

Некоторые нагрузки переворачивают эту логику и намеренно нуждаются в широко открытом порте — узел Tor обязан принимать соединения откуда угодно, а полный узел Bitcoin обслуживает пиров только тогда, когда доступен порт 8333. И это нормально. Правило не «не открывать ничего», а «открывать осознанно», а сервис, задуманный как публичный, — это осознанный выбор.

fail2ban, и почему он значит меньше, чем кажется

fail2ban следит за логами и банит адреса, которые многократно проваливают аутентификацию. Он по-настоящему полезен, но стоит честно понимать, что именно он делает, когда вход по паролю уже отключён: в этот момент угадать пароль уже ни у кого не получится, так что fail2ban больше не предотвращает взлом. Что он предотвращает — так это тысячи бессмысленных строк в логах каждый день, расход CPU на эти попытки подключения и риск того, что реальное событие затеряется в шуме, который вы перестали читать ещё несколько месяцев назад.

И всё равно это стоит десяти секунд настройки — а по-настоящему защитным он становится в тот момент, когда вы запускаете что-то, действительно принимающее пароль: форму входа веб-приложения, почтовый сервер, панель управления. Направьте его на эти логи, а не только на sshd. Задайте окно бана в часах, а не в минутах, и добавьте собственный адрес в игнор-лист, чтобы опечатка в пароле не заблокировала вас на вашей же машине.

Обновления, о которых не нужно помнить самому

Реалистичная угроза для правильно настроенного сервера — не в том, что кто-то взломает ваши SSH-ключи. Она в уязвимости, опубликованной для чего-то, что вы установили и забыли, которую сканер эксплуатирует через три дня, пока вы заняты другими делами. Ответ на это — автоматические обновления безопасности: на Debian и Ubuntu это unattended-upgrades, настроенный на установку обновлений именно из security-репозитория; на Fedora, Rocky или Alma — dnf-automatic. Включите это в первые десять минут — и машина будет сама себя патчить ещё долго после того, как ваше внимание переключится на что-то другое.

Обновления ядра и libc — исключение, где без вас всё же не обойтись: они вступают в силу только после перезагрузки, поэтому сервер, который не перезагружался четыреста дней, почти наверняка работает на коде, пропатченном на диске ещё год назад. needrestart в Debian покажет, какие сервисы работают со старыми, уже удалёнными библиотеками, а плановое окно перезагрузки — пусть даже раз в месяц — это разница между установленными патчами и применёнными. Всё, что вы запускаете, в любом случае должно переживать неожиданную перезагрузку; если нет — это отдельная проблема, которую стоит решить.

Утечки личности, которые упускает чек-лист по харденингу

Этот раздел важен, если вы намеренно выбрали офшорный хостинг без KYC. Обычное руководство по харденингу написано для корпоративного сервера, чей владелец и так всем известен, поэтому оно никогда не задаётся вопросом, что о вас записывает конфигурация по умолчанию. А на машине, арендованной анонимно, часть этих настроек по умолчанию незаметно возвращает на неё ваше имя.

• Ваш публичный SSH-ключ несёт в себе комментарий — по умолчанию это ваше локальное имя пользователя и hostname ноутбука, что-то вроде alex@alex-macbook, — и этот комментарий дословно сохраняется в authorized_keys на сервере. Задайте его флагом -C при генерации ключа или отредактируйте строку уже после копирования.
• Hostname, который вы задаёте серверу, попадает в логи, в заголовки писем, в вывод систем мониторинга, а иногда и в баннеры сервисов. Обезличенный hostname не выдаёт ничего; а вот ваше имя или название вашей компании — выдаёт.
• Часовой пояс системы. Облачные образы по умолчанию используют UTC, а это никому ничего не сообщает. Если выставить свой локальный часовой пояс, круг возможных мест вашего нахождения сужается, а метки времени в каждом логе после этого подтверждают ваши рабочие часы.
• Конфигурация Git, скопированная на сервер, — она несёт имя и email, под которыми вы делаете коммиты. То же касается файлов истории шелла, dotfiles, синхронизированных с вашей рабочей машины, и любых учётных данных, закешированных во время поспешного теста.
• Email, который вы отдаёте Let's Encrypt при выпуске сертификата, — он становится частью публичной записи об этом сертификате. Используйте адрес, никак не связанный с вашей личностью.
• Баннеры версий веб-сервера и заголовки X-Powered-By, а также любая аналитика, сборщик крашей или агент мониторинга от вендора, который отправляет данные домой с прикреплённым идентификатором аккаунта.

Эти уровни стоит держать раздельно и не путать. Харденинг не пускает посторонних на машину. Эти детали не дают машине рассказать о вас тому, кто на неё уже смотрит. А уровень оплаты решает, было ли вообще какое-то имя, которое можно найти, — этот вопрос честно разобран в материале о том, действительно ли покупка VPS за Bitcoin анонимна, а тема развита в материале про пополнение через Monero. По отдельности каждый уровень уязвим; вместе они держат оборону.

Резервные копии: то, что харденинг не сделает за вас

Ни одно правило файрвола не защищает от удалённой базы данных, отказавшего диска или изменения конфигурации, которое в момент внесения казалось разумным. Резервные копии — единственная мера, которая спасает вас от ваших же собственных ошибок, а это статистически самый вероятный способ потерять данные на хорошо защищённой машине. Шифруйте их до того, как они покинут сервер, храните хотя бы одну копию там, куда сам сервер дотянуться не может, и настройте их создание по расписанию, а не по мере того, как вы вспомните.

Последний пункт важнее, чем звучит: резервная копия, которую сервер может перезаписать сам, — это копия, которую уничтожит всё, что имеет на сервере root. Отправка зашифрованных архивов на отдельный сервер хранения — или их выгрузка оттуда, чтобы учётные данные жили вне резервируемой машины, — даёт вам копию, которая переживёт саму машину. И хотя бы раз сделайте восстановление намеренно, пока всё в порядке. Непроверенная резервная копия — это гипотеза, а не страховка.

Ошибки, которые незаметно сводят всю работу на нет

• Отключить вход по паролю, не проверив ключ, — и обнаружить ошибку уже с ноутбука, который больше не может войти.
• Включить файрвол раньше, чем разрешить SSH, — та же самая блокировка, только с другой стороны.
• Написать правила только для IPv4, оставив каждый сервис доступным по IPv6-адресу машины.
• Тщательно защитить сервер в первый день, а затем поставить панель управления, базу данных и стек мониторинга, каждый из которых без спроса открывает собственный порт.
• Запускать всё от root, потому что так на одну команду sudo меньше, — из-за этого первый же изъян в чём угодно оборачивается полной компрометацией.
• Считать fail2ban заменой ключам — из-за этого игра в угадывание пароля продолжается, просто медленнее.
• Считать, что арендованный сервер можно скрыть от хостера шифрованием диска, — полное шифрование диска защищает украденный накопитель, а не работающую машину.
• Никогда не перезагружать сервер, из-за чего месяцы установленных патчей ядра лежат на диске, пока продолжает работать старое ядро.

Ничего из этого не сложно и не занимает много времени. Делайте по порядку, подтверждайте каждый шаг из второго терминала, прежде чем двигаться дальше, — и машина, развёрнутая несколько минут назад, перестанет быть находкой для любого, кто прочёсывает адресное пространство. А дальше разворачивайте то, ради чего вы на самом деле сюда пришли, — сайт, узел, туннель, приватный эндпоинт модели — на основе, которую вы полностью понимаете.