Вникаем: command and control (C2) (кейс из ИТ/ИБ-перевода)

Имеем фразу из буклета по межсетевому экрану нового поколения одного американского вендора: 

Threat Prevention goes beyond typical intrusion prevention system (IPS) technology to inspect all traffic for threats—regardless of port, protocol, or encryption—and automatically blocks known vulnerabilities, malware, exploits, spyware, and command and control (C2).

Выделенная фраза у переводчика сложностей вроде бы не вызвала: 

Решение Threat Prevention … блокирует … техники управления и контроля (С2).

Я посчитал, что вариант переводчика расплывчат, и решил добавить конкретики: 

Решение Threat Prevention … блокирует … попытки таких [вредоносных] программ установить связь со своими центрами командования и управления (С2).

Задумался, а не дал ли я маху, дописав это? В оригинале этого ведь не было. Вдруг наврал? В общем, надо вникнуть и решить — что вообще такое С2 и что стоит за этим термином для ИТ/ИБ-переводчика. Этим и займемся. 

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

Основной алгоритм

Итак, основной механизм выглядит примерно так: 

  1. Злоумышленники намечают мишени — круг интересующих их пользователей (например, пользователи определенной организации). 
  2. Мишеням загружается кусок вредоносного кода (дроппер) — либо через присылаемые фишинговые письма, либо заражая их через часто посещаемый ими сайт (разумеется, предварительно заразив и этот сайт тоже). 
  3. Далее, загруженный вредоносный код связывается с управляющей инфраструктурой ботнета (как раз это и есть C2  — command and control), чтобы догрузить нужные модули и окончательно передать зараженный компьютер под управление ботнета. 
  4. Всё. Компьютер выполняет задачи, которые ему время от времени поручают через ботнет. 

Зона ответственности вышеупомянутого межсетевого экрана —  пункты 2, 3, 4. В каждом из этих пунктов зашита масса хитрых механизмов, которые появлялись в результате противоборства как со стороны разработчиков ботнета, так и со стороны разработчиков антивирусов. Пробежимся по эпизодам этого противоборства. 

Технологии

1. 

В самом начале развития ботнеты были централизованы. Их строили по принципу каналов IRC: серверы ботнета напрямую отдавали команды зараженным компьютерам — ботам. Если какой-то компьютер излечивали, и он выпадал из ботнета, это в целом не сильно нарушало работу системы. 

 

Botnet multi-server topology | Download Scientific Diagram

Однако такая схема оказалась уязвимой к целенаправленным атакам защитников на серверы ботнета. Дело в том, что адреса серверов были жестко зашиты в тело самих вредоносных программ (далее — вирусы, хотя это и утрированное название). Следовательно, как только выяснялись адреса серверов, их заносили в черный список, черные списки распространялись, и это выбивало почву из под ног ботнета. 

 

 

2. 

Успех таких контратак заставил разработчиков ботнетов изменить их архитектуру — ботнеты двинулись в сторону децентрализации (decentralized, peer-to-peer) и структурированных оверлейных сетей (утрированно — сеть в сети)

Feature selection for detection of peer to-peer botnet traffic

 

Distributed Systems 21./24. Peer-to-Peer Systems - ppt download

 

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

 

3.

Защитники начали блокировать открытые порты.  Разработчики ботнетов ответили тем, что начали подделывать трафик своих ботов в трафик легитимных приложений — например, в виде комментариев к блог-постам . Подход оказался удачным — защитники не могли заблокировать легитимные программы. На какой-то момент начали даже набирать силу централизованные ботнеты.  

 

 

4.

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

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

 

 

5.

Далее защитники стали активно вычислять адреса серверов ботнета, чтобы блокировать попытки связи с ними. Ботоводы ответили им технологией DGA — domain generation algorithm. Эта технология позволяет быстро регистрировать на первый взгляд рандомные имена сайтов, причем срок жизни таких сайтов — от 2,5 часов. Алгоритм, по которому будут генерироваться будущие имена сайтов, знают только разработчики ботнета и загружаемые ими вирусы — в формуле учитываются и текущее время, и курсы валют, и новостные заголовки с определенного сайта. У защитников такой информации обычно нет, следовательно, они не имеют возможности занести такие сайты в черный список. 

