LINUX.ORG.RU

как проверить чистоту записанного на носитель образа?

 ,


0

0

если гипотетически машина заражена, как можно убедиться в отсутствии возможных ошибок, rootkitов, плохих скриптов в исполнительных файлах внутри образа дистрибутива, который был dd на usb-stick? т.е. есть ли хотя бы теоретические способы проверки и является ли обязательным условием наличие минимум нескольких машин? т.е ты не знаешь, не заражена ли вторая машина, чтоб довериьть ей запуск md5sum

----

есть ли сайты, похожие на virustotal.com для проверки линуксячих файлов?

★★★★★

Последнее исправление: teod0r (всего исправлений: 1)

как можно убедиться в отсутствии возможных ошибок, rootkitов, плохих скриптов в исполнительных файлах внутри образа дистрибутива, который был dd на usb-stick?

Только извне, через чексамы ВСЕХ файлов и загрузчика. Это, разумеется, с заведомо чистой машины. При подключении сохранять осторожность, не допускать автомонтирования.

является ли обязательным условием наличие минимум нескольких машин?

Да

есть ли сайты, похожие на virustotal.com для проверки линуксячих файлов?

Пробивать мд5 700-метрвых образов? В паблике, думаю, нет.

Yustas ★★★★
()
Ответ на: комментарий от Yustas

Только извне, через чексамы ВСЕХ файлов и загрузчика. Это, разумеется, с заведомо чистой машины.

Это, разумеется, с заведомо чистой машины.

замкнутый круг

teod0r ★★★★★
() автор топика
Ответ на: комментарий от teod0r

Учитывая тренд на «апаратные бэкдоры» - лента Мёбиуса ))

Yustas ★★★★
()
Ответ на: комментарий от kss

наверное это единственный способ. придётся заказать какой-нить дистр. как можно оплатить, если неохота заниматься регистрацией веб-кошелька? можно ли по почте оплатить?

teod0r ★★★★★
() автор топика
Ответ на: комментарий от dmfd

гипотетически можно (в будущем мб)

teod0r ★★★★★
() автор топика

Снять образ заново и сравнить его с исходным?

BMX ★★☆
()

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

А вообще вряд ли кто-то уже написал настолько совершенный руткит и эта паранойя с заражением образов уже перебор.

KivApple ★★★★★
()
Ответ на: комментарий от KivApple

Нет. Идеальный руткит может полностью скрыть своё пребывание

но его можно вычислить, как я писал комментарием выше - разбиваем файл /usr/bin/md5sum на куски по 5 байт (я не программист и не знаю какого МИНИМАЛЬНОГО размера может быть руткит, может меньше, может больше - тогда куски будут другого размера), потом содержимое этих неск. десятков кусков распечатываем и подсчитываем ВРУЧНУЮ (на калькуляторе) сумму каждого из них...

teod0r ★★★★★
() автор топика
Ответ на: комментарий от teod0r

можно заметить, что файл выводится юзеру на экран и подменить файл оригиналом. то есть на диске всё заражено, а при чтении куда угодно кроме exec - не заражено. и при записи обратно исполняемые файлы вновь заражаются автоматически.

заражённой идеальным руткитом системе нельзя доверять в принципе, пока она активна.

KivApple ★★★★★
()
Ответ на: комментарий от KivApple

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

teod0r ★★★★★
() автор топика
Ответ на: комментарий от teod0r

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

1) В системном вызове exec инфицируем уже загруженный в память код.

2) Руткит на диске хранится только в образе ядра. При любых запросах на открытие и чтение файла с образом ядра - отдаём оригинал. При любой записи чего-то, что можно определить как образ ядра (не думаю, что это сильно сложно - найти ELF с Multiboot-заголовком) - инфицируем.

Как такое обнаружить без LiveCD?

KivApple ★★★★★
()
Ответ на: комментарий от KivApple

А вообще вряд ли кто-то уже написал настолько совершенный руткит и эта паранойя с заражением образов уже перебор.

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

gentoo_root ★★★★★
()
Ответ на: комментарий от gentoo_root

Ну... что уж тогда... можно считать, что все системы уже заражены неким руткитом. Все новые приложения подвержены ему, потому что компилятор добавляет код руткита. В таком случае в исходниках этого руткита уже может и совсем не быть. Да, hex-редакторы, ассемблеры и т. д. уже тоже заражены (своими компиляторами) и даже с их помощью нельзя набрать чистый код. Файловые менеджеры из-за руткита показывают размеры файлов меньше, чем есть, чтобы скрыть присутствие руткита.

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

KivApple ★★★★★
()
Ответ на: комментарий от KivApple

Кстати, вариант для сценария фильма %) Хакер обнаруживает этот руткит, подбирает код управления и пытается захватить мир.

KivApple ★★★★★
()
Ответ на: комментарий от KivApple

может кто-нибудь сможет сделать реверсинженеринг ядра? в будущем...

teod0r ★★★★★
() автор топика
Ответ на: комментарий от KivApple

нет всё таки если чтение подменено, то dd > куданибудь.... в общем по-хитрому как-то можно схему придумать

teod0r ★★★★★
() автор топика
Ответ на: комментарий от KivApple

на открытие и чтение файла с образом ядра - отдаём оригинал

на открытие и чтение файла с образом ядра - отдаём оригинал

teod0r ★★★★★
() автор топика
Ответ на: комментарий от teod0r

Ну запишите вы на флешку неинфицированное ядро (вы же не на системный диск пишете, так что подменять данные не следует. нас ведь интересует максимальная незаметность, а не заражение других машин), а толку? Только если загружаться с флешки, но это уже тот вариант с LiveCD. А пока активно ядро с руткитом ничего странного вы не заметите.

Обнаружить факт виртуализации находясь внутри виртуальной машины можно только заметив ошибки и неточности эмуляции. Если их нет, то мы никогда не узнаем правды. Совсем никогда. Аналогично с Матрицей.

KivApple ★★★★★
()
Ответ на: комментарий от KivApple

Ну запишите вы на флешку неинфицированное ядро (вы же не на системный диск пишете

что то не понял, какой системный диск?

teod0r ★★★★★
() автор топика
Ответ на: комментарий от teod0r

я тебя тоже :-)

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

KivApple ★★★★★
()
Ответ на: комментарий от teod0r

из-под активной системы при копировании с флешки на системный диск данные будут модифицированы руткитом. при копировании из-под чистого LiveCD всё получится, но я это и не отрицал. Ты же говоришь тебе надо без дополнительных доверенных компьютеров и LiveCD.

KivApple ★★★★★
()
Ответ на: комментарий от KivApple

при чём тут с какой системы копировать? вирус и на ливсд может есть. факт что можно записать как-то в чистом виде, или я опять что-то упустил?

teod0r ★★★★★
() автор топика
Ответ на: комментарий от teod0r

в общем, если у вас есть некий девайс, которому вы доверяете и который имеет ATA/SATA порт, то его можно подключить к диску и накатить чистую систему. и только при условии, что нет бэкдора в контроллере жёсткого диска или процессоре (в этом случае система будет повторно заражена после первой загрузки на этой машине).

KivApple ★★★★★
()
Ответ на: комментарий от KivApple

ну а если через шину принтера ты подклячаешь и принтер и переходник на usb одновременно и кидаешь на вывод шины dd с образами программ?

teod0r ★★★★★
() автор топика
Ответ на: комментарий от KivApple

будет повторно заражена после первой загрузки на этой машине

методом исключения можно будет выявить заражённые блоки и подменить

teod0r ★★★★★
() автор топика
Ответ на: комментарий от KivApple

мы же уже решили, что достаточно руткита в ядре. так что надо просто полностью прозрачно перенаправлять файловый ввод-вывод к оригинальной копии ядра на диске, когда происходит open к /boot/vm-linuz

KivApple ★★★★★
()
Ответ на: комментарий от teod0r

я это сказал для случая бэкдора в процессоре. то есть аппаратном рутките.

если всё только программное, то никаких проблем специальным девайсом подключиться напрямую к диску и изменять данные на нём.

KivApple ★★★★★
()
Ответ на: комментарий от KivApple

специальным девайсом подключиться напрямую к диску и изменять данные на нём

что за девайс?

можно содержимое памяти под жидким азотом прочитать.

если всё только программное

и то мне кажется что с помощью каких нибудь махинаций с ядром можно выявить руткит в железе

teod0r ★★★★★
() автор топика
Ответ на: комментарий от teod0r

что за девайс?

Это ты начал про девайсы)

можно содержимое памяти под жидким азотом прочитать.

разумеется. но имхо проще просто загрузиться с LiveCD.

и то мне кажется что с помощью каких нибудь махинаций с ядром можно выявить руткит в железе

Если в нём нет ошибок, то нельзя. Только п внешним признакам. Например, если руткит сливает данные куда-либо, то засечь странные пакеты на шлюзе (где стоит ОС, которой мы доверяем), либо засечь радио-передачу с помощью специального оборудования, которому мы опять же доверяем.

KivApple ★★★★★
()
Ответ на: комментарий от KivApple

будет повторно заражена после первой загрузки на этой машине

чем, если же мы смогли записать его чистым?

teod0r ★★★★★
() автор топика
Ответ на: комментарий от teod0r

при условии, что нет бэкдора в контроллере жёсткого диска или процессоре

если в процессоре тоже сидит зловред (на уровне микрокода), то он пропатчит память ядра при первой загрузке, а дальше уже по стандартной схеме.

KivApple ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.