Защита нового VPS в первый час

Посмотрите на journalctl -u ssh на сервере, который был онлайн всего час, — объём записей пугает при первом взгляде. Пугаться не стоит. Перед вами фоновое излучение интернета: горстка сканирующих операций — часть научных, часть коммерческих, часть криминальных — которые непрерывно перебирают всё пространство IPv4 и передают результаты ботам, подбирающим учётные данные. До вашего адреса добрались потому, что он существует, по порядку номеров, и до него доберутся снова через несколько часов, что бы вы ни делали.

Это полезным образом меняет форму задачи. Вы защищаетесь не от противника, который выбрал именно вас и будет подстраиваться, а от скрипта с фиксированным набором приёмов: root, admin, ubuntu, test, git, oracle, postgres и двадцать тысяч паролей, засветившихся в утечках. У него нет ни терпения, ни изобретательности, ни интереса к машине, которая не ответила с первой попытки. Отключение парольной аутентификации не замедляет этого противника — оно убирает его с доски полностью.

Стоит знать две детали. Во-первых, IPv6 значительно тише, потому что /64 нельзя просканировать целиком, — но в тот момент, когда ваша AAAA-запись становится публичной или адрес машины попадает в заголовок письма или в лог certificate-transparency, тишина заканчивается. Никогда не считайте IPv6 укрытием — считайте его просто меньшим стогом сена. Во-вторых, у IPv4-адреса есть прошлое. До вас у него был другой арендатор, и если тот плохо администрировал почтовый сервер или хостил что-то, что попало в чёрные списки, вы наследуете эту репутацию, пока она не сойдёт на нет. Если почта для вас важна, проверьте адрес по обычным блок-листам, прежде чем строить на нём что-либо, — это пятиминутная проверка, которая экономит две недели разбирательств с доставляемостью писем.

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

Причина здесь структурная, а не статистическая. Обе меры закрыты по умолчанию — они безопасно отказывают. sshd, принимающий только ключи, невозможно взломать перебором, сколько бы попыток ни пришло, потому что в коде просто нет пути, принимающего пароль. Файрвол с политикой default-deny защищает и те службы, которые вы ещё не установили, — включая базу данных, которую вы добавите через три месяца и забудете привязать к localhost. Всё остальное в чек-листе по харденингу — это перечисление конкретных плохих вещей, список того, что нужно отключить, а такой список хорош ровно настолько, насколько он полон.

Так что если вы читаете только один раздел и закрываете вкладку — читайте этот, выполните шаги со 2 по 5 ниже и считайте час потраченным не зря. Всё остальное по-настоящему полезно, но по-настоящему второстепенно.

