Сергей ЯРЕМЧУК
Превод Zerg
N 9
(284) 01.03.2004
За съжаление, абсолютно
защитени системи все още не са измислени — готови програми за проникване
във всяка от съществуващите, както и описание на съответните технологии, може
да се намери в открити източници. Старите дупки в операционните системи и
сервизи с времете благополучно се сменят с нови, и на този процес не се вижда
края. Твърденията на поддръжниците на ОС GNU/Linux за това, че тази система е доста
по защитена от системите на Microsoft, ми се струват донякъде преувеличени. Да,
аз съм съгласен, възможността за пряк анализ на кода на системата, без
необходимост от нейното диасемлиране,съществено облекчава търсенето на
уязвимости — въпроса е в това, кой първи ще открие тази уязвимост. До
неотдавна Linux, както и Unix в цяло, ги спасяваше фрагментацията —
наличие на голямо количество дистрибутиви и операционни системи, а също и
различието на влизащите в състава им приложения или техни версии. Тази безразборност
не способстваше до появата на големи вирусни епидемии, характерни за Windows,
основния код на която едва ли се е преработвал толкова съществено от версия към
версия. Но в последно време се забелязва тенденция към намаляване на
спасителното разнообразие, и как ще бъде по натакък е неизвестно. Може, разбира
се да се вика, тропа с крака, пише в писма и форуми, но действително добри
аналитични материали, сравняващи архитектурите на Linux и Windows, в Интернет
не са чак толкова много — ПО голямата част от статиите са основани на
емоцията. Различните статистики на фиксираните пробиви, сами по себе си не
говорят нищо, а отразяват разпространеността на системите, пък и истинска пълна
статистика не знае никой, за много пробиви пострадалите предпочитат да премълчат.
Между впрочем и в Unix/Linux-системите също има всякъкви вируси, червеи,
троянски коне, rootkits и други твари. Принципа «това не може да бъде, защото
не може да бъде никога» — е лоша основа за защита.
За да бъдем справедливи трябва да
отбележим, че все пак общата култура за защита на потребителите на системите Open Source е развита по добре.
Няколко причини способстват за това. Все пак, каквото и да си говорим, средно
статистическия Linux-потребител е по подготвен, той знае, че компютърния вирус
— това е( колкото и странно да звучи) само една програма, която трябва да
стартираш на своя компютър (не всички използват уязвимости в тези или онези
сервизи). Допълнителна отговорност върху разработчиците и допълнителен контрол
от страна на потребителите се налага от разпространението на програмите в
изходен код. Да се добвят две три функции, отварящи достъп до компютъра —-
лесна работа —- да прекомпилира rpm-пакети иска/може не всеки. А за това за
нови програми се ходи на тези ресурси, на които напълно се доверяват, и които
се безпокоят за своята репутация (домашната страница на програмата, специални
сайтове като http://rpmfind.net/
и http://www.freshports.org/).
На домашната страница на Васил Пупкин едва ли си срува да се ходи за новата
версия на XMMS. Така също всеки уважаващ себе си разработчик или
разпространител на ПО редом със своята програма в отделен файл като
checksum.md5 (и/или вътре в отелен файл) поставя контролната сума, която
може веднага да се провери. Такава проверка по алгоритъма MD5 по възможност
гарантира, че в файла няма промени, и пред вас е действително оригинал.
Да се разбере контролната сума на
сваления файл е много просто (помощната програма md5sum е в наличност
във всеки дистрибутив— ако я няма може да се вземе от http://www.gnu.org/software/textutils/textutils.html):
# md5sum /home/sergej/aide/aide-0.10.tar.gz
39eb7d21064cac7b409c45d038b86cd8 /home/sergej/aide/aide-0.10.tar.gz
Сега, сравнявайки стойностите на
контролната сума, дадена от програмата, с посочената във файла, може да
направим извод за оригиналността на файла. Аналогично, купувайки дистрибутив
някъде на пазара, е желателно за успокояване на душата да посетим сайта на
производителя и да изясним контролната сума на поставените iso-образи или
отделни приложения. Проверката на контролната сума изобщо трябва да стане навик
при всяко инсталиране на програмни средства. В FreeBSD-системите при отсъствие
в дистрибутива на нужната програма или версия, преди да се обърнем към сайта
или да компилираме от изходен код, трябва да се обърнем към дървото на пакетите
или портове. Ако програмата е включена в тях, тогава тя е преминала
тестиране на съвместимост/безопасност и в крайна сметка няма да стане причина
за крах на системата. В този случай контролната сума се проверява автоматично
при инсталирането, без явното участие на потребителя. И това е най простия и
безопасен способ да се постави ново ПО.
Случва се, че компилацията с
помоща на портове, в това число и по причина на неправилна контролна сума,
завършва с грешка. В този случай може да помогне обновяването на дървото на
портовете. В края на краищата, винаги може да се обърнете за помощ към човека
поддържащ съответния порт ( MAINTAINER).
Да разберете неговия електронен
адрес е много просто. Влезте в каталога на нужния порт и дайте командата:
# more Makefile | grep MAINTAINER
MAINTAINER= anarcat@anarcat.dyndn.org
Изпратете на този адрес изхода от
компилатора и информация за системата (uname ), и не забравяйте предварително
да благодарите за помощта.
С помощта на контролната сума
може не само да се проверяват инсталираните програми Ако злоумышленика все-пак
е успял да проникне в мрежата, то неговото първо действие, най вероятно, ще
бъде инсталирането или изменението на някои програми. Например, той може
да замени стандартната и често
използвана програма ps на друга, с «троянец» вътре, а командата ls може
да не забележи създадените от него каталози. За да избегнат откриването си от,
например, командата find, такива програми «умеят» да имитират времето на
създаването си, но да се организира подправена контролна сума е къде по сложно.
Тези, които използват
rpm-based-дистрибуции, могат за контрол на целостта на системата да се
възползват от възможностите на мениджъра на пакети. Когато се инсталира
нова програма, то данните за пакета в цяло и отделните файлове, негови
съставляващи, в това число и контролната сума, се записват в база данни. Затова
въвеждайки командата
# rpm -Va > file
може да се получи представа за
променените файлове (и за самолично развалените също). Ако файла се окаже
празен, то промени няма— наистина, това още не означава, че системата е чиста.
Но ако се появят подобни редове:
# rpm -Va
S.5....T c /etc/hotplug/usb.usermap
S.5....T c /etc/sysconfig/pcmcia
то изменените файлове е
необходимо да се проверят. Опции:
• M — различава се
състоянието (включително разширение и тип на файла);
• S — различава размера на
файла;
• 5 — различава се сумата
MD5;
• D — не съответства
броя основни/второстепенни устройства;
• L — не съответства
пътя readLink(2);
• U — различава се
потребителя-собственик;
• G — различава се групата-
собственик;
• T — различава се mTime.
Ако, както в показания пример,
това са конфигурационни файлове, които, естествено, са длъжни да се променят,
то нищо страшно няма. Но ако има
файлове от каталозите, съдържащи изпълними файлове, то е редно да застанем
нащрек. При помощта на командата rpm -qf /path/to/file може да проверим, явява
ли се дадения файл част от пакета. Намерените изменения може — естествено,
предварително запазвайки съхранениет файлове за по нататъшно изследване —
веднага да възстановим:
# rpm -i --force
Но това не е всичко. По простото
и ясно структурирано файлово дърво във всички Unix-системи, в които изпълнимите
файлове, конфигурационните файлове, постоянно променящите се файлове (например,
лог-файловете) и други лежат в различни клонове на дървото, позволява не само
да се изнесат цели дискови раздели в read-only или да се ограничи достъпът до
тях на ниво ядро с помощта на специални кръпки (патчове), но и да се контролира
целостта на нужните файлове. В Windows, например, да се изпълни подобна задача
е доста по сложно, тъй като ще се наложи да се обхване голям обем данни
(програмата пише данни, необходими за работата и, там където счете за нужно
нейния създател, и за това те са разхвърляни по целия диск). Впрочем, отделни
решения съществуват— именно с тяхна помощ успяваме да разберем за това, че нещо
или някой е опитвал да измени без знанието на стопанина на компютъра регистъра
и други критични области с данни. Например, WinPatrol. Така прилагането на
специално обучени програми, проверяващи целостта на системните файлове, може да
е това крайно средство, което ще попречи на злоумишленика да се закрепи на
вашия компютър.
Сред Open-Source програмите,
предназначени за автоматизация на процеса на изчисляване на контролни суми и
даване на резултат от сравняването, най популярни са Tripwire ( http://www.tripwire.org/) и
AIDE — Advanced Intrusion Detection Environment ( http://www.cs.tut.fi/~rammer/aide.html
или http://sourceforge.net/projects/aide).
Някоя от тях определено ще намерите във вашия дистрибутив, макар че се случва
да са поставени и двете. Днес ще видим как се настройва и използва AIDE.
Програмата AIDE е тествана и
работи на повечето Unix-системи: Solaris, Linux, FreeBSD, Unixware, BSDi,
OpenBSD, AIX 4.2, TRU64 4.0x и под Cygwin.
Инсталирането и не е особено
сложно. Разопаковаме архива и компилираме по обикновения начин:
# tar -xzvf aide-0.10.tar.gz
#cd aide-0.10
# ./configure
#make
#su
$make install
В качеството на допълнителни
опции мога да препоръчам –with-zlib за да е възможно използване на
zlib-компресия и –with-psql за съхранение на данни върху външна база данни РostgresSQL.
Ако компилацията е преминала
нормално, е време да се заемем с конфигурационния файл. Той се нарича
aide.conf, и след инсталиране се намира в директорията /usr/local/etc. Да го
разчоплим върху дадения пример (макар и на сложен — за нормална работа е
достатъчно само да покажем проверяваните директории).
# AIDE conf
# база данни, за четене, —
желателно е да се копира в недостъпно място(по подразбиране е ./aide.db)
database=file:/var/lib/aide/aide.db
# местоположението на
новосъздаваната база данни (./aide.db.new)
database_out=file:/var/lib/aide/aide.db.new
# ако програмата е компилирана
с поддръжка на zlib, то по този начин се включва архивирането на данните за
икономия на място
gzip_dbout=yes
# тук за справка са описани
всички възможни параметри, изменението на които може да контролира AIDE
#
#p: permissions — изменение на правата
#i: inode — изменение на inode
#n: number of links — изменение на количеството препратки
#u: user — изменил се е потребителя
#g: group — групата
#s: size — размера
#b: block count — индекса на блока
#m: mtime — време на модификации
#a: atime — време на достъпване
#c: ctime — време на създаване
#S: check for growing size — проверка за изменение/нарастване
на размера
# конролни суми по съответните алгоритми
#md5: md5 checksum —
#sha1: sha1 checksum
#rmd160: rmd160 checksum
#tiger: tiger checksum
#haval: haval checksum
#gost: gost checksum
#crc32: crc32 checksum
# предустановки,
сгруппированные под определенные задачи
#R: p+i+n+u+g+s+m+c+md5
#L: p+i+n+u+g
#E: Empty group (празна група т.е. нищо не се контролира)
#>: Growing logfile p+u+g+i+n+S (това е за
постоянно увеличаващи се файлове)
# и самостоятелно създадени от
потребителя
Binlib =
p+i+n+u+g+s+b+m+c+md5+sha1
ConfFiles =
p+i+n+u+g+s+b+m+c+md5+sha1
Logs = p+i+n+u+g+S
Devices =
p+i+n+u+g+s+b+c+md5+sha1
Databases = p+n+u+g
StaticDir = p+i+n+u+g
ManPages = p+i+n+u+g+s+b+m+c+md5+sha1
# в редовете долу се задават
директории и правила, които ще се контролират, макар и за проверка на цялата
система може да се използва просто / R; забележете също, че се прилагат
регулярни изрази
# такава конструкция добавя
само директорията /boot без поддиректории
=/boot$ Binlib
# всичко, което е по долу, ще
бъде заобиколено рекурсивно
/bin Binlib
/sbin Binlib
/usr/bin Binlib
/usr/sbin Binlib
/usr/local/bin Binlib
/usr/local/sbin Binlib
/usr/games Binlib
/lib Binlib
/usr/lib Binlib
/usr/local/lib Binlib
# надолу, както виждате,
се прилагат вече други правила
/var/log$ StaticDir
/var/log/aide/aide.log(.[0-9])?(.gz)?
Databases
/var/log/aide/error.log(.[0-9])?(.gz)?
Databases
/var/log/setuid.changes(.[0-9])?(.gz)?
Databases
/var/log Logs
# директории /dev и /proc ще
бъдат изключени от списъка на проверяваните
!/dev
!/proc
Както виждате, единствения
проблем се състои в това да определим към кои директории да приложим правилата
за да избегнем повторения и лъжливи тревоги. Впрочем, след две три преминавания
на конкретната система, правилата могат да се коригират според ситуацията. Във
файла също е възможно поставянето на променливи — например, в реда @@define
MAILTO root на променливата MAILTO се присвоява стойност root. При следващо
пускане на aide с помощта на cron (виж статията на Сергей ПАРИЖСКИ
«Пингвин на автопилот», МК №50 (273)) отчета за работата ще бъде
изпратен на указаният адрес. След задаване на правилата ги записваме и
създаваме база. За целта стартираме програмата aide с параметър –i:
# aide -i
Това действие ще създаде база и
ще я съхрани в database_out, в нашия случай това е /var/lib/aide/aide.db.new.
Това е основната база, с която ще сверяваме в бъдеше. При това е желателно
базата да се съхранява на отделен носител, като по този начин я защитаваме от
модификации. Например, като я съхраним на дискета:
#mount /dev/fd0 /mnt/floppy
#mv /var/lib/aide/aide.db.new /mnt/floppy/
И без да задаваме каквато и да е
стойност на променливата database във файла aide.conf,след това при проверка я
монтираме, влизаме в каталога и даваме команда за проверка.
#mount /dev/fd0 /mnt/floppy
#cd /mnt/floppy
#aide --check
Ако изхода е голям, което не може
да се избегне при първоначална настройка, пренасочваме изхода към файл:
#aide –check > ~/check
И гледаме, какво се е променило
след създаването на базата. Във файла ще видим приблизително такива редове:
Start timestamp: 2004-02-12 16:54:09
Summary:
Total number of files=54989,added files=2,removed files=2,changed files=54818
Added files:
added:/var/lib/xdm/authdir/authfiles/A:0-Q5jFPJ
added:/var/lib/aide/aide.db
Removed files:
removed:/var/lib/xdm/authdir/authfiles/A:0-v8GwFo
removed:/var/lib/aide/aide.db.new
Changed files:
changed:/opt/pbs/lib/xpbs
changed:/opt/pbs/lib/xpbs/bin
Directory: /bin
Atime : 2004-02-12 09:54:53 , 2004-02-12 16:50:34
Mtime : 2004-02-02 14:12:13 , 2004-02-12 16:44:19
Ctime : 2004-02-02 14:12:13 , 2004-02-12 16:44:19
File: /bin/dd
Atime : 2004-02-12 09:50:51 , 2004-02-12 16:45:02
File: /bin/ash
Atime : 2004-02-12 09:50:51 , 2004-02-12 16:45:02
Ctime : 2004-01-31 21:12:55 , 2004-02-12 16:44:19
И т.н.
Веднага се вижда, какво става в
системата и каква информация следва да се изключи от контрола, за да не претоварваме
изхода. Така, например, за изпълнимите файлове контролирането на времето на
достъп atime е излишно, иначе при всяко пускане на програмата информация за
това ще бъде включена в отчета, а изменението на времето на създаване (ctime)
за /bin/ash изглежда много подозрително. Ако в системата са станали глобални
изменения (например, обновени са някои пакети), то базата следва да се обнови,
използвайки опцията –update.
Е това е всичко за което исках да
Ви разкажа. Както виждате, толкова просто нещо, позволява да получите пълна
информация за това какво се случва в компютъра, да контролирате достъпа към
важните системни файлове, и при правилно използване прави фактически невъзможно
незабележимо да се променят файловете.
Linux forever!
добре
зле
Вариант за отпечатване
