Pull to refresh

Comments 39

Теперь мы можем выполнять команды от имени root, используя префикс sudo. Это гораздо безопаснее, так как система будет каждый раз спрашивать пароль вашего пользователя (admin), защищая от случайных деструктивных действий.

И чем это безопаснее? Только будет отвлекать каждый раз, увеличивая вероятность ошибок.

Я понимаю, когда человек использует компьютер в каких-то своих мирных целях и иногда переключается в привелегированный режим через sudo, чтобы в системе что-нибудь подкрутить. Это - разумный способ использования, и действительно, нет никакого смысла делать повседневную работу с правами рута.

Совсем другое дело, когда примерно всё, что делает человек с данным компьютером, это его администрирование (как в случае той же VPS-ки). Зачем ради каждой команды менять режим и вводить пароль, мне решительно непонятно.

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

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

UFW (Uncomplicated Firewall) — это простой интерфейс для управления файрволом. Наша задача — закрыть все порты, кроме тех, что нам нужны.

Зачем нужен firewall в системе, в которой контролируется набор программ, которые в принципе могут принимать входящие соединения? Чистый карго-культ.

Просто не запускайте лишних, ненужных вам, неизвестных и непонятных сервисов и следите за этим после каждого обновления системы и/или на какой-то еще периодической основе.

Если на каком-то порту никто не слушает, запрет/разрешение этого порта на уровне firewall-а не влияет вообще ни на что.

А самые опасные порты, 22-й, 25-й, 80-й, 443-й вы в любом случае откроете, потому что ради них эту VPS-ку и покупали, и будете обеспечивать их безопасность какими-то другими методами.

Самое печальное в такой схеме с sudo, когда из-за ошибки ввода команды начинаешь дальше вводить пароль, не смотря на экран, и он записывается в историю команд :)

А надо в качестве пароля использовать строку "rm -rf /". Тогда ущерб при случайной ошибке будет самоустраняющийся :-)

Этот пароль слишком часто встречается в словарях перебора :)

Можно так: "bfijrhgfiurfhe; rm -rf /"

Тогда будет (1) секретно (2) если начало обрежется, хвост всё равно сработает.

Для случаев, когда мне нужно не сохранить историю текущей сессии (включая описанный вами), делаю export HISTFILE=/dev/null. Пока что это самый удобный из найденных мной способов.

В частном случае можно поставить пробел перед командой и она в историю не запишется

Не везде работает к несчастью(

Просто не запускайте лишних, ненужных вам, неизвестных и непонятных сервисов 

тут скорей рекомендация для default deny outgoing, но автор это не понял, просто скопипастил из интернетов.

default deny на выход сделан для того, чтоб из вашей машины при компрометации безправного сервиса (например nginx, xray итд) не превратили в ботнет с рассылкой спама и DDOS атак куда ни попадя.

и, конечно же, это не харденинг самого хоста, это минимизация ущерба при состоявшемся взломе.

А вот правила для исходящих соединений надо уже с умом настраивать. Чтобы не отшибить полезные сервисы.

а это и другие полезные советы вы прочтете в телеграм-канале автора

SSH ключи удобно держать в каком то парольном менеджере типа китпасса который автоматом их подставляет и убирает.

Быть бы еще уверенным, что ключи оттуда не утекут...

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

Аппаратные ключи без возможности экспорта приватного ключа

Ключи должны быть запаролены. Сверху keeagent для удобства использования.

Файрвол нужен, чтобы дропать invalid и т.п. пакеты и пакеты с некоторыми флагами.

Зачем их дропать? С этим вполне справляется ядерный TCP/IP стек...

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

Также не забываем, что речь идет о виртуальном калькуляторе по цене чашки кофе...а, нет, сорян, 2025 год же, кофе дороже, который интересен только доморощенным кулхацкерам-ботоводам. Целенаправленно ломать ваш ноут за двойным НАТом (это же еще вас как самого владельца впс найти надо), чтобы потом взломать копеечный впс? Рили?

1-2 Спорно. Меня лично бесит писать sudo каждый раз, учитывая, что почти все, что я делаю это требует.

3 Частично согласен. Ключи это отлично, но например пароль из 15-20 символов не сильно хуже.

4 Спорно. Обычно сервисы, не требующие удаленного доступа просто биндятся на lo. FW может быть полезен, если нужно разрешить удаленный доступ только некоторым диапазонам адресов.

5 Бесполезная хрень. Ну долбятся они и пусть долбятся. Там все равно часто ботнеты с кучей разных IP.

Если что, я использую собственные VPS уже 10+ лет (делаю только п. 3, иногда 4) и за все это время был только один инцидент, связанный с дырявым php движком форума.

Мои обязательные шаги - замена пароля ssh на ключи и снос всех лишних сервисов, которые не требуются (иногда шаблоны VPS у провайдера забиты по умолчанию кучей всего лишего), apt-get update && apt-get dist-upgrade.

Насчет sudo понимаю, меня тоже подбешивает. Если садишься админить надолго, проще sudo -i и погнал, тут без вопросов. Но для статьи... сам понимаешь, пишу для тех, кто может и сервак снести случайной командой (сложность статьи Простой).

Пароль на 20 символов — да, хрен подберешь, согласен. Но ключ удобнее для скриптов, и его не сфишишь, в отличие от пароля. Тут просто кому что удобнее.

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

Fail2ban — да, от реальной атаки ботнета он не спасет, это просто "дворник", чтобы в логах мусора поменьше было, и самые тупые сканеры отсеивать. Не более.

Но для статьи... сам понимаешь, пишу для тех, кто может и сервак снести случайной командой (сложность статьи Простой).

Разок снесут - навсегда запомнят.

Я один раз сносил из-за случайной опечатки :) И даже починил без переустановки системы. Механические диски, они медленные, процесс не успел далеко зайти...

Снести случайной командой сервер sudo новичка не спасет - он же привык, что sudo надо вначале обязательно набирать и сделает это на автомате :)

Новичок не полезет в логи, он никогда и не узнает (да и не надо это ему), что к нему ломятся с подбором пароля.

Весь этот набор рекомендаций я вижу уже много лет практически без изменений. Нет, ничего плохого в нем нет, но почему то он часто преподносится, как будто без этого нельзя. Если ты опытный пользователь, то эти рекомендации либо уменьшают удобство работы или сам знаешь как это сделать по другому более правильно. А новичок сможет выстрелить себе в ногу тысячей других способов (failtoban в свой IP это прям классика), особенно когда выполняет инструкции с сайта бездумно методом copy-paste.

Создание пользователя и "permitrootlogin no" добавляет чуток безопасности - необходимость подбирать не только пароль, но и пользователя. Наличие sudo добавляет не сколько безопасности, сколько удобства в плане использования sudo su / sudo -i (без необходимости помнить километровый пароль рута.) Плюс, ограничение списка используемых команд для sudo позволяет разнести команды из разных областей администрирования по разным пользователям, что тоже слегка добавляет безопасности. Ну и иногда удобно, если надо выполнять команды от сервисных юзеров с shell:/bin/false или /bin/nologin.

Странно, что нет совета по смене порта для ssh, тоже отсеит определенное количество ботов.

# Можно еще сменить стандартный порт 22 на любой другой (например, 2222)

# Это не столько безопасность, сколько "гигиена" - боты перестанут долбиться в логи.

# Port 2222

Интересно сколько людей действительно вчитывается?

Только 2222 плохой пример (поскольку без изменений гуляет от статьи к статье, откуда его бездумно копипастят) и в него уже тоже по умолчанию долбятся

Почти не помогает. Через небольшое время сканеры находят какой порт открыт и начинают долбить туда. Для параноиков можно настроить Port knocking.

В современных реалиях смену Ssh порта на зарубежных VPS делать опасно - можно остаться без доступа. Потому что РКН пропускает ssh трафик по 22 порту, а вот на нестандартных его рубит. Понятно что есть VPN, да и некоторые регионы более лояльны чем другие, но об этой особенности следует помнить.

Замена порта и вход по ключу... Более чем достаточно, уже много лет. До кучи ( имея дома белый ip) в sshd_config разрешаю вход только со своего ip.

Удобно ещё скрипт настроить, чтобы хотя бы приблизительно понимать насколько твой vps интересует кого-нибудь.

У меня от моих vps примерно такие отчёты приходят в телеграм:

🔐 Отчёт по SSH за период:🕒 2025-07-09 09:00:00 → 2025-07-10 09:00:00❌ Неудачных входов: 196🚫 Забаненные IP:нет📜 Последние попытки:Jul 10 07:32:36 ********** sshd[217607]: Failed password for invalid user admin from 45.135.232.177 port 58650 ssh2Jul 10 07:33:36 ********** sshd[217616]: Failed password for invalid user user from 45.134.26.79 port 23294 ssh2

Можно будет как то в рамках одной статьи, попробовать написать такого бота)

Настроил аналитику на индустриальном стандарте: Prometheus + VictoriaMetrics + PushGateway + Grafana + десятки экспортеров метрик.

Заметил, что, как правило, стучатся чаще всего на азиатские и российские серверы (G-Core и бывш. Sbercloud соответственно, в моем случае).

Скриншот с Графаны
Скриншот с Графаны
Скриншот с Графаны

150К отлупов, феерично!

Я понимаю, что это "минимальный набор новичка", но дабы не вводить в заблуждение, тех кто только постигает азы, нужно уточнить следующее: Через 5 секунд ляжет любой сервак как ддосить начну в прямой ип на L3. По L7 никакие платные клаудфлеиры или ддосгуарды не помогут. Как реальная защита на проде это все не годится.

На проде да – не годится, я старался охватить как можно больше но в рамках сложности "Просто"

И как действовать? Но я так понимаю, что это уже не просто мимо проходящие боты, а целенаправленная атака на твой сервер?

RSA ключи не рекомендуют, используйте ESD

Sign up to leave a comment.

Articles