VDS/VPS какова степени защищенности от "слива" админами?!

И на Вятку & etc.

Нет, это вы не понимаете азов серверной безопасности. Когда происходит загрузка сервера, то все файловые системы зашифрованы. Загрузчик грузит initrd и монтирует ram-disk, подымая SSH. Сам файл загрузчика подписан, ключи для верификации удаленном сервере, то есть подменить его нельзя.

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

Вы никак не сможете залить туда свой сертификат или украсть оттуда существующий.

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

Опа, оказывается, что ни initrd ни ram-disk таки не зашифрованы и на нем sshd со всеми ключами, которые мы можем менять как угодно.

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

По ssh? Хаха, ssh само собой терминируется на mitm машине и проксируется на ваш уже с левыми ключами, которые туда были добавлены выше по тексту. Все что вы вводите в ssh логируется в открытом виде.

Да, спасибо за ключ, но он нам уже особенно не нужен, мы просто зайдем по ssh и сольем базу с расшифрованного диска. В этот раз вам как-то не хватило фантазии усложнить :)

См. выше.

Вы называете это фантастикой, а я - недостатком квалификации. Будет применять или нет - это не важно, в данном случае принципиально то, что невозможно защитить информацию расшифровуя ее в небезопасной среде (на выделенном сервере), но вы почему-то пытаетесь доказать, что можно.

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

А мне ничего не помешает залить новый initd на сервер и ребутнуть его повторно, что сделает все ключи старого недействительными :)

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

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

А как вы собираетесь перехватывать initrd, если его передача будет идти при помощи p2p?

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

Почему не известны? Если пропускать весь трафик через mitm, то очень даже известны и даже нет разницы со скольки удаленных серверов качается initrd, все кусочки соберем. Но надо ли? Тут же такой момент, у нас уже есть доступ к текущей системе по ssh и мы видим все, что вы по ssh там делаете. Когда вы собрали из кусочков новый initrd и вводите команду на перезапись - тут мы и заменим ее, initrd вместо перезаписи будет скачан прямо на mitm машину :)

Для того чтоб получить доступ к ssh вам сначала нужно ключ получить

А он каждый раз новый при старте севрера через p2p заливается

А вычленить ключ из p2p это такая же фантастика как прослушать скайп, именно по этому его сормы не довят

Думайте, что говорите

Ок, какой алгоритм теперь? После монтирования ram-disk'а запускается какой-то софт, который с нескольких удаленных машин собирает host key и ключи для авторизации по ssh и запускает sshd, такой?

Ну тогда долго не думая мы пересоберем sshd так, чтобы он при старте отправлял все ключи на нашу mitm машину и принимал все соединения с нее вообще без ключей, вуаля :)

Наша задача очень простая же - проникнуть внутрь и подождать.

Вы ничего не можеие пересобрать так как поменяется сигнатура, о чем я писал ранее