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 ()

FSS основан на «Forward Secure Pseudo Random Generators», созданным Бертрамом Поттеринг (брат Леннарта)

А, так весь сыр-бор, чтобы брата попиарить?

red_eyed_peguin ()

Однако, он сможет удалить все журналы целиком, но администратор точно обратит на это внимание.

А не пофиг ли уже будет? Следы то уничтожены.

devl547 ★★★★★ ()

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

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

Нет. Если машина взломана (тем более если на нее удалось установить руткит) злоумышленнику выгодно как можно дольше оставаться незамеченным. Удаление логов будет сразу замечено.

at ★★ ()

Во сколько раз больше ресурсов это будет жрать?

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

и все шито-крыто

Нет. Нормальный администратор сразу примет меры по заделыванию всех возможных дыр и минимизации урона от возможного слива инфы

MahMahoritos ★★★ ()

добавим в юзы -fss делов то

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

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

Jayrome ★★★★★ ()

созданным Бертрамом Поттеринг

Их уже двое. Линуксокапец близок как никогда :)

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

действительно. На боевом сервере, на который никто просто так не заходит, внезапно исчезли все логи. Ващи ничего не значит, ага.

anonymous ()

он не сможет отредактировать файлы журналов, чтобы администратор не заметил взлома

небольшие исправления в journald, заменяешь системный на свою версию, и он тебе «Войну и мир» в логи запишет, хотя можно и только старые логи, да

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

f%ck

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

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

wota ★★ ()

В этой системе есть маленькая проблема: атакующий не должен о ней знать.

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

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

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

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

Глупость.

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

В этой системе есть маленькая проблема: атакующий не должен о ней знать.

Эта проблема - у тебя в голове.

mironov_ivan ★★★★★ ()

А можно сохранить существующий лог, сделать свои тёмные дела, а затем восстановить лог?

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

Проблемы нет. Атакующий не должен знать начального секретного ключа, поэтому на хосте его не хранят. Без него он не сможет подделать логи.

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

А можно сохранить существующий лог, сделать свои тёмные дела, а затем восстановить лог?

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

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

Не менее интересно: зачем жить, если мы все рано или поздно умрем?

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

При достаточной подготовке секретный ключ разве нельзя извлечь из памяти процесса journald?

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

видимо, чтение/запись лог-файлов тоже надо логировать :)

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

из памяти процесса journald?

он определенно будет на диске, иначе банальное отключение света все сломает

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

Его там нет. Я же написал, что секретный ключ на хосте не храниться, то есть ни на диске, ни в памяти.

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

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

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

Я же написал, что секретный ключ на хосте не храниться, то есть ни на диске, ни в памяти.

А подпись как выполняется? У journald должно быть что-то, иначе он не отличается от процесса взломщика.

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

Его там нет. Я же написал, что секретный ключ на хосте не храниться, то есть ни на диске, ни в памяти.

Браво! :-]

А ничего, что лог подписывать будет просто нечем? Лучше бы SELinux назвали в качестве аргумента, честное слово.

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

хотя опять же - плевать на сохранение старых логов, плевать на подписи, достаточно подправить выдачу логов админу + сделать свое логирование, чтоб не терять новые логи

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

opennet.ru

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

at ★★ ()

Теперь их двое! Вот это прогресс ждёт линукс!

А то эти закостянелые линупсы (да-да, я про Убунту и Арч) уже надоели.

Versed ()

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

вот это грибы

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

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

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

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

Секретным ключом подписывается только первая запись. После чего он удаляется. Остальные подписываются по цепочке.

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

Чтобы отрезать последние записа надо по крайней мере остановить systemd. Попробуйте становить инит удаленно.

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

Остальные подписываются по цепочке.

что не дает простой возможности вставить или удалить что- либо из середины, не больше, как я уже писал, «забываешь» последние логи и пишешь дальше, вполне вероятно для этого даже systemd править не надо, только обрезать файл с логами и перестартовать journald, что он дальше вел лог

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

остановить systemd.

а разве там не отдельный journald?

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

Остальные подписываются по цепочке.

Либо это нечто сакральное и мне непонятное, либо все данные, необходимые для последующих подписей, таки присутствуют в памяти процесса.

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

Так лог же бинарный. Хрен поймёшь, откуда резать.

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

wota ★★ ()
Ответ на: комментарий от wota
root@home:~# ps -A | grep jour
  226 ?        00:00:07 systemd-journal
root@home:~# kill -9 226
root@home:~# ps -A | grep jour
 4313 ?        00:00:00 systemd-journal

Т.е. остановить не получается. При принудительном завершении systemd его поднимает.

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

При принудительном завершении systemd его поднимает.

и это как раз то, что и надо - перезапустить его, чтоб он перечитал файл

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

Х.з. надо будет попробовать. У меня нет версии с подписываемым журналом. На дебиане пока не собирается.

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

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

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

P.S. мне также интересно, как он отреагирует если я изменю логи, загрузившись с внешнего носителя.

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

по идее он должен «не заметить» подмены и вести лог дальше

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

При принудительном завершении systemd его поднимает.

Заменить бинарь и прибить?

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

Насколько понял одно не исключает другого. У меня сейчас логи дублируются на выделенных хост. Как выйдет хотя бы бета RHEL7 посмотрю как будет работать на тестовой площадке. Пока это делать рано.

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

Попробую сделать как соберу. На дебе он собираться пока не хочет.

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

localhost ~ # mv /usr/lib64/systemd/systemd-journald /usr/lib64/systemd/systemd-journald_
localhost ~ # ps -A | grep journal
23977 ? 00:00:00 systemd-journal
localhost ~ # kill -9 23977
localhost ~ # ps -A | grep journal
localhost ~ # mv /usr/lib64/systemd/systemd-journald_ /usr/lib64/systemd/systemd-journald
localhost ~ # ps -A | grep journal
localhost ~ #

Дохнет намертво и уже не респаунится.

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