Comments 33
Расскажите мне, а кто вообще на хабре целевая аудитория статей на тему "Сейчас настроим VPS"? Пока у меня только одно предположение - для портфолио.
Хабр огромный ресурс, на котором уже давно постится всё подряд, некоторое даже с натяжкой ITшным не назовёшь. Почему все считают, что тут всё ещё только прожжёные гики сидят? Сюда приходит множество новичков, но их отсюда гонят ссаными тряпками, вместо того, чтобы поделиться опытом.
Какое портфолио?
Это обычная реклама телеграмм канала, для собирания подписчиков, для того что бы там крутить рекламу. Хабр уже давно утонул в подобных статьях от бизнесменов рекламирующих телеграмм каналы. У кого то они полезней, а у кого то просто авторерайт и перевод через LLM, любого мусора, лишь бы вставить ссылку.
Так же учитывайте что люди приходят и из поисковой системы, и читатели совсем не обязательно коренные жители хабра.
Эти бизнесмены создают десятки аккаунтов, стараются поднять им рейтинг, и когда зацепятся, то допустим написав статью с нужной ссылкой одним аккаунтом, остальными аккаунтами плюсуют эту статью, и плюют в карму тем кто нехорошо отозвался про автора статьи. И так по кругу.
Хабр уже давно превратился в площадку для продвижения и куда постят любой мусор.
В принципе просто деградировал до того же Дзена.
Как шпаргалка статья полезна, для тех кто ежедневно не настраивает.
Не мешайте человеку учиться ) https://ny.pressanybutton.ru/
Если бы в начале был чек лист. Который ты мог скопировать и ставить галочки. Для человека который в первый раз настраивает ок. Так прочитать все статью заставляют.
Как шпаргалка статья полезна
Неа. Есть концептуальные ошибки, которые напрямую могут привести к компрометации сервера прямо с первой минуты его работы. Эти ошибки просто копипастят из предыдущих статей, такчто имеем что имеем.
Пожалуйста, напишите, какие здесь концептуальные ошибки.
В ответ на запрос введите
yesи нажмите Enter.
1) При первом подключении предлагается ответить Yes на вопрос "доверяете ли вы этому серверному ключу". Это хреновый совет т.к. если уже в этот момент времени у вас MitM, то он теперь останется с вами навсегда :-) На самом деле ключ сначала надо проверить и только потом, если он действительно от вашего сервера а не от MitM, тогда ему можно доверять. Эта концептуальная ошибка есть чуть менее чем в каждом руководстве по настройке виртуалок.
2) В статье написано как перейти с входа по паролям на вход по клиентским ключам. Сгенерить и залить на сервер ключ, потом сделать изменения в конфиге сервера:
PasswordAuthentication noPermitRootLogin prohibit-passwordPubkeyAuthentication yes
Включится ли после этого вход по ключам? Конечно. Это проверяется последующим заходом с ключем. Выключится ли после этого вход по паролям? У меня для вас неприятный сюрприз - это не обязательно. Потому что вход по паролям работает если включена хотя бы одна из следующих опций: PasswordAuthentication или KbdInteractiveAuthentication. Подавляющее большинство статей предписывают отключать PasswordAuthentication но при этом забывают отключить KbdInteractiveAuthentication. В результате вход по паролям не отключается, но мамкин админ об этом не знает т.к. теория в статьях не описана а практической проверки такого отключения админ не делает. В некоторых дистрах KbdInteractiveAuthentication включена по умолчанию, в некоторых других - нет.
3) Отсюда сразу следующий пункт: в статьях часто нет предписания немедленно поменять выданный хостером пароль. Так что пароль лежит в электронной почте и ждет своего часа. То есть вы получаете валяющийся в почте в открытом виде рутовый пароль плюс недовыключенный вход по паролям из предыдущего пункта. Прекрасная дыра в безопасности. Конкретно в этой статье эта дыра закрыта директивой PermitRootLogin prohibit-password но я уже насмотрелся статей в которых этого нет.
4) В настройках фаерволла режутся входящие TCP соединения но никак не предпринимается никаких попыток убедиться в том, что наружу не выставлено что-нибудь с UDP. Там может обнаружиться какой-нибудь унылый syslogd.
5) Конкретно в этой статье творится какое-то безумие с sudo. Если хостер вам выдал рутовый логин-пароль и вы действительно работатете под рутом, то зачем вам далее по тексту sudo? А если вы все же работаете под другим юзером, то у вас не написано ничего про создание этого юзера и его последующее добавление в sudoers.
Для новичков полезно.
Я вот узнал о существовании 2-х утилит, о которых раньше не слышал.
А, еще тема для ZSH.
Я, например, с интересом прочитал о доп.софте типа Tabby.
Не смотря на относительно известные процедуры. Мне всегда приятно читать новые статьи, нет-нет да что-то новенькое проскочит. Не дает останавливаться на достигнутом.
Я бы посоветовал новичкам вместо докера устанавливать podman, безопаснее.
Очередная статья ради ссылки на ТГ.
Вы бы хоть как-то креативили..
Как реклама телеграм-канала - ок. Но как гайд именно для первичной настройки VPS — спорно: нету чек листа короткого веачале. Вынуждаете читать всю статью.
Плюс, сам подход с ручными командами плохо масштабируется. Новичок через месяц уже не вспомнит, что он правил в sshd_config, какие порты открывал в UFW и почему именно так. А если вы делаете это регулярно, то повторять одно и то же руками каждый раз - тоже нерационально: неизбежно появляется "дрейф" конфигурации и мелкие отличия между серверами. Потому и для опытных людей бесполезно.
На практике такие вещи лучше оформлять в репозиторий Ansible (или Terraform + Ansible): роли, переменные, идемпотентность, понятный порядок шагов. Тогда вместо полотна команд просто даёте ссылку на репозиторий и запускаете playbook — и через месяц/год сервер будет настроен ровно так же, как в первый раз. И 2–3 и тд VPS поднимаются значительно быстрее, без расхождений и забытых шагов.
А есть где-нибудь гайд с примерами для начинающих про то, что вы написали?
Новичок через месяц уже не вспомнит, что он правил в sshd_config, какие порты открывал в UFW и почему именно так.
Это вопрос дисциплины, и не только для новичка.
Засобирались настраивать сервер - заведите себе ~/Documents/<сервер>_install.txt и записывайте в него лог своих действий. Настраиваете что-то по инструкции из интернета, по handbook или по манам - ну вот и напишите ссылку на источник знаний. Если источником выступает внешний сайт - сохраните локально на всякий случай, или загоните его в archive.org.
Перед изменением sshd_config сделайте cp -p sshd_config sshd_config.<дата>.bak и только потом редактируйте конфиг. Поредактировали - добавте коммент, ну камон, не полагайтесь тупо на память - она не бесконечна.
Как много букв😂😂😂 так он смог подключиться сам к себе после нового года?
Прям вижу как автор набирает текст и зажимает alt + 0151. Я тоже всегда так делаю. С телефона копирую — и вставляю ибо не знаю как набрать длинное тире.
Смена порта не является полноценной мерой безопасности, но она:
Уменьшает нагрузку на сервер.
Это как оно снижает нагрузку?
Я бы начал настройку с остановки демона ssh (активные сессии продолжат работать). Особенно, если хотер не потрудился изменить порт по умолчанию. И уже после настройки SSH и сетевого экрана запустил бы демона.
1.1. В идеале, конечно, держать sshd выключенным и запускать его на 1-2 минуты чтобы успеть самому подключиться. Или спрятать его в туннель. Если бы не контора вредителей, из-за которой рассчитывать на оба эти варианта не приходится.
Что касается сетевого экрана:
2.1. Сам как раз таки предпочитаю настраивать сетевой экран "на всякий случай". Лучше на всякий случай закрою оба контура (и входящий и исходящий трафик) снизив, тем самым, вероятность стать инициатором паразитного трафика в случае заражения.
2.2. Не будет лишним привязать правила ко внешнему интерфейсу. Это во первых снизило бы нагрузку на ЦП, а во вторых не пришлось бы плодить правила для сервисов, к которым доступ извне нежелателен.
Я начал более параноидально относиться к настройке, когда в один прекрасный день на собственном никому ненужном VPS обнаружил активную сессию от своего имени, но в 1000 км от себя (если верить RIPE). При том что доступ на сервер по паролю был отключен. Файл ключа был запаролен и никому не передавался.
Вопрос первый: я слышал что rsa "морально устарел", и что сейчас актуальнен ed25519, обеспечивающий безопасность схожего уровня при более коротких ключах. Почему вы решили остановиться на RSA?
Вопрос второй, насчёт фаервола. Чем ufw лучше, чем nftables?
А не проще ли использовать cloud-init и сразу получать настроенный под себя vps без всяких плясок с бубном?
Есть серьезный пункт о котором автор умолчал(по незнанию или неопытности) - открытие портов докером в обход ufw.
Запускаете в докере базу с публикацией порта, думая что он виден только на локалхосте, а он себе прекрасно торчит на ружу, потому что докер внес свои изменения в iptables.
Если статья для новичков, то наверное будет правильно рекомендовать им изучать что-то актуальное и свежее.
1) Зачем ставить и изучать ufw, если на Debian 12-13 уже работает nftables?
2) Зачем рекомендовать генерацию rsa ключей, если широко распространены более компактные ed25519?
3) Зачем править системный sshd_config, если в системе специально есть целый каталог sshd_config.d, для пользовательских изменений? А еще sshd_config может по недосмотру затереться настройками "по умолчанию" при обновлении системы.
4) KbdInteractiveAuthentication no надо добавить, иначе парольная аутентификация продолжит работать.
5) Неплохо бы проверить IPv6 на VPS. А то VPS может оказаться доступна всем.
6) Работа из под root пользователя не самая лучшая рекомендация для начинающего.
Гайд по первоначальной настройке VPS