Ещё раз Об АВ-чекере


Привет!

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

Итак, ав-чекер - это онлайн-сервис, проверяющий файлы/данные на вирусы/трояны/черви/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 это делается так:
      • [+] составляем полный веб-адрес (google safebrowsing);
      • [+] скачиваем содержимое по данному урлу;
      • [+] на полученной страничке ищем определённый текст (нашли "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 можно создать дополнительную ВМ, в которой эмулировать заход юзера на сайт итд).

Проверка файлов - динамика

К данной категории относятся:

  • проверка файлов на работоспособность (основная мулька - проверка на большом количестве различных ОСей. Результат - "воркает!" или "ошибка пляшет");
  • "утилитный" поведенческий анализатор (мониторинг изменений файловой системы (ФС) и реестра, сетевая активность, логирование вызовов winapi-фунок, анализ трафика и нажатий клавиш, установка драйвера и другие фичи. Результат - подробный отчёт всех действий программы, на основании которого юзер сам выносит вердикт: файл чистый или грязный);
  • "аверский" поведенческий анализатор (иначе говоря - чек файлов проактивками АВэх. Результат авера (не юзера) - "OK"/"название детекта");
  • etc etc.

Как и в остальных случаях, есть несколько вариантов создания такой проверки (вышеперечисленные пункты, само собой, можно объединять в один большой или миксовать, как по кайфу =)):

  • [+] ранее приведённая схема работы (чек файлов-статика) - сюда вписывается тоже отлично. И если будем строить, скажем, "аверский" поведенческий анализатор - то, ясное дело, вместо ав-сканеров будут работать проактивки - принцип их обработки схожий. Особое внимание заслуживает диспетчер задач (ДЗ) - его втыкаем на отдельную ВМ. Функции диспетчера - принимать/обрабатывать task'и, выдавать файлы обработчикам, получать от них результат и отсылать его в БД, откат снапшотов после каждой проверки файла проактивками, обновление ОСей/аверов (и другого софта) с созданием новых снапшотов итд.
    Кроме того, ДЗ в целом мониторит работу движка сервиса. И если что-то пошло не так, то принимает соответствующие меры (например, если какой-то процесс заглючил (что часто бывает), или проверяется хитрый софт, который bsod'ит ось etc).
  • [+] всё остальное:
    • другой каркас: вариант без ДЗ, поочерёдная проверка, принцип "матрёшки" (внутри ВМ запущены другие ВМ) итд;
    • альтернатива ВМ: физическая машина (например, используется полный бэкап системы в посекторном режиме с возможностью отката), песочницы (со специальными анализаторами) и другое.

0x

Вот такая получается картинка. В принципе, всё относительно просто. Разве что много рутины, очевидной и не очень, которая появится в процессе разработки. Но это всё фигня. Главное - найти мощный сервак :p. Так что, кому надо - делайте, и всё получится, ёба.


Смотри также:


______________________________
m1x
http://lj.rossia.org/users/pr0mix/
2013

Inception E-Zine