LINUX.ORG.RU

В Journald добавлена поддержка криптографической защиты журналов

 , , ,


0

1

Леннарт Поттеринг (Lennart Poettering) из RedHat представил новую систему FSS, являющуюся дополнением к системе ведения логов Journald, входящей в состав системы инициализации Systemd. Данная инновация войдет в состав Fedora 18.

Forward Secure Sealing (FSS) позволяет накладывать криптографические отпечатки на журнал системных логов. Таким образом, злоумышленники не смогут изменить журнал (однако, смогут полностью удалить его). Это работает путем создания пары криптографических ключей (ключ отпечатков и верификационный ключ). Первый остается на машине, сохранность журналов которой необходимо гарантировать, и автоматически меняется через определенные интервалы времени (старый ключ удаляется без возможности восстановления). Второй ключ записывается на бумагу, мобильный телефон или в другое защищенное место (это означает, что он не должен храниться на машине, журналы которой необходимо защищать). Имея верификационный ключ, вы можете проверить журналы и, в случае успешной проверки, быть уверенным в целостности логов (даже, если бы машина была взломана).

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

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

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

Данное нововведение уже доступно в составе 189 выпуска systemd (подробнее).

FSS основан на «Forward Secure Pseudo Random Generators», созданным Бертрамом Поттеринг (Bertram Poettering, брат Леннарта) в Royal Holloway университете Лондона, в котором он занимается криптографическими исследованиями. Вскоре будет доступна документация по FSPRG.

>>> Подробности на Google+

★★★★★

Проверено: Aceler ()
Последнее исправление: Silent (всего исправлений: 5)

Ответ на: комментарий от tailgunner

Я не производил замену. Если подсунуть левый модуль журналирования перед прибиванием процесса, то скорее всего поднимется.

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

в systemd есть код, который дает нужное смещение

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

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

Это сакральное и непонятное тебе дерево Меркле. Почитай на досуге, технология почти такая же.

anonymous
()
Ответ на: комментарий от Jayrome

Пропажа журнала говорит о том, что произошло что-то странное. Надо быть идиотом , чтобы не понять, что либо админ что-то начудил, либо система была взломана. А админ знает, что в тот день он ничего не трогал и вообще сервер уже несколько месяцев непрерывно работает и логи никуда не пропадают.

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

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

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

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

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

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

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

KivApple ★★★★★
()

Объясните мне, глупому, что злоумышленнику, который получил права на изменение журналов (т.е. root) помешает заменить бинарник верификации логов таким образом, чтобы при попытке верификации выполнялся хотя бы 1 из пунктов:

  1. Выдавать статус Ок независимо от реального результата проверки
  2. Сразу после ввода верификационного ключа генерить из текста новый журнал, которые будет проходить проверку даже после смены бинарника на правильный.

Предположения о том, что остановить systemd нельзя (хотя верифицировать же не сам systemd будет?) можно не рассматривать: всегда можно подправить процесс в памяти не завершая его, имея root-права.

r_a_vic
()
Ответ на: комментарий от Homura_Akemi

Да не за что, мне вот непонятно как не дать злоумышленнику ответвиться от дерева в нужный момент... Но тут, наверное, на помощь приходит волшебная технология брата Поттеринга!

anonymous
()
Ответ на: комментарий от imul

Повторить не удалось. Вероятно зависит от того, где именно были внесены изменения (я не думаю, что systemd-journal перечитывает весь журнал). При второй попытке он поднялся, но ставил старый журнал.

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

2-й вариант очень понравился, особенно патч адресного пространства процесса журнала.

Подводя итог: remote syslog server - намного более надежное решение.

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

remote syslog server - намного более надежное решение.

Бесспорно.

r_a_vic
()
Ответ на: комментарий от unfo

Подводя итог: remote syslog server - намного более надежное решение.

С этим никто не спорит, к сожалению не всегда это возможно сделать.

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

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

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

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

С этим никто не спорит, к сожалению, когда-нибудь уберут из journnald бекэнд в syslog и это вообще невозможно будет сделать.

Печальный фикс.

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

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

Равносильно удалению файла с журналами.

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

Равносильно удалению файла с журналами.

удаление всех логов админ увидит, а вот изменение старых - не факт

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

Вряд ли. syslog используют не только компы. Поставить systemd на какую-нибудь киску не получится.

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

удаление всех логов админ увидит, а вот изменение старых - не факт

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

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

Верификацию вторым ключом этот журнал уже не пройдет.

с чего ты взял? в коде systemd проверяются хеши для записей, а не их содержимое

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

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

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

r_a_vic
()
Ответ на: комментарий от wota

Forward Secure Sealing (FSS) позволяет накладывать криптографические отпечатки на журнал системных логов. Таким образом, злоумышленники не смогут изменить журнал ...

Текст новости. Это все и придумано для того, чтобы нельзя было редактировать логи. Исходники лень читать, смотреть как именно оно все там реализовано.

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

Ужасные костыли. Леннарт хотел как лучше, а получилось как всегда.

Зато генератор QR-кодов для консольки написал, как же без него.

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

В таком случае сверка последних подписей (с бекапной и рабочей машины) займет меньше времени, чем диф пары гигов логов.

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

Костыль, конечно. Это ежу понятно. А на счет хотел как лучше: криптография сама по себе не панацея. Если есть возможность подменить криптомодуль контроля, то все напрасно. Именно поэтому вводится TrustedComputing и прочие eToken'ы.

Никогда не влезал в местные баталии за/против systemd и Леннарта лично, но предлагаемая реализация подписи журналов создает лишь видимость безопасности. Поэтому может быть стоило заняться доведением до ума других аспектов systemd, вместо добавления нового бессмысленного функционала? И это все больше напоминает MS-way, когда в систему добавляли всякие SFC, UAC и прочие. Такие изменения лишь осложняют жизнь легальному пользователю; создают, повторюсь, ложное чувство защищенности; да, делают неработоспособными старые атаки. Но появляются новые - еще более скрытные и изощренные. Это не решение проблем с безопасностью, это - заклеивание черного хода обоями: изнутри выглядит нормально.

r_a_vic
()
Ответ на: комментарий от at

Не понял сути высказывания. И причем тут диф?

Лог бинарный. Просто сверить не получится - будут отличия из-за новых записей. И наверняка в заголовок что-то дописывается.

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

r_a_vic
()

У меня двоится в глазах? Поттеринги, ТЕПЕРЬ ИХ ДВОЕ?!

По теме: А разве journald не бросили ради принципиально новой системы логов линуксов?

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

Т.е. предполагаю такую схему: Имеется сервер на удаленной площадке, связь с которым осуществляться через GPRS (я сталкивался с парой таких устройств). Т.е. постоянно бекапить логи не получается. Естественно я могу загрузить логи за определенное число, но постоянно это делать не желательно. Вместо этого мы передаем на бекапный сервер подписи логов (естественно не все, а с некоторым интервалом). Т.к. у бекапного сервера есть предыдущие подписи он может проверить он может проверить их корректность. В случае расхождения послать аларм и т.д. Сами логи с вскрытой машины интереса не представляют, им все равно нельзя верить. Достаточно установить сам факт подмены логов и примерное время.

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

А разве journald не бросили ради принципиально новой системы логов линуксов?

Вы, вероятно, про это.

У этого проекта есть сайт, на котором написано:

Code Repository

libumberlog A drop-in replacement for syslog.h that provides structured logging support

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

Но активность в этоп репозитории имеется.

unfo ★★★★★
() автор топика

Сомнительное нововведение. %)

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

Чтобы проверить хеш новой записи лога нужен хеш старой записи лога и сама запись лога. Иначе ведь никак. h = hash(prev_h, log_entry)

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

Да, я не правильно написал. Имелось ввиду, что не обязательно для каждой новой записи делать новый ключ. Это можно делать с некоторым интервалом, скажем каждые n записей или по времени. Мне интересно другое: достаточно ли самих ключей для проверки их корректности или обязательно нужны сами записи.

at ★★
()

Bertram Poettering, брат Леннарта

Их еще и двое?! Где напалм?

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

P.S. Все понял. Невнимательно прочитал. Обидно, что это не возможно.

at ★★
()

А веб-серверов таких нет?

чтобы отдавали только те страницы, которые подписаны цифровой подписью ;)

SCHigi
()
Ответ на: комментарий от Jayrome

То, что логи исчезли, не свидетельствует ни о чем.

Шалит logrotatе, lol

Deleted
()
Ответ на: комментарий от Homura_Akemi

А ничего, что лог подписывать будет просто нечем?

А Леннарт ничего подписывать и не собирается. Там какая-то муть с хешированием. И, как я уже написал, нерабочая.

segfault ★★★★★
()

FSS основан на «Forward Secure Pseudo Random Generators», созданным Бертрамом Поттеринг (Bertram Poettering, брат Леннарта) в Royal Holloway университете Лондона, в котором он занимается криптографическими исследованиями.

О Боже, еще один Поттеринг, только в криптологии... Ну ничего, там велосипедостроение не любят, а кривые поделия быстро обламываются.

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

Долго думал, но так и не понял, зачем это может быть нужно

Чтобы в сохраненном на другой машине логе точно найти место, с которого он подделан :)

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

А Леннарт ничего подписывать и не собирается.

А открытый и закрытый ключи на что?

unfo ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.