На Debian 13 и Ubuntu 24.04 файл /etc/ssh/sshd_config начинается со строки Include /etc/ssh/sshd_config.d/*.conf, а облачные образы кладут в этот каталог файл — обычно 50-cloud-init.conf — который уже задаёт PasswordAuthentication. Редактировать основной файл и дописывать свои директивы в конец кажется естественным, но в результате получается конфиг, который делает не то, что в нём написано.

Правило, которое удивляет в sshd почти всех: для каждого ключевого слова побеждает первое полученное значение. Это противоположность тому, как работает почти любая другая система слияния конфигов, с которой вы имели дело. Строка Include находится в самом начале основного файла, поэтому drop-in читается раньше тела sshd_config — а среди самих drop-in-файлов решает алфавитный порядок. Файл 10-hardening.conf побеждает 50-cloud-init.conf. Файл 60-hardening.conf, наоборот, тихо проигрывает ему, и вы не узнаете об этом из перезапуска, который бодро отрапортует об успехе.

Именно поэтому никогда не верьте файлу, который только что написали. Спросите у самого демона, что он на самом деле прочитал:

sshd -t                 # syntax check — silence means valid
sshd -T | grep -Ei '^(permitrootlogin|passwordauthentication|pubkeyauthentication|kbdinteractive|allowusers|port) '

sshd -T выводит итоговую конфигурацию уже после того, как учтены все include, все переопределения и все значения по умолчанию. Если в этом выводе значится passwordauthentication yes, значит, парольная аутентификация включена — независимо от того, что утверждает любой файл на диске. Ничто другое не считается подтверждением.

Вторая ловушка из той же серии. Ubuntu 24.04 запускает sshd через активацию по сокету: слушающий порт принадлежит ssh.socket, а директива Port в sshd_config полностью игнорируется. Проверьте это командой systemctl is-enabled ssh.socket; если сокет включён и вам нужен другой порт, меняйте его через systemctl edit ssh.socket и переопределение ListenStream= — а не в sshd_config, где настройка будет выглядеть правильной и не делать ничего.

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

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

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

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

На нашей платформе у вас два независимых друг от друга уровня. Фильтр на границе — опциональный, настраивается для каждого сервера в панели управления и применяется на уровне гипервизора, поэтому заблокированный трафик вообще не доходит до вашей гостевой системы, — он полезен для правил уровня 4, которые нужно применить прежде, чем ваше ядро потратит на пакет хоть один такт, а также чтобы скомпрометированная гостевая система оставалась недоступной, пока вы с ней разбираетесь. Файрвол внутри гостевой системы — целиком ваш: nftables, iptables, pf — что бы ни поставлялось с вашим образом. Мы никогда его не трогаем. Используйте оба уровня, если машина важна; используйте как минимум второй — всегда.

Два момента в наборе правил из шага 5 заслуживают объяснения, потому что в большинстве скопированных откуда попало наборов правил их делают неправильно. Не дропайте весь ICMP целиком. Это кажется аккуратным решением, но оно ломает обнаружение path-MTU, а это порождает худший из возможных классов багов: маленькие запросы работают, большие ответы зависают, и ни в одном логе нет ни слова про файрвол. Разрешите как минимум destination-unreachable, time-exceeded и parameter-problem. Не фильтруйте ICMPv6 по типу, если не знаете весь список типов. IPv6 полагается на ICMPv6 для обнаружения соседей и анонсов маршрутизаторов; заблокируйте его широким мазком — и связность по IPv6 умрёт так, что это будет выглядеть как проблема с маршрутизацией. Разрешить весь ICMPv6 целиком на одиночном хосте — разумный компромисс, и набор правил ниже именно так и делает.

Одно предупреждение перед тем, как вы выполните flush ruleset: если установлен Docker, эта строка удаляет NAT- и filter-правила, записанные Docker, и сетевая связность контейнеров пропадает, пока systemctl restart docker не вернёт их обратно. Сначала загрузите свой набор правил, затем перезапустите Docker — и прочитайте следующий раздел, прежде чем публиковать хотя бы один порт контейнера.

Спросите у машины, что она слушает. Не то, что вы, как вам кажется, установили, — а то, что реально забиндено прямо сейчас:

ss -tulpn | grep -vE '127\.0\.0\.1|\[::1\]'

Всё, что проходит через этот фильтр, доступно откуда-то ещё, кроме самой машины. На стандартном образе обычно находятся rpcbind на 111 (он не нужен ничему из того, что вы запускаете), слушатель exim4, оставшийся от базовой установки, и заглушка systemd-resolved, безобидная на loopback и превращающаяся в открытый резолвер, если это не так. Опасные находки появляются позже, вместе с софтом, который вы поставили сознательно: PostgreSQL на 0.0.0.0:5432, потому что какой-то туториал велел отредактировать listen_addresses; Redis без пароля, потому что у Redis почти всю его историю не было пароля по умолчанию; узел Elasticsearch; экспортер Prometheus; Jupyter notebook. Каждая из этих вещей не раз становилась первым шагом настоящего взлома.

А теперь ловушка, в которую попадают даже аккуратные люди. Docker не спрашивает разрешения у вашего файрвола. Когда вы пишете -p 5432:5432, Docker добавляет DNAT-правила в цепочку PREROUTING таблицы nat, которую ядро обрабатывает раньше, чем пакет вообще попадёт в вашу цепочку input; трафик после этого перенаправляется в контейнер. Ваша политика default-deny для input вообще не спрашивается, ufw status показывает порт закрытым, а база данных при этом торчит в публичном интернете. Это задокументированное поведение Docker, оно такое уже десять лет, и на нём засветилось огромное количество баз данных.

Исправление умещается в одну строку, и стоит выработать привычку её использовать:

# wrong — reachable from the entire internet, whatever your firewall says
docker run -p 5432:5432 postgres

# right — bound to loopback, reachable only through an SSH tunnel or a proxy
docker run -p 127.0.0.1:5432:5432 postgres

И напоследок — получите взгляд со стороны. Скан портов с самого сервера говорит о том, что думает ядро; скан откуда-то ещё говорит о том, что видит мир, а это единственная цифра, которая имеет значение. Запустите nmap -Pn -p- <your-ip> с вашего ноутбука, а не с самой машины, и сравните результат со списком, который вы ожидали увидеть.

Небольшие серверы взламывают не через уязвимости нулевого дня. Их взламывают в те четыре недели между публикацией CVE вместе с рабочим proof-of-concept и следующим разом, когда вы случайно зайдёте на сервер. Инструменты для атак осваивают новый удалённый баг за считаные дни; машина, которую вы патчите «как руки дойдут», остаётся уязвимой весь этот промежуток, и любой честный администратор знает, насколько на самом деле длинным бывает этот промежуток.

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

Часть, которую все пропускают, — это перезагрузка. Пропатченная на диске libssl ничего не даёт процессу, который замапил старую версию библиотеки при запуске, а обновление ядра вообще ничего не даёт, пока вы в него не загрузитесь. Либо согласитесь на автоматическую перезагрузку в выбранное вами окно, либо поставьте needrestart и пусть он сообщает, какие службы работают с уже удалёнными библиотеками, — но сделайте хоть что-то одно. «Автообновления включены» при uptime в 340 дней — это удобная иллюзия, и это самая частая иллюзия, которую мы видим.

fail2ban читает ваши логи, замечает повторяющиеся неудачные попытки с одного адреса и на время банит его. CrowdSec делает то же самое и вдобавок делится вердиктами по сети участников, так что вы можете заблокировать адрес, который уже успел где-то напакостить, ещё до того, как он доберётся до вас. Обе программы хороши. Но ни одна из них не делает того, что думает большинство людей, если речь о SSH-сервере, принимающем только ключи.

Как только PasswordAuthentication выставлен в no, перебор пароля по SSH не может увенчаться успехом. Не «маловероятен» — а именно не может, потому что для этого просто нет пути в коде. Поэтому бан адреса после пяти неудачных попыток ничего не предотвращает — он лишь сокращает объём логов и ничтожную долю нагрузки на CPU. Это реальная польза, просто не польза для безопасности, и плата за неё не нулевая: неудачно написанный jail, который смотрит не в тот лог, запирал администраторов вне их собственных серверов чаще, чем когда-либо запирал снаружи атакующих.

Там, где эти инструменты по-настоящему оправдывают себя, — это на уровень выше, на службах, которые вы действительно выставляете наружу: форма входа, админка WordPress, API с рейт-лимитами, почтовый сервер с SMTP AUTH. Вот они действительно принимают пароли, их действительно можно перебирать, и список банов — именно то средство, которое здесь нужно. Поэтому наш вердикт узкий и конкретный. Пропустите jail для SSH. Поставьте CrowdSec или fail2ban перед тем, что реально имеет поле для пароля. И что бы вы ни выбрали, сначала занесите в белый список собственный адрес для управления — ignoreip существует именно для того вечера, который иначе запомнится вам совсем не с той стороны.

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

Сохраняйте логи. На многих образах журнал живёт в /run и испаряется при перезагрузке, а значит, запись об инциденте исчезает при следующей же перезагрузке. Создание /var/log/journal — правка в одну строку и самая ценная вещь в этом разделе.

Узнавайте о входах в систему. Строка в /etc/ssh/sshrc, вызывающая logger при каждом начале сессии, ничего не стоит и даёт вам чистую, удобную для grep запись отдельно от собственной болтовни sshd. Есть нюанс, на котором люди спотыкаются: sshd запускает ~/.ssh/rc вместо /etc/ssh/sshrc, если у пользователя есть свой файл, — то есть общесистемный файл пропускается именно для той учётной записи, у которой скорее всего есть свой кастомный dotfile. Если вам нужен хук, который нельзя перекрыть, используйте вместо этого pam_exec.

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

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

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

Это не защищает данные на работающей машине. Укреплённое ядро и закрытый файрвол не имеют никакого значения для того, у кого есть доступ к гипервизору, и для содержимого оперативной памяти, пока машина включена. Если вас беспокоит диск в момент, когда сервер выключен, изъят или списан, — это шифрование диска, и это другая процедура с другим сценарием отказа — см. шифрование диска VPS с помощью LUKS.

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

Это не чинит ваше приложение. SQL-инъекции, неаутентифицированной админ-ручке или зависимости с бэкдором совершенно всё равно, какие у вас настройки sshd. Большинство взломов хорошо настроенных серверов происходит через порт, который вы сами, сознательно, открыли для написанной или установленной вами службы.

Это не резервная копия. Ransomware, rm -rf с переменной, которая оказалась пустой, и неудачное обновление — всё это заканчивается одинаково. Сделайте копию, положите её в другое место и хотя бы раз восстановитесь из неё до того, как это понадобится по-настоящему, — та же дисциплина, что делает переживаемым переезд на другой хостинг, делает переживаемым и один неудачный вторник.

Ничто из этого не довод против того самого часа. Это довод в пользу того, чтобы точно знать, что именно этот час вам купил.