The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Разработчики systemd представили Journal, замену системе syslog, opennews (ok), 19-Ноя-11, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


110. "Разработчики systemd представили Journal, замену системе sys..."  +9 +/
Сообщение от Аноним (-), 19-Ноя-11, 09:24 
Объясните мне скорбному, как криптография может защитить от подделки логов на локальной машине? В рабочей системе, очевидно, имеется всё необходимое и достаточное для создания записей в логах, ведь как-то эти логи ведутся. А цепочки хэшей лишь гарантируют, что нельзя изменить стараю запись, не затронув более новые записи. Но ничто не мешает злоумышленнику стереть N последних записей и заменить их своими. Как и в git, собственно, можно изменить любую ревизию, изменив все последуюдие. В случае гита спасает то, что у всех есть актуальные копии репозитория, и можно убедиться, что хэш последней ревизии правильный. А в случае службы логов на изолированной машине этот последний хэш хранится где-то на этой же машине. Ваш msyslog примерно так и делает - хранит хэш лога в отдельном файле, по умолчанию /var/ssyslog/.var.log.messages.key. Исключительно в надежде на то, что злоумышленник об этом хэше не знает и не догадается его подделать. В общем, мы приходим к выводу, что единственный доступный способ защиты логов от подделки - хранить контрольный хэш на удалённой машине. А далее приходим к выводу, что один контрольный хэш не спасает от полного уничтожения логов, то есть, лучше на удалённой машине хранить весь лог целиком. Как, собственно, и делается давным-давно. Поздравляем тов. Поттеринга с очередным газопусканием в лужу и желаем ему дальнейших творческих успехов.
Ответить | Правка | Наверх | Cообщить модератору

111. "Разработчики systemd представили Journal, замену системе sys..."  –4 +/
Сообщение от Аноним (-), 19-Ноя-11, 09:43 
> Объясните мне скорбному, как криптография может защитить от подделки логов на локальной
> машине?

Да.

> В рабочей системе, очевидно, имеется всё необходимое и достаточное для
> создания записей в логах, ведь как-то эти логи ведутся.

Да.

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

Нет.

> Но ничто не мешает злоумышленнику стереть N последних записей
> и заменить их своими.

Вполне можно сделать так, что изменение N предыдущих записей влияет на параметры защищённого заголовка файла к примеру. Хотя во внутренней архитектуре Journal ещё не разбирался, так что как именно это реализовано Поттерингом не знаю.

> Как и в git, собственно, можно изменить
> любую ревизию, изменив все последуюдие.

В git не ставилась задача неизменности истории ревизий.

> А в случае службы логов на изолированной машине
> этот последний хэш хранится где-то на этой же машине.

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

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

А мы приходим к выводу, что рассуждения о безопасности архитектуры Journal без её изучения и без знания основ криптографии - бессмысленны.

> А далее
> приходим к выводу, что один контрольный хэш не спасает от полного
> уничтожения логов, то есть, лучше на удалённой машине хранить весь лог
> целиком.

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

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


Ответить | Правка | Наверх | Cообщить модератору

134. "Разработчики systemd представили Journal, замену системе sys..."  +4 +/
Сообщение от Макс (??), 19-Ноя-11, 12:34 
Хм. Если мы владеем рутом (и следовательно ядром), что мешает нам подцепиться к Journal или вытащить оттуда ключ, и воссоздать зашифрованный лог без компрометирующих нас записей? Я все еще не понимаю. Как-никак, вся история малвари и DRM на венде говорит о том, что локальной машине доверять нельзя, должен быть проверенный контрагент.

Насколько я понимаю, как бы оно ни было реализовано, существует только один принципиальный способ это сделать - security through obscurity, со всеми вытекающими.

Ответить | Правка | Наверх | Cообщить модератору

146. "Разработчики systemd представили Journal, замену системе sys..."  –2 +/
Сообщение от Аноним (-), 19-Ноя-11, 13:00 
> Я все еще не понимаю.
> Насколько я понимаю, как бы оно ни было реализовано, существует только один
> принципиальный способ это сделать - security through obscurity, со всеми вытекающими.

