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

[Hristo Erinin <erinin@xxxxxxxxx>]

Здравейте,


On Fri, 11 Mar 2005 13:38:51 +0200
Vasil Kolev wrote:

> On пт, 2005-03-11 at 13:24 +0200, Aleksandar Valchev wrote:
> > >
> > И това си го мислех, ама на малката ми глава й е трудно да понесе
> > толкова мислене. 
> > Дали защитата не става, ако при самата компилация на изпълнимия файл
> > да се подава -Dнещо-си. Това "нещо-си" да е значимо за криптирания
> > файл с паролата или за самия изпълним файл. Това са много сурови
> > идеи. А дали съществува нещо като фускацията при Java-та. Там в
> > jar-овете се поставят запазени думи като if, else, while.
> 
> Спомням си само една горе-долу прилична система за такава защита, тя
> представляваше пресмятане на позицията на първия JMP на програмата на
> база паролата. Но каквото и да правиш, ако програмата трябва да може
> да работи без външна намеса, и някой придобие пълен достъп до
> машината, то той ще може да прави съвсем същото, което прави и самата
> програма...

Цялата идея за криптирането на базата с контролните суми на файловете
според мен е безмислена и ялова. По-добре е, ако тя се съхранява на
носител физически защитен от презапис.

Нека подчертая, че тук говоря за проверка на файловете "на живо", а не
след като сме извадили твърдия диск и сме го закачили на друга машина
или пък сме стартирали компютъра от LiveCD от сорта на DSL, Кnoppix и
т.н.. 
Ако кракера е успял да сдобие пълен контрол над машината и не
говорим за поредното script kiddie, пускащо IRC bouncer, каквото и да
правиш си загубен. Единственият смисъл да криптираш базата е, ако я
съхраняваш на друг сървър. Тогава можеш да използваш асиметричен
алгоритъм за криптирането и, така че ако някой пробие сървъра на който
се съхраняват файловте, той ще може само да я прочете, но не и да я
подмени. Всяко друго решение свързано със съхранение на паролите в
самата програма или пък изискването им от администратора е обречено на
провал. Няма измислена такава защита на компилиран код, която да не може
да бъде разбита. Една от най-известните и добре измислени е TEEE Burneye
на Team TESO (TESO ELF Encryption Engine
http://bismark.extracon.it/linux/teso/, team-teso.net/ дава 403
Forbidden). И за нея си има лечение - burndump LKM и fenris tracer. 
В края на краищата, ако нямаш изградена HA система в която да можеш да
спираш отделните машини, без да прекъсваш работата на услугите, всички
решения от рода на Aide, Tripwire и други са до голяма степен безмислени
- кой може да си позволи да спира сървъра по няколко пъти на месец/ден
(зависи от нивото на параноя) за да проверява файловете?

Ех... With paranoia you're never alone.


-- 
Best Regards,
Hristo Erinin
============================================================================
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
============================================================================