Разработка детекторов руткитов

[coldfire]

На сколько эта тема еще не заезжена?
Т.е. на сколько там уже все изучено?
Если ли смысл попробовать разработать свой детектор в качестве дипломного проекта, кто что думает поэтому поводу? =)

P.S.: Я бы конечно данный топик написал бы в раздел флуд, но что-то нечего подходящего не нашел =(... Кстати, может кто-то еще предложит какие-то интересные темы в целом, не касающиеся руткитов?

[root]

На сколько эта тема еще не заезжена?

Это тема всегда была и будет актуальной.

Т.е. на сколько там уже все изучено?

Если бы все было изучено, то вирусы/руткиты вымерли бы.

Если ли смысл попробовать разработать свой детектор в качестве дипломного проекта, кто что думает поэтому поводу? =)

Этих детекторов пруд пруди. Да и разработать, свой, более менее работающий детектор, за время отведенное на диплом вряд ли получится. Это раз.
Во-вторых: тебе надо будет объяснять, по крайней мере рецензенту, чем твой детектор лучше остальных?
В третьих: скажу тебе по секрету - это все лишний геморрой... Почему? Да потому, что уровень дипломных работ, сфере "компьютерной безопасности" (я правильно идентифицировал твою специальность?) в Украине, оставляет желать лучшего и это еще мягко говоря сказано. Мой тебе совет: Подойди к своему дипломному руководителю и попроси для ознакомления:

• перечень "дипломных тем" за последние несколько лет;
• дипломы его бывших дипломников.

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

не касающиеся руткитов

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

темы в целом, не касающиеся руткитов?

Первое что пришло в голову, но это уже зависит от уровня знаний и желания взять на себя лишний геморрой:

1. Провести какой-нибудь ресерч на поиск уязвимостей (0-day) в приложениях/ос.
2. Устроить какой-нибудь развесистый краш-тест антивирусам.
3. Написать какой-нибудь аналог TeamViewer.
4. Реализовать Honeypot для отлова малвари.
5. Реализовать аналог VirusTotal.
6. Обеспечение безопасности сетей базирующихся на IPv6.
7. etc.

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

[coldfire]

Специальность у меня немножко другая ( комп. системы и сети ), но просто хотелось бы взять темы связанную с комп. безопастностью, так как достаточно интересно двигаться в этом направлении.
Темы, которые вы предложили мне понравились, но с нашими преподователями мне кажется, что темы вида 1 и 2 могут не пройти по причинам, к-ые известны только преподователю...
А вот темы 4 и 5, вполне интересны.... Правда я видел что-то похожее вида VirusTotal, мне кажется, что там выдумать что-то новое сложно, ну, надо же будет мне как-то новизну объяснить...=)

А подойти на счет тем, к-ые писали в прошлых годах, то там как правило фигня....

Еще я думал может попробовать что-то сделать вида аппаратного сниффера для блютуза например? на сколько я знаю это не сильно распрастраненно и программной реализации вроде как нельзя сделать...
Кстати, а что интересно можно придумать в сфере в ИБ связанное с МК?

[root]

Еще я думал может попробовать что-то сделать вида аппаратного сниффера для блютуза например? на сколько я знаю это не сильно распрастраненно и программной реализации вроде как нельзя сделать...
Кстати, а что интересно можно придумать в сфере в ИБ связанное с МК?

Был бы Luna-Tic, может что-то и предложил, у него иногда идеи хардверные появляются... А так лучше поспрашивать тут

[UNKNOWN]

Кстати, сегодня в "Компьютерре" вышла статья Берда Киви (отчасти) на эту тему.

Пара цитат от туда:

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

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

[coldfire]

....
4. Реализовать Honeypot для отлова малвари.
5. Реализовать аналог VirusTotal.
....

А не знаете ли, если какой-то материал по основам разработки ханипотов?
А то я полазил по сети, находил только про настройки существующих ханипотов, а про то как их разрабатывать не видел...

И что бы вы могли предложить придумать нового в аналоне VirusTotal'a?

[root]

А не знаете ли, если какой-то материал по основам разработки ханипотов?

Не интересовался. В каждом конкретном случае все достаточно индивидуально - это первая причина по чему нет материалов.
Вторая, возможно, никто не хочет делится своими наработками.
Третья, если разработанная концепция показала хорошие/интересные результаты - ее можно продать.