Первое утверждение правильное: ты всё ещё не понимаешь. Более того - без изучения основ криптографии - вряд-ли поймёшь.
Начать можешь с википедии, дальше - Applied Cryptography Шнайера.
Где-то через месяц понимание придёт. При усердии - уже через неделю.

Ответить | Правка | Наверх | Cообщить модератору

162. "Разработчики systemd представили Journal, замену системе sys..."  +1 +/
Сообщение от XPEHemail (?), 19-Ноя-11, 13:47 
Ну вы сокровенным знанием-то поделитесь с общественностью, не держите все в себе.
Ответить | Правка | Наверх | Cообщить модератору

309. "Разработчики systemd представили Journal, замену системе sys..."  –4 +/
Сообщение от Аноним (-), 20-Ноя-11, 12:58 
> Ну вы сокровенным знанием-то поделитесь с общественностью, не держите все в себе.

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

Ответить | Правка | Наверх | Cообщить модератору

211. "Разработчики systemd представили Journal, замену системе sys..."  +/
Сообщение от Аноним (-), 19-Ноя-11, 16:58 
> Хм. Если мы владеем рутом (и следовательно ядром), что мешает нам подцепиться
> к Journal или вытащить оттуда ключ,

А он там обязан быть? А что если начальный хеш убрали из системы?

Ответить | Правка | К родителю #134 | Наверх | Cообщить модератору

213. "Разработчики systemd представили Journal, замену системе sys..."  +/
Сообщение от Аноним (-), 19-Ноя-11, 17:01 
Но нам же нужен этот хэш для верификации лога. В таком случае верифицировать логи придется на удаленной системе (не будем же мы его компрометировать на локальной?), что делает все такое шифрование бессмысленным, ибо и так придется логи трансферить на удаленный сервер. Проще уж сразу логить на удаленную систему, как и делается сейчас - какой смысл огород городить?
Ответить | Правка | Наверх | Cообщить модератору

414. "Разработчики systemd представили Journal, замену системе sys..."  +/
Сообщение от Аноним (-), 23-Ноя-11, 16:22 
> так придется логи трансферить на удаленный сервер.

Зачем? Можно загрузить например локальный сервер с доверяемого ливцд/флехи в оффлайн режиме и произвести разбор полетов, проверив в том числе и достоверность лога. Это не требует отдельной машины. А вот отдельный сервер имеет недостаток: он баблосов стоит, бэть.

Ответить | Правка | Наверх | Cообщить модератору

136. "Разработчики systemd представили Journal, замену системе sys..."  +1 +/
Сообщение от Аноним (-), 19-Ноя-11, 12:39 
Объясните, что такого надо особенного знать про криптографию? Вот есть приватный ключ, им подписывается лог. Так ведь он находится на уже скомпрометированной системе. Неизвестно, может быть злоумышленник его давно вытащил и переписал логи, подписавшись им.

Как иначе можно сделать систему без дополняющего контрольного сервера? А я вам даже скажу - никак. Это невозможно. Так что -

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

Ответить | Правка | К родителю #111 | Наверх | Cообщить модератору

149. "Разработчики systemd представили Journal, замену системе sys..."  –1 +/
Сообщение от Аноним (-), 19-Ноя-11, 13:04 
> Объясните, что такого надо особенного знать про криптографию?

Для начала - систмы с открытым ключом, особенности использования как открытого, так и закрытого ключей. Потом - различные криптопротоколы. Потом - вдумчивое чтение книги Шнайера.


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

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

> Как иначе можно сделать систему без дополняющего контрольного сервера? А я вам
> даже скажу - никак.

До тех пор, пока ты не выполнишь предыдущие пункты - всё, что ты скажешь не имеет ни малейшего смысла.

Ответить | Правка | Наверх | Cообщить модератору

408. "Разработчики systemd представили Journal, замену системе sys..."  +/
Сообщение от anonimous (?), 23-Ноя-11, 08:44 
>> Как иначе можно сделать систему без дополняющего контрольного сервера? А я вам
>> даже скажу - никак.
> До тех пор, пока ты не выполнишь предыдущие пункты - всё, что
> ты скажешь не имеет ни малейшего смысла.

В 'предложении' Поттеринга всё должно быть локально доступно --- и для шифрования и для дешифровки. Т.е. при компрометации системы --- всё есть для того, чтобы оставить для изучения fake records.

