Re: lug-bg: Софтуер за следене на файлове

[Dean Stoeff <dean@xxxxxxxxxxxx>]

> Второ, предлаганата от мен схема на разследване: почива на използване
> на особеностите на пакетната система RPM. При това предполагаме, че
> всички бинарни и др. файлове, които може да са обект на интерес за
> модифициране са инсталирани от пакети и записи за тях са налични в
> локалната база на пакетната система. Ако на мен ми се налага да
> инсталирам нещо, което го няма в официалните пакети, изграждам RPM
> пакет и го подписвам. Това е правилния начин. Дори неща от рода на
> отделни скриптове не е проблемно да се инсталират на RPM пакет с
> подписи. Всякакви самоделки от рода на "make" и "make install" изобщо
> не отговарят на стратегията за построяване на сигурна система. Освен
> ако не си направите още по-самоделна система да подписвате
> продуцираните файлове. Истината е, че при пакетна система, която
> почива на електронно подписване има гъвкавост - при остраняване или
> прибавяне на пакет се опреснява базата с данни и не ви се налага да
> пипате другаде.
Супер :) пакетните системи са нещо много добро и удобно, особено когато 
си в състояние сам
да си създадеш пакетите или поне да можеш да разгледаш сорсовете за да 
си нясно какво правят.
> Тук някои хора с 200 годишно родословно дърво описаха как щяли да
> създадат база с хешове и да я криптират.
Какво против, хората с 200 годишно родословно дърво / понеже визираш мен/

> Целта е тази база да е
> ПОДПИСАНА, а не криптирана. 
И това е супер, разбира се, че може и да бъде само подписана, макар че 
ако и е криптирано още по трудно ще бъде "атакуващия" да разбере с какво 
си има работа за да прави каквито и да е промени по системата.
> Ужасявам се как хората не искат да се
> научат на елементарни неща.
Не сам съгласен с теб напротив аз лично постоянно уча нови неща, дори се 
възползвам от нещата които ти самия си писал, когато те не са обиди и 
ругатни или пък просто беполезни. 

> Защо разследването не може да се извърши върху "жива" система (т.е.
> защо ни е да е рестартираме и от диск да зареждаме rescue версия от
> CD-ROM или USB)?
Идеята /поне според мен/ е точно да се измисли алгоритъм който да бъде 
достатъчно сигурен /не 100%, а ДОСТАТЪЧНО сигурен/ да се прави на живо, 
какво значи достатъчно е въпрос на нивото на параноя.
А ако искаме да ставаме найстина много ПАРАНОЙЧНИ, неща от сорта на:

"РЕСТАРТИРАНЕ, И ЗАРЕЖДАНЕ ОТ ГАРАНТИРАНО ЧИСТ НОСИТЕЛ..." , както 
навремето казваше проф. Веселин Бончев, също не са много сигурни. Точно 
поради тая му реплика бяха измислени алгоритми как да се преодолее това. 
Малко примерче макар, че нещото не прави точно това но прави достаъчно, 
че ако се използва неговия подход лесно може да се окаже , че 
"гарантирано чистото зареждане" не е толкова гарантирано - имам предвид 
вируси от типа на Чернобил. Нима повечето машини набедени за рутери и 
сървъри , са найстина защитени така щото нищо да не може да пише при 
необходимост в БВИС /BIOS/. С такава модификация също ще се окажеш в  
ситуацията която сам  си описал по долу.
> Причините са много. Ако са засегнати системни библиотеки е на практика
> невъзможно да се установи модифицирането им.
>
> Ето ви примерче. Носите си на дискета инструмента md5sum и/или sha1sum
> и на лист хешовете на всички библиотеки. И рзчитате като изпълните
> тези инструменти от дискетата те да дадат верен резултат. Всичко би
> било прекрасно, но тези инструменти не четат директно информацията от
> файловата система. Потока се подава от библиотеките н а glibc. Няма
> проблеми те да се модифицират така, че при поискване за прочит на
> някоя библиотека, да бъде подавана немодифицираната й версия (скрита
> някъде по файловата система), а при изпълнение да се изпълнява
> модифицираната. Така чрез sha1sum или md5sum вие ще получите
> информация, че библиотеката е немодифицирана, но това няма да е така.
Като цяло мога да кажа че идеята е добра, и ако все пак имаш :

1. алгоритъм "достатъчно сигурен" , на който да се довериш за да си 
направиш проверката
2. Наистина чист источник не само на ключовете но и на съответните 
пакети /да речем CDROM/
3. алгоритъм които доверявайки се на 1) "разпознае" опит за 
неоторизирана подмяна на каквото и да е /койда е от пакетите или части 
от тях/ да го възтановява от 2)
мисля, че общо взето е това! Чакам коментари по идеята - но моля те 
савсем сериозни. Смятам, че може да се заформи интересна дискусия.
С уважение :
Деан
============================================================================
A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers).
http://www.linux-bulgaria.org - Hosted by Internet Group Ltd. - Stara Zagora
To unsubscribe: http://www.linux-bulgaria.org/public/mail_list.html
============================================================================