предложить придумать нового в аналоне VirusTotal'a?

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

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

Помимо этого, нет никаких материалов, которые хоть как-то, практически, описывают построение такого сервиса, по крайней мере я не видел.

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

Развернуться в этой теме можно и без всяких нововведений... Нововведения штампуют, когда есть какая-то основа или когда ты видишь какие-нибудь минусы сервиса и можешь предложить пути их решения.

[UNKNOWN]

Помимо этого, нет никаких материалов, которые хоть как-то, практически, описывают построение такого сервиса, по крайней мере я не видел

Ты прото не читаешь "Хакер", элите это не положено . VirusTotal своими руками: Создаем публичный сервис для проверки файла несколькими антивирусами

[root]

Сходил посмотреть: там один оффтоп на тему "Qt удобная вещь"...

[coldfire]

Собственно, решил делать для себя аналог Virus Total'a....
Тему прошу не закрывать буду сюда писать свои вопросы по мере поступления + буду по возможности писать, что сделал , может кто-то будет исправлять и говорить, что добавить или так делать нельзя и тд...

Что касается серверной части, то пока что проблем нету, т.к. там я обладаю нужными знаниями в виде ЯП и тд, там пока особых проблем нету, пока есть идеи, пока это трогать не буду...

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

По скольку у меня нету опыта разработки web-сайтов, то хотелось бы, что бы мне кто-то подсказал какие технологии мне надо будет за использовать и желательно где по этому поводу не читать, что бы я не сидел просто и не перечитывал куча книг по тому как я понимаю мне PHP, HTML, CSS, Ajax... И как я понимаю мне не надо будет тоже каких-то серьезных знаний, что касается веб части... Поэтому кто может подсказать где можно так сказать прочитать, что-то в виде не большого введения в данные темы....
Кстати, такой вопросик по поводу веба, если ли смысл использовать заместь РНР тот же Руби, или может будет вообще достаточно новомодного HTML5, к-ый я так понимаю поддерживает передачу файлов и тд ?

И есть у меня еще один пока пару общих вопросов, что бы его сразу заложить в архитектуру будущего ПО:
Если ли смысл делать этот продукт в виде распределенный сети вида : с веб-сайта получаем файлик и передаем на сервер, к-ый будет выполнять роль командного центра, к-ый будет дальше распределять наш файлик ботам, к-ый будут собственно проверять и отправлять результат.
Или в данном продукте это не будет оправданно? Достаточно ли будет сделать только веб-часть и серверную, к-ая будет многопоточной и соотв обрабатывать результат...
И какая оптимизация будет со стороны сервера мне пока понятна, т.е. будут там разнообразные базы уже провернных файлов и тд, что бы куча раз не проверять, и другие оптимизации, а вот какие оптимизации и если ли смысл их там делать со стороны клиента, в моем случаи веб-сервера?

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

[root]

По скольку у меня нету опыта разработки web-сайтов, то хотелось бы, что бы мне кто-то подсказал какие технологии мне надо будет за использовать и желательно где по этому поводу не читать, что бы я не сидел просто и не перечитывал куча книг по тому как я понимаю мне PHP, HTML, CSS, Ajax... И как я понимаю мне не надо будет тоже каких-то серьезных знаний, что касается веб части... Поэтому кто может подсказать где можно так сказать прочитать, что-то в виде не большого введения в данные темы....

Та я не знаю даже как сказать, там все элементарно. Если С/C++ знаешь, то можно просто гуглить и по ходу дела разбираться, один из запросов: "PHP загрузка файлов" или "PHP загрузка файлов скрипт" и так все остальное.

какие технологии мне надо будет за использовать

1. В любом случае нужна какая-то база данных, обычно это MySQL. В базе данных будут примерно такие таблицы (основные):

• Таблица: Информация о файле (Info) - содержит информацию о файле;
• Таблица: Хэш (Hash) - содержит информацию о хэшах проверенных файлов и файлов которые сейчас стоят в очереди на проверку.
• Таблица: Задачи (Tasks) - содержит информацию о задачах поставленных на выполнение;
• Таблица: Выполненные (Completes) - содержит информацию о выполненных задачах;
• Таблица: АВ (AV) - содержит расширенную информацию по "выполненным задачам", т.е. как отреагировали антивирусы на проверяемый файл;
• Таблица: Пользователи (Users) - содержит информацию о пользователе запросившем проверку (например, его e-mail, куда будет отправляться результат сканирования).

