The OpenNET Project / Index page

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



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

Оглавление

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

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


80. "Разработчики systemd представили Journal, замену системе sys..."  +18 +/
Сообщение от Andrew Kolchoogin (?), 19-Ноя-11, 05:02 
+100500! :)

Никак не спасёт. Поттеринг просто немного перегрелся.

Никакая криптография и проч. не спасает от тамперинга логов. Только вынос лога на отдельный, недоступный из Интернета сервер. Всё.

Вообще, у Поттеринга, как и у любого другого человека, есть идеи удачные, и не очень.

Небольшой debriefing лично от меня, как от человека, администрирующего Юникс последние лет 15 (или больше уже?):

I. systemd. В принципе, идея верная, но это reinvention of wheel. Был же launchd от Apple, чем плох? Ах, да, лицензия, как же, как же...
Но init, действительно, давно и безнадёжно устарел. В старые добрые времена особенно много зависимостей сервисов друг от друга сделать было просто физически невозможно: машинки были слабыми. Как правило, на одной физической машине работал Apache, на другой -- SQL, на третьей -- почтовка, ну и так далее. Поэтому, по большому счёту, всё равно, что там, как и когда запускалось. Не работает -- саппорт машину перезагрузит по звонку админа, и дело с концом. Другие сервисы не пострадают (они на другом физическом железе), а этот и так упал.

Но времена изменились, и теперь на одном физическом хосте можно собрать всё вместе и сразу.
Нет, конечно, это не очень правильно -- правильно сделать облако, виртуалки на нём и т.д. Но в 70-80% случаев оверхед от администрирования облачной инфраструктуры будет сравним с затратами на администрирование того, что на этой инфраструктуре крутится.
Кто его оплатит? Теоретики "облачности"? Сомневаюсь.
Так что интеллектуальный пускач-следилка по сути. Но, опять-таки, systemd -- это изобретение колеса.

II. Сломанная загрузка без /usr. Не стреляйте в Поттеринга -- это не его рук дело. Дело в корявых софтоархитекторах.

Директории /sbin и /usr/sbin имеют буковку "s" в своём названии не зря -- они имеют оную буковку потому, что подразумевалось, что все бинарники в них -- STATICALLY linked.
Тот, кто это сломал -- сломал и загрузку без /usr. Да, можно вынести часть библиотек в /lib, без проблем, но библиотеки написаны так, что без /usr/share половина из них не работает. Ну и так далее.

III. PulseAudio. Ну, опять-таки, reinvention of wheel. Был NAS. Он СПЕЦИАЛЬНО был сделан для ремотного проброса аудио. Использует аутентификацию X'ов. Но лих же, нет! Надо было своё, с шахматами и поэтессами, придумать!
А те, кто кричит, что звуковой сервер в UNIX'е не нужен, идут в сад. Тривиальности про Terminal Server мы опустим сразу, тут и так всё понятно.
Вот смотрите: у вас есть, к примеру, Asterisk. Стоит он чёрт-те где, за семью замками, за семью дверями, рядом с SDH'ным барахлом ГТС. Ходят к нему абоненты. Через SIP. И начинают вам жаловаться, что у них-де "плохо слышно". Как проверить? Правильно, встать столом на линию абонен... Ой, про что это я? Ах, да. Позвонить абоненту со станции, вот. Да-да, "console dial ...". И как вы это будете без звукового сервера слушать? За семь замков, за семь дверей пешком пойдёте?
Идея подключиться к станции SIP-клиентом и позвонить порочна по сути. Ну услышите вы, что плохо слышно. Это у вас SIP-клиент кривой, или у абонента?

IV. Логгер. Ну, тут всё вообще хорошо. Во-первых, msyslog тыщщу лет как умеет криптографически логи подписывать. Во-вторых, для того, чтобы что-то подписывать, совершенно необязательно перетаскивать всё это в бинарный формат. В третьих, "каждый процесс может представиться Apache с PID 4321" -- ну да. Вы от remote logging'а откажетесь, или по сети будете проверять?

Ну и таки да -- от "cat /dev/null > /var/log/whatever" это всё равно не спасёт. :)

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

