проблема доиде 1 че се сговни единия хдд който беше за прокси и всичко от начало и 2 от iptables трябваше да се пише наново за 2 машина и в бързината не беше дадено ignore all а не че не са могли да си инсталират или конфигурират мрежата
[Отговори на този коментар]
Към: Към: Към: Шегичка Към: Към: Какви ОС
От: zritel
На: 18-12-2004@18:41 GMT+2
Оценка: 1/НеутраленОтносно операционните системи на участниците, доколкото видях имаше Fedora, Mandrake, Slack, и колкото странно да изглежда - имаше един Wi nXP!!!
А за машините, които трябваше да бъдат пробити - Дебиан, Вин - непачван, ФрееБСД(със екплойтабъл версия на SSH - доста стара). Gateway -ът беше с Дебиан. Организаторите се бяха погрижили тези машини да бъдат максимално уязвими, защото все пак времето за "хакване" беше само 2 часа. И въпреки това участниците успяха да пробият само 3 услуги.
През повечето време вниманието на участниците беше съсредоточено върху търсене на експлоити, въпреки че имаше сървиси, които можеше да бъдат пробити доста лесно без помощта на талива.
Възможните "дупки" в сигурността на някои услуги бяха повече от една - Георги Чорбаджииски, 'без да иска" разбра паролата на една от услугите, въпреки че не беше състезател :)
[Отговори на този коментар]
Към: Към: Към: Към: Шегичка Към: Към: Какв
От: the_real_maniac
На: 18-12-2004@22:02 GMT+2
Оценка: 1/Неутрален"Fedora, Mandrake, Slack, и колкото странно да изглежда - имаше един Wi nXP!!!"
За мен това си е напълно несериозно.
Не че се очакваше нещо интересно :)
Но все пак очаквах и изненади :)
ЩЕ видим пълния "доклад" / report :D
[Отговори на този коментар]
Към: Към: Към: Към: Към: Шегичка Към: Към:
От: Beco <vlk (a) lcpe __точка__ uni-sofia __точка__ bg>
На: 19-12-2004@9:56 GMT+2
Оценка: 2/Остроумен/Смешен
Ти си патологичен случай... Взлом в една система се прави с инструменти, а не с операционна система.
Да не говорим, че ако бяха по-умни инсталиращите Fedora, щяха да сложат машина примамка (активират targeted SELinux, правят root никой, поставя се някакъв пробит демон в chroot) и да губят времето на другя отбор в безмислени атаки и пробиви в нищото. При повече находчивост може да се направи така, че да се наподоби дори изтриването на файлова система, което е невероятно гаднярски номер.
Също така... Можеше да се редиректват портове към машина "черна дупка" (blackhole) в/у която да има една read only файлова система и машината, която е цел на атаката да прави редиректване към порт на черната дупка за някои услуги и прочие и така да не се знае коя услуга къде е - това може да обърка тотално атакуващия.
Изобщо.. има какво още да се желае.
Тъпотия No.1 (тип "кваратален хакер" и "IRC герой") : аз сканирам един IP адрес - значи аз сканирам една машина
Тъпотия No.2 (тип "селски ерген от градски тип") : вляза ли като root - мога да направя всичко
Тъпотия No.3 (тип "администратор на квартален LAN") : всичко, което виждам в машината, в която съм влязал е истинско
Тъпотия No.4 (тип "администратор на free сървър") : атакувайки web сървъра на другарчето не мисля за собствения си web сървър или по народному "виждам треската в чуждото око, но не и гредата в своето"..
и т.н.. веселия преди Коледа
Редактиран на: 19-12-2004@10:07
[Отговори на този коментар]
Към: Към: Към: Към: Към: Към: Шегичка Към:
От: the_real_maniac
На: 19-12-2004@11:41 GMT+2
Оценка: 1/Неутрален1.Нещата зависят естествено от задкомпютърното у-во / потребителя - ДА(!), така е. Няма спор.
2.НО също така и от OS-а.
Debian , Gentoo много по-добър избор пред Fedora или Mandrake (според мен) за случея.
Самата ориентация на Операционната Система определя и развитието на потребителя.
Gentoo - няма смисъл да ти обяснявам , защото съм 99% сигурен , че знаеш какви възможности предоставя.
Тази дист. (като знаеш) е ориентиране към installation от source ( т.е source-based). Един такъв подход те кара да изучиш нещата повече от man emerge(emerge prog) / само потребител /, ами и да разбираш какво всъщност става. Как работят нещата.
Debian - много се е изписалo , едва ли аз ще мога да го напиша по-добре. Пък и със сигурност ти знаеш повече аргументи от мен.
Mandrake , Fedora - еми за мен това е несериозно. Може би е грешка - ок, но RH -> fedora не кара потребителя да се замисля много , много - ами му дава е това GUI, е това GUI за онова и готово. Не кара потребителя да вникне в нещата.
Естествено Fedora, Mandrake е Линукс - ДА!
Може да си компилираш ядрото с ( подръжка на ) SeLinux и т.н ... НО кое ще ти е по-лесно и по-удобно. Дори да го кажем "по-оптимизирано" за работа , а в конкретния случей.?
Gentoo / Debian / Fedora / Mandrake ?
Да можеш да направиш всичо - това са все Линукс ОС , но защо трябва да преобразуваш нещо , а не ползваш това, което е създадено с такава цел. Или направо Gentoo Hardned (или Gentoo + hardned-sources (ядро)), Adamantix (за който напоследък се заговори много).
Почвам да се повтарям , но ... какво ново да ти кажа , което не го знаеш.
Относно патологичния случей - ти знаеш ли какво е това (не се заяждам).?
"Болезнено отклонение от нормалното."
Ако твоето мнение или всеобщото е "нормалното" то моето 'отклоение' е напълно нормално ;)
Тъй като всички сме уникални => лични мнения / различни мнения :P
Относно:
--- Свето Евангелие от МАТЕЯ --- Глава 7 ---
3. А защо гледаш сламката в окото на брата си, пък гредата в своето око не усещаш?
4. Или, как ще кажеш брату си: чакай, да извадя сламката от окото ти; а пък на, в твоето око има греда!
5. Лицемерецо, извади първом гредата от окото си, и тогава ще видиш, как да извадиш сламката от окото на брата си.
------
Не го бях чувал до преди 2 седмици и от тогава ми се мъдри в подписа. Наистина добре казано.
---
Очаквам отговора Ви/ти с интерес. :)
[Отговори на този коментар]
Към: Към: Към: Към: Към: Към: Към: Шегичка
От: Beco <vlk __@__ lcpe< dot >uni-sofia< dot >bg>
На: 19-12-2004@13:54 GMT+2
Оценка: 1/НеутраленМалко фенско го раздаваш.. с много предразсъдъци и не толкова знания.
Това за Fedora искренно ме разсмя. Понеже си фен и не си правил никога каквото и да е сравнение и анализ, ще си позволя да ти направя един подобен... Дай Боже да се научиш и следващия път да не се изказваш неподготвен.
Проектът Fedora се ръководи на практика от Алън Кокс и повечето идеи и насоки за разработката на дистрибуцията идват от него. Ако не знаеш кой е той и каква е ролята му в Линукс общността си е в твой трагичен минус.
Проектът преди всичко залага на сигурността. Да ме прощаваш, но на интернет страницата на проекта веднага се набива цифровия отпечатък на публичния ключ от OpenPGP сертификата на проекта - нещо, което при другите дистрибуции е някъде в ъгъла или изобщо хората не се грижат за това. Проектът идва с пакетна система, която е интегрирана с нейерархичен удостоверителен модел (казвам интегрирана, а не тип Gentoo, където електронния подпис е отделно от пакета и е тип "к'ъв да е подпис"). При RPM подписът е вътре в пакета. Това е едно невероятно улеснение - то носи освен сигурност и превенция на колизии и възможност за рабора с пакети подписвани от различни удостоверители, при това всичко е автоматизирано.
В рамките на пакетната система на Fedora (че и на Mandrake) няма подобни китни селянии като взимане на "к'ъв да е пач" от някъде си без да се знае произхода му и прилагането му. Подобни неща са в разрез с модела на сигурност и в тази дистрибуция място за подобни кретенизми няма.
Има възможност за реподписване на пакета и прочие. Има възможност за използване на различни хранилища с различни удостоверители и система за онаследяване на доверие.
Едно много добро ревю на RPM може да бъде намерено на следните адреси:
http://www.redhat.com/magazine/001nov04/features/betterliving/
http://www.redhat.com/magazine/002dec04/features/betterliving-part2/
Що се касае до модела за изграждане на пакетите.. Това, че някаква дистрибуция изгражда пакет от сорс по време на инсталацията на пакета, изобщо не е никакво предимство и не е чак толкова обучаващо потребителя. Това са фантасмагории. Колкото обучаващо е компилирането на пакет по схемата configure -> make -> make install. Потребителят заучава няколко набора команди и това е. Всичките фенове на Gentoo представят дистрибуцията все едно едва ли не потребителя пише изходния код на програмите:) Това са тинейджърски работи.
SELinux беше за първи път интегриран на 100% във Fedora. В това отношение другите дистрибуции са догонващи. При това реализацията обхваща и пакетната система и то така, че selinux обект се инсталира 1:1 като в жива файлова система (благодарение на CPIO ахива, който е в основа на RPM). Да не говорим, че самият проект Fedora се е наел да доразвива SELinux, за разлика от други дистрибуции, които само са ползватели на това.
Ядрото на Fedora е последна дума на разработките. Можеш да отвориш CHANGELOG на ядрото на kernel.org и да видиш колко хора с адреси @redhat.com са слагали нови неща. Повечето са прилагани за първи път именно в проекта Fedora. Да не говорим, че на прототипното ядро за Fedora Core 1 (което е от серията 2.4) беше постигнат световен рекорд по скорост на обработка на заявки от Oracle. В момента тече една доста голяма оптимизация на ядра 2.6 за проекта Fedora.
Също така са направо във вестникарски стил обяснения как сядаш и си инсталираш от изходен код дистрибуцията. Това се невероятно непрофесионални изказвания. Целта в реална обстановка е инсталацията да мине бързо и безпроблемно и системата да функционира в маскимално кратък срок и то напълно. Ако някой иска.. да си компилира цял ден. Особено на по-слаба машина ще е голям зор и самоубийство. И преди съм го давал този пример - излиза екплойт за ядрото. Имаш 10 машини.. какво ще направиш, ще компилираш на всяка от тях ядро ли? Колко време ще ти отнеме това?
Също така е мит, че като компилираш нещо си на машината ти, то едва ли не "залепва" по нея и работи прекрасно. Това са меко казано неистини. Оптимизация се прави на база архитектура и на една и съща архитектура с едни и същи флагове за компилация, ще постигнеш една и съща скорост на изпълнение на компилирания ELF, върху идентични по капацитет конфигурации. Имаше преди време един интересен спор м/у Алън Кокс и някои членове на fedora-devel листа защо RPM пакетите идват основно компилирани за i386, а нямат версии за i686. Просто на практика не се печели голяма производителност от това. Смисъл има да се прави за glibc и kernel. Само там има значим ефект. В момента не мога да намеря точно връзката, но можеш да потърсиш и да имаш по-голям късмет от мен и да намериш някъде по архивите обясненията.
Аз лично поддържам локално хранилище на RPM пакети и компилирам сам доста неща. Така, че е малко наивно да си мислиш, че съм просто един кликач на бутони за инсталиране. Да не говорим, че да направиш един RPM работещ и неопасен за системата е малко по-голямо изкуство, отколкото да компилираш. Най-малкото трябва да познаваш архитектурата на дистрибуцията много много добре, за да не мажеш. Малко са хората, които правят много добри RPM пакети (Dag Wieers примерно). Аз не смятам, че съм достигнал тяхното ниво, но нищо не ми пречи да се старая да го достигна.
А за графичните инструменти за конфигуриране.. стига толкова ресторантски фолк. Изобщо не е срамно или вредно да ги има. С повечето от тях се пeчели най-малкото време. С времето човек разбира, че подобни изсилвания и фолклорни мотиви от рода на "аз работя само на конзола - значи съм по-добър от другите" са смешни и обикновено се казват от хора, които нямат никакъв опит в администрирането на системи. Не е важен пътя на конфигурацията, а нейното качество. Който не е разбрал това, да се върне от начало и да почва отново да си създава мироглед в/у UNIX системите. Всичко друго са IRC полемики и аз не мисля да падам толкова ниско, че да се включвам в тях.
Освен това Mandrake Soft и RedHat (архитектите на Fedora) продават много добри сървърски решения и влагат доста пари за разработка (тях никой не ги спонсорира, но те спонсорират OpenSource разработки). Ако те не бяха гъвкави и не предлагаха сигурни системи, те щяха да фалират при тези пазарна конкуренция на подобни решения. Защото в ИТ бизнеса никой не се интересува от цената, а от здравината. И не може фобията от 2-3 икони в повече да е определяща за това дали една дистрибуция е здрава или не. Въз основа на такива аргументи изводи могат да правят само доста едностранно развити хора.
Редактиран на: 19-12-2004@15:06
[Отговори на този коментар]
Към: Към: Към: Към: Към: Към: Към: Към: Ше
От: the_real_maniac
На: 19-12-2004@16:48 GMT+2
Оценка: 1/Неутрален"Малко фенско го раздаваш.. с много предразсъдъци и не толкова знания."
Почти съгласен. :)
"Това за Fedora искренно ме разсмя. Понеже си фен и не си правил никога каквото и да е сравнение и анализ, ще си позволя да ти направя един подобен... Дай Боже да се научиш и следващия път да не се изказваш неподготвен."
Относно анализа си прав. Сранение съм правил само м/у RedHat (не Fedora) , Debian , Gentoo - Mandrake && Fedora само съм виждал , което е нищо; т.е но не е и използвал ;)
"Проектът Fedora се ръководи на практика от Алън Кокс и повечето идеи и насоки за разработката на дистрибуцията идват от него. /
Ако не знаеш кой е той и каква е ролята му в Линукс общността си е в твой трагичен минус."
...
"Проектът преди всичко залага на сигурността. Да ме прощаваш, но на интернет страницата на проекта веднага се набива цифровия отпечатък на публичния ключ от OpenPGP сертификата на проекта - нещо, което при другите дистрибуции е някъде в ъгъла или изобщо хората не се грижат за това. Проектът идва с пакетна система, която е интегрирана с нейерархичен удостоверителен модел (казвам интегрирана, а не тип Gentoo, където електронния подпис е отделно от пакета и е тип "к'ъв да е подпис"). При RPM подписът е вътре в пакета. Това е едно невероятно улеснение - то носи освен сигурност и превенция на колизии и възможност за рабора с пакети подписвани от различни удостоверители, при това всичко е автоматизирано.
В рамките на пакетната система на Fedora (че и на Mandrake) няма подобни китни селянии като взимане на "к'ъв да е пач" от някъде си без да се знае произхода му и прилагането му. Подобни неща са в разрез с модела на сигурност и в тази дистрибуция място за подобни кретенизми няма.
Има възможност за реподписване на пакета и прочие. Има възможност за използване на различни хранилища с различни удостоверители и система за онаследяване на доверие."
Не мога да дам толкова компетентно и така подробно написано мнение като тебе, но моето скромно мнение е:
При Gentoo си има md5(sum) проверка. Което мисля е достатъчно да по/за -твърди , че кода/пакета е този , който трябва да бъде (непроменен). Може и да не е толкова съвършено , колкото представяш сегашната версия на RPМ, но опрелдено не е " "к'ъв да е пач" от някъде си " .!
"
Едно много добро ревю на RPM може да бъде намерено на следните адреси:
http://www.redhat.com/magazine/001nov04/features/betterliving/
http://www.redhat.com/magazine/002dec04/features/betterliving-part2/
"
В интерес на истината съм го виждал, но чак сега ще го прочета.
"
Що се касае до модела за изграждане на пакетите.. Това, че някаква дистрибуция изгражда пакети от сорс изобщо не е никакво предимство и не е чак толкова обучаващо потребителя. Това са фантасмагории. Колкото обучаващо е компилирането на пакет по схемата configure -> make -> make install. Потребителят заучава няколко набора команди и това е. Всичките фенове на Gentoo представят дистрибуцията все едно едва ли не потребителя пише изходния код на програмите:) Това са тинейджърски работи."
Не толкова самото компилиране от source - ами последващите стъпки ;)
1.Незнам дали това го има като термин или подобно, но: слединталационното конфигуриране е различно от това при инсталиране на бинарен пакет - започва от по-ниско стъпало. Не казвам , че това е идеално за обновяване на много машини.
За подръжка на n брой машини или сървъри - да; трябва пакетираща система - аз лично ще предпочета deb/apt.
2.Определено самото компилиране не е голяма философия , но при инсталирането от source code възникват повече проблеми :D -> което е предпоставка за научаването на нещо. (така звучи доста смешно и неопределено).
"
SELinux беше за първи път интегриран на 100% във Fedora. В това отношение другите дистрибуции са догонващи. При това реализацията обхваща и пакетната система и то така, че selinux обект се инсталира 1:1 като в жива файлова система (благодарение на CPIO ахива, който е в основа на RPM). Да не говорим, че самият проект Fedora се е наел да доразвива SELinux, за разлика от други дистрибуции, които само са ползватели на това.
Ядрото на Fedora е последна дума на разработките. "
Това не го знаех, но не го приемам на 100% (вяра).
"Можеш да отвориш CHANGELOG на ядрото на kernel.org и да видиш колко хора с адреси @redhat.com са слагали нови неща."
Да - забелязал съм.
"Повечето са прилагани за първи път именно в проекта Fedora. Да не говорим, че на прототипното ядро за Fedora Core 1 (което е от серията 2.4) беше постигнат световен рекорд по скорост на обработка на заявки от Oracle. В момента тече една доста голяма оптимизация на ядра 2.6 за проекта Fedora.
Това също не го знаех. :|
"Също така са направо във вестникарски стил обяснения как сядаш и си инсталираш от изходен код дистрибуцията. Това се невероятно непрофесионални изказвания. Целта в реална обстановка е инсталацията да мине бързо и безпроблемно и системата да функционира в маскимално кратък срок и то напълно. Ако някой иска.. да си компилира цял ден. Особено на по-слаба машина ще е голям зор и самоубийство. И преди съм го давал този пример - излиза екплойт за ядрото. Имаш 10 машини.. какво ще направиш, ще компилираш на всяка от тях ядро ли? Колко време ще ти отнеме това?"
Горе ти отговорих и съм съгласен с теб.
"Също така е мит, че като компилираш нещо си на машината ти, то едва ли не "залепва" по нея и работи прекрасно. Това са меко казано неистини. Оптимизация се прави на база архитектура и на една и съща архитектура с едни и същи флагове за компилация, ще постигнеш една и съща скорост на изпълнение на компилирания ELF, върху идентични по капацитет конфигурации. Имаше преди време един интересен м/у Алън Кокс и някой членове на fedora-devel листа защо RPM пакетите идват основно компилирани за i386, а нямат версии за i686. "
... / мълчеливо съгласие
"Просто на практика не се печели голяма производителност от това. Смисъл има да се прави за glibc и kernel. Само там има значим ефект. В момента не мога да намеря точно връзката, но можеш да потърсиш и да имаш по-голям късмет от мен и да намериш някъде по архивите обясненията."
Еми не съм го казал аз: "истината си е истина / факта си е факт" - Съгласен с теб. (съжелявам че се повтарям :)) ).
"Аз лично поддържам локално хранилище на RPM пакети и компилирам сам доста неща. Така, че е малко наивно да си мислиш, че съм просто един кликач на бутони за инсталиране. Да не говорим, че да направиш един RPM работещ и неопасен за системата е малко по-голямо изкуство, отколкото да компилираш. Най-малкото трябва да познаваш архитектурата на операционната система много много добре, за да не мажеш. Малко са хората, които правят много добри RPM пакети (Dag Wieers примерно). Аз не смятам, че съм достигнал тяхното ниво, но нищо не ми пречи да се старая да го достигна."
Относно направата на пакетите - потвърждавам , че не е лесна работа. Аз се пробвах с напаравата на deb пакети.
"А за графичните инструменти за конфигуриране.. стига толкова ресторантски фолк. Изобщо не е срамно или вредно да ги има. С повечето от тях се пeчели най-малкото време. С времето човек разбира, че подобни изсилвания и фолклорни мотиви от рода на "аз работя на конзола - значи съм по-добър от другите" са смешни и обикновено се казват от хора, които нямат никакъв опит в администрирането на системи. Не е важен пътя на конфигурацията, а нейното качество. Който не е разбрал това, да се върне от начало и да почва отново да си създава мироглед в/у UNIX системите."
Обаче такова нещо не съм казвал ! Казвам само ,че използването на GUI най-често не дава същата свобода на избор / конфугуриране,което дава ръчното.
" Всичко друго са IRC полемики и аз не мисля да падам толкова ниско, че да се включвам в тях."
Аз пък въобще не ползвам IRC , с леки изключения =< 10 пъти за доста голям период от време.
И току що ме попитаха същия този въпрос , който и аз си зададох на края "и за какво толкова пишеш ?" :)
Защото определено свеждането нещата до прости не е води до решение; но ако трябва да опростим:
Да - 99% нещата зависят от потребителя. И този потребител работи с това, с което му е най-удобно.
Но аз дадох SeLinux като пример ,който не се оказа толкова удобен за моя случай. (все пак това което каза за връзката
м/у SeLinux и Fedora). Примерно другите Security проекти и интеграцията им сравнение м/у Gentoo , Debian , Fedora , etc.
И оставих долното изречение за накрая с цел:
Наистина ти блгагодаря за отделеното време (!) и подробните обяснения, информация.!(!)
(по-горната информация ще е полезна на много хора, не само на мене).
След време ще имам повече база за сравнение и повече знания , тогава ще мога по-достойно да се аргументирам , а и не
само - въобще да защита тезата си или потвърдя твойта.
Според това, което аз съм ползвал и знам избора е Debian / Gentoo ( Adamantix/Gentoo Hardned , който не съм ползвал обаче).
[Отговори на този коментар]
Към: Към: Към: Към: Към: Към: Към: Към: Къ
От: Beco <vlk< at >lcpe[ точка ]uni-sofia[ точка ]bg>
На: 19-12-2004@18:25 GMT+2
Оценка: 1/НеутраленЦитирам:
****************************************
При Gentoo си има md5(sum) проверка. Което мисля е достатъчно да по/за -твърди , че кода/пакета е този , който трябва да бъде (непроменен). Може и да не е толкова съвършено , колкото представяш сегашната версия на RPМ, но опрелдено не е " "к'ъв да е пач" от някъде си " .!
****************************************
Ммммм.. не искам да влизам в тежък спор но..
Една MD5 или SHA1 сума може да се използва само за да се провери дали файла е цял и не е повреден. Но да се установи идентичността му е невъзможно по този метод.
Представи си сега, че аз успея да пробия огледалото, от което ти сваляш файловете, да поставя фалшив пакет (примерно OpenSSH, който съм модифицирал за да мога да влизам в системата ти). Какъв е проблемът аз да изчисля MD5 сумата на файловете и да ги сложа във файла със сумите. Щом за теб MD5 сумата е меродавно доказателство за идентичността на файл или блок данни, то трябва да направиш сериозна преоценка на знанията си. И според мен твоята система е супер несигурна - ако ти предлагаш примерно на мен хостинг в/у твоята система, аз ще подмина офертата ти с усмивка, защото твоята система няма никаква идентичност.
По същата логика няма нито една система с Debian, която да е доказано автентична. Чак сега в Debian се появява система за електронно подписване на пакети (и то още е unstable).
Истината е следната. Една MD5 сума без електронен подпис върху нея е най-измамното нещо, което има на света. Не само това, тя е подвеждаща, защото върху нея няма никаква идентификация на това кой я е извършил. Затова при електронното подписване на един файл се изчислява MD5 или SHA1 сумата и получения резултат се подписва с RSA или DSA частен ключ (проверката се прави с публичния ключ в OpenPGP сертификата на подписващия). Такъв подпис има смисъл.
Сега се връщаме на пакетната система и смъсъла от интегация.
Имаме два варианта на реализация:
1) Подписва се файла с MD5 сумите на пакетните файлове (архиви)
Примерната схема може да се представи така:
Дистрибутора прозивежда архивен файл (примерно tar.gz). Изчислява електронния подпис на файла и го прибавя в общ файл или в отделен файл (т.е. за всеки архивен файл има друг отделен файл, който е примерно с наставка .asc и съдържа електронния подпис). Друг вариант на тази схема е дистрибутора да поддържа файл, в който се прибавят изчислените MD5 или SHA1 сумите на произведените от него архивни файлове. Той подписва електронно този файл.
Как потребителят трябва да процедира? Потребителят процедира по следния начин: сдобива се с файла, който съдържа MD5 или SHA1 сумите и електронния подпис върху него, или с електронния подпис към архивите, които е в отделен файл за всеки архивен файл. Проверява електронния подпис и след това инсталира.
Тук следва една много основна слабост на тази схема. Не може да се следи състоянието на файловете от архива след като те бъдат инсталирани в системата. Т.е. примерно инсталраш OpenSSH, но след това не можеш да кажеш дали файла /usr/sbin/sshd примерно не е подменен в собствената ти систама - да, можеш да вземш пак архива, който го съдържа, да извадиш този файл и да го сравниш като MD5 или SHA1 сума с този в твоята система. За целта ще трябва да имаш локално копие на всички пакети, ако искаш да можеш да следиш състоянието на файловете от пакета.
Една малко по-лесна поправка е след инсталирането на файловете от архива, за всеки архив да се прави файл, който да съдържа MD5 или SHA1 сумите на файловете екстрктирани от архива. Това решение си е доста тромавично, освен това ще ти се налага да подписваш електронно всеки файл.. при обовняване на системата.. ще се скъсаш да си въвеждаш паролата за частния ключ.
Накратко този вариант е малко не съвсем в час с технологиите и принципите за бързина. При него има опасност от наследени козии, но не мога да пиша цяла нощ за това.
2) Вариантът на пакетната система RPM
Съставя се CPIO архив с "жива" файлова система (т.е. 1:1 както тя ще бъде копирана спрямо посочения от администратора относителен спрямо "/" път). Прави се интегриран подпис над CPIO архива и останалите файлове (инфо, пре и постинсталационни скриптове) и този подпис остава в пакета. Т.е. това не е допълнителен файл или допълнителен запис в някакъв единен файл. М/у другото на всеки файл от "живата" файлова система в CPIO се прави MD5 сума и тя се подпива - информацията за това се намира също в RPM файла.
Потребителят трябва да процедира така: снабдява се с OpenPGP сертфиката на дистрибутора на пакета, инсталира го в специална база (BerkeleyDB формат), която е интегрирана в RPM пакетната система на локалната машина. При инсталацията се прави проверка на електронния подпис интегриран в пакета и при несъотетствие не се разрешава инсталиране. Цялата информация за MD5 сумите на инсталираните в системата файлове се влага в базата с данни на RPM системата.
След това много лесно и бързо може да се направи пълен анализ на автентичността на инсталираните файлове и много лесно да се забележи подмяната.
Специално за RPM.. Хайде да направим един тест за проверка на интеграцията.. Примерно за пакета bind:
$ rpm -q -vv --verify bind
D: opening db index /var/lib/rpm/Packages rdonly mode=0x0
D: locked db index /var/lib/rpm/Packages
D: opening db index /var/lib/rpm/Name rdonly mode=0x0
D: opening db index /var/lib/rpm/Pubkeys rdonly mode=0x0
D: read h# 750 Header sanity check: OK
D: ========== DSA pubkey id b44269d04f2a6fd2
D: read h# 713 Header V3 DSA signature: OK, key ID 4f2a6fd2
D: ========== +++ bind-9.2.4-2 i386/linux 0x1
D: opening db index /var/lib/rpm/Depends create mode=0x0
D: opening db index /var/lib/rpm/Basenames rdonly mode=0x0
D: read h# 752 Header V3 DSA signature: OK, key ID 4f2a6fd2
D: Requires: /bin/bash YES (db files)
D: Requires: /bin/sh YES (db files)
D: Requires: /bin/sh YES (cached)
D: Requires: /bin/sh YES (cached)
D: Requires: /bin/sh YES (cached)
D: Requires: /bin/sh YES (cached)
D: Requires: /bin/sh YES (cached)
D: read h# 778 Header V3 DSA signature: OK, key ID 4f2a6fd2
D: Requires: /bin/usleep YES (db files)
D: opening db index /var/lib/rpm/Providename rdonly mode=0x0
D: read h# 207 Header V3 DSA signature: OK, key ID 4f2a6fd2
D: Requires: bind-utils YES (db provides)
D: read h# 15 Header V3 DSA signature: OK, key ID 4f2a6fd2
D: Requires: chkconfig YES (db provides)
D: Requires: config(bind) = 20:9.2.4-2 YES (added provide)
D: Requires: config(bind) = 20:9.2.4-2 YES (db provides)
D: read h# 72 Header V3 DSA signature: OK, key ID 4f2a6fd2
D: Requires: fileutils YES (db provides)
D: read h# 11 Header V3 DSA signature: OK, key ID 4f2a6fd2
D: Requires: glibc >= 2.2 YES (db provides)
D: read h# 931 Header V3 DSA signature: OK, key ID 4f2a6fd2
D: Requires: grep YES (db provides)
D: Requires: libc.so.6 YES (db provides)
D: Requires: libc.so.6(GLIBC_2.0) YES (db provides)
D: Requires: libc.so.6(GLIBC_2.1) YES (db provides)
D: Requires: libc.so.6(GLIBC_2.1.1) YES (db provides)
D: Requires: libc.so.6(GLIBC_2.1.3) YES (db provides)
D: Requires: libc.so.6(GLIBC_2.3) YES (db provides)
D: read h# 80 Header V3 DSA signature: OK, key ID 4f2a6fd2
D: Requires: libcrypto.so.4 YES (db provides)
D: read h# 206 Header V3 DSA signature: OK, key ID 4f2a6fd2
D: Requires: libdns.so.16 YES (db provides)
D: Requires: libisc.so.7 YES (db provides)
D: Requires: libisccc.so.0 YES (db provides)
D: Requires: libisccfg.so.0 YES (db provides)
D: Requires: liblwres.so.1 YES (db provides)
D: Requires: libnsl.so.1 YES (db provides)
D: Requires: libpthread.so.0 YES (db provides)
D: Requires: libpthread.so.0(GLIBC_2.0) YES (db provides)
D: Requires: rpmlib(CompressedFileNames) <= 3.0.4-1 YES (rpmlib provides)
D: Requires: rpmlib(PartialHardlinkSets) <= 4.0.4-1 YES (rpmlib provides)
D: Requires: rpmlib(PayloadFilesHavePrefix) <= 4.0-1 YES (rpmlib provides)
D: read h# 87 Header V3 DSA signature: OK, key ID 4f2a6fd2
D: Requires: sed YES (db provides)
D: read h# 922 Header V3 DSA signature: OK, key ID 4f2a6fd2
D: Requires: shadow-utils YES (db provides)
D: Requires: textutils YES (db provides)
D: opening db index /var/lib/rpm/Conflictname rdonly mode=0x0
D: closed db index /var/lib/rpm/Depends
......... c /etc/logrotate.d/named
......... c /etc/rc.d/init.d/named
..?...... c /etc/rndc.conf
........C c /etc/rndc.key
S.5....T. c /etc/sysconfig/named
......... /usr/sbin/dns-keygen
......... /usr/sbin/dnssec-keygen
......... /usr/sbin/dnssec-makekeyset
......... /usr/sbin/dnssec-signkey
......... /usr/sbin/dnssec-signzone
......... /usr/sbin/lwresd
......... /usr/sbin/named
......... /usr/sbin/named-bootconf
......... /usr/sbin/named-checkconf
......... /usr/sbin/named-checkzone
......... /usr/sbin/rndc
......... /usr/sbin/rndc-confgen
......... /usr/share/doc/bind-9.2.4
......... d /usr/share/doc/bind-9.2.4/CHANGES
......... d /usr/share/doc/bind-9.2.4/COPYRIGHT
......... d /usr/share/doc/bind-9.2.4/README
......... /usr/share/doc/bind-9.2.4/arm
......... d /usr/share/doc/bind-9.2.4/arm/Bv9ARM-book.xml
......... d /usr/share/doc/bind-9.2.4/arm/Bv9ARM.ch01.html
......... d /usr/share/doc/bind-9.2.4/arm/Bv9ARM.ch02.html
......... d /usr/share/doc/bind-9.2.4/arm/Bv9ARM.ch03.html
......... d /usr/share/doc/bind-9.2.4/arm/Bv9ARM.ch04.html
......... d /usr/share/doc/bind-9.2.4/arm/Bv9ARM.ch05.html
......... d /usr/share/doc/bind-9.2.4/arm/Bv9ARM.ch06.html
......... d /usr/share/doc/bind-9.2.4/arm/Bv9ARM.ch07.html
......... d /usr/share/doc/bind-9.2.4/arm/Bv9ARM.ch08.html
......... d /usr/share/doc/bind-9.2.4/arm/Bv9ARM.ch09.html
......... d /usr/share/doc/bind-9.2.4/arm/Bv9ARM.html
......... d /usr/share/doc/bind-9.2.4/arm/Makefile
......... d /usr/share/doc/bind-9.2.4/arm/Makefile.in
......... d /usr/share/doc/bind-9.2.4/arm/README-SGML
......... d /usr/share/doc/bind-9.2.4/arm/isc.color.gif
......... d /usr/share/doc/bind-9.2.4/arm/nominum-docbook-html.dsl
......... d /usr/share/doc/bind-9.2.4/arm/nominum-docbook-html.dsl.in
......... d /usr/share/doc/bind-9.2.4/arm/nominum-docbook-print.dsl
......... d /usr/share/doc/bind-9.2.4/arm/nominum-docbook-print.dsl.in
......... d /usr/share/doc/bind-9.2.4/arm/validate.sh
......... d /usr/share/doc/bind-9.2.4/arm/validate.sh.in
......... /usr/share/doc/bind-9.2.4/misc
......... d /usr/share/doc/bind-9.2.4/misc/Makefile
......... d /usr/share/doc/bind-9.2.4/misc/Makefile.in
......... d /usr/share/doc/bind-9.2.4/misc/dnssec
......... d /usr/share/doc/bind-9.2.4/misc/format-options.pl
......... d /usr/share/doc/bind-9.2.4/misc/ipv6
......... d /usr/share/doc/bind-9.2.4/misc/migration
......... d /usr/share/doc/bind-9.2.4/misc/migration-4to9
......... d /usr/share/doc/bind-9.2.4/misc/options
......... d /usr/share/doc/bind-9.2.4/misc/rfc-compliance
......... d /usr/share/doc/bind-9.2.4/misc/roadmap
......... d /usr/share/doc/bind-9.2.4/misc/sdb
......... d /usr/share/man/man5/named.conf.5.gz
......... d /usr/share/man/man5/rndc.conf.5.gz
......... d /usr/share/man/man8/dnssec-keygen.8.gz
......... d /usr/share/man/man8/dnssec-makekeyset.8.gz
......... d /usr/share/man/man8/dnssec-signkey.8.gz
......... d /usr/share/man/man8/dnssec-signzone.8.gz
......... d /usr/share/man/man8/lwresd.8.gz
......... d /usr/share/man/man8/named-checkconf.8.gz
......... d /usr/share/man/man8/named-checkzone.8.gz
......... d /usr/share/man/man8/named.8.gz
......... d /usr/share/man/man8/rndc-confgen.8.gz
......... d /usr/share/man/man8/rndc.8.gz
......... /var/named
missing /var/named/data
missing /var/named/slaves
......... /var/run/named
D: closed db index /var/lib/rpm/Pubkeys
D: closed db index /var/lib/rpm/Conflictname
D: closed db index /var/lib/rpm/Providename
D: closed db index /var/lib/rpm/Basenames
D: closed db index /var/lib/rpm/Name
D: closed db index /var/lib/rpm/Packages
Задачка-закачка:) Открийте кои файлове са променени:) Ясно си личи...
Хайде сега да проверим контекстната интеграция със SELinux за този пакет:
# rpm -q --fscontext bind
/etc/logrotate.d/named system_u:object_r:etc_t
/etc/rc.d/init.d/named system_u:object_r:initrc_exec_t
/etc/rndc.conf system_u:object_r:named_conf_t
/etc/rndc.key user_u:object_r:etc_t
/etc/sysconfig/named system_u:object_r:etc_t
/usr/sbin/dns-keygen system_u:object_r:sbin_t
/usr/sbin/dnssec-keygen system_u:object_r:sbin_t
/usr/sbin/dnssec-makekeyset system_u:object_r:sbin_t
/usr/sbin/dnssec-signkey system_u:object_r:sbin_t
/usr/sbin/dnssec-signzone system_u:object_r:sbin_t
/usr/sbin/lwresd system_u:object_r:named_exec_t
/usr/sbin/named system_u:object_r:named_exec_t
/usr/sbin/named-bootconf system_u:object_r:sbin_t
/usr/sbin/named-checkconf system_u:object_r:sbin_t
/usr/sbin/named-checkzone system_u:object_r:sbin_t
/usr/sbin/rndc system_u:object_r:ndc_exec_t
/usr/sbin/rndc-confgen system_u:object_r:sbin_t
/usr/share/doc/bind-9.2.4 system_u:object_r:usr_t
/usr/share/doc/bind-9.2.4/CHANGES system_u:object_r:usr_t
/usr/share/doc/bind-9.2.4/COPYRIGHT system_u:object_r:usr_t
/usr/share/doc/bind-9.2.4/README system_u:object_r:usr_t
/usr/share/doc/bind-9.2.4/arm system_u:object_r:usr_t
/usr/share/doc/bind-9.2.4/arm/Bv9ARM-book.xml system_u:object_r:usr_t
/usr/share/doc/bind-9.2.4/arm/Bv9ARM.ch01.html system_u:object_r:usr_t
/usr/share/doc/bind-9.2.4/arm/Bv9ARM.ch02.html system_u:object_r:usr_t
/usr/share/doc/bind-9.2.4/arm/Bv9ARM.ch03.html system_u:object_r:usr_t
/usr/share/doc/bind-9.2.4/arm/Bv9ARM.ch04.html system_u:object_r:usr_t
/usr/share/doc/bind-9.2.4/arm/Bv9ARM.ch05.html system_u:object_r:usr_t
/usr/share/doc/bind-9.2.4/arm/Bv9ARM.ch06.html system_u:object_r:usr_t
/usr/share/doc/bind-9.2.4/arm/Bv9ARM.ch07.html system_u:object_r:usr_t
/usr/share/doc/bind-9.2.4/arm/Bv9ARM.ch08.html system_u:object_r:usr_t
/usr/share/doc/bind-9.2.4/arm/Bv9ARM.ch09.html system_u:object_r:usr_t
/usr/share/doc/bind-9.2.4/arm/Bv9ARM.html system_u:object_r:usr_t
/usr/share/doc/bind-9.2.4/arm/Makefile system_u:object_r:usr_t
/usr/share/doc/bind-9.2.4/arm/Makefile.in system_u:object_r:usr_t
/usr/share/doc/bind-9.2.4/arm/README-SGML system_u:object_r:usr_t
/usr/share/doc/bind-9.2.4/arm/isc.color.gif system_u:object_r:usr_t
/usr/share/doc/bind-9.2.4/arm/nominum-docbook-html.dsl system_u:object_r:usr_t
/usr/share/doc/bind-9.2.4/arm/nominum-docbook-html.dsl.in system_u:object_r:usr_t
/usr/share/doc/bind-9.2.4/arm/nominum-docbook-print.dsl system_u:object_r:usr_t
/usr/share/doc/bind-9.2.4/arm/nominum-docbook-print.dsl.in system_u:object_r:usr_t
/usr/share/doc/bind-9.2.4/arm/validate.sh system_u:object_r:usr_t
/usr/share/doc/bind-9.2.4/arm/validate.sh.in system_u:object_r:usr_t
/usr/share/doc/bind-9.2.4/misc system_u:object_r:usr_t
/usr/share/doc/bind-9.2.4/misc/Makefile system_u:object_r:usr_t
/usr/share/doc/bind-9.2.4/misc/Makefile.in system_u:object_r:usr_t
/usr/share/doc/bind-9.2.4/misc/dnssec system_u:object_r:usr_t
/usr/share/doc/bind-9.2.4/misc/format-options.pl system_u:object_r:usr_t
/usr/share/doc/bind-9.2.4/misc/ipv6 system_u:object_r:usr_t
/usr/share/doc/bind-9.2.4/misc/migration system_u:object_r:usr_t
/usr/share/doc/bind-9.2.4/misc/migration-4to9 system_u:object_r:usr_t
/usr/share/doc/bind-9.2.4/misc/options system_u:object_r:usr_t
/usr/share/doc/bind-9.2.4/misc/rfc-compliance system_u:object_r:usr_t
/usr/share/doc/bind-9.2.4/misc/roadmap system_u:object_r:usr_t
/usr/share/doc/bind-9.2.4/misc/sdb system_u:object_r:usr_t
/usr/share/man/man5/named.conf.5.gz system_u:object_r:man_t
/usr/share/man/man5/rndc.conf.5.gz system_u:object_r:man_t
/usr/share/man/man8/dnssec-keygen.8.gz system_u:object_r:man_t
/usr/share/man/man8/dnssec-makekeyset.8.gz system_u:object_r:man_t
/usr/share/man/man8/dnssec-signkey.8.gz system_u:object_r:man_t
/usr/share/man/man8/dnssec-signzone.8.gz system_u:object_r:man_t
/usr/share/man/man8/lwresd.8.gz system_u:object_r:man_t
/usr/share/man/man8/named-checkconf.8.gz system_u:object_r:man_t
/usr/share/man/man8/named-checkzone.8.gz system_u:object_r:man_t
/usr/share/man/man8/named.8.gz system_u:object_r:man_t
/usr/share/man/man8/rndc-confgen.8.gz system_u:object_r:man_t
/usr/share/man/man8/rndc.8.gz system_u:object_r:man_t
/var/named system_u:object_r:named_zone_t
/var/named/data system_u:object_r:named_cache_t
/var/named/slaves system_u:object_r:named_cache_t
/var/run/named system_u:object_r:named_var_run_t
Ако желаем да променим контекста - няма проблеми, има опция --recontext
Редактиран на: 19-12-2004@18:30
[Отговори на този коментар]
Към: Към: Към: Към: Към: Към: Към: Към: Къ
От: Rumen_Yotov <rumen_yotov< at >dir__dot__bg>
На: 19-12-2004@18:53 GMT+2
Оценка: 1/НеутраленЗдравейте,
Намесвам се тук не за да защитавам/хваля Gentoo, а по-скоро в интерес на точното посочване на фактите.
От около 2 месеца всички пакети в gentoo се подписват електронно (има три нива на сигурност: gpg, gpg strict, третото не го помня как беше), отделно (много отдавна) има md5-sum за проверка на целостта на сорс пакетите. Очаква се скоро да се подписват и eclass-пакетите (bash-scripts) към portage.
PS: Разбира се интегрираността не е като в Fedora/SElinux,но върши необходимата работа.
Румен
[Отговори на този коментар]
Към: Към: Към: Към: Към: Към: Към: Към: Къ
От: Beco <vlk< at >lcpe __точка__ uni-sofia __точка__ bg>
На: 19-12-2004@19:02 GMT+2
Оценка: 1/НеутраленПрави си:) Така е.. ама човека не знаеше това. Да не говорим, че има и потребители на Fedora, дето изобщо не си проверяват електронните подписи... Т.е. нещата не опират само до наличност на подписи в дистрибуцията, но и до грамотността на хората.
Примерно това можеше да се експлоатира на състезанието. Със сигурност някои хора са си слагали софтуер от огледални сървъри през връзката към Интернет. Ако Васил беше зъл гений, можеше да направи един IP спуфинг и да насочи хората към някое подправено огледало:) Тогава щеше да стане много много интересно. Със сигурност можеше да пусне някакъв елемент на социално инженерство от рода на : "кое огледало искате да ползвате за да ви осигуря бърза връзка до него":) И непроверката на електронните подписи щеше да изиграе турбо лош номер на участниците. Да не говорим за това, че едва ли някой си е носил отпечатъци от публичните ключове на листче:)
Можеше да се спретне такъв зловещ сценарий:))) че състезанието щеше да се превърне в една оргия от пакетни измами и експлойти в принципно здрави версии на дадени демони. Можеше да се рализира изтриване на диск без проникване в системата:)
Редактиран на: 19-12-2004@19:06
[Отговори на този коментар]
Към: Към: Към: Към: Към: Към: Към: Към: Къ
От: Rumen_Yotov <rumen_yotov (a) dir__dot__bg>
На: 19-12-2004@19:25 GMT+2
Оценка: 1/НеутраленЗдравей,
Сигурно сега хората ще почнат да си казват, добре че не беше Весо да осигурява състезанието ;-) че ни бе спукана работата.
Все пак това е за първи път,а както се знае всяко начало е трудно, но вероятно и интересно.
Май се натрупа доста материал за мислене/ тренировка на бъдещи участници ;).
PS:горните препоръки приличат малко на сценарии за Big Brother ;)- не че го гледам.
Румен
[Отговори на този коментар]
Към: Към: Към: Към: Към: Към: Към: Към: Къ
От: the_real_maniac
На: 19-12-2004@20:22 GMT+2
Оценка: 1/НеутраленЕми ... хъх ... нямам коментар.
За пореден път се почуствах малък в големия свят :)
Благодаря и на двама Ви за информацията.
И един въпрос към Румен:
Търсих на gentoo.org и с google, и преглеждайки самия сайт.
Къде има статия / документация относно подписването на пакетите в Gentoo и използването на тази възможност в Gentoo ?
Аз лично намерих смао откъсачна информация в теми от форума на gentoo.org.
Ако можеш да посочиш документ от Gentoo/.org или накакви ключови думи за търсене ?
Най-много информация намерих тук:
http://forums.gentoo.org/viewtopic.php?t=3283
http://forums.gentoo.org/viewtopic.php?t=3432
[Отговори на този коментар]
Към: Към: Към: Към: Към: Към: Към: Към: Къ
От: Rumen_Yotov <rumen_yotov __@__ dir[ точка ]bg>
На: 20-12-2004@6:27 GMT+2
Оценка: 1/НеутраленЗдравей,
Честно казано мисля, че наистина няма информация за това.
Аз го видях/разбрах от gentoo-dev-ML, там бе съобщено, но нямаше пълно инфо как точно да се направи. За да не търся из старите мейли ето:
Слагаш в /etc/make.conf -> FEATURES="...gpg..." и PORTAGE_GPG_DIR=... - виж по долу в README-то.
Това е за да проверява gpg-подписите.
Самите подписи ;) ги има в личната директория на carpaski: http://dev.gentoo.org/~carpaski
и поддиректорията: gpg.
Виж/прочети README.
PS1:забравих, трябва (gpg-тата)да ги преименуваш на: pubring.gpg и pubring.gpg.asc. Аз съм ги сложил в: /etc/portage/gpg-директорията.
PS2: това е още от 16-авг-2004
Успех
Румен
Редактиран на: 20-12-2004@6:56
[Отговори на този коментар]
Към: Към: Към: Към: Към: Към: Към: Към: Към: Къ
От: .
На: 20-12-2004@8:12 GMT+2
Оценка: 1/НеутраленДа, но за съжаление тази система все още не е
напълно функционираща. За сега, ако човек иска да
е сигурен в автентичноста на portage дървото си,
трябва да го изтегля с
websync(emerge-webrsync) като цял пакет. Тези
пакети са подписани.
А относно проверката за цялостта на даден
инсталиран пакет, лесно е :
$qpkg -c -v pkg_name
пример :
$ qpkg -c -v postgresql
dev-db/postgresql-7.4.6 *
/etc/conf.d/postgresql !md5! !mtime!
1/909
---------
За повече подробности man qpkg.
Редактиран на: 20-12-2004@8:56
[Отговори на този коментар]
Към: Към: Към: Към: Към: Към: Към: Към: Къ
От: SRG
На: 20-12-2004@8:42 GMT+2
Оценка: 1/НеутраленМалко в страни от темата,но просто не мога да се сдържа ;)
http://forums.gentoo.org/viewtopic.php?t=10934&highlight=gpg+portage
[Отговори на този коментар]