Если лень или напряжно работать с несколькими таблицами, то можно все соединить в одну, но это будет грубовато, особенно если на защите диплома будет сидеть какой-нибудь препод разбирающийся в проектировании БД. Который прикалебется и скажет, что таблица не приведена к 3-й нормальной форме или что-то подобное.

2. В качесте веб-морды может выступать одна PHP страничка (скрипт). На которой у пользователя будет запрашиваться "файл" и "его e-mail". Этот скрипт будет добавлять:

• В таблицу (Info) - Информацию о файле: номер файла, имя, размер, дата добавления, тра-ля-ля...
• В таблицу (Hash) - Будет добавлять: номер файла (которому принадлежит хэш) и собственно сам хэш.
• В таблицу (Tasks) - Будет добавлять: номер задачи, номер файла, номер юзера (поставленного на выполнение).
• В таблицу (Users) - Добавит: email, если такой пользователь с таким мэйлом уже есть, то ничего добавлять не будет.
• Сохранять файл на диск.

3. Далее в игру должен вступать скрипт, которые раздаст проверяемый файл N-ному количеству антивирусников.
4. После проверки антивирусами должен включаться еще один скрипт, которые соберет все результаты от антивирусов и сложит их в какую-нибудь папку.

5. После того как результаты были помещены в какую-то папку, должен срабатывать другой скрипт, не важно какой (PHP, Perl, Python, etc), который добавит собранную информацию в базу данных:

• В таблицу (AV) - добавит: номер выполненной задачи, информацию по антивирусам;
• В таблицу (Completes) - добавит: номер выполненной задачи, номер проверенного файла, номер юзера + удалит такую же запись из Tasks;
• Отправит пользователю отчет на email или ссылку для просмотра результата.

6. Можно абгрейднуть скрипт из пункта "2", добавив в него просмотр результата по ссылке из e-mail.
7. Как будет сделан пункт "6", можно добавить мониторинг результата, без перехода по ссылки и e-mail.
8. Как будет сделан пункт "7", можно будет добавить регистрацию. Тогда придется расширить таблицу "Users".
9. И так далее... Пока будет хватать времени.

т.е. делаем вывод что надо знать по вебу:

• HTML - на уровне чайника;
• PHP - работа с базой данных, работа с файлами, загрузка файлов, отправка письма на e-mail, возможно регулярные выражения. Для этого понадобится какой-нибудь справочник, например: "PHP5 Библиотека профессионала (Леон Атиксон)" либо любой другой, так же возможно будет интересна книга "Разработка Web-приложений с помощью PHP и MySQL (Люк Веллинг)", но я сомневаюсь, что у тебя будет время ее читать там 800+ страниц...
• CSS + Ajax - если будет время, и захочется добавить жизни для веб-морды, но я думаю это лишнее, это уже можно допилить, если проект будешь развивать после сдачи диплома.

Кстати, такой вопросик по поводу веба, если ли смысл использовать заместь РНР тот же Руби, или может будет вообще достаточно новомодного HTML5, к-ый я так понимаю поддерживает передачу файлов и тд ?

Я Руби в глаза не видел, но у меня к нему какое-то странное отвращение... Как-то странно он у меня с Delphi ассоциируется, который я терпеть не могу. А вообще без разницы, если серверная часть поддерживает Руби, и ты больше знаком с этим языком чем к примеру с Python'ом, PHP, Perl, etc. То можешь написать на нем все скрипты. HTML5 - не смотрел, но его явно будет мало.

Если ли смысл делать этот продукт в виде распределенный сети вида : с веб-сайта получаем файлик и передаем на сервер, к-ый будет выполнять роль командного центра, к-ый будет дальше распределять наш файлик ботам, к-ый будут собственно проверять и отправлять результат.

Если командный центр - будет совершать всего-лишь командование, то это слишком жирно будет, лучше совместить веб-сайт и командный центр.

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

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

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

Может быть только пару оптимизаций с клиентской стороны. Это обсчет хэша для файла, перед его отправкой. Затем отправка этого хэша на сервер и его поиск там. И если такого хеша в БД нет, то загружаем файла для проверки, если же такой хэш есть, то тут можно:

• либо вывести результат, который уже хранится в базе данных;
• либо все же загрузить файл и проверить его снова.

Как-то так...

