Привет!
Темы об ав-чекерах поднимались неоднократно: концепты, сырые и готовые реализации, размышления, а также всякая хуйня. Поэтому тут я сваливаю в одну кучу всё то, что касается рабочей схемы чекера. Только кое-что новое добавив, а кое-что лишнее выкинув.
--------------------------------------------------------------------------------------------------------------------------------
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
x x
x Ещё раз Об АВ-чекере x
x x
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Привет!
Темы об ав-чекерах поднимались неоднократно: концепты, сырые и готовые реализации, размышления, а также
всякая хуйня. Поэтому тут я сваливаю в одну кучу всё то, что касается рабочей схемы чекера. Только кое-что
новое добавив, а кое-что лишнее выкинув.
Итак, ав-чекер - это онлайн-сервис, проверяющий файлы/данные на вирусы/трояны/черви/etc (заранее
подготовленными) различными антивирусными (АВ) сканерами. Для начала нам потребуется мощный выделенный сервак,
многопроцессорный (чем больше ядер, частоты, кеша - тем лучше), с кучей оперативной памяти и поддерживающий
аппаратную виртуализацию (для гипервизора). А также широкие сетевые каналы и безлимитный трафик в придачу
(конкретные ТТХ намеренно не указываются, так что тут рулят только желание + возможность). Можно обойтись
"обычным" компьютером с установленной виртуальной машиной (ВМ), но тогда скорость работы ав-чекера будет
соответствующей. Ибо первое узкое место в производительности - это мощность оборудования и его настройка.
Что касается языков программирования, то писать можно на чём угодно и как угодно. Например, Си (для движка
системы) и php + html (для веб-морды).
Далее, онлайн-сканер можно наделить следующими (популярными) фичами aka проверками:
[+] файлов - статика (проверка локальными ав-сканерами, чек трафа на лету, реалтайм проверка при
копировании/скачивании данных - здесь задействованы сигнатурный анализатор + эвристик + кодоэмулятор);
[+] связок (они же exploit pack / webpage / etc);
[+] урлов/доменов;
[+] файлов - динамика (проверка файлов на работоспособность, поведенческий анализ итд).
Разберёмся с каждым из этих пунктов по порядку.
-------------------------
Проверка файлов - статика
-------------------------
Завуалировано говоря, чекер -> это веб-админка + движок системы, которые "общаются" между собой
посредством базы данных (БД) и размещены на некоем охуенном железе.
Технология реализации:
[+] на выделенном сервере создаём нужное количество ВМ (с гостевыми ОСями);
[+] одну из ВМ делаем сервером - на нём будут крутиться веб-морда и БД (файлы будут закачиваться через
админку и храниться в базе для последующей проверки антивирусом);
[+] на каждую ВМ ставится один АВ и наша программа "обработчик", который:
[1] загребает из БД файл, который нужно проверить на конкретном АВ. При этом опрос базы осуществляется
постоянно через заданный интервал времени. Однако, здесь детектится очередное слабое звено - при
большой нагрузке база начнёт неебически загибаться. Выход из ситуации - файлы держать в
веб-директории, а в базе хранить только ссылки на их скачивание;
[2] запускает АВ (консольный с нужными настройками) на сканирование файла. Но и тут затаился пиздец -
низкая скорость проверки. А всё из-за того, что сканеры (некоторых) АВэх очень долго подгружаются
(инициализация движка, загрузка модулей/вирусных баз и прочие махинации (и это, не считая времени
самого чека)).
Поэтому, как вариант, можно заюзать гуй-версию, которая грузит свои потроха в память только 1 раз.
Плюс ко всему, сократим общее время сканирования, скачивая файлы не по одному, а пачкой и чекать,
вызывая сканер также 1 раз.
Дополнительно можно использовать проверку трафа на лету, а также реалтайм сканирование, настроив
его выполнение при скачивании и/или копировании данных. Но, по стандарту, всё надо тщательно и
рьяно проверять, ибо такие вещи у большинства Авэх по прежнему работают убого, особенно при
повышенной нагрузке;
[3] получает от АВ результат. Который можно поймать, например, перенаправив вывод консольного сканера
в пайп/файл. Из "личного" лога ав-движка. Если манипулируем гуишкой, то через её форму путём
отправки сообщений и тыканием по кнопкам. Другие варианты - из журналов событий, расшифровки
скрытых файлов (хуёвый метод), БД (например, есть любители SQLite) etc;
[4] кладёт результат в БД. Тут всё просто - парсим полученный отчёт, если файл чистый - отправляем
"ОК", если грязный - посылаем название детекта;
[5] проводит обновления АВ и его вирусной базы (с некоторым заданным интервалом).
Ещё нужно позаботиться о том, чтобы проверяемые файлы не сливались к аверам (поднимаем локальную
сеть):
первым делом вырубаем интернет на всех ВМ, где валяются АВ. Затем, одну, заранее выделенную ВМ
делаем роутером - всё это дело настраиваем. Далее, в другую ВМ будем скачивать антивирусные
обновки и сохранять их в расшаренных папках. Финальный штрих - вырубаем в каждом АВ все службы
анонимной отправки данных и прописываем в качестве зеркала обновлений нужные пути в шаре. Для тех,
кто не поддерживает данный параметр - всё делаем самостоятельно: скачивание вирусных баз с помощью
wget/curl и их раскидывание по нужным директориям.
В особо тяжких ситуациях ставим проксик для контроля исходящего трафа.
Основная писанина - это подпункты [2], [3] и [5] - так как для каждого АВ будет свой алгоритм. Поэтому эти
поинты можно вынести в отдельный модуль (handler_n), который на входе будет иметь унифицированный интерфейс
(task manager), а реализация, соответственно, будет заточена под каждый тип АВ.
Схематично работу чекера можно представить так:
******************************<-***********************************
* *
* SERVER *
* *
* *
* *
* ************ *
* * * *
* 5. profit * * * 4. result *
* *<---------------------------* web-site *<----------------------------------+ *
* * * * * | *
* * 1. file * * * | *
* user *------------------------>* * | *
* * * ************ | *
************* * | | *
* | 2. file\task | *
* +---------------->******** ********** *
* * * 3. file\task * * *
* * DB *--------------->* engine * *
* * * * * *
* ******** ********** *
* *
* *
* *
******************************->***********************************
******************************<-***********************************
* *
* ENGINE *
* *
* *
* *
* ************* ******** *
* * * <-report * * *
* +------>* handler_1 *<------------>* AV_1 * *
* | * * file-> * * *
* *********** | ************* ******** *
* * * | *
3.2 result * * * | *
<--------------------------------* * | ************* ******** *
* * task * <-report * * <-report * * *
3.1 file/task * * manager *<----------->* handler_2 *<------------>* AV_2 * *
-------------------------------->* * file-> * * file-> * * *
* * * | ************* ******** *
* * * | *
* * * | *
* *********** | ************* ******** *
* | * * <-report * * *
* +------>* handler_n *<------------>* AV_n * *
* * * file-> * * *
* ************* ******** *
* *
* *
* *
******************************->***********************************
И вообще будет заебись, если замутить ещё:
[+] (реалтайм) вывод результатов;
[+] обработку архивов (распаковка файлов с последующим помещением каждого в веб-папку) / файлов
(определение типа);
[+] увеличение производительности (перед проверкой файла поиск его хэша в базе - найден / не найден -
принимаем нужное решение);
[+] скачивание и проверка больших по размеру файлов;
[+] общее снижение нагрузки на сервер/админку/бд/движок;
[+] (при наличии нескольких серверов) распараллеливание работы handler'ов;
[+] под дополнительные сервисы, как проверка доменов итд - соответственно, поднять ещё ВМ с нужным
обработчиком под конкретную задачу;
[+] etc Ж).
---------------
Проверка связок
---------------
Вкратце, связка - она же связка/набор эксплоитов, выдающихся ротатором (+ имеется админка со статистикой и
много чего другого). Ротатор - скрипт, который определяет различные характеристики машины (ОС, браузер и его
версию, итд) и выдаёт подходящий сплоит. Связка юзается для тестирования софта на пробиваемость, заражения
уязвимых машин с последующим распространением своего софта etc.
Для движка ав-чекера проверка связок == проверке файлов, различия будут видны только админке. Принцип
работы следующий:
[+] на вход подаётся полный веб-адрес, по которому скачивается (одно и то же) содержимое страницы
несколькими юзер-агентами (чем больше их, тем лучше - повторю, это нужно для того, чтобы связка выдала
разные экспы);
[+] полученные данные сохраняются в обычные файлы (например, с расширением *.html);
[+] чек файлов авером.
Ещё можно позаботиться о том, с какими протоколами будет работать проверка связок, и что делать, если в
связке включена блокировка по IP после каждого захода (хотя, это затруднение уже не чекера). Вот такие дела.
----------------
Проверка доменов
----------------
DNSBL (DNS BlockList/BlackList - ранее RBL - RealTime Blackhole List) - по сути, это чёрный список
IP/доменов, рассылающих спам, и хранящийся с использованием системы архитектуры DNS. Ещё существует множество
различных DNSBL-серверов, предоставляющих свои услуги (списки) для борьбы с негодной информацией. А отсюда
следует, что всё уже построено - нам остаётся только прикрутить нужные сервисы в свой чекер и автоматизировать
проверки (ага, всего то, блядь, прикрутить =)). На самом деле задача довольно лёгкая, и, на мой взгляд, её
проще реализовать на скриптах в пределах одной ВМ.
Общий каркас системы будет почти такой же, как и на чекере файлов (с диспетчером задач, обработчиками
etc), но со своими нюансами, а именно (следуя нумерации ранее перечисленных подпунктов):
[1] вместо файла проверяется ip/domen (ну это и так понятно, хуле);
[2] чек айпи/доменов осуществляют выбранные в админке DNSBL-сервисы. Причём имеем 3 основных типа чеков:
[a] проверка по веб-базам путём парсинга скачанной страницы результатов. Например, для google это
делается так:
[+] составляем полный веб-адрес
("http://www.google.com/safebrowsing/diagnostic?site=eof-project.net");
[+] скачиваем содержимое по данному урлу;
[+] на полученной страничке ищем определённый текст (нашли "NO" - домен чист);
[b] скачивание (в простейшем случае, текстовой) базы грязных ипов/доменов с дальнейшим поиском нужного
IP (spyeyetracker blocklist etc);
[c] резолвинг IP -> запись IP в нотации DNS PTR -> добавление в хвост имени DNSBL-сервера -> получение
(отсутствие) ответа. Здесь же добавлю, что есть 2 типа DNSBL: LHSBL (Left Hand Side BlackList) и
RHSBL (Right Hand Side BlackList). Основное различие в том, что в LHSBL проверяются IP, а в
RHSBL - домены.
Пример для LHSBL:
допустим, имеется адрес eof-project.net. Получаем его айпишник - пусть это будет 12.34.56.78.
Далее, записываем его в обратном порядке: 78.56.34.12. И добавляем имя какого-либо хоста списка:
78.56.34.12.cbl.abuseat.org. В Си проверку можно сделать, например, с помощью функи
gethostbyname(char *name)). Если придёт ответ (для данного хоста - это IP 127.0.0.2), то
проверяемый адрес залочен (находится в списке).
Полученный IP может оказаться любым, важен лишь факт его наличия/отсутствия в ответе на запрос.
Аналогичный пример и для RHSBL, только вместо IP подставляем домен (eof-project.имя_хоста);
[x] другие типы чеков, реализуемые в соответствии с поставленной задачей (например, для Internet
Explorer можно создать дополнительную ВМ, в которой эмулировать заход юзера на сайт итд).
--------------------------
Проверка файлов - динамика
--------------------------
К данной категории относятся:
[1] проверка файлов на работоспособность (основная мулька - проверка на большом количестве различных ОСей.
Результат - "воркает!" или "ошибка пляшет");
[2] "утилитный" поведенческий анализатор (мониторинг изменений файловой системы (ФС) и реестра, сетевая
активность, логирование вызовов winapi-фунок, анализ трафика и нажатий клавиш, установка драйвера и
другие фичи. Результат - подробный отчёт всех действий программы, на основании которого юзер сам
выносит вердикт: файл чистый или грязный);
[3] "аверский" поведенческий анализатор (иначе говоря - чек файлов проактивками АВэх. Результат авера (не
юзера) - "OK"/"название детекта");
[x] etc etc.
Как и в остальных случаях, есть несколько вариантов создания такой проверки (вышеперечисленные пункты,
само собой, можно объединять в один большой или миксовать, как по кайфу =)):
[+] ранее приведённая схема работы (чек файлов-статика) - сюда вписывается тоже отлично. И если будем
строить, скажем, "аверский" поведенческий анализатор - то, ясное дело, вместо ав-сканеров будут
работать проактивки - принцип их обработки схожий. Особое внимание заслуживает диспетчер задач (ДЗ) -
его втыкаем на отдельную ВМ. Функции диспетчера - принимать/обрабатывать task'и, выдавать файлы
обработчикам, получать от них результат и отсылать его в БД, откат снапшотов после каждой проверки
файла проактивками, обновление ОСей/аверов (и другого софта) с созданием новых снапшотов итд.
Кроме того, ДЗ в целом мониторит работу движка сервиса. И если что-то пошло не так, то принимает
соответствующие меры (например, если какой-то процесс заглючил (что часто бывает), или проверяется
хитрый софт, который bsod'ит ось etc).
[+] всё остальное:
[1] другой каркас: вариант без ДЗ, поочерёдная проверка, принцип "матрёшки" (внутри ВМ запущены
другие ВМ) итд;
[2] альтернатива ВМ: физическая машина (например, используется полный бэкап системы в посекторном
режиме с возможностью отката), песочницы (со специальными анализаторами) и другое.
-------------------------
0x
-------------------------
Вот такая получается картинка. В принципе, всё относительно просто. Разве что много рутины, очевидной и не
очень, которая появится в процессе разработки. Но это всё фигня. Главное - найти мощный сервак :p. Так что,
кому надо - делайте, и всё получится, ёба.
Смотри также:
[1] Крис Касперски "VirusTotal своим руками, лапами и хвостом", http://www.insidepro.com/kk/314/314r.shtml
[2] Википедия "DNSBL", http://ru.wikipedia.org/wiki/DNSBL
[3] Википедия "Сравнение виртуальных машин", http://ru.wikipedia.org/wiki/Сравнение_виртуальных_машин
[+] 2013
m1x
http://lj.rossia.org/users/pr0mix/
вирмэйкинг для себя...искусство вечно
|
