Привет, Хабр! У каждого из нас бывает этот момент. Ты нажимаешь кнопку «Заказать», и вот он — твой первый, сияющий, свежеустановленный VPS. Ощущение, как будто получил ключи от собственной цифровой квартиры. Можно ставить что угодно, экспериментировать, запускать свои пет‑проекты... Но есть один нюанс.
Эта «квартира» сейчас стоит с дверью нараспашку посреди самого темного и опасного района интернета. И пока ты радуешься, к этой двери уже тянутся сотни автоматизированных ботов, чтобы проверить, не забыл ли ты закрыть замок.
Я сам прошел через это. Мой первый сервер прожил в «диком» виде около часа, прежде чем я заглянул в логи и увидел непрекращающийся поток попыток входа по SSH. Это было мое «приключение» — превратить уязвимый кусок железа в безопасное убежище. Я наступил на пару граблей, но в итоге собрал «сокровище» — этот чек‑лист, которым хочу поделиться с вами.
Это не исчерпывающее руководство по пентесту, а набор первых, самых важных шагов, которые отсекут 99% автоматических атак и дадут вам спокойно спать по ночам.
Шаг 0: Входим на сервер
Первое, что мы делаем — заходим на наш свежий сервер под пользователем root и паролем, который прислал хостер.
ssh root@ВАШ_IP_АДРЕСЭто единственный раз, когда мы так делаем. Обещаю.
Шаг 1: Меняем замки на главной двери (Root)
Работать под root — это как ходить по минному полю с завязанными глазами. Одна опечатка в команде rm -rf — и прощай, сервер. Первым делом создадим надежный пароль для root (он нам еще понадобится для sudo) и немедленно выйдем из-под него.
Лайфхак: Никогда, слышите, никогда не работайте под root на постоянной основе. Это аксиома.
# Система сразу попросит вас сменить пароль.
# Задайте что-то очень сложное и сохраните в менеджере паролей.
passwdШаг 2: Создаем личного помощника (пользователь с sudo)
Теперь создадим обычного пользователя, от имени которого мы и будем работать. Назовем его, например, admin.
# Создаем пользователя
adduser admin
# Даем ему права суперпользователя (добавляем в группу sudo)
usermod -aG sudo adminТеперь мы можем выполнять команды от имени root, используя префикс sudo. Это гораздо безопаснее, так как система будет каждый раз спрашивать пароль вашего пользователя (admin), защищая от случайных деструктивных действий.
Шаг 3: Настраиваем VIP-вход (SSH по ключам)
Пароли — это зло. Их можно подобрать, перехватить, они могут утечь. SSH-ключи — наш стандарт де-факто. Это криптографическая пара: приватный ключ хранится у вас на компьютере, а публичный — на сервере. Подделать его практически невозможно.
На вашем локальном компьютере:
Если у вас еще нет ключа, генерируем: ssh-keygen (просто жмите Enter на все вопросы).
Копируем ваш публичный ключ на сервер.
# Эта команда скопирует ваш ~/.ssh/id_rsa.pub на сервер
# и правильно положит его в нужный файл для пользователя admin
ssh-copy-id admin@ВАШ_IP_АДРЕСТеперь на сервере (заходим уже под admin):
Открываем конфигурационный файл SSH:
sudo nano /etc/ssh/sshd_configИщем и меняем эти строки. Это самые важные изменения в статье:
# Запрещаем вход под root вообще. Это маст-хэв!
PermitRootLogin no
# Разрешаем вход только по ключам, отключая пароли.
PasswordAuthentication no
# Можно еще сменить стандартный порт 22 на любой другой (например, 2222)
# Это не столько безопасность, сколько "гигиена" - боты перестанут долбиться в логи.
# Port 2222Важно! Прежде чем перезагружать SSH, откройте новое окно терминала и попробуйте зайти по ключу: ssh admin@ВАШ_IP_АДРЕС. Если пустило — вы все сделали правильно!
Теперь применяем изменения:
sudo systemctl restart ssh
Шаг 4: Ставим простого, но злого охранника (Файрвол UFW)
UFW (Uncomplicated Firewall) — это простой интерфейс для управления файрволом. Наша задача — закрыть все порты, кроме тех, что нам нужны.
# Разрешаем подключения по нашему новому SSH порту (если меняли)
sudo ufw allow 2222/tcp # Или 22, если не меняли
# Разрешаем стандартные веб-порты, если планируется сайт
sudo ufw allow 'Nginx Full' # или 'Apache Full'
# И включаем нашего охранника
sudo ufw enable
# Проверяем статус
sudo ufw statusТеперь на ваш сервер можно попасть только через разрешенные «двери».
Шаг 5: Нанимаем вышибалу (Fail2ban)
Fail2ban — это утилита, которая сканирует логи и автоматически банит IP-адреса, с которых идет слишком много неудачных попыток входа. Даже если у нас отключены пароли, боты все равно будут «стучаться». Зачем нам этот мусор в логах?
# Установка простая
sudo apt update
sudo apt install fail2ban
# Запускаем и добавляем в автозагрузку
sudo systemctl start fail2ban
sudo systemctl enable fail2banИ все! Fail2ban уже работает «из коробки» с настройками по умолчанию для SSH. Он будет защищать ваш сервер, пока вы пьете кофе.
Крепость построена, но что насчет шпионов?
Правило честного компромисса: Конечно, это лишь базовый набор. Для серьезного продакшена я бы еще настроил автоматические обновления безопасности и многое другое. Но эти шаги — тот самый фундамент, без которого строить что-либо дальше просто опасно. Это как ремень безопасности в машине — не гарантирует 100% защиты, но критически повышает ваши шансы.
Мы построили стены (UFW), поставили вышибалу на входе (Fail2ban) и создали VIP-пропуска (SSH-ключи). Наша крепость защищена от лобовых атак. Но что, если враг уже внутри? Или пытается проникнуть не через парадную дверь, а через хитрые, замаскированные запросы?
В следующей части мы поднимем планку: установим и настроим Maltrail — систему обнаружения вредоносного трафика. Это наш личный «датчик движения», который будет ловить подозрительную активность внутри периметра, о котором не догадываются известные нам UFW и Fail2ban.
А теперь вопрос к вам, сообщество: Какие еще обязательные первые шаги вы делаете на свежеустановленном сервере? Какие грабли собирали вы, забыв про какой-нибудь из этих пунктов? Давайте делиться опытом в комментариях
Комментарии (38)
GoblinHero
10.07.2025 09:111-2 Спорно. Меня лично бесит писать sudo каждый раз, учитывая, что почти все, что я делаю это требует.
3 Частично согласен. Ключи это отлично, но например пароль из 15-20 символов не сильно хуже.
4 Спорно. Обычно сервисы, не требующие удаленного доступа просто биндятся на lo. FW может быть полезен, если нужно разрешить удаленный доступ только некоторым диапазонам адресов.
5 Бесполезная хрень. Ну долбятся они и пусть долбятся. Там все равно часто ботнеты с кучей разных IP.
Если что, я использую собственные VPS уже 10+ лет (делаю только п. 3, иногда 4) и за все это время был только один инцидент, связанный с дырявым php движком форума.
Мои обязательные шаги - замена пароля ssh на ключи и снос всех лишних сервисов, которые не требуются (иногда шаблоны VPS у провайдера забиты по умолчанию кучей всего лишего), apt-get update && apt-get dist-upgrade.
cyberscoper Автор
10.07.2025 09:11Насчет sudo понимаю, меня тоже подбешивает. Если садишься админить надолго, проще sudo -i и погнал, тут без вопросов. Но для статьи... сам понимаешь, пишу для тех, кто может и сервак снести случайной командой (сложность статьи Простой).
Пароль на 20 символов — да, хрен подберешь, согласен. Но ключ удобнее для скриптов, и его не сфишишь, в отличие от пароля. Тут просто кому что удобнее.
Про биндинг на lo — вот тут ты абсолютно прав, это вообще самый чистый способ. Но файрвол — это как раз на тот случай, когда ты поставил что-то новое и забыл это сделать. Просто тупая страховка от себя же.
Fail2ban — да, от реальной атаки ботнета он не спасет, это просто "дворник", чтобы в логах мусора поменьше было, и самые тупые сканеры отсеивать. Не более.
apevzner
10.07.2025 09:11Но для статьи... сам понимаешь, пишу для тех, кто может и сервак снести случайной командой (сложность статьи Простой).
Разок снесут - навсегда запомнят.
Я один раз сносил из-за случайной опечатки :) И даже починил без переустановки системы. Механические диски, они медленные, процесс не успел далеко зайти...
GoblinHero
10.07.2025 09:11Снести случайной командой сервер sudo новичка не спасет - он же привык, что sudo надо вначале обязательно набирать и сделает это на автомате :)
Новичок не полезет в логи, он никогда и не узнает (да и не надо это ему), что к нему ломятся с подбором пароля.
Весь этот набор рекомендаций я вижу уже много лет практически без изменений. Нет, ничего плохого в нем нет, но почему то он часто преподносится, как будто без этого нельзя. Если ты опытный пользователь, то эти рекомендации либо уменьшают удобство работы или сам знаешь как это сделать по другому более правильно. А новичок сможет выстрелить себе в ногу тысячей других способов (failtoban в свой IP это прям классика), особенно когда выполняет инструкции с сайта бездумно методом copy-paste.
Jsxii
10.07.2025 09:11Создание пользователя и "permitrootlogin no" добавляет чуток безопасности - необходимость подбирать не только пароль, но и пользователя. Наличие sudo добавляет не сколько безопасности, сколько удобства в плане использования sudo su / sudo -i (без необходимости помнить километровый пароль рута.) Плюс, ограничение списка используемых команд для sudo позволяет разнести команды из разных областей администрирования по разным пользователям, что тоже слегка добавляет безопасности. Ну и иногда удобно, если надо выполнять команды от сервисных юзеров с shell:/bin/false или /bin/nologin.
xitriy87
10.07.2025 09:11Странно, что нет совета по смене порта для ssh, тоже отсеит определенное количество ботов.
cyberscoper Автор
10.07.2025 09:11# Можно еще сменить стандартный порт 22 на любой другой (например, 2222)
# Это не столько безопасность, сколько "гигиена" - боты перестанут долбиться в логи.
# Port 2222
Интересно сколько людей действительно вчитывается?
CherryPah
10.07.2025 09:11Только 2222 плохой пример (поскольку без изменений гуляет от статьи к статье, откуда его бездумно копипастят) и в него уже тоже по умолчанию долбятся
GoblinHero
10.07.2025 09:11Почти не помогает. Через небольшое время сканеры находят какой порт открыт и начинают долбить туда. Для параноиков можно настроить Port knocking.
Raam
10.07.2025 09:11В современных реалиях смену Ssh порта на зарубежных VPS делать опасно - можно остаться без доступа. Потому что РКН пропускает ssh трафик по 22 порту, а вот на нестандартных его рубит. Понятно что есть VPN, да и некоторые регионы более лояльны чем другие, но об этой особенности следует помнить.
Dimanao
10.07.2025 09:11Замена порта и вход по ключу... Более чем достаточно, уже много лет. До кучи ( имея дома белый ip) в sshd_config разрешаю вход только со своего ip.
apevzner
И чем это безопаснее? Только будет отвлекать каждый раз, увеличивая вероятность ошибок.
Я понимаю, когда человек использует компьютер в каких-то своих мирных целях и иногда переключается в привелегированный режим через sudo, чтобы в системе что-нибудь подкрутить. Это - разумный способ использования, и действительно, нет никакого смысла делать повседневную работу с правами рута.
Совсем другое дело, когда примерно всё, что делает человек с данным компьютером, это его администрирование (как в случае той же VPS-ки). Зачем ради каждой команды менять режим и вводить пароль, мне решительно непонятно.
Не забываем при этом, что ваш личный компьютер, на котором хранятся ключи, становится универсальной отмычкой для всех тех мест, на которые вы с него ходите. И все ваши ключи удобно и централизовано на нём собраны, с заботой о том, кто захочет ими поживиться.
Зачем нужен firewall в системе, в которой контролируется набор программ, которые в принципе могут принимать входящие соединения? Чистый карго-культ.
Просто не запускайте лишних, ненужных вам, неизвестных и непонятных сервисов и следите за этим после каждого обновления системы и/или на какой-то еще периодической основе.
Если на каком-то порту никто не слушает, запрет/разрешение этого порта на уровне firewall-а не влияет вообще ни на что.
А самые опасные порты, 22-й, 25-й, 80-й, 443-й вы в любом случае откроете, потому что ради них эту VPS-ку и покупали, и будете обеспечивать их безопасность какими-то другими методами.
Shaman_RSHU
Самое печальное в такой схеме с sudo, когда из-за ошибки ввода команды начинаешь дальше вводить пароль, не смотря на экран, и он записывается в историю команд :)
apevzner
А надо в качестве пароля использовать строку "rm -rf /". Тогда ущерб при случайной ошибке будет самоустраняющийся :-)
Shaman_RSHU
Этот пароль слишком часто встречается в словарях перебора :)
apevzner
Можно так: "bfijrhgfiurfhe; rm -rf /"
Тогда будет (1) секретно (2) если начало обрежется, хвост всё равно сработает.
ovegio
Для случаев, когда мне нужно не сохранить историю текущей сессии (включая описанный вами), делаю
export HISTFILE=/dev/null. Пока что это самый удобный из найденных мной способов.Shaman_RSHU
В частном случае можно поставить пробел перед командой и она в историю не запишется
Petr_axeman
Не везде работает к несчастью(
max9
тут скорей рекомендация для default deny outgoing, но автор это не понял, просто скопипастил из интернетов.
default deny на выход сделан для того, чтоб из вашей машины при компрометации безправного сервиса (например nginx, xray итд) не превратили в ботнет с рассылкой спама и DDOS атак куда ни попадя.
и, конечно же, это не харденинг самого хоста, это минимизация ущерба при состоявшемся взломе.
apevzner
А вот правила для исходящих соединений надо уже с умом настраивать. Чтобы не отшибить полезные сервисы.
max9
а это и другие полезные советы вы прочтете в телеграм-канале автораpolearnik
SSH ключи удобно держать в каком то парольном менеджере типа китпасса который автоматом их подставляет и убирает.
apevzner
Быть бы еще уверенным, что ключи оттуда не утекут...
polearnik
кипасс проходил независимый аудит. Думаю это вполне достатчочно для бытового применения и большинства бизнесов
ColorPrint
Аппаратные ключи без возможности экспорта приватного ключа
Xaos13
Ключи должны быть запаролены. Сверху keeagent для удобства использования.
SignFinder
Файрвол нужен, чтобы дропать invalid и т.п. пакеты и пакеты с некоторыми флагами.
apevzner
Зачем их дропать? С этим вполне справляется ядерный TCP/IP стек...
hochbar
Не забываем при этом, что ваш личный компьютер, на котором хранятся ключи, становится универсальной отмычкой для всех тех мест, на которые вы с него ходите.Также не забываем, что речь идет о виртуальном калькуляторе по цене чашки кофе...а, нет, сорян, 2025 год же, кофе дороже, который интересен только доморощенным кулхацкерам-ботоводам. Целенаправленно ломать ваш ноут за двойным НАТом (это же еще вас как самого владельца впс найти надо), чтобы потом взломать копеечный впс? Рили?