Положите картинки на amazon s3, будет стоить $1.5 в месяц за хранение, а трафик, скажем 30 Гиг в месяц обойдется в чуть больше $3. И гарантированно никто не выпрет.
Почему не известны? Если пропускать весь трафик через mitm, то очень даже известны и даже нет разницы со скольки удаленных серверов качается initrd, все кусочки соберем. Но надо ли? Тут же такой момент, у нас уже есть доступ к текущей системе по ssh и мы видим все, что вы по ssh там делаете. Когда вы собрали из кусочков новый initrd и вводите команду на перезапись - тут мы и заменим ее, initrd вместо перезаписи будет скачан прямо на mitm машину :)
Большое количество - это сколько? 1, 10, 100, 1000 ГБ?
Andreyka, ну пусть сигнатура лежит на удаленном сервере, в чем проблема? Если ваш сервер отсылает хэш инитрд куда-то для верификации, то мне ничто не помешает пропустить эту отсылку хэша через mitm машину и отправлять настоящий хэш на верификацию, вместо левого. Так же, как мне ничто не помешает не пропустить новый initrd на ваш сервер, а оставить его на mitm машине.
Какой бы способ вы не придумали, вы не сможете защитить данные, если вы расшифровуете их в чужой среде.
Опа, оказывается, что ни initrd ни ram-disk таки не зашифрованы и на нем sshd со всеми ключами, которые мы можем менять как угодно.
Как это нельзя? Подменим, переподпишем левым ключем и пропустим через mitm машину, которая будет проводить "верификацию", а отдавать удаленному хосту на "верификацию" она будет старый настоящий "файл загрузчика". Тада. Что теперь?
По ssh? Хаха, ssh само собой терминируется на mitm машине и проксируется на ваш уже с левыми ключами, которые туда были добавлены выше по тексту. Все что вы вводите в ssh логируется в открытом виде.
Да, спасибо за ключ, но он нам уже особенно не нужен, мы просто зайдем по ssh и сольем базу с расшифрованного диска. В этот раз вам как-то не хватило фантазии усложнить :)
См. выше.
Вы называете это фантастикой, а я - недостатком квалификации. Будет применять или нет - это не важно, в данном случае принципиально то, что невозможно защитить информацию расшифровуя ее в небезопасной среде (на выделенном сервере), но вы почему-то пытаетесь доказать, что можно.
Andreyka, ну глупости же говорите, если у вас сертификат зашифрован на файловой системе, то вы не получаете ключ для этой файловой системы через ssl, для которого этот самый сертификат и нужен.
Рекурсия получается, вы хотите спрятать сертификат для получения ключа от зашифрованной файловой системы на саму файловую систему :)
P.S. санитайзеры никак не спасут вас от дампа памяти, у них в общем-то совсем другая задача, типа помочь защититься от эксплоитов. Да и ничего не спасет от дампа памяти, особенно если это хардверный девайс воткнутый в pcie с контроллером доступа к памяти, который после включения только инициализируется и отключается, пока на нем кнопку не нажмут и потому вообще никак не виден из ОС (нагуглил статью про такой девайс, как раз создан чтобы красть ключи и пароли органами у уголовников, т.е. forensic analysis).
Ну во-первых, если мы уже засунули сертификат левой authority на ваш сервер, то все запросы с и на него будут идти только через mitm машину, на которой терминируятся все эти ssl соединения. Т.е. весь зашифрованный ssl трафик будет расшифрован на ней, записан в лог и перешифрован с левым сертификатом, которому неожиданно доверяет скомпрометированный сервер. И хоть с бубном танцуйте, а ключ достанется атакеру в открытом виде.
P.S. Забыл про во-вторых. Во-вторых мы все-таки можем слить дамп памяти с гораздо меньшими трудозатратами, чем mitm.
Ну и хорошо, тогда нужно позаботиться о том, чтобы новый сертификат заменялся только на mitm, а на вашем сервере так и лежал левый. Вы же его передаете на скомпрометированный сервер, не забывайте.
Хотя если вы будете так изощряться, т.е. менять сертификат после ребута, то уже наверное проще дамп памяти слить. И да, искать что-то в дампе памяти совсем не сложно, вы зря так его отбрасываете, готовых утилит вполне достаточно :)
Каким способом? Нет ни одного, при котором нельзя украсть ключ, если есть доступ к железу :)
В самом крайнем случае можно слить дамп оперативки и найти ключ в нем, если до чего-то очень хитрого кто-то додумается.
А что изменится? То что нужно будет добавить левую authority в хост, чтобы на него прозрачно передавать запросы с MITM машины? Ну да, чуть усложняется, но раз есть доступ к железу - не беда.
ENELIS, короче, не может быть сервера на ЧУЖОЙ площадке с какой-либо гарантией защиты информации, разговор получается ни о чем. Фактически у ЧУЖОЙ площадки всегда есть физический доступ ко всем ключам и паролям, необходимым для конструирования любой, даже самой сложной, MITM атаки, а доступ к этим ключам как раз и дает возможность обойти все виды защит от MITM.
А то, что вы говорите, типа сменять сервер и площадку при сбое - звучит абсурдно. Так вам нужно вводить ваш пароль для монтирования зашифрованного раздела, доверяя только одной компании, а при смене площадки вам нужно каждый раз доверять новой компании, тем самым только еще больше увеличивая риск.