Ответить | Правка | Наверх | Cообщить модератору

415. "Разработчики systemd представили Journal, замену системе sys..."  +/
Сообщение от Аноним (-), 23-Ноя-11, 16:23 
> В 'предложении' Поттеринга всё должно быть локально доступно --- и для шифрования
> и для дешифровки.

Он предлагал цепочку хешей. Начальный не обязан быть доступен на локалной системе.

Ответить | Правка | Наверх | Cообщить модератору

433. "Разработчики systemd представили Journal, замену системе sys..."  +/
Сообщение от anonymous (??), 24-Ноя-11, 11:56 
>> В 'предложении' Поттеринга всё должно быть локально доступно --- и для шифрования
>> и для дешифровки.
>
> Он предлагал цепочку хешей. Начальный не обязан быть доступен на локалной системе.

Как бы да, но... либо можно переписать n хвостовых участков (т.е. тех, для которых есть оба ключа), либо нужно депонировать цепочку закрытых ключей на стороне (и тогда решение с remote log-сервером выглядит более адекватным). Ну, и частота смены ключа. Чем реже его менять, тем больше времени для маскировки атаки (хвост-то можно подменить); если чаще --- то remote log-сервер становится предпочтительней.

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

Ответить | Правка | Наверх | Cообщить модератору

212. "Разработчики systemd представили Journal, замену системе sys..."  +/
Сообщение от Аноним (-), 19-Ноя-11, 16:59 
> Неизвестно, может быть злоумышленник его давно вытащил и переписал логи, подписавшись им.

Вообще-то вполне можно так сделать что вытаскивать будет нечего.

Ответить | Правка | К родителю #136 | Наверх | Cообщить модератору

114. "Разработчики systemd представили Journal, замену системе sys..."  +/
Сообщение от tmx (?), 19-Ноя-11, 09:59 
>Но ничто не мешает злоумышленнику стереть N последних записей и заменить их своими.

вот именно.

Ответить | Правка | К родителю #110 | Наверх | Cообщить модератору

164. "Разработчики systemd представили Journal, замену системе sys..."  +2 +/
Сообщение от Аноним (-), 19-Ноя-11, 14:12 
Ок, до меня дошло, как оно работает. Мы выбираем некий ключ и записываем его в файл, а также сохраняем где-нибудь в сейфе. При каждом записи в лог считается хэш от (текущий ключ + текущая запись), и полученное значение записывается вместо старого ключа. Для проверки валидности лога мы достаём из сейфа первоначальный ключ и ещё раз проделываем эти операции, последовательно вычисляя хэш от каждой записи и текущего ключа, полученное значение должно совпадать с текущим хэшем на проверяемой системе. При этом удалить записи из лога, подделав хэш, невоможно, т. к. первоначального ключа злоумышленник не знает, и старые значения хэша нигде не сохраняются.

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

Ответить | Правка | К родителю #110 | Наверх | Cообщить модератору

172. "Разработчики systemd представили Journal, замену системе sys..."  +1 +/
Сообщение от Аноним (-), 19-Ноя-11, 14:22 
Более того - при попытке открыть "сейф" на скомпрометированной машине он тоже становится скомпрометированным, так что это надо делать на посторонней машине.
Ответить | Правка | Наверх | Cообщить модератору

235. "Разработчики systemd представили Journal, замену системе sys..."  +/
Сообщение от spf (??), 19-Ноя-11, 20:28 
> и старые значения хэша нигде не сохраняются.

А как просмотреть лог с начала и убедиться в корректности данных?
Без первоначального ключа невозможно.
Каждый раз для viewlog доставать из сейфа?

Ответить | Правка | К родителю #164 | Наверх | Cообщить модератору

259. "Разработчики systemd представили Journal, замену системе sys..."  +/
Сообщение от Аноним (-), 20-Ноя-11, 00:31 
Лог не зашифрован же, ключ нужен только для проверки целостности
Ответить | Правка | Наверх | Cообщить модератору

289. "Разработчики systemd представили Journal, замену системе sys..."  +/
Сообщение от Аноним (-), 20-Ноя-11, 02:27 
Так а где его проверять-то? На локальной машине? А если там руткит сидит и заставляет проверку завершаться всегда успешно?

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

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру