Comments 33
В текущих реалиях еще и Xray-core
я бы еще tmux добавил
Пароли по SSH? РуВДС угорает что ли?
Да за одну только такую мысль требуется публичное покаяние редактора или кто там причастен к делу.
Попробую скачать netdata. Полезная статья!
Эм, смена порта ssh? Отключение root по ssh? Вход по сертификатам?
Ну это наверно уже все знают. Хотя…
Я понимаю эти меры на крутом рабочем VPS, но зачем это на бюджетной вдске где крутится xray и заглушка? Ну вот стоит там 12-символьный не словарный пароль на ssh на 22 порту и fail2ban. В чем уязвимость?
Не то чтобы уязвимость... Тут больше речь идёт о "лучших практиках" , я думаю. Вход по сертификату в любом случае удобней, так зачем тогда оставлять вход по паролю - дело пары минут.
Lynis всё расскажет что подхарденить
Как уже заметили в комментариях, помимо базовой минимальной настройки ssh (запрет входа для root, вход только сертификату), проверки установки tmux (как правило сейчас устанавливается по дефолту) я бы посоветовал вместо тяжеловесной для первой VDS Netdata ставить более легкий Beszel, а также обязательно устанавливать sysstat (только не забудьте настроить автозапуск сервиса) и хотя бы первое время и потом периодически запускать команду sar. Некоторые вопросы, глядя на статистику собранную этим старинным проверенным инструментом, отпадают сами собой.
Хороший набор. Только fail2ban защищает примерно как замок на двери с открытой форточкой: брутфорс SSH закроет, а вот `PasswordAuthentication yes` в sshd_config останется открытой. Сначала ключи, потом fail2ban – не наоборот.
Ключи, ключи. Сколько раз использовал дефолтный пароль на ssh от провайдера VPS (а они генерируются достаточно длинные), ни разу такие сервера никто не ломал.
Вот тут я с вами полностью согласен. Все эти "best practice" не для тех, кто взял первую ВПС, а для профессионалов и систем с чувствительными данными. Профессионалы лезут везде со своими ключами, и не понимают, что только усложняют то, что усложнять не нужно. И то, что только отпугивают новичка сложностью. Вспоминая себя n лет назад, настраивающего первый 3xui на первой в жизни linux: и так страшно, и не понятно вообще ничего. Нейросетей нет, того кто объяснит нет. Везде "АААА, ключи!, АААА рут!, фэйлтубан!!, Гроб! Гроб, кладбище!... Взлом!". Отправить бы себе сообщение туда "чувак, не парься, поставь пароль подлиньше и побессмысленней".
В целом, новичкам не нужно всё это, или нужно преподнести это как опционал на будущее(если ему это вообще понадобится), просто, чтобы знал, что такое существует. А так, новичок просто должен знать что ему нужен надёжный пароль и всё.
По ключу, например, вход на машину с remnawave. А на ноды - пароль. Мои пароли 62 в 25 степени комбинаций(в принципе тут понятно из чего он состоит и какой длины), удачи, интернет, встретимся когда остынут белые карлики. А при взломе будет получено что? А голая машина с нодой, да на здоровье.
Свой КВН на своем ВПС - это просто, ребята, паранойя - лучший помощник, но только не нужно доводить до абсурда.
Снимать виртуалку за сто рублей чтобы половину ресурсов отдать под мониторинг и защиту от китайских ботнетов - классический путь самурая-девопса
Зачем этот Fail2ban во все обзоры пихают для "защиты SSH"...
Мало того, что начиная с версии OpenSSH 9.8 появился встроенный механизм защиты от брутфорса и DDoS-атак. Так ещё одна строчка в конфиге AllowUsers username обломает ботов с порога.
у меня мой vps который не торчит нигде глобально стабильно по два айпишника в секунду банит фаилбан за попытку подбора пароля к ssh
я из интереса даже сделал сборшик логов в локи что бы смотреть динамику и ситуация не меняется уже года полтора
просто обламывать с порога недостаточно. еще из забавного - если блочить все порты кроме нужных на vps (включая 22) то нагрузка на vps падает заметно, для дешевых это особо актуально так как краулеры своим дедосом до 10% cpu могут отжирать
Пара интересных замечаний.
Fail2ban можно заменить на более продвинутый Crowdsec.
Ест он не многим больше, удобнее. Да и в целом, иметь буквально базу зловредных ip лучше, чем составлять её с нуля.
UFW не столько надстройка над iptables, сколько фронтэнд. А бэкэндом может быть и nftables. Это стоит хотя-бы упомянуть. Хотя конечно, новичку это может показаться и вовсе тёмным лесом.
В остальном, полезно. Хотя в интернете куча таких вот статей, информация в них может быть неактуальной, или вовсе опасной. Так что приятно видеть время от времени такие вот обновления, пусть даже в них и почти ничего не поменялось за последние 5-6 лет...
Digitalocean Еще для ubuntu 18 делал отличную шпаргалку (с пояснениями),которую дальше можно развивать так,как нужно под конкретные задачи
https://www.digitalocean.com/community/tutorials/ubuntu-18-04-ru
Вместо htop можно использовать btop.
Иногда требуется посмотреть нагрузку на сеть - тогда nload.
ЗЫ Картинки взяты из выдачи Google.
Если iptables, то ufw не нужен. Для открыть/закрыть порты нет сложного синтаксиса.
еще мастхев тула https://github.com/tsl0922/ttyd - далеко не всегда ssh доступен. при подключении к публичным wifi, в корп сетях (очень часто), различного рода цензура и т.д.
правда обычно vps-хостинги дают веб-консоль, но это не так удобно как правило
Я бы добавил утилиту vnStat – для сбора и агрегации статистики потребления сетевого трафика
>при установке Docker правила UFW игнорируются.
А можно об этом поподробнее?
При указании портов как это показано в подавляющем большинстве примеров (“-p 8000:8000”) докер вешает порт на 0.0.0.0 хоста и пишет свои правила напрямую в iptables, что не попадает под ограничения, которые в тот же iptables пишет ufw.
Лечение зависит от того, для чего нужен порт. Как пример, если сервис в контейнере предполагается держать за условным nginx, который установлен как системный пакет, и который проксирует запросы на порт на локалхосте, то решение - биндить порт из контейнера на локалхост, т.е. “-p 127.0.0.1:8000:8000”. Если тот же nginx не в системе, а в соседнем контейнере, то можно завести отдельную сеть в докере и вешать контейнеры туда, тогда на хост вообще никаких портов не надо тащить.
Инструменты, которые должен знать каждый, кто арендует первый VDS