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)
Ответ на: комментарий от devl547

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

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

А от удаления журналов помогает периодический бэкап.

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

Здесь есть еще одна проблема. Как сделать инкрементальный бекап бинарного файла, сравнить две версии и т.д. В документации этого не нашел. Возможно, это как то связано с вот этой системой http://people.redhat.com/sgrubb/audit/

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

С инкрементальным проблема. Если его не встроят в сам journald, то сложно. Можно каждый день копировать старый журнал и создавать новый. Будет 1 день - 1 файл.

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

С инкрементальным проблема. Если его не встроят в сам journald, то сложно.

Вот этого я пока и не вижу, хотя вещь нужная. Надеюсь это появится хотя бы до беты RHEL.

Можно каждый день копировать старый журнал и создавать новый. Будет 1 день - 1 файл.

Это более неудобное решение, чем существующее. Причем не сильно лучше его в плане безопасности. Если есть возможность периодически сливать логи проще настроить сислог.

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

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

Для инициализирующей записи. Без разницы, как она сделана. Важно то, что после нее никаких подписей не предусмотрено.

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

Почему нерабочая?

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

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

Сейчас у меня настроен сислог везде, где возможно. РедХат предлагает систему с бинарными логами, причем модуля сислога там пока(?) нет. Бекапить бинарный файл с прибиванием сислога выглядит несколько странно.

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

На данный момент логи собирает специально выделенная машина, на серверах они не хранятся. Т.е. стандартная схема.

В предлагаемом РедХатом решении (journald) модуля для отправки на удаленный хост нет. Хотя, возможно, они его еще не написали.

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

Записи подписываются. См. новость. Если бекапить его без остановки логирования стандартными утилитами возможно получить нечитаемый файл. В оракле, mysql и т.д. для этого есть специальные утилиты, которые и следят за целостностью. Чего то подобного для journald я не нашел.

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

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

Там ситуация такая. Сетевого лога нет и никогда не будет. Есть форвардинг логов в syslog. В journald логи хранятся не в одном файле. Более того, для каждой «сессии» - своя серия. Логи дробятся по размеру и по времени.

scripts > find /var/log/journal -type f | wc -l  
21

Так что можно просто брать архивные, и копировать

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

Сетевого лога нет и никогда не будет.

Вот это мне и не нравится. Логи надо собирать не только с серверов.

Логи дробятся по размеру и по времени.

У меня один файл. Скорей всего зависит от настроек. У меня пока дефолтная конфигурация.

Т.е. возможно разбить логи по времени? Спасибо. Это немного лучше.

Осталось понять как верифицировать логи на удаленном хосте. Новая версия systemd у меня пока не собирается.

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

Для инициализирующей записи. Без разницы, как она сделана. Важно то, что после нее никаких подписей не предусмотрено.

Гм. И как же ты собирешься подделать цепочку лога?

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

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

Не может, для этого ему нужны данные, использовавшиеся для хеша первой записи, которые хранятся у админа под подушкой.

Legioner ★★★★★
()

А что слабо было это прикрутить к существующим логам? Да хоть дублированием.. Кому надо - пожалуйста... 90% в гробу видели эти бинарные логи с подписями... Кроме плюса что видно место где проникли (если журнал не удален) не видно...

anonymous
()

Епрст, ну хорошо, энтерпрайзу самое оно, но зачем это в моей уютной фидорке?!

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

равносильно сбою при работе винта/ФС, например... ну или аналогичному страшносистемному багу.

anonymous
()

Бертрамом Поттеринг

ОНИ НА СВЕТ ЛЕЗУТ!

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

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

Значит, админ генерит пару ключей, закрытый оставляет серверу, а открытый выписывает себе. Сервер после каждой новой записи в лог генерирует новую пару, приписывает новый открытый ключ к этой записи и подписывает лог или последнюю запись старым закрытым, после чего безвозвратно стирает старый из памяти. Таким образом он отсекает самому себе возможность подменить лог.

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

segfault ★★★★★
()
Последнее исправление: segfault (всего исправлений: 1)
Ответ на: комментарий от segfault

Значит, админ генерит пару ключей, закрытый оставляет серверу, а открытый выписывает себе. Сервер после каждой новой записи в лог генерирует новую пару, приписывает новый открытый ключ к этой записи и подписывает лог или последнюю запись старым закрытым, после чего безвозвратно стирает старый из памяти. Таким образом он отсекает самому себе возможность подменить лог.

Не совсем так. Исходники не изучал, но как-то так.

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

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

открытый оставляет серверу, а закрытый прячет у себя под подушку.

Ну да, если б ничего не было вывернуто наизнанку, то ПО писал бы не Поттеринг =)

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

процессоры сейчас имеют aes_enc инструкции,которые делают аес-кодирование блока за один шаг, так что надо думать что не слишком ресурсоёмко в случае если будут пользовать aes как prp.

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

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

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

не обязательно хранить ключ, достаточно использовать его для инициализации, как я понимаю.

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

Не может, для этого ему нужны данные, использовавшиеся для хеша первой записи, которые хранятся у админа под подушкой.

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

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

Ну да, так и надо. Или хранить вечно или очищать все логи, сохраняя новый ключ для проверки. Разве тут есть какая-то проблема?

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

Ну да, так и надо. Или хранить вечно или очищать все логи, сохраняя новый ключ для проверки. Разве тут есть какая-то проблема?

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

Хранить логи вечно - кто себе может такое позволить? Для кого логи сильно важны, те и так хранят их на write-only удалённом сервере, канал к которому может быть завёрнут в ipsec.

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