LINUX.ORG.RU
Ответ на: комментарий от MagicMirror

Это понятно. Но если они добавят свое в authorized_keys то потом можно будет потихоньку юзать, а если пароль у юзера сменят то это уже быстрее всплывет.

mx__ ★★★★★
() автор топика
Ответ на: комментарий от mx__

если они добавят свое в authorized_keys

А если оно доберётся до рута и подменит бинарь sshd, то тебя вообще ничего не спасёт. А если подменит systemd, то ты этого даже не заметишь никогда, потому что и журнал и всё остальное — под его контролем.

mord0d ★★★★★
()
Ответ на: комментарий от mx__

Раньше вобще считалось, что оставлять торчащий наружу ssh-порт небезопасно и всё. Не важно, ключ или пароль. Нестандартный порт + knockd или ещё что. И какой-нибудь анализатор логов, если на машину можно заходить со всех ip-адресов. Чтобы

потихоньку юзать

долго не получалось бы.

mky ★★★★★
()
Ответ на: комментарий от mx__

У меня authorized_keys под опекой оркестратора, так что подмена идёт в /dev/null as soon as possible. Плюс я никогда не даю юзеру прав больше, чем ему требуется и никогда нигде не свечу свои пароли (они даже из буфера обмена стираются сразу после использования), даже сам их не знаю, чтобы уж наверняка.

Тут проблема не в том что что-то может получить доступ, а в том что админ это каким-либо образом допустил.

Абсолютной безопасности не бывает.

mord0d ★★★★★
()
Ответ на: комментарий от mx__

Добирание до рута от юзера это уже дыра в системе

И systemd и sudo позволяют кэшировать пароль и не запрашивать его снова какое-то время. Я уверен что вредоносы умеют этим пользоваться, пусть и не все.

Удобство всегда было противоположностью безопасности.

mord0d ★★★★★
()
Ответ на: комментарий от MagicMirror

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

Сам я на NodeJS не пишу (по крайней мере пока), а левые проекты запускаю в виртуалке, причём каждый от отдельного пользователя, которым su запрещён, а sudo в виртуалке не установлен. Ну и systemd во FreeBSD нет, так что в большинстве случаев вредоносы умрут от поноса. (%

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

mord0d ★★★★★
()
Ответ на: комментарий от MagicMirror

Нафейхоа нужно запускать NodeJS на локалхосте? И уж тем более для работы

Обычно это какие-то веб-сервисы, которые supposed to be торчать наружу, и сервить их с десктопа/ноута — тупняк. Даже если нет сервера, можно использовать дноплатник, специально для этого заведённый, чтобы как минимум отделять мух от котлет.

ключи, куки и пароли из браузера

Хранить ключи без пассфразы и уж тем более пароли в браузере… штош, это целевая аудитория таких вредоносов, приятного им аппетита. (%

mord0d ★★★★★
()
Ответ на: комментарий от mord0d

Мне например на работе надо ансиблем ходить. А там центось с древним питоном, с которым не работает ансибль из репозиториев. Приходится ставить из е******о pip. И че делать?

MagicMirror ★★
()
Ответ на: комментарий от MagicMirror

Вот за это я Ansible и не люблю, кстати.

Недавно кто-то жаловался, что Ansible с Bitrix подрались и пришлось руками что-то там разруливать в обход менеджера пакетов дистрибутива.

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

И че делать?

Жаловаться. Если не поможет — откатывать Ansible на тот, который совместим с Python из штатного репозитория дистрибутива. Зашевелятся — тыкать носом в жалобы и список уязвимостей.

mord0d ★★★★★
()
Ответ на: комментарий от MagicMirror

Жаловаться

На свой же локалхост?

Так на работе, или на своём локалхосте? Это две принципиально разные вещи.

У меня на домашней инфре (полноценный сервер с кучей виртуалок и контейнеров) вообще самописный оркестратор без зависимостей (ну почти, ему нужен только git, а на linux — coreutils ещё).

mord0d ★★★★★
()
Ответ на: комментарий от mx__

password все таки безопаснее ключа

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

В теории, ключи можно не запрещать полностью, а прописать ″AuthorizedKeysCommandUser″. Правда, не знаю, не искал, что туда прописать, чтобы у каждого пользователя было локальное шифрованое хранилище ключей...

mky ★★★★★
()
Ответ на: комментарий от mky

однако пароль подобрать проще чем ключ :) и подбирателей пароля ssh по интернету бегают кучами, постоянно вижу в логах. а вот побирателей ключей ssh чет ни одного не видел (хотя и не искал)
если есть подозрения в дырявости машины, то сделай ключ с паролем. выдернуть пароль для ключа очень и очень сложно.
абсолютным средством конечно же будет аппаратный токен с аппаратным набором пароля или хотя бы кнопкой разрешения.

pfg ★★★★★
()
Ответ на: комментарий от mky

Шёл 2025-ый год, по прежнему не пользовались ни FIDO2, ни PKCS11.

Трояны очень любят пароли из головы. Голова ведь их вводит в конечном итоге внутрь системного блока, а FIDO2 и токены PKCS11 со своими ключами так никогда не поступают (в системный блок они никогда не попадают - ни в RAM, ни в CPU).

sanyo1234
()
Ответ на: комментарий от pfg

аппаратный токен с аппаратным набором пароля или хотя бы кнопкой разрешения.

Лучшее решение. Миниклавиатура или кнопка ессно должна быть на борту самого токена.

sanyo1234
()
Ответ на: комментарий от pfg

То есть код, пишущий что-то в authorized_keys есть, а бота, который стучит нету?

подбирать/перебирать? Подобрать ключ просто, если он на флешке, которая выпала из кармана.

сделай ключ с паролем.

Я понимаю, что «Ъ» по ссылкам не ходят, но можно было понять, что тут исходный контекст топика — это код, который сам пишет в .ssh/authorized_keys Куда там прописывать пароль для ключей, заносимых в этот файл?

токен с аппаратным набором пароля или хотя бы кнопкой разрешения.

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

mky ★★★★★
()
Ответ на: комментарий от sanyo1234

Да, в том числе. Selinux может порезать доступ ко всему. Т.е. допустим, у тебя есть файл. Он доступен для user:group. Например, vasya:vasya. Получается что, если vasya запустит вирусню, всё что доступно Васе, становится доступным руткиту? А вот и нет. А вот если есть selinux, то приложения запускаются в контексе. А если файл в другом контексте, то ничего не выйдет. Отака ерунда.

Pierre_Dolle
()
Ответ на: комментарий от MagicMirror

Зачем такие сложности, если всё плейнтекстом на диске лежит?

  1. Диски некоторые шифруют.

  2. Некоторые пользуются современными хранилками паролей даже с привязкой к аппаратным токенам для открытия ключницы, и с автоматическим вытиранием нешифрованного пароля из RAM-ы.

sanyo1234
()
Ответ на: комментарий от mord0d

Если добирешся до рута то уже можно и не прятатся, клавиатуру юзеру просто отключи чтобы он чего не нажал, и хер на мониторе нарисуй чтобы чего не увидел -)

antech
()
Последнее исправление: antech (всего исправлений: 2)