. Хостер FirstVDS оставил бэкдоры в поставляемых клиентам VDS
Хостер FirstVDS оставил бэкдоры в поставляемых клиентам VDS

Хостер FirstVDS оставил бэкдоры в поставляемых клиентам VDS

Хостер FirstVDS поставляет VDS своим пользователям с вот таким вот содержимым файла /root/.ssh/authorized_keys:

Т.е. это даёт возможность получать доступ через SSH к арендуемым пользователями VDS тем личностям, которые установили этот ключ. Комментарий в файле гласит, что этот ключ — для доступа техподдержки. При этом никакого оповещения пользователю не выдаётся. Решил написать в техподдержку для разъеснения этой ситуации и получил вот такой ответ

После последнего сообщения переписка была переведена в архив. Т.е., как я понял, была заблокирована для ответа. Вот такие у них отзывчивые менеджеры отдела Заботы о клиентах.

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

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

Один из вариантов решения — удаление файла /root/.ssh/authorized_keys

П.С. Оригинал на хабре Ссылка

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

reyicapow: Хостер FirstVDS поставляет VDS своим пользователям с вот таким вот содержимым файла /root/.ssh/authorized_keys:

Т.е. это даёт возможность получать доступ через SSH к арендуемым пользователями VDS тем личностям, которые установили этот ключ. Комментарий в файле гласит, что этот ключ — для доступа техподдержки. При этом никакого оповещения пользователю не выдаётся. Решил написать в техподдержку для разъеснения этой ситуации и получил вот такой ответ

После последнего сообщения переписка была переведена в архив. Т.е., как я понял, была заблокирована для ответа. Вот такие у них отзывчивые менеджеры отдела Заботы о клиентах.

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

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

Один из вариантов решения — удаление файла /root/.ssh/authorized_keys

П.С. Оригинал на хабре Ссылка

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

Че кипишь то подымать? Они и так имеют доступ ко всем ВМ. А ключ вероятней всего для упрощение решения проблем всунули. Еще и подписали его для того, что бы параноики не кипишевали.

Если нужно они пароль от впс за пол минуты сбросят и без вашего участия. Так что полностью согласен с smart2web

полностью нормальная ситуация.

Единственное, что можно не использовать прямю авторизацию root

Через sudo будет ок :)

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

Относительно самого размещения ключа - проблемы тут нет, хсотер и так может в любой момент получить любые данные на VPS клиента. А для sudo. смысла особого нет, там придется или NOPASSWD прописывать или вводить пароль в последствии, к тому же ключ это куда надежнее чем plain-text пароль, по этому вполне допускаю его размещение прямо у рута. Однако уже давно не помни ни одной системы (которую ставил) где бы я первым делом не запрещал прямой вход рута :))))

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

P.S: Честно говоря, читая заголовок, подумал о том, что нашли какой-то патченный бинарик в системе или модуль в ядре, а тут целый ssh ключ :)))) Тема слишком громко названа!

reyicapow, больше не лазьте на чужие сервера и не оказывайте сисадминских и прочих услуг, в которых ничего не понимаете. Хостер и так имеет полный доступ к вдс. Ключ для упрощения процедуры оказания услуг саппорта хостингом.

Только подумайте, если бы каждый сотрудник банка имел доступ ко всем счетам всех клиентов для удобства оказывать поддержку :D))) Смешно, правда?

Дырища огромная, хотя некомпетентные люди подобное иногда вытворяют. Но это хостинг, тут почти все такие :)

reyicapow, а ещё клиент сам может при переустановке ОС, установить свой ключ!

P.S. ТС, прежде чем делать такие громкие заявления, изучите VMmanager, который для этого используется, а так же почитайте о способах доступа к данным со стороны хостера, при наличии виртуального и физического доступа к серверу.

У сотрудников хостинга, как и у приведённых Вами в качестве примера сотрудников банка, есть разграничение прав доступа и тот же ключ будет предоставлен не всем сотрудникам.

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

К сожалению именно так и есть, любой сотрудник любого банка может совершить любую сделку со счетом любого абонента без его фактического присутствия или согласия. Я говорю о возможном факте. то, что потом это будет быстро выяснено и сотрудник будет взят за яйца - это совсем другое дело и предмет другого разговора, но это возможно технически! Ведь по сути именно сотрудник банка занимается подтверждением ваших намерений по той или иной операции. что ему мешает фальсифицировать пару бумажек и сделать вид что вы "приходили в офис лично". ничего..

Тоже самое и тут, любой хостер может получить доступ к любому VPS находящемуся у него на площадке, выяснить будет сложнее или легче - не суть важно, но он это может.

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

На своей практике я однажды ощутил подобное, я как и любой нормальный сис.админ всегда стремлюсь к оптимизации собственного труда, к оптимизации процессов с которыми я работаю и.т.п, однажды родилась у меня мысль автоматизировать сбор данных по пяти десяткам серверов для аналитики происходящего в центральном месте, выбрал самый простой способ, ssh ключи, разложил везде и картинка ожила, одна команда собирала мне логи по всем серверам, анализировала их и быстренько показывала если что-то было за пределами допустимых логик. Однажды я обнаружил , что мой центральный сервер на котором была аналитика каким-то чудо образом взломали, я точно уже сейчас не вспомню, что там было причиной, но суть - устаревшее ПО которое дало трещину )))) как же быстро шевелились волосы на моей голове, когда я осознал, что если бы взломщики понимали что за сервер они получили . какой бы я отгреб геморой. и какие бы были проблемы, к моему великому счастью, все увенчалось рассылкой спама с сервера и запуском каких-то perl процессов из /tmp :) доступа на "подконтрольные" сервера не произошло. А если бы произошло, одним махом был бы продан доступ на 50 серверов. Собственно после этого, подобного рода "процессы" вызывают у меня только меланхолический смех :)))

📎📎📎📎📎📎📎📎📎📎