DGA classification and detection for automated malware analysis – cyber.wtf

 

Разумеется, это лишь несколько эпизодов. Желающие могут погуглить также технологии полиморфизма (когда при каждой загрузке до неузнаваемости меняются дропперы) или технологии «спячки» (когда вирус, обнаружив, что находится под наблюдением антивируса, не проявляет никакой активности).  И все же, у читателя, полагаю, сложилось понимание того, что какие механизмы включает  в себя управляющая инфраструктура ботнета — C2, и что должны уметь системы безопасности, чтобы ее нейтрализовывать.  

На закуску приведу краткое описание одного довольно успешного ботнета, который в 2007 году был на пике своего могущества — до 50 миллионов зараженных машин . 

 

Storm

Этот ботнет — прекрасный образец использования децентрализованной архитектуры для управления и контроля. Метод распространения — спам со ссылками на зараженные сайты. 

 

Попадая на компьютер, дроппер первым делом проверял корректность работы компьютерных часов — именно по ним он в будущем вычислял, как нужно устанавливать связь с C2-узлами.

 

Ботнет работал в децентрализованной анонимной оверлейной сети, типа TOR —  там никто никого не знает по имени, и все общаются только с 128-битными идентификаторами, которые случайно генерируются на каждый сеанс связи, и маршрут выстраивается не по географии, а по идентификаторам — т.е. каждый раз маршрут от  точки А до точки Б был непредсказуем. 

 

Для обмена сообщениями с ботами Storm использовал систему «издатель/подписчик» (publisher/subscriber). Это значит, что управляющий узел (C2-узел) на какое-то время генерировал «афишу» с сообщением для ботов и присваивал ей идентификатор, а подписчики (т.е. боты) со своей стороны, по формуле, вычисляли этот идентификатор и находили по нему эту афишу. 

 

Немного про формулу. Как я уже писал выше, дроппер с самого начала и сверял часы зараженного компьютера. Он брал дату, генерировал случайное число от 0 до 31, объединял эти числа  — получались идентификаторы «афиш». Перебирая их они находили нужную, и считывали опубликованное сообщение. 

 

Сообщение было в формате *.mpg;size=*, где из * бот собирал 16-битное число, конвертировал его в IP-адрес и номер порта, по которому далее подключался напрямую и общался с управляющим компьютером. 

 

Учитывая, что это ботнет почти 15-летней давности, можете себе представить, что умеют ботнеты — и что должны уметь системы безопасности — сейчас. 

 

Заключение 

Вернемся к нашей дилемме. Напомню суть. 

Threat Prevention goes beyond typical intrusion prevention system (IPS) technology to inspect all traffic for threats—regardless of port, protocol, or encryption—and automatically blocks known vulnerabilities, malware, exploits, spyware, and command and control (C2).

Вариант переводчика: 

Решение Threat Prevention … блокирует … техники управления и контроля (С2).

Вариант редактора: 

Решение Threat Prevention … блокирует … попытки таких [вредоносных] программ установить связь со своими центрами командования и управления (С2).

 

Думаю, что мы оба ошиблись. 

Из варианта переводчика не совсем понятно, о каком управлении и контроле идет речь (или над чем?). 

 

А из моего варианта становится очевидно, что вариант с центрами уже безнадежно устарел — речь идет об узлах.  

 

Поэтому, я бы предложил исправленный вариант в таком виде: 

Решение Threat Prevention … блокирует … попытки таких [вредоносных] программ установить связь со узлами командования и управления (С2).

Или в таком (в зависимости от аудитории): 

Решение Threat Prevention … блокирует … попытки таких [вредоносных] программ установить связь со С2-узлами.

 

С уважением, 

Евгений Бартов, главред бюро. 

 

 

Особая благодарность Игорю Сидорову, к.т.н., доценту кафедры безопасности информационных технологий Южного Федерального Университета, за помощь в подготовке этой публикации.