91. "Разработчики systemd представили Journal, замену системе sys..."  –4 +/
Сообщение от Аноним (-), 19-Ноя-11, 08:25 
> Никакая криптография и проч. не спасает от тамперинга логов. Только вынос лога
> на отдельный, недоступный из Интернета сервер. Всё.

Ты даже русский толком не знаешь, а пытаешься иностранными словами щегольнуть.
Tampering - это как раз "подделка\изменение" логов и криптография от него отлично спасает.
А простое удаление это wiping, который заметен сразу.

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

148. "Разработчики systemd представили Journal, замену системе sys..."  +/
Сообщение от Andrew Kolchoogin (?), 19-Ноя-11, 13:01 
> Ты даже русский толком не знаешь, а пытаешься иностранными словами щегольнуть.

Учителя русского языка так не считают.

> Tampering - это как раз "подделка\изменение" логов и криптография от него отлично спасает.

Вообще говоря, "tampering" -- это любая манипуляция. Фальсификация в частности.

> А простое удаление это wiping, который заметен сразу.

Если буквоедствовать, то "cat /dev/null >" -- это не удаление.

Короче, Онанизмус как всегда. ;)

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

150. "Разработчики systemd представили Journal, замену системе sys..."  –3 +/
Сообщение от Аноним (-), 19-Ноя-11, 13:10 
Как я предполагал - облажался и стал буквоедствовать. Если действительно "никакая криптография не спасёт от подделки", то подделай логи для Поттеринговской реализации и выложи proof-of-concept.

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

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

155. "Разработчики systemd представили Journal, замену системе sys..."  +/
Сообщение от Michael Shigorinemail (ok), 19-Ноя-11, 13:24 
> Как я предполагал - облажался и стал буквоедствовать.

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

to wipe можно как файл, так и данные.  Это различные операции и к tampering относятся обе, хотя обычно последний термин применяют, говоря о модификации, а не уничтожении тех же логов.

> Если действительно "никакая криптография не спасёт от подделки", то подделай логи
> для Поттеринговской реализации и выложи proof-of-concept.

Я чуть ли не каждый день пользуюсь git rebase и пока не с чем сверять снаружи -- такую "подделку" можно обнаружить разве что до git prune (или git gc через пару недель с дефолтным таймаутом, если уж докапываться).

> Впрочем, тебе не просто слабо - ты даже не знаешь с какой
> стороны взяться за подобное.

Слушайте, а давайте-ка *Вы* предъявите общественности плоды своего понимания криптографии и обсуждаемого, набросав PoC для переписи истории таких логов при условии возможности поправить и лежащий локально начальный хэш.  А мы дружно посыпем головы пеплом и извинимся, что не разглядели в трамвайном хаме хотя бы специалиста.

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

167. "Разработчики systemd представили Journal, замену системе sys..."  +/
Сообщение от Аноним (-), 19-Ноя-11, 14:14 
>> Если действительно "никакая криптография не спасёт от подделки", то подделай логи
>> для Поттеринговской реализации и выложи proof-of-concept.
> Я чуть ли не каждый день пользуюсь git rebase и пока не
> с чем сверять снаружи -- такую "подделку" можно обнаружить разве что
> до git prune (или git gc через пару недель с дефолтным
> таймаутом, если уж докапываться).

Ну что, можно засчитывать слив? :)
1. Есть тупое утверждение, что "никакая криптография не спасёт от подмены логов".
2. Есть разумное предположение, что криптография очень даже может предотвратить изменение логов.

Для утверждения №2 есть предварительная реализация Поттеринга, описанная в новости.
Для утверждения №1 есть только потрясающе "умная" аргументация как кто-то "использовал git rebase", не имеющий к исходному вопросу вообще никакого отношения.

Ещё есть вопросы, почему я считаю утверждение №1 тупым?

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

174. "Разработчики systemd представили Journal, замену системе sys..."  +1 +/
Сообщение от Michael Shigorinemail (ok), 19-Ноя-11, 14:26 
> Ну что, можно засчитывать слив? :)

Уже засчитали.

> 1. Есть тупое утверждение, что "никакая криптография не спасёт от подмены логов".

Это утверждение не тупое, хотя в некоторых случаях неверное -- в данном (подписывание, не шифрование) верное.

> 2. Есть разумное предположение, что криптография очень даже может предотвратить
> изменение логов.

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

> Ещё есть вопросы, почему я считаю утверждение №1 тупым?

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

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

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

201. "Разработчики systemd представили Journal, замену системе sys..."  +/
Сообщение от Аноним (-), 19-Ноя-11, 16:45 
> Я чуть ли не каждый день пользуюсь git rebase и пока не
> с чем сверять снаружи -- такую "подделку" можно обнаружить разве что
> до git prune (или git gc через пару недель с дефолтным
> таймаутом, если уж докапываться).

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

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

210. "Разработчики systemd представили Journal, замену системе sys..."  +1 +/
Сообщение от Michael Shigorinemail (ok), 19-Ноя-11, 16:57 
> А тут будет базовый хеш от которого танцы

Не-не, сама идея понятна и уместна.

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

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

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

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

401. "Разработчики systemd представили Journal, замену системе sys..."  +/
Сообщение от Аноним (-), 22-Ноя-11, 20:45 
> Базовый хэш нужен для проверки логов, следовательно логи придется все равно тащить
> логи на доверенный сервер, чтобы там проверить подпись.

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

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

295. "Разработчики systemd представили Journal, замену системе sys..."  +/
Сообщение от vi (?), 20-Ноя-11, 03:46 
>> Я чуть ли не каждый день пользуюсь git rebase и пока не
>> с чем сверять снаружи -- такую "подделку" можно обнаружить разве что
>> до git prune (или git gc через пару недель с дефолтным
>> таймаутом, если уж докапываться).
> А тут будет базовый хеш от которого танцы, недоступный хаксору в идеале.
> С помощью которого можно проверить - надули нас или нет.

Простите, бедного, слепого и прочего необученного (за глупые вопросы).
Если мы можем:
>Ну и таки да -- от "cat /dev/null > /var/log/whatever" это всё равно не спасёт. :)

то разве мы не можем cat /dev/mem | grep "базовый хеш" ?
или полюбовно договорится с новоявленной поделкой, ну например о том, что логгировать, а что нет?

Спасибо.

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

218. "Разработчики systemd представили Journal, замену системе sys..."  +6 +/
Сообщение от гость (?), 19-Ноя-11, 17:29 
>> Никакая криптография и проч. не спасает от тамперинга логов. Только вынос лога
>> на отдельный, недоступный из Интернета сервер. Всё.
> Ты даже русский толком не знаешь, а пытаешься иностранными словами щегольнуть.

И вообще, разве нас может интересовать мнение человека лысого, с таким носом? Пусть сначала исправит нос, отрастит волосы, а потом и выскажется. (с) Жванецкий

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

Давайте посмотрим, что нам вообще дает среднестатистическая система защиты логов  криптографией в вакууме.

- Она гарантирует целостность уже записанных данных? Да.
- Она гарантирует аутентификацию процесса (именно нужный процесс записал в лог)? Нет.
- Она гарантирует сохранность уже записанных данных? Нет.

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

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

407. "Разработчики systemd представили Journal, замену системе sys..."  +/
Сообщение от anonimous (?), 23-Ноя-11, 08:34 
> - Она гарантирует целостность уже записанных данных? Да.

Не совсем. Поскольку всё --- локально доступно, то есть возможность создать фальшивую историю и подписать её. Данные будут целостными, но фальшивыми.

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

269. "Разработчики systemd представили Journal, замену системе sys..."  +/
Сообщение от Аноним (-), 20-Ноя-11, 00:58 
> Был же launchd от Apple, чем плох? Ах, да, лицензия, как же, как же...

systemd пофичастее будет. Да и к технологиям линукса поближе (вряд ли в апстрим lanuchd добавят механизмы на основе fanotify, autofs4 и т.д.)
Каждому свое.

> В третьих, "каждый процесс может представиться Apache с PID 4321" -- ну да. Вы от remote logging'а откажетесь, или по сети будете проверять?

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

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

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

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




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

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