PS: Рекомендую веб-часть отложить до того, как ты сделаешь основную. Основная часть это шаги 3, 4.

[coldfire]

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

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

Под многопоточностью я тут иммел ввиду, что на 1 боте будет стоять сразу много антивирей, и что бы не ждать там результат от одного антивиря, то сразу в потоках на каждом отдельно проверять.
Или это вообще не резонно ставить на 1 бот сразу n антивирусов?
Они же еще скорее всего будут как-то нехорошо реаигровать друг на друга, как с этим бороться?

[root]

Под многопоточностью я тут иммел ввиду, что на 1 боте будет стоять сразу много антивирей, и что бы не ждать там результат от одного антивиря, то сразу в потоках на каждом отдельно проверять.
Или это вообще не резонно ставить на 1 бот сразу n антивирусов?
Они же еще скорее всего будут как-то нехорошо реаигровать друг на друга, как с этим бороться?

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

• Либо запускают каждый антивирус на отдельной виртуалке (минусы: нужно один или несколько мощных компьютеров, в зависимости от количества АВ);
• Либо запускают антивирусы по очереди, т.е запустил KAV проверил файл(ы) - выключил, потом запускаешь Dr. Web проверяешь файл(ы) - выключил и т.д. (минусы: тратится лишнее время на постоянные "загрузки" и "выгрузки");
• Либо комбинированный метод 1-го и 2-го вариантов.

[coldfire]

привет.
Всех с наступившим новым годом...

Появился вопрос, вот решил посоветоваться...
Собственно, вопрос состоит в том, как мне лучше всего забирать файлики с клиентской машины?... пока я думал так дать доступ к папке и по фтп качать ... а так уже устроить связь между клиентом и сервром по ТСП и там только передавать команды вида: занят, свободен, проверить файл такой-то...
И 2е что я хотел бы узнать почему все так любят формировать пакеты передаваемые между клиентом и сервером в формате xml? Почему просто нельзя как обычный буфер и его потом разбирать, чем этот подход на столько хуже?

[root]

Собственно, вопрос состоит в том, как мне лучше всего забирать файлики с клиентской машины?... пока я думал так дать доступ к папке и по фтп качать ... а так уже устроить связь между клиентом и сервром по ТСП и там только передавать команды вида: занят, свободен, проверить файл такой-то...

Та как угодно, главное что бы по несколько раз не качались. Я бы сделал вообще просто (а там уже если бы не понравилось переделал бы по другому):

1. На клиентских машинах расшарил бы папки.
2. Написал бы скрипт (положил бы на сервере) для копирования файлов по расшареным папкам.
3. На сервере в корн/etc записал бы задачу на запуск "скрипта" каждые "N минут".

Итог: Нету геморроя с разными FTP/TCP/etc. Файлы копируются один раз, на каждую клиентскую машину и удаляются после того, как были скопированны на все машины.

И 2е что я хотел бы узнать почему все так любят формировать пакеты передаваемые между клиентом и сервером в формате xml? Почему просто нельзя как обычный буфер и его потом разбирать, чем этот подход на столько хуже?

С XML-ем лучше и проще расширяемость.

Например (примитивный пример), ты в своем протоколе передаче задал такое:
-----------------
HEADER - 20 байт
INIT - 40 байт
DATA - 80 байт
-----------------
Доступ ты получаешь примерно так (условно):

header = Read(Packet[0:19])
init = Read(Packet[19:39])
data = Read(Packet[39:79])

А теперь представим, что тебе что-то не понравилось в твоей реализации и ты решил изменить/добавить что-то в своем протоколе:
-----------------
HEADER - 40 байт
COUNT - 10 байт
INIT - 55 байт
DATA - 80 байт
POSTDATA - 10 байт
-----------------

Если использовать xml, то:

• старая версия твоей программы будет (с большой вероятностью) спокойно продолжать работу, даже не смотря на то, что у полей HEADER и INIT изменился размер, поскольку при xml-парсенге опираются на "Имя", а не "количество байт";
• намного проще доступ к переменным "Packet";
• при изменения в протоколе, тебе не надо постоянно корректировать твой "парсер" (имеется ввиду, определять количество байт под каждую переменную);
• etc.

Если не использовать xml, то:

• старые версии программ накроются медным тазом, поскольку будет либо фолт (fallout), либо не правильно распарсится или как минимум будет не правильно работать;
• для всех переменных постоянно приходится рассчитывать количество отводящихся байт;
• при изменениях в протоколе, старые версии программ (с большей вероятностью) будут завершаться ошибкой/ми;
• etc.

