Противодействие Honeypots: Сетевые вопросы, Часть первая

Лорент Аудот и Торстен Хольц, перевод Владимир Куксенок

0. Аннотация

Для дезинформации атакующих и улучшения защиты больших компьютерных сетей, аналитики и инженеры безопасности устанавливают honeypots. Так как подобная деятельность становится очень распространенной в сообществе белых шляп (whitehat), черный шляпы (blackhats) изучают способы обнаружения и обмана этих средств защиты. Несмотря на то, что не все согласны с большим потенциалом honeypots, они эффективны и часто используются - поэтому черные шляпы уже работают над способами противодействия honeypots. Кибер-война продолжается.

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

1. Теория

В этой статье описываются удаленные действия атакующего, находящегося далеко от honeypot, а также локальные действия на скомпрометированном honeypot, c использованием средств сетевого уровня. Это выходит за рамки данной статьи, но если вы заинтересованы в серьезном изучении технических материалов о методах атаки на honeypots, вы определенно должны посетить следующую конференцию PacSec в Токио, организатором которой является Драгос Руи (Dragos Ruiu) [ссылка 0].

1.1 Удаленные действия

Прежде чем атакующий получит доступ к honeypot, он предпримет попытки обнаружения чего-нибудь подозрительного в работе интересующего его компьютера. Вряд ли он захотел бы атаковать компьютер, используемый в качестве ловушки, и не хотел бы, что за всеми его действиями следили, так как это может идентифицировать его, раскрыть используемые методы и утилиты. Например, использование 0-day эксплойта против honeypot, которые фиксирует все (сетевой трафик, низкоуровневую системную активность и многое другое), вероятно приведет к раскрытию тайных методов атакующего.

Большинство удаленных действий атакующего очень просты для понимания. Он просто пробует взаимодействовать с honeypot и смотрит на результаты. Эта игра может вестись на многих уровнях модели OSI, в зависимости от типа исследуемого honeypot. Обычно для honeypot основанных на TCP/IP, атакующий будет вести сетевой диалог и смотреть на результаты уровней 3 и 4, или даже 2, если он находится рядом или в одном сегменте сети со своей целью. Иногда, уровень 7 (прикладной уровень) также может использоваться удаленным атакующим.

1.2 Локальные действия

После того, как атакующий получит доступ к honeypot, например через шел, он все еще может использовать сетевой уровень для проверки не скомпрометировал ли он honeypot, вместо реального компьютера. Обычно это происходит путем взятия отпечатка (fingerprint) honeypot через сетевой уровень. К этому времени, защитники системы уже получат отчет о злонамеренной деятельности.

1.3 Скрытые проблемы

Цитируя Лэнса Спицнера (Lance Spitzner), основателя проекта Honeynet, "honeypot - ресурс информационной системы, предназначение которого заключается в неавторизованном или незаконном использовании этого ресурса". К примеру, если потенциальный агрессор способен определить, что атакуемый компьютер - honeypot, не обнаруживая себя, можно предположить что это было бы проблемой. Но в большинстве случаев honeypot ведет логи почти всего и атакующему очень трудно оставаться незамеченным. Под "противодействием honeypot" в этой статье подразумевается атака с целью обнаружения и/или отключение некоторых функций (например ведения логов) honeypot. Обратите внимание, некоторые белые шляпы используют honeypots в качестве сигнализации, и обнаружение и отключение функций таких honeypots не является большой проблемой, если администратор получил уведомление о начальных действиях хакера.

1.3 Крушение Матрицы

Даже если honeypot не реальный компьютерный ресурс в сети компании и он всего лишь ожидает атаки, есть способы определения его предназначения. Такие действия называются сбор отпечатков (fingerprint). Если вы хотите понять, как атакующий определяет honeypot по отпечаткам, задайте себе вопрос: какие различия есть между архитектурой honeypot и архитектурой реального компьютера?

Несмотря на то, что этот вопрос может казаться очень простым и поверхностным, это ключевой вопрос размышлений на тему сокрытия honeypots. Атакующий будет пытаться оценить, реальный или поддельный этот маленький мир, в который он попал? Помните фильм "Матрица"? Здесь тот же самый набор проблем определения реальности. В зависимости от уровня взаимодействия и типа honeypot, методы снятия отпечатков могут различаться.

Если администратор honeypot пытается моделировать или эмулировать среду, атакующий скорее всего будет пытаться узнать правду, анализируя определенные различия, существующие в скомпрометированной среде по сравнению с реальной средой. Представьте, что вы для поимки спаммеров установили поддельный прокси сервер. Взгляните на следующие вопросы:

• Вы уверены, что сможете ответить на любые возможные запросы, так же как реальный прокси сервер?
• Что если спаммер пошлет необычный или неправильный запрос?
• Что если спаммер попробует воспользоваться неосуществленными или сложными функциями, которые должны предоставляться вашим сервисом?
• Что если спаммер попробует воспользоваться прокси для проверки остается ли он функциональным под тяжелой нагрузкой и в течении длительного времени?

Как вы видите, моделировать реальность не так просто. В вышеупомянутом примере со спаммерами, атакующий вероятно будет действовать на 7 уровне OSI, посылая поддельные запросы. Используя возможности протоколов, атакующий вероятно найдет способ снятия отпечатков нашего поддельного мира.

Решение при котором обеспечивается наиболее реалистичное взаимодействие с honeypot это базирование honeypot на реальной системе. С точки зрения маскировки, совершенный honeypot должен быть "пожертвованной" реальной системой. Когда вы устанавливаете такой ресурс защиты, вы хотите вести логи всех возможных событий. Системы захвата трафика проходящего через канал вашего honeypot не всегда достаточно. Подумайте о атакующих, использующих зашифрованные каналы. Хорошо известно, что некоторые черные шляпы используют SSH для соединения с скомпрометированным компьютером. Поэтому администраторы начали изменять ядро операционной системы с целью записи всех низкоуровневых системных событий. Следующие статьи будут сфокусированы на подобных системных решениях.

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

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

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

Теперь давайте покажем несколько технических примеров.

2. Практические примеры

2.1 Tar Pits

Tarpit это компьютерный объект, преднамеренно медленно отвечающий на входящие запросы. Цель его состоит в том, чтобы ввести в заблуждение клиентов с целью мониторинга и замедления неавторизованного и незаконного использования поддельного сервиса. Обратите внимание, не все считают, что tarpit является honeypot, несмотря на то, что он является поддельным системным ресурсом, который может задержать внешних агрессоров. Например, для борьбы со спаммерами часто запускается tarpit, напоминающий открытый почтой релей, очень медленно отвечающий на SMTP команды. Это tarpit седьмого уровня OSI. Другие известные tarpits - открывающие сокет для приема входящих соединений, при этом запрещающие любой трафик, проходящий через него (уровень 4).

Labrea Tarpit [ссылка 1] - превосходный пример игры с TCP/IP стеком, для замедления распространения саморазмножающихся вирусов в Интернет, но кроме него есть также и другие средства, типа Honeyd [ссылка 2] и некоторые встроенные утилиты Linux. Например, netfilter/iptables [ссылка 3] поддерживает TARPIT адресат. Для реализации этого, iptables принимает все входящие TCP/IP соединения и затем сразу ставит размер окна в ноль. Это запрещает атакующему дальше отсылать любые данные. Любая попытка закрытия соединения будет игнорирована, потому что атакующий не может отослать какие-либо данные на хост. Поэтому соединение остается активным. Это расходует ресурсы на системе атакующего, но не на Linux сервере или брандмауэре, использующем tarpit. Пример правила iptables для режима TARPIT выглядит примерно так:

iptables -A INPUT -p tcp -m tcp -dport 80 -j TARPIT

Хотя tarpits и не позволяют избежать взятия отпечатка, они являются интересным техническим решением для нашего первого примера.

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

Для tarpit четвертого уровня, таких как Labrea, размер окна уменьшается до нуля, а tarpit продолжает принимать входящие пакеты. Эта простая сигнатура вероятно предупредит атакующего.

В следующем выводе tcpdump вы можете увидеть атакующего (10.0.0.2), пытающегося достигнуть поддельного веб сервера, моделируемого Labrea в постоянном режиме (10.0.0.1):

03:26:01.435072 10.0.0.2.1330 > 10.0.0.1.80: S [tcp sum ok]
911245487:911245487(0) win 64240 <mss 1460,nop,nop,sackOK> (DF) (ttl 64, id 6969, len 48)
03:26:01.435635 10.0.0.1.80 > 10.0.0.2.1330: S [tcp sum ok] 
3255338435:3255338435(0) ack 911245488 win 3 (ttl 255, id 48138, len 40)
03:26:01.435719 10.0.0.2.1330 > 10.0.0.1.80: . [tcp sum ok] 
1:1(0) ack 1 win 64320 (DF) (ttl 128, id 4970, len 40)
03:26:01.435887 10.0.0.2.1330 > 10.0.0.1.80: . [tcp sum ok] 
1:4(3) ack 1 win 64320 (DF) (ttl 128, id 4971, len 43)
03:26:01.436224 10.0.0.1.80 > 10.0.0.2.1330: . [tcp sum ok] 
1:1(0) ack 4 win 0 (ttl 255, id 44321, len 40)
03:26:03.731433 10.0.0.2.1330 > 10.0.0.1.80: . [tcp sum ok] 
4:5(1) ack 1 win 64320 (DF) (ttl 128, id 4973, len 41)
03:26:03.731673 10.0.0.1.80 > 10.0.0.2.1330: . [tcp sum ok] 
1:1(0) ack 4 win 0 (ttl 255, id 35598, len 40)

Взглянув на ответы от 10.0.0.1, вы сразу заметите размер окна 3 и затем 0 для следующего соединения (win 0). Так вы можете понять, как атакующий может легко получить отпечаток этой активности.

2.2 Несколько слов об уровне 2

Если атака была начата из того же сегмента LAN, где находится honeypot, могут появиться проблемы, заметные на втором уровне OSI. Это может быть важно, если вы хотите контролировать риск проникновения злоумышленником глубже и глубже в вашу сетевую инфраструктуру. Также это может быть важно для honeypot, который использует для обнаружения злонамеренных внутренних пользователей.

У Labrea есть возможность ответа на запросы, посланные с несуществующего компьютера. Анализируя безответные ARP запросы, Labrea может быть настроена на эмуляцию неиспользуемых IP адресов, что является очень интересным способом борьбы с саморазмножающимися вирусами в больших сетях с тысячами таких IP адресов. Если атакующий находится в том же сегменте сети, что и Labrea, есть способ снятия отпечатка на втором уровне OSI: этот демон всегда отвечает с одним и тем же MAC адресом 0:0:f:ff:ff:ff, который работает подобно черной дыре, и таким образом, есть очевидный способ обнаружить его. Анализируя подобные ARP ответы, атакующий мог бы увидеть следующее:

04:59:00.889458 arp reply 10.0.0.1 (0:0:f:ff:ff:ff) is-at 0:0:f:ff:ff:ff 

Если вы хотите исследовать этот пример, вы можете найти и изменить это значение в исходниках Labrea (PacketHandler.c):

u_char bogusMAC[6] = {0,0,15,255,255,255};

VMWare [ссылка 4] это известное коммерческое ПО для создания виртуальных машин, позволяющее вам одновременно запускать несколько ОС на одном компьютере. Эти операционные системы изолированы в безопасных виртуальных машинах и уровень виртуализации VMWare использует физические аппаратные ресурсы как ресурсы виртуальной машины, таким образом каждая виртуальная машина имеет свой собственный виртуальный процессор, память, диски, устройства ввода/вывода и т.д. В настоящее время эмулируются только аппаратные средства x86, и это широко используется honeypot администраторами, так как среди прочих возможностей, позволяет без труда развертывать honeypots. Иногда можно предположить, что система запущена на VMWare, проанализировав MAC адреса. Это не значит, что система - honeypot, но может задержать и вызвать сомнения у агрессора. Если вы посмотрите на стандарты IEEE [ссылка 5], вы найдете текущий диапазон MAC адресов назначенных VMWare, Inc:

00-05-69-xx-xx-xx
00-0C-29-xx-xx-xx
00-50-56-xx-xx-xx

Итак, если заметите любой из подобных MAC адресов в кэшированных MAC адресах (через arp -a), или в данных связанных с сетевым интерфейсом (Unix: ifconfig или Windows: ipconfig /all) агрессор тоже может найти что-нибудь интересное.

Некоторые атакующие пытаются воспользоваться удаленным сервисом NetBIOS для запуска специфичных для Windows атак. Мечта администраторов Honeypots - выявление 0-day эксплойтов, используемых против пропатченной систем, но использование интегрированного в Windows брандмауэра может остановить большинство атакующих. Именно поэтому они часто открывают связанные с Windows порты (порты NetBIOS, включающие в себя 135, 137-139 и 445 TCP/UDP порт), ожидающие злоумышленника. Но что если атакующий попробует подключиться к сервису NetBIOS? Он сможет получить MAC адрес и предположить, что система запущена под VMWare (Unix: nmblookup или Windows: nbtstat -A @IP). Некоторые утверждают, что в конфигурации VMWare можно изменить MAC адрес, но не все адреса могут быть приняты: адреса VMWare начинаются с 00:50:56 (например ethernet0.address = 00:50:56:XX:YY:ZZ).

Также есть и другие признаки, по которым атакующий может сделать отпечаток VMWare на основе MAC адреса. Например, когда сервер VMWare ESX автоматически генерирует MAC адреса, подобные 00:05:69:XX:YY:ZZ, это обычно означает, что IP адрес этого сервера подобен A.B.C.D, где XX это шестнадцатеричное значение C, а YY - шестнадцатеричное значение D. Это может быть признаком использования NAT перед VMWare компьютером (различные внешние адреса).

Honeyd [ссылка 2] это мощный honeypot демон с открытым исходным кодом, написанный Нильсом Провосом (Niels Provos). Раньше многие использовали Honeyd с другой утилитой - arpd. Она отвечает на ARP запросы и переадресовывает их к Honeyd. Некоторые думают, что это может создать проблему с маскировкой, так как будет много IP адресов с одинаковыми MAC адресами (но это также может произойти на втором уровне OSI моста). Если вы используете свежую версию, Honeyd теперь позволяет указывать MAC адрес для каждого виртуального компьютера, без каких-либо ограничений. Просто добавьте эту строчку в созданный шаблон, выбрав MAC адрес для вашей эмулируемой системы:

set template ethernet "<vendor|mac address>"

Это может быть лучше, чем использование arpd демона и дает большие возможности для маскировки на уровне 2. Максимилиан Дорнсэйф (Maximillian Dornseiff) также описал несколько причин использования honeyd без arpd [ссылка 6].

User-Mode Linux (UML) - свободное ПО, распространяющееся под лицензией GPL, еще одна утилита для создания виртуальных машин [ссылка 7]. Это виртуализированный Linux, позволяющий вам запускать полную Linux среду в памяти доступной пользователю, а также дающий возможность запускать несколько копий Linux одновременно на одном компьютере. Сфокусированное на Linux, это ПО напоминает коммерческое решение VMWare. Именно поэтому очень многие используют его для создание honeypots. На втором уровне OSI есть большой набор опций для изменения MAC адреса отдельных сеансов UML, которые включаются добавлением нескольких параметров запуска:

eth0=tuntap,,xx:xx:xx:xx:xx:xx,@IP (где xx:xx:xx:xx:xx:xx это MAC адрес
и @IP это IP адрес).

3. Заключение первой части

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

3.1 Обобщение

В этой статье обсуждаются проблемы использование tarpits и виртуальных машин прежде всего на втором уровне модели OSI. В следующий раз мы продолжим обсуждение с большим количеством практических примеров обнаружения honeypots, включающих honeypots основанных на Sebek, snort_online, Fake AP, Bait и Switch honeypots. Всего хорошего.

4. Ссылки

[ccылка 0, PacSec in Tokyo [http://pacsec.jp/], organized by Dragos Ruiu, and attend the talk "Countering Attack Deception Techniques" from Oudot Laurent.
[ccылка 1, Labrea Tarpit, by Tom Liston: http://labrea.sourceforge.net/ ]
[ccылка 2, Honeyd project, by Niels Provos: http://honeyd.org/ ]
[ccылка 3, netfilter/iptables: http://www.netfilter.org/ ]
[ccылка 4, VMWare: http://www.vmware.com/ ]
[ccылка 5, IEEE standards: http://standards.ieee.org/regauth/oui/oui.txt ]
[ccылка 6, Maximillian Dornseif's discussion on using honeyd without arpd. http://blogs.23.nu/antlab/stories/4485/ ]
[ccылка 7, Know Your Enemy: Learning with User-Mode Linux http://www.honeynet.org/papers/uml ]