[ИНТРО]

Сети "зомби"... Размышляя абстрактно, не трудно найти аналоги этих сетей в нашей реальной жизни. И самая крупная сеть "зомби" - телевидение. Да, телевидение обладает всеми качествами реальной "зомби" сети. Есть хозяин, к примеру Телевизионная компания ОРТ, есть сегменты сети, управляемые телевизорами, и "зомби" - это люди прикованные к "голубым экранам" своих телевизоров. Возможно кому-то пример не понравится, но этот пример не политический демарш или протест против телевидения (хотя кто знает?), а изложение одной из концепций построения сетей, которые не разрушимы (во многом благодаря тому что легитимны). Наша задача построить неразрушимую сеть (или сделать так чтобы разрушение этой сети давалось максимально дорого).
В этой статье я не приведу готовых программных решений, это я хочу оговорить сразу. Цель статьи показать определенные наработки людей из нашей команды в этой области. Наработки - нереализованные (за неимением времени), но тем не менее интересные, и я полагаю способные вызвать интерес у читателей, а также развитие этих наработок, и возможно в конечном итоге оформление в более менее реальный проект. Когда все это разрабатывалось, активно искались какие-то материалы по данной теме, но они очень скудны, причем не только в Рунете, но и в зарубежных источниках, поэтому надеюсь эта статья восполнит некоторый пробел в этой области. Кое-какие линки будут приведены в конце статьи. Также для тех кому статья покажется через чур заумной - рекомендую почитать сначала раздел [Терминология], а затем [Практический алгоритм реализации], после чего возможно появится интерес к прочтению всей статьи :)).

[Вкусность идеи]

С чего все начилось? "Определенная группа людей" (не буду называть тут не чьи имена... так как это не имеет значения в данном случае), объединилась для разработки различных проектов, и в один прекрасный (или не очень) день возникла идея создание rat-сети, или говоря по-русски сети "зомби". То есть, что из себя представляет стандартная сеть "зомби"? Это несколько компьютеров (от 10 до многих тысяч и даже возможно миллионов) которые имеют среди прочего софта проинсталлированного на них официально, небольшие "модули" или проще говоря трояны установленные тайно. Модули позволяют их хозяинам управлять этими компьютерами, либо выполнять от имени этих компьютеров определенные действия. Начиная от спама и заканчивая ddos'ом. Полезно иметь такую сеть у себя на хакерской "ферме". Это огромная власть, и чем больше на вашей "ферме" численность "парнокопытных", тем эта власть более могущественна. Ну и естественно такая заманчивая идея пришла этой "определенной группе людей" не первой. Это уже давно известно и на данный момент такие сети являются распространенным явлением. Но так как эта "группа людей" была довольно таки амбициозна, и в тоже время исследовательски направленной, решено было разработать собственный алгоритм построение такой сети.

[Краткая терминология]

Бот - он же троян, он же модуль. Программа контролирующая компьютер жертвы (зараженный компьютер).
Сектор - логическое звено сети третьего уровня (группа ботов под управлением Организатора сектора).
Организатор сектора - бот, имеющий некоторые расширенные функции по сравнению с обычными ботами.
Сеть "зомби" - сеть зараженных ПК ботами.

[Базовые принципы]

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

1. Высокая степень устойчивости и поддержания внутренней структуры сети.
Этот принцип является основным и распадается на более мелкие:
1.1 Модульность.
1.2 Децентрализованность управляющих структур.
1.3 Криптостойкость каналов связи (шифрование всей информации).
1.4 Высокая сегментация внутри сети.
1.5 Собственные протоколы авторизации и аутентификации ботов.
2. Глубокая интеграция в систему ("живучесть" в среде).
3. Максимальная незаметность для жертвы.
4. Максимальная автономность сети.

Теперь по прорядку проедемся по этим принципам, изложив то что было наработано "определенной группой людей".
Небольшое отвлечение. На сайте http://www.computer.edu.ru/make/ss2k4/ посвященном разработке интеллектуальной программы для общения с человеком на языке эсперанто мне встретились интересные слова-размышления. Приведу цитату:

"Есть достаточно интересная и сложная тема: разговор человека и компьютера. Т.е. есть человек, и есть машина. Они разговаривают (хотя бы просто в текстовом режиме). Нужно, чтобы машина правильно разбирала то, что ей говорят, по возможности понимала, и адекватно разговаривала. Впрочем, можно разговорить и пару (или больше) машин между собой. Или попросить машину реально выполнять то, что ей говорит человек, на вымышленном ("мир кубиков") или даже на реальном мире ("эй, машина, а сотри-ка все файлы? как, уже?!"). И устроить согласованное взаимодействие компьютеров по сети так, чтобы они решали какую-то общую задачу (или наоборот, соперничали, но это тоже согласованное действие)."

Мы не будем рассматривать вариант разговора человека с машиной, так как в нашей сети все сходилось на том чтобы заставить общаться между собой ботов на зараженных машинах. Кто-то скажет -"Ха! Тривиальная задача. Вот вам алгоритм GET PUT HEAD и т.п". Но проблема заключалась именно в сложности данного общения в той среде в которой планировалось разворачивать и использовать таких ботов. Это конечно не приближало эту систему к типу общения "человек-машина", но тем не менее вынуждало строить сложную систему взаимоотношений ботов. При этом если вы знаете что такое троянмэйкинг, то поймете сколь малыми ресурсами (память/место на диске/процессорное время) приходиться оперировать в подобных задачах. Нужна была определенная логическая структура, каркас, на который насаживалась бы остальная конструкция сети (и которая соблюдала бы первый базовый принцип).

[Принцип построения сети]

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

Глобальная схема сети:

[ Хозяин сети ] <- физически существующий человек (ОГЛ? :)

[ компьютер(ы) хозяина сети ] <- Первый уровень
/ | \
proxy vpn shell's <- Каналы связи
/ | \
---------------------------------------------------------------------
Порутанные сервера (взломанные сайты), анонимные фтп (EzSharez etc.),
файлообменные сети, icq и прочие aim боты,
кэш поисковых систем (Google,MSN etc.), бесплатные доски объявлений, <-- Второй уровень
форумы (в частности приватные сообшения в форумах), чаты,
irc боты и т.п
---------------------------------------------------------------------
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
||||proxy||||||||proxy||||||||proxy||||||||proxy||||||||proxy||||||||| <-- Каналы связи
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
========= Сеть из зараженных машин ==========
===========================================================================

Третий уровень
====================================================================

Принцип шахматной доски начинает работать только на третем уровне. Так как это и есть "корни" нашей системы, хотя конечно если понимать под корнями то что обычно понимают... Но половина ведь из вас юниксоиды, и такая система вам не кажется не логичной? Кому кажется - отправляю вас к изучению файловой системы UNIX :)).
Итак, что обозначает вся эта схема? Есть человек построивший свою сеть. Что ему нужно после построения? В первую очередь управление сетью, во-вторую контроль за ней. Как в данной схеме осуществляется контроль и управление? Через кусочки зашифрованной информации направленные/размещенные на определенных ресурсах - на втором уровне (подробнее смотри в практическом примере реализации).
Рассмотрим подробнее третий уровень нашей сети, а точнее к организацию его структуры.
Что особо важно на этом третьем уровне для нас, как хозяев такой сети? В первую очередь высокая сегментонезависимость. Во вторую очередь - полное шифрование информации хранящейся на локальных компьютерах и передающейся по сети.
Это два самых главных момента. За ними сразу же следует - незаметность в сети, незаметность в системе, устойчивость в системе.
Итак, долго обсуждая тему организации структуры сети, ОГЛ разродилась идеей о принципе "шахматной доски", где каждый бот сети - клетка на доске, и которому известно только о 8 своих собратьях. Помимо этого эта доска не "бесконечна наружу", то есть имеет определенные масштабы. К примеру, возьмем масштаб обычной шахматной доски 8х8. Этот квадрат 8х8 - является сектором, содержащим в себе 64 бота, и любой из этих ботов не знает что его сектор содержит 64 его собратьев, а знает лишь то, что у него есть 8 соседей и КАКОЙ-ТО организатор сектора (типа - работаю на босса, но не знаю кто он). Этим и заканчивается его маленький мир. Зато организатор сектора знает что у него есть 64 подопечных (либо 64 вакансии для подопечных, но это уже тонкости). Орг.Сектора также знает о наличии соседнего сектора (или о его гипотетическом наличии, или даже не знает о нем ничего, но это опять же тонкости :)). Если гибнет один бот (в результате переустановки системы/гибели винта и прочих стихийных бедствий :), то мы создаем лишь небольшую брешь в нашей сети, и наш сектор получает информацию о том, что открыта вакансия для еще одного бота внутри его структуры. Если гибнет организатор сектора, в результате тех же событий, то боты не найдя своего босса, пытаются путем широковещательных запросов (к примеру) обнаружить еще одного босса, и если таковой находиться и у него есть вакансии для этих безработных бедолаг, то он их принимает, либо сообщает им адрес соседнего сектора о наличии которого он знает (если знает). Сектора, по сути, представляют собой такие же клетки на шахматной доске, но содержащие в себе еще более мелкие элементы. Конечно, вся эта идея секторов и шахматной доски плотно завязана на маршрутизации, адресации и т.п (хотя возможны и другие варианты).
" Определенная группа людей" выдвнула следующие идеи относительно адресации этих структур. подобно цветам в HTML, сектора были адресованы следующим образом: Первый сектор имеет адрес AAAAAA, второй BAAAAA, и т.д. Соответственно боты в этих секторах адресовались так: AAAAAA-e2,BAAAAA-e4, и т.п. Тут отличия от шахматной доски никакой нет, e2-e4 - это именно E2-E4 - тот самый "первый ход Бендера" :). Теперь представим рассмотренную схему на рисунке:

рис. 1 строение одного сектора, где каждая машина - бот с адресом вида AAAAAA-a1, AAAAAA-a2, ... AAAAAA-e5

рис. 2 Примерное строение организации секторов

кол-во секторов 308.915.776 (26^6), максимальное кол-во ботов в сети 19.770.609.664 (308915776х64). На наш Интернет хватит :)).

В этой сети любой бот может осуществлять поиск командных файлов, (то есть делать запросы через гугл и т.п), и после получения такого файла обмениваться им с соседями, в том числе и со своим организатором сектора. Хотя возможны и альтернативные варианты построения. К примеру - не свзязывать между собой сектора, а считать что каждый сектор - автономная сеть (подробнее читай ниже). Скажу пару слов об этом организаторе сектора в случае если сектора взаимосвязаны.Организатором Сектора, я называю такой же компьютер в сети, но несущий на себе дополнительную "чисто организационную" задачу, не более того. Он не передает команды ботам от хозяина, и боты не передают команды ему от хозяина, но в результате взаимодействия ботов внутри сектора формируется определенная информационная среда, более мобильная, нежели среда взаимодействия всей сети в целом. После выполнения определенного задания полученного в сектор (или начало его выполнения) - каждый из ботов передает сигналы на организатор сектора, после получения к примеру 80 % откликов от ботов, организатор формирует файл ответа для хозяина, и рассылает его всем своим ботам. После получения такого файла боты начинают пытаться передать информацию по определенным каналам (через бэкдоры на взломанных серверах, и т.п).
Можно построить сеть на множестве подсетей (читай секторов) не связанных между собой (то есть не знающих и даже не предполагающих наличие соседних сетей/секторов). Некоторые уже действующие "зомби"-сети так и построены (читай ниже доклад Honeypot.org о подобных сетях). Тут есть плюсы и минусы. Не будем на них останавливатся ибо они очевидны.

[Способы разворачивания сети "зомби"]

Как вы наверно поняли, сеть с такой сложной стуктурой, разворачивается не в ручную. Оптимальный вариант - написание лоадера, который будет минимально весить, использовать какую-нить багу в IE, и прочих прелестях виндовз,(RPC,MSSQL,UnPnP ...) также подойдут синженерные письма, типа - "Вы только что оплатили заказ на сумму 200 у.е в нашем магазине, для получения информации о способах доставки товара перейдите по ссылке http://hackerzfakeshop/exploit_for_ie.htm" или всем сотрудникам организации рассылается поддельное письмо от лица и за подписью руководителя службы ИТ или информбезопасности. В письме с соблюдением всех корпоративных стандартов (привычные цвета, оформление, язык, подписи и т. д.) сотрудников просят срочно установить последнее обновление системы безопасности, устраняющее найденные недавно "дыры". В роли обновления выступает наш лоадер, и после запуска на целевом компьютере, этот лоадер должен выполнять определенные действия, как то:

[1]Загрузка всех необходимых модулей с одного из многочисленных зеркал
[2]Запуск модулей-контроллеров
[3]Сканирование подсети заражанного компьютера
[4]Дальнейшее распрастранение по подсети
[5]Удаление себя на целевом компьюетере на котором загрузка и установка модулей прошла успешно.

То есть после установки всех нужных модулей, наш лоадер продолжает свое дело, но уже в отношении компьютеров в одном сегменте сети с зараженным компьютером. Что это дает? Ну во-первых, более менее централизованные сектора, во-вторых, внутри различных домовых локальных сетей (которые сейчас так популярны в крупных и не очень городах), защищенность компьютеров на порядок ниже, чем у компьютеров подвластных всем ветрам Интернета. К примеру, бывает, в таких сетях закрыты порты 445,139,135, для избежания атак на эти службы виндовз. Что это порождает? Тепличный климат. Юзера не патчат свои тачки, и это дает нам возможности по легкому затрояниванию подобных сеток. Ведь выход в интернет с этих компов будет (пускай они и сидят за шлюзом, траф то они генерить могут :)), а значит наша задача будет выполнена. Теперь сразу же скажу о плюсах нашей системы в подобных сетях. Почему классические трояны в данном случае проигрывают? Хозяин как правило хочет иметь direct access к зараженному компу (прямой доступ). А с сетками за шлюзами и фаэрами, это проблематично (хотя масса троянов делает всевозможные грамотные бэкконнекты). Нам не потребуется "прямой доступ", но потребуется обход персонального фаэрвола, наличие которого нам стоит предполагать на целевом компьютере. Здесь нас выручит туннелинг, интеграция с различнами приложениями, типа ie, и т.п (о способах обхода фаэрволов читай статьи said'a в winter-2004/2005 и spring-2005). В любом случае - в итоге нам нужно просто получить акцесс к вэбу, запросить командный файл, скачать его по http, и успокоиться. Хотя конечно, для выолнения задач типа ддос, потребуются дополнительные "фишки", по организации этого самого доса.
Помимо ддоса, спама и прочих сетевых приблуд, мы можем использовать нашу сеть к примеру, как мощную вычислительную базу. Если будет перед нами ставиться такая задача, то тут открывается еще одно поле для действия - это закрытые локальные сети, а точнее полузакрытые (вроде той что мне приходиться каждый день админить :). В таких сетях доступ к Интернет имеют "избранные", к примеру начальники отделов, но компов в сети гораааздо больше, просто они не имеют доступа в интернет. Тем не менее эти - "заблудшие овцы", имею процессор, память и прочие нужные для вычисления рюшки :)), и этому добру нечего стоять без дела, подсчитывая баланс в 1С :), гораздо интересней использовать их для взлома MD5 хэшей, SHA-1, и всего что вам взбредет в голову :-)).. Тут в роли передающего всю информацию в сектор бота должен выступать компьютер с доступом в инет. Но это уже немного другая история, хотя такая функциональность предусматривалась в проекте ОГЛ :)).

[Слабые стороны и их устранение]

В рассматриваемой нами модели сети, естественно есть масса изъянов. Самый очевидный, это внедрение "раковой опухоли" в нашу сеть (см. следующий пункт). То есть создание ложных структур, которые будут мешать нормально работать нашей сети. Эта опасность представляется в виде:
а) Ложных агентов,
б) Ложных секторов,
в) Ложных Организаторов секторов,
г) Ложных командных файлов (в случае раскрытия алгоритма проверки подлинности таких файлов).
Для борьбы с этими факторами, предлагается следующие методы.
1. При получении неверного формата данных от агентов/Организаторов секторов, их адреса заносятся в список untrusted, и при повторном получении неверного формата данных, помечаются как скомпрометированные, и выбывают из сети. Данные об untrusted хостах не рассылаются между другими секторами, а имеют актуальность только в рамках сектора в который был получен неверный формат данных (во избежания ликвидации сети через эту функцию). Здесь также стоит учесть функцию авторизации, то есть прежде чем обмениваться данными, боты должны удостоверится, что они оба разговаривают на одном языке, а то может получиться, что с одной стороны бот, а с другой nmap (netcat,telnet etc.) :)))...
2. Для борьбы с пунктом г), предлагается следующий алгоритм шифрования командых файлов. Использование public/private ключей, (PGP), но только, в нашей сети распрастранятся будет private key, а public будет засекречен и хранится у хозяина сети. Для чего это надо, думаю понятно. Итак, как формируется командный файл:
[1] Хозяин сети подписывает файл своим приватным ключем (Mp)
[2] Хозяин сети шифрует файл после подписи открытым ключем бота (Bo)
[3] Бот получив файл расшифровывает его своим закрытым ключем (Bp)
[4] Затем проверяет подпись открытым ключем Хозяина сети (Mo).
Мы допускаем возможность раскрытия ключей Bp и Mo, и исключаем раскрытие Mp и Bo.
Соответственно, если Bp и/или Mo и попадет в руки "злоумышленников", то они смогут только расшифровать командный файл (и порверить его подпись), но не смогут создать ложный командный файл. Язык описания команд в командном файле, естественно должен быть максимально НЕ логичным и запутанным. В данном случае это будет сильной стороной языка :-)).
Еще одна слабая сторона. Отклик из сети к хозяину. Как рассматривалось выше, отклики формируются внутри секторов. То есть каждый сектор после выполнения задания формирует пакет для доставки на наш feedback сервер (в нашем примере сервер с бэкдором). Представьте себе у нас 10000 секторов, и если каждый поместит на сервер файл, к примеру такого содержания:
11184810 -- имя сектора в DEC (AAAAAA)
3С -- кол-во ботов в секторе в hex (60 штук в примере)
C8 -- статус (код 200 в hex)
Это примерный файл. Заметьте имя сектора мы храним в dec, остальное в hex, (это только лишь некоторые наброски для того чтобы запутать врага). Вес файла 16 байт. При этом мы шифруем файл через PGP в ASCII формат. Получаем примерно 870 байт. Многовато, но не шифровать нельзя. Итак, суммарный объем отклика от сети будет составлять 10000x870=8.3 Мб!!! Восемь мегабайт, это вам не фунт изюма, а довольно таки заметный файлик. Если мы не будет шифровать, то размер будет составлять: 10000х16=156,25 Кб. Уже лучше, но как мы сказали не шифровать нельзя. ASCII формат в PGP прибавляет веса где-то на 30%, если его не применять, файл сократится до 500 байт, но это не облегчение. Вообще в данном случае PGP нам не подходит. Для командного файла PGP оптимальный вариант, а вот для формирования отклика нет. Нужно использовать криптографическое сжатие данных этого файла+возможность дописывать в файл данные, без поверждения его структуры. То есть. Нам нельзя плодить 10000 маленьких файлов на сервере, а нужно все писать в один, и выглядеть это будет примерно так (в plaintext'e):

11184810
3С
C8
--
12233386
3С
C8
--
...

Каждый агент, найдя файл отклика на сервере, анализирует его на предмет данных из его сектора, и если они есть, покидает сервер, если нет, дописывает их в конец этого файла. В каждом секторе должен быть свой ключ для шифрования и сжатия данных. Выбираться ключ должен по определенному алгоритму. Возможно даже использование "одноразовых блокнотов" при формировании откликов. Отвлекусь и скажу что такое сжатие данных и "одноразовые блокноты".
Сжатие данных - это процесс устранения избыточности представления информации. В нашем случае сжатие очень подходит, по причине довольно-таки узкого набора символов в тексте. Причем можно даже не прибегать к готовым алгоритмам, а быстро реализовать свой - узкоспецилизированный, что позволит нам работать чуть-чуть быстрее (при грамотной реализации). В нашем примере, избыточность данных налицо. К примеру заместо того чтобы писать АААААА шесть раз (или переводить это в dec), можно ограничится символом j, код этого символа в dec 106, а в hex 6A. Думаю понятно почему 6 А :). И теперь пропишем в hex редакторе остальное содержание нашего файла, разделителями пусть будет 20. получаем в HEX:
6A 20 3C 20 C8
Вес файла сократился с 16 байт до 5 байт, неплохо :). При этом, данные все те же, только представлены немного по другому. Вот это и есть сжатие данных, хотя конечно есть еще масса других алгоритмов, но для их описания потребуется еще одна статья (или книга :)).
Теперь про "одноразовый блокноты".
Можно сказать, это идеальный способ шифрования данных. Советские шпионы его очень любили, и их шифровки до сих пор не раскрыты ЦРУ. Процитирую Б.Шнаэра: "в классическом понимании одноразовый блокнот является большой неповторяющейся последовательностью символов ключа, распределенных случайным образом и написанных на странице блокнота... ... каждый символ ключа используется только единожды и для единственного сообщения. Отправитель шифрует сообщение и уничтожает использованные страницы блокнота... Получатель использует точно такой же блокнот и дешифрует каждый символ текста... ...Новое сообщение новые символы ключа" [3].
О конкретной реализации этого метода опять же говорить не будем, так как задача эта не из простых, как и многое в этой системе.
Как видите узких и трудных мест довольно много, но их обнаружение делает систему более стабильной.

[Реальный пример угрозы типа "раковая опухоль"]

Сюда хочу привести в качестве примера, один интересный проект, который запустил некто Торстен Хольц (www.honeynet.org). Он создал большую Honeypot сеть, для того чтобы изучать работу бот-сетей ("зомби"-сетей), и надо сказать довольно неплохо приуспел в этом. Мы своей статьей как раз помогаем таким людям как он :)), и в тоже время учим хакеров "лучше думать", при организации своих сетей.
Привожу цитату из журнала "Компьютерные вести" (www.kv.minsk.by) статья Андрея АСФУРА "Особенности компьютерного зомбирования":
" Основой проекта Хольца, явилась сеть из минимально защищенных компьютеров-ловушек, которая была подвергнута заражению со стороны хакеров, а потом регистрировала всю деятельность ботов. Таким образом, с помощью нескольких "пожертвованных" хакерам компьютеров отслеживалась деятельность владельцев бот-систем.
Команда Хольца наблюдала работу более чем сотни различных бот-сетей, в некоторые из них входило до 50 тысяч зараженных компьютеров. Специалисты обнаружили, что эти компьютеры незаметно для их пользователей общаются между собой и работают как серверы. Стоит отметить, большинство машин были постоянно подключены к широкополосному доступу в интернет.
Руководителю проекта стало известно еще о нескольких нюансах хакерской деятельности. Во-первых, было найдено несколько небольших зомби-сетей, которые находились под контролем одних и тех же личностей. По мнению Хольца, распределяя контроль над машинами на несколько серверов, хакеры способствуют тому, что бот-сети становятся менее уязвимыми. Во-вторых, оказалось, что операторы зомби-сетей активно соревнуются друг с другом. Причем имеет место продажа целых сетей, что позволяет говорить о существовании целого теневого сектора, в котором "процветают" как спамеры и авторы вирусов, так и операторы бот-сетей. Наконец, Хольц убедился, что далеко не все хакеры обладают высоким уровнем технической грамотности. Многие из них просто задают глупые, а иногда и нелепые вопросы друг другу.
Механизм "зомбирования" прост. Взломанные компьютеры сообщают о себе по IRC-каналам. После этого на машину посылается условный сигнал, активизирующий бот. В результате, компьютеры-зомби начинают либо безобидную рассылку спама, либо передачу злоумышленникам конфиденциальных данных.
По мнению журнала New Scientist, раньше провайдеры пытались управиться с бот-сетями, производя реверсный инжиниринг хакерских ботов: они получали из них логины и пароли, а затем и приводили бот-сеть в негодность. Однако реверсный инжиниринг занимает большое количество времени. Кроме того, хакеры быстро нашли средства борьбы с ним: теперь все чаще встречаются боты, которые моментально самоуничтожаются, если их пытаются взломать.
Команда Хольца использует другой метод: в зомби-сеть внедряется фальшивый бот, очень похожий на оригинальный, но записывающий в отдельный файл все команды, которые ему передают. В другой файл записывается вся остальная информация.
Дроны - те самые фальшивые боты - не участвуют в рассылке спама или атаке на онлайн-ресурсы, поскольку запрограммированы на игнорирование таких действий. Иногда это вызывает подозрения у хакеров. Несколько раз дроны обнаруживали и закрывали для них доступ в хакерские чаты. Один из хакеров и вовсе попытался организовать против команды Хольца DoS-атаку. Тогда Хольц прибегнул к тем же средствам, которые спамеры используют для того, чтобы заметать следы: команды дронам передаются через удаленные серверы, так что их истинный источник отследить не удастся."
Как видите - "механизм зомбирования прост", и механизм управления сетями прост, отсюда и быстрое обнаружение сети. IRC-боты для управления "зомби"-сетями уже сейчас не актуальное решение. Рано или поздно вашу сеть накроют, если вы будете рассчитывать только на управление ей через IRC-бота. И опять же читая эту заметку, вы наверное заметили, что ни одна из описанных здесь методик уничтожения бот-сетей (внедрение дронов, реверсный инжиниринг) не сможет быть реализована в сети построеннной в соответствии с нашими базовыми принципами. Внедрение дронов, будет блокировано хотя бы даже нашим протоколом аутентификации и проверки подлинности бота. Для создания дрона, который будет полностью имитировтаь нашего бота потребуется для начала полностью дизассемблировать его (полиморфизм, шифрование, антиотладочные механизмы должны затруднить этот процесс). Затем, изучить структуру данных, а для того чтобы изучить структуру данных нужно УЖЕ внедрить дрона. Получается замкнутое кольцо. При этом одной-двух ошибок в формате передаваемых данных (или протокола аутентификации) будет достаточно для блокировки такого лже-бота.

[Программная модель ботов]

Что должна представлять из себя программная архитектура бота? Из предыдущего материала можно предположить, что наши боты должны строится на модели клиент/сервер. И на первый взгляд это кажется логичным. Но ведь модель клиент/сервер - отнюдь не единственная. Позвольте привлечь ваше внимание MAM, или mobile agent model, переведу это на русский, как модель мобильных агентов. Это условие позволяет нам придержитватся базовых принципов, в частности пункта 4. Максимальная автономность сети. Чем плохи в данном случае модели клиент/сервер, тем что на сервер возлагаются, как правило, слишком большие полномочия, и гибель сервера приводит к дестабилизации сектора/сети. Технология мобильных агентов, еще молодая, и наработок в этой сфере не так много, но тем не менее это нам позволит быть на шаг впереди. Остановимся подробнее на понятии мобильных агентов, и их модели построения.
Для начала несколько базовых понятий:
MAE - (mobile agent enviroment) - окружение мобильного агента, или среда исполнения мобильного агента. Эта среда позволяет агенту беспрепятственно выполнять свои задачи. В нашем примере MAE должен создавать описанный выше лоадер. Отталкиваясь от этой идеи, лоадер не должен закачивать все модули и т.п, он только готовит среду MAE, к примеру - устанавливает бэкдор, определенные разрешения, подготавливает информационное поле, для будущего агента, и покидает компьютер.
Mobile agent=Code+State - это понятие подразумевает разделение внутри самого мобильного агента. Агент обладает самим исполняемым кодом, и state - информацией, которая требуется для исполнения кода, либо для чего-то еще (информация о состоянии). Это может быть ip-адреса соседей, какие-то ключи, записи о незавершенных задачах и т.п.
Client-centric - клиент-ориентированность мобильных агентов, подразумевает под собой, то что всю основную работу производит клиент, а серверные функции в данной системе выполняет MAE. То есть согласитесь ваш броузер, гораздо надежнее чем web-сервер какой-либо конторы. Не в плане безопасности и устойчивости к взлому (в данном случае речь не об этом). А в плане мобильности и автономной работы. Вы захотели получить страницу ya.ru, запустили броузер, запросили страницу. Захотели передать почту, зашли на web-mail передали почту, и т.п. Так же должен работать наш мобильный агент, он должен использовать MAE для решения своих задач, которые могут менятся от раза до раза. Агент, должен быть максимально автономным. Сервер же заточен под определенный круг служб.
Расширяя идею мобильных агентов, можно предложить еще более новаторский метод работы внутри секторов. Будем исходить из того, что MAE в нашем случае выполняет все обязанности (ддос, криптовка-декриптовка данных, и т.п), но не занимается транспортировкой данных куда либо. То есть MAE является полностью локальной программой (комплексом модулей), не считая ее "сетевых вылазок". За передачу данных отвечает мобильный агент. Суть в следующем. На организаторе сектора содержится код и информация о состоянии (state) мобильного агента. После получения командного файла оргнизатор сектора запускает мобильного агента по сектору. Агент рекурсивно обходит всех ботов, и доставляет им необходимую информацию. Для отправки данных обратно на организатор сектора, мобильный агент постоянно "бродит" по сектору (как муравей присматривает за тлей), и отслеживает ботов выполнивших задачу. Это позволяет оптимизировать работу сектора в целом (боты не будут простаивать без дела), и снять с ботов функции транспортировки данных. Так же позволяет просматривать активность сектора и ботов. Возможен вариант, когда мобильный агент читает информацию о соседях бота из базы самого бота, а не Организатора сектора. То есть, если придерживатся принципа шахматной доски, то агент, может "бродить" по сектору по следующему алгоритму:
Агент стартовал с Орг.сектора и попал на первую клетку доски (на первого бота). Он читает информацию о 8-ми соседях бота, и копирует себя (естественно вместе со state информацией), на эти адреса, при этом адрес с которого он приходит он затирает из своего журнала обхода (назовем его так). То есть здесь получаем не рекурсивный обход, а что-то вроде обхода методом деления.
При попадании на соседний бот, агент считывает информацию уже о его соседях и снова копирует себя на эти адреса, при этом он попадет и на тот бот, с которого пришел. Для того чтобы не наводнять сектор многочисленными копиями агентов (или просто не генерить лишнюю работу), нужно создавать определенные временные метки и какой либо ID для агента. То есть, если агент попадает на бота, на котором совсем недавно побывал другой агент, он передает state информацию организатору сектора, и уничтожается. Организатор сектора анализирует получаемую информацию по временным меткам, и актуальной будет информация полученная от последнего агента. Хотя с отслеживанием информации все не так просто. Здесь скорее всего потребуется какая-то математическая модель, для контроля полноты информации, и исключения недополучения информации или ее дублирования.
Вообще, для лучшего понимания этой системы рассмотрим один интересный пример - колония муравьев. Каждый муравей живет по следующим трем основным правилам:

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

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

1. Если ты оказалась далеко от других птиц, следуй к ближайшей из них.
2. Если ты можешь врезаться в другую птицу, поверни в сторону.
3. В противном случае, лети в том же направлении, что и ближайшая к тебе птица.

Используя эти три простые правила, ни одна из птиц не представляет себе поведения всей стаи. «Птица впереди» — это просто позиция данной птицы в данный момент и через несколько минут ее заменят другие. Все это просто информация к размышлению.

[Способы хранения и обмена информацией внутри сети]

"База данных членов организации - это весьма важная вещь. С одной стороны вы хотите предоставить к ней доступ всем членам, желая, чтобы они общались друг с другом, обменивались идеями и делились друг с другом бутербродами. С другой стороны, если вы пустите в вашу базу данных кого угодно, сведения обязательно попадут в руки надоедливых агентов и докучливых поставщиков всякого хлама по почте." [3] Читая эти строки я думаю у вас уже возникают правильные ассоциации (что? еще не возникают?! тогда читайте эту статью с начала...). Под "кого угодно" в нашем случае стоит понимать описанных выше дронов, под "надоедливые агенты" - это дяденьки из AV и Honeypot компаний. За деталями и более подробной информацией я отправляю вас к книге [3] глава 3.8 "Криптографическая защита баз данных", которую вы можете найти на сайте http://cryptopunks.ru. Скажу лишь, что суть криптографической защиты сводится к тому, что легко получить информацию об одном агенте, но очень тяжело обо всех агентах сектора. Реализуется это с помощью однонаправленного хэширования адреса агента, и использования этого адреса в качестве ключа для шифрования всей остальной информации об агентах каким либо симметричным алгоритмом (здесь желательно использовать более длинные адреса клиентов). В данном случае нужно точно знать адрес агента (в plaintext'e) иначе информация об агенте добывается довольно такие дорогостоящим путем (брутфорс). Причем, эта защита базы данных может быть наложена поверх криптографического сжатия данных, описанного выше.

[Практический алгоритм реализации]

Информация изложенная в статье очень отрывиста, я ведь предупреждал об этом с самого начала:). Но чтобы как-то обобщить ее, давайте спроектируем уже конкретную модель сети . Эта модель естественно одна из многих, которую реально построить, и довольно примитивна.
Итак, основной каркас сети - сектора. Сеть состоит из независимых секторов. Сектора никак не связаны друг с другом.
Первый наш программный продукт, будет называться loader, и на него ложатся следующие функции (после его запуска на ПК жертвы по имени victim-A):
пункт I:
[1] Копирование на hdd модуля bot и модуля sector (из первоисточника).
[2] Копирование на hdd открытого ключа хозяина сети и закрытого ключа бота (из первоисточника).
[3] Прописывание программы bot и sector в систему для последующего запуска (в реестр, например)
[4] Считывание информации о IP адресе ПК victimA, и сканирование подсети этого ПК на возможные уязвимости.
[5] В случае первого успешного обнаружения уязвимого компьютера (victimB), транспортировка модулей loader, bot на уязвимую машину (с victimA на victimB).
[6] Создание записи в базе данных бота на victimA, о боте victimB.
[7] Назначение ПК victimA - Организатором сектора.
[8] Удаление себя с ПК victimA (удаление модуля loader).
Теперь действия loader'a на всех последующих компьютерах (пока не будет достингнут предел численности ботов в секторе):
пункт II:
[1] Копирование открытого ключа хозяина и закрытого ключа бота (из первоисточника).
[2] Прописывание программы bot в систему для последующего запуска.
[3] Считывание информации о IP адресе ПК victimB (а далее victimN), и сканирование подсети этого ПК на возможные уязвимости.
[4] Передача информации о IP адресе ПК victimB (а далее victimN) на Организатор сектора victimA.
[5] В случае первого успешного обнаружения уязвимого компьютера (victimN), транспортировка модулей loader, bot на уязвимую машину (с victimB на victimN).
[6] Удаление себя с ПК victimA (удаление модуля loader).
И так далее, пок сектор не заполнится. Как только произойдет заполнение, loader начинает все с чистого листа (см. пункт I).
Здесь loader несет на себе функцию мобильного агента, используя в качестве MAE - уязвимости ОС, и любого софта на ПК.
Теперь рассмотрим, работу уже созданного сектора.
Организатор сектора (модуль sector), после инициализации всего сектора (т.е получения списка IP всех своих "подопечных" ботов), запрашивает на Google командный файл, к примеру с именем AB6053DA7DEE70F0FEF630DDAFD5FDBA-command-net. Естественно предварительно, хозяин сети должен разместить этот файл, а также ссылки на него на нескольких подконтрольных сайтах (под словом несколько понимается от 200 и выше). Думаю что гугл рано или поздно выдаст линки на этот файл. Организатор сектора шлет запросы с определенным интервалом времени, и как-только получит ссылки на файл, скачивает его. После проверки файла на соответствие CRC, а также проверки синтаксиса расшифрованного командного файла (здесь надо предусмотреть проверку синтаксиса, к примеру аля perl -c file.pl :). Если файл корректно составлен, то принять его к исполнению, если нет - запрашивать дальше. Думаю с получением командного файла все ясно. Теперь что в файле должно содержатся помимо непосредственно задачи для исполнения. Командный файл, должен выполнять еще и функцию "refresh information" - или обновления информации. В частности в нем должны содержатся url сайтов, с которых можно получить командные файлы в последствии (для того чтобы снизить процент случайности), url сайтов с которых можно скачать исполняемые модули (зачем - читай ниже).
То есть сектор накапливает определенную базу информации. При этом он разделяет информацию на устаревшую и актуальную. К примеру, url сайтов, с которых он получает не корректные командные файлы или не получает файлы совсем - он может переводить в раздел устаревших. Для чего это нужно? Как правило, AV компании если обнаруживают ресурс к которому обращаются всякие сетевые черви и т.п, такой ресурс закрывают, или начинают с его помощью подрывную деятельность (формирование лже-файлов и т.п). Мы же постоянно будем обновлять информацию о таких ресурсах для Орг.сектора.
Итак, после получения корректного командного файла, Орг.сектор закачивает модуль mobagent, с url прописанного в командном файле. И после проверки CRC для этого модуля, запускает его в своем секторе.
Итак, в игру вступает еще один вариант мобильного агента - модуля mobagent. Он выполняет следующие функции:
[1] Обходит рекурсивно весь сектор, согласуясь со списком ботов, поученных от Орг.сектора
[2] При попадании на ПК с ботом, он оставляет информацию для этого бота, и команды к исполнению шифрованные ключем конкретного бота (ключ получаем в результате однонаправленного хэширования адреса бота). Здесь стоит отметить что бот знает свой адрес в plaintext'e, а для получения ключа хэширует его по определенному алгоритму.
[3] Оставляет метку (феромон) в базе даннх бота, и следует к следующему адресату.
[4] Обойдя всех ботов, мобильный агент передает на Орг.сектор информацию о том что все боты приступили к выполнению задачи.
[5] После передачи информации на Орг.сектор, мобильный агент переходит в состояние "creep", а проще говоря рандомно блуждает по сектору и отслеживает работоспособность ботов. Как только бот выпадает из сети (к примеру отключения ПК), агент тут же сообщает об этом в Орг.сектор.
[6] Мобильный агент постоянно сообщает на Орг.Сектора (с определенным интервалом времени) свой статус и адрес. Если Орг.сектор не получает очередной контрольный ответ от мобильного агента, то запускает еще одну его копию.
[7] Если мобильный агент (М-агент), не может соединится с орг.сектором, то он активирует резервный Орг.сектор, и передает информацию о ботах в сети на него (в данном случае резервным Орг.сектором выступает любой бот из сектора).
[8] Если в игру вступает резервный Орг.сектор, то он принимает от М-агента его код (для запуска копии в случае пропадания М-агента со связи), а также всю информацию о ключах шифрования и адресах ботов.
После окончательного выполнения задачи, Орг.сектора формирует отклик, и передает файл по url из командного файла.
Вот в общем-то и весь механизм работы. Этот пример прост, и я думаю более наглядно демонстрирует идеи описанные выше.

[Заключение]

В заключение, еще несколько полезных советов. При написании кода - используйте полиморфизм. При создании каналов связи между ботами используйте различные протоколы (как транспортные, так и прикладные - в зависимости от задач), туннелирование в этих протоколах и т.п. Для хранения данных на NTFS, не забудте об альтернативных потоках в этой файловой системе, причем как в файлах, так и в каталогах. Последнее предпочтительнее, так как вы можете хранить все настройки своего бота к примеру в файле C:\WINDOWS:devil.txt. Эту папку наврядли кто-то додумается удалить :).
Как видите создание такой системы задача нетривиальная, это вам не взломать 10 серваков, поставить на них флуд ботов, работающих через HF или QIII, и кричать что ты "король мира", здесь все гораздо сложней, и требует высокого уровня знаний.
Зато если уж развернуть такую сеть и отладить, тогда можно говорить о том что ты реально крут. Естественно разработка подобного проекта вряд ли будет по силам одному человеку. Лучше вести подобные разработки командой единомышленников и специалистов в различных областях, как то:

- программирование (ASM,С/С++,Java,Perl etc.),
- криптография,
- TCP/IP сети, протоколы, маршрутизация и т.п.,
- Базы данных,
- Windows/Unix системы,
- Прикладные протоколы (HTTP,ICQ,IRC,FTP и т.п),
- Социальная инженерия (психология),
- ...

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

[Ссылки по теме:]
http://uinc.ru
http://www.honeynet.org/papers/bots/
[3] Б.Шнаэр "Прикладная криптография. Протоколы, алгоритмы и исходные тексты на языке Си"
http://www.cetus-links.org/oo_mobile_agents.html
http://cryptopunks.ru

[P.S]

Уже после написания статьи (она была закончена где-то в конце апреля 2005 года), на телевидении и в Интернете все чаще возникала тема ДДОС атак и сетей "зомби". Так что теперь - следите за рекламой :)