PS (По поводу файлов): Можно конечно выпендриться и зафигачить свой протокол обмена файлами, в плоть до того, что по нему будет передаваться вся информация (файлы, результаты сканирования, etc) от клиентских машин серверу, но это нужно писать клиентское ПО, а к нему еще и серверное ПО. Лишний гемор как по мне. Эти улучшения лучше произвести уже в Магистерском дипломе, а в Бакалаврском осуществить более мене стабильную работу проекта.

[coldfire]

Написал бы скрипт (положил бы на сервере) для копирования файлов по расшареным папкам.

Так все равно же придется какой-то протокол использовать для того, что бы установить соединение. Разве нет?

PS (По поводу файлов): Можно конечно выпендриться и зафигачить свой протокол обмена файлами, в плоть до того, что по нему будет передаваться вся информация (файлы, результаты сканирования, etc) от клиентских машин серверу, но это нужно писать клиентское ПО, а к нему еще и серверное ПО. Лишний гемор как по мне. Эти улучшения лучше произвести уже в Магистерском дипломе, а в Бакалаврском осуществить более мене стабильную работу проекта.

А что подразумевается под свой протокол? Все равно же мы строим на базе какого-то существующего или имеется ввиду что не используя нечего чисто на сокетах все строим? и тогда я тоже как понимаю по сути надо будет только добавить все данные в хml ( ну там файлы, результаты и тд.. ). Или я не прваильно понимаю?

[root]

Так все равно же придется какой-то протокол использовать для того, что бы установить соединение. Разве нет?

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

FOR /L %N IN (101,1,110) DO copy "C:\samples" "\\192.168.1.%N\samples\check" /y

Эта строка копирует все файлы из папки "C:\samples" в папку "\samples\check" для каждого из 10-ти компьютеров клиентов, входящих в интервал "192.168.1.101 - 192.168.1.110".

В данном примере всю работу с сетью выполняет ОС, в нашем случае Windows, как она это делает, нас совершенно не интересует.

А что подразумевается под свой протокол? Все равно же мы строим на базе какого-то существующего или имеется ввиду что не используя нечего чисто на сокетах все строим? и тогда я тоже как понимаю по сути надо будет только добавить все данные в хml ( ну там файлы, результаты и тд.. ). Или я не прваильно понимаю?

Сокеты тоже используют протоколы. Под протоколом я имел ввиду общее понятие "условные команды между приложениями сервер <=> клиент". Например, тот же скрипт "showthread.php" (http://forum.reverse4you.org/showthread.php?t=1173&page=2), поддерживает свой протокол общения с браузером, получая в параметрах "t - идентификатор темы", "page - номер страницы", etc.

[coldfire]

А какой макс. размер файла можно будет запихнут в xml?
Допустим я открыл файл, по указатели на этот файл переписал его допустим в файлик xml. ( все файлы пусть будут до 2 мб ) ... т.е. у меня получится в районе 2 мб, яже так понимаю я потом этот xml не смогу же сразу передать по сети весь?
Или как мне вообще загнать сам файлик в пакет оформленный в виде xml?

[root]

А какой макс. размер файла можно будет запихнут в xml?

Внешне XML-файл ничем не отличается от TXT. Поэтому размер у него может быть любой. Единственное о чем следует оговориться, это то, что файл при парсинге будет грузиться в память, со всеми от сюда вытекающими. Файлы в 2 МБ - это не большие файлы, так что нормально.

Или как мне вообще загнать сам файлик в пакет оформленный в виде xml?

Загнать не получиться, поскольку максимальный размер пакета, в сетях построенных на протоколе IP, меньше 64 кб. Поэтому большие файлы бьешь на куски и передаешь.

[coldfire]

Внешне XML-файл ничем не отличается от TXT. Поэтому размер у него может быть любой. Единственное о чем следует оговориться, это то, что файл при парсинге будет грузиться в память, со всеми от сюда вытекающими. Файлы в 2 МБ - это не большие файлы, так что нормально.


Загнать не получиться, поскольку максимальный размер пакета, в сетях построенных на протоколе IP, меньше 64 кб. Поэтому большие файлы бьешь на куски и передаешь.

Т.е. это сам файлик xml не может быть больше 64 кб?