Pull to refresh

Comments 34

UFO just landed and posted this here

Шифрование упомянуто в статье, как основной способ защиты. Сама же заметка посвящена ликвидации доступа к терминалу.

UFO just landed and posted this here

Абсолютной защиты не бывает, но ее наличие увеличивает шанс на выживаемость. Это сопоставимо с бронежелетом, который часто закрывает около 60% торса, не предусматривая попадание в слабые места, а также сбоку, в ноги, руки и голову.

Вы пробовали поковыряться хотя бы 200 Мб RAM? Это кажется что 200 Мб копейки, на самом деле это размер 200 средних книг, т.е. целый книжный шкаф. Выискивать там информацию — то еще удовольствие. Особенно когда ключи хранятся в памяти подсоленные — понять где подсоленный ключ, где соль — это не так просто.

Разумеется, байты надо вручную читать, после распечатки на принтере. Ни один хаккер не догадается вбить в гугль ssh keys from memory dump и найти вот это: https://github.com/DiabloHorn/pageant_xkeys


Я уверен, что таких проектов килограммами можно найти.

Только для популярного софта, а не вашего уникального сервиса.

В 99% случаев либо никому этот софт не нужен, либо он использует стандартные библиотеки. Более того, даже не зная нифига о софте, но имея его копию, написать грепалку, которая по дампу памяти найдёт нужное (просто по регэкспу) — не то, чтобы совсем просто, но и не rocket science.


(Что-то мне подсказывает, что для всего нужного софта дампилки уже давно написаны. И кошельки у крипты, и gpg пароли...)

В 99% случаев либо никому этот софт не нужен

Криптообменник, к примеру. Софт не нужен, а ключи — нужны.

либо он использует стандартные библиотеки

В библиотечную функцию передал ключ, получил подпись — данные из памяти потерлись. Выискать ключ среди всех переменных, особенно если ключ подсолен, исходников нет — то еще удовольствие.

А передалось оно откуда? Из программы. Которая, либо страдает паранойей (ура, хорошо), либо на php и ничего такого не думала. Тогда, зная регэксп стандартного формата ключа найти его — как нефиг делать. Вот, смотрите:


(-----BEGIN OPENSSH PRIVATE KEY-----)(.+)(-----END OPENSSH PRIVATE KEY-----)


Как вы думаете, что я найду в памяти? Этот комментарий, и....

И всё равно терминал вы не отключаете. Остаётся grub, остаётся консоль линукса (sysrq).


Учитесь.
linux:
console=ttyS0,115200 i8042.nokbd


grub:
GRUB_TERMINAL=serial
GRUB_DISABLE_RECOVERY=true


systemd:


systemd:
name: getty@tty1.service
enabled: false
state: stopped
masked: true


(Переключает консоль на последовательный порт).

И опять-таки, недобросовестный хостер найдёт способ в последовательный порт "воткнуться".

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

Что даёт доступ к терминалу, если злоумышленнику неизвестен пароль?

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


Помимо всего описанного, нянкэт вместо эмулятора терминала — это всё же своего рода юмор.

А вы пробовали брутофорсить пароль в терминале линукса? Похоже что нет.

Помоему рубить сук на котором сидишь. То же самое, что брать в аренду сервер, без ipkvm.
А в такой конфигурации не сработает сочетание на реальной клавиатуре Alt + SysRq + K для запуска консоли с login.

Последней фразой я хотел спросить:
А в такой конфигурации не сработает сочетание на реальной клавиатуре Alt + SysRq + K для запуска консоли с login?

Статья настолько бессмысленная насколько и беспощадная :(

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


Или вы используете шифрованный $HOME?

Ключ luks вводится до запуска всего описанного гербария при включении VM. Отношения к logind и getty не имеет, т.к. на стадии ввода ключа диск с упомянутыми утилитами еще зашифрован.

Как то видел финт ушами, с ssh сервером в рамдиске и некой "магии с настройками", в итоге при полнодисковом шифровании стартовало ядро и ssh сервер, который ожидал подключения и ввода пароля

Было бы любопытно ознакомиться!

У меня так настроено. Магии там нет :)

Я уже второй год собираюсь об этом написать, да все времени не найду :(

Было бы очень интересно почитать!

Можно еще добавить вот так.


systemctl mask getty\@tty1

/etc/default/console-setup


ACTIVE_CONSOLES="/dev/tty1"

/etc/security/access.conf


-:ALL:tty1

/etc/pam.d/login


account  required       pam_access.so
А что мешает недобросовестному хостеру подключаться по ssh?
Ну, можно и рутовый пароль из сотни символов поставить — эффект тот же.
Важно добавить. Всё эти способы «доверяют» платформе и как правило не имеют средств защиты от компрометации загрузчика. Если кто-то задумал получить ваши ключи шифрования, совсем не надо искать их в ОЗУ, надо подменить загрузчик на тот, который и сольет все ключи. Единственная, и довольно слабая надежда на Secure Boot.
Этот способ защиты работает не зависимо от типа виртуализации (OpenVZ, KVM...) или нет?
Sign up to leave a comment.

Articles

Change theme settings