Какие сведения собирают на приманку

Лучше всего работу сетей-приманок можно продемонстрировать на примере анализа данных, собранных о конкретной атаке.

В феврале 2002 года член Honeynet Project Майкл Кларк с помощью технологии GenI развернул виртуальную сеть, аналогичную представленной на рис. 1. В роли предполагаемых жертв выступали несколько ловушек, на которых был установлен Linux. 18 февраля с помощью стандартного эксплоита FTP хакер проник на одну из ловушек с операционной системой Linux, установленную в сети-приманке. В данном случае использовался wu-ftpd massrooter, хорошо известный и весьма эффективный инструментарий для автоматизированных атак. Сеть-приманка легко обнаружила атаку и собрала о ней сведения, в том числе первые команды хакера, инициированные на взломанной системе. Проанализировав все сетевые пакеты, собранные Snort, мы легко определили природу атаки и команды, выполненные на удаленной системе.

После запуска эксплоита, хакер инициировал команду для загрузки из удаленной системы исполняемого файла foo, установил его под именем /usr/bin/mingetty и запустил, после чего покинул систему. Это еще раз подтверждает, что простая запись всех команд хакера не позволяет получить всю необходимую информацию. Что представляет собой исполняемый файл foo, и чего хотел добиться хакер?

Вскоре после того, как этот файл был выполнен, механизм фильтрации сети-приманки для управления данным (в нашем случае IPTables) зарегистрировал, что с ловушки передаются входящие и исходящие пакеты, но наш анализатор Snort не получил и не зарегистрировал никакой деятельности. Мы совершили ошибку. После анализа трафика мы поняли, в чем она состояла. В этом случае кто-то посылал в ловушку нестандартные IP-пакеты — пакеты протокола Network Voice Protocol. Межсетевой экран регистрировал эту передачу, но анализатор — нет. Мы сами попали в ловушку, проектируя сеть-приманку так, чтобы она собирала сведения о том, что, по нашему предположению, должны были делать хакеры, но, на самом деле, далеко не все, что они могли действительно делать. К счастью, поскольку информация в сети-приманке собирается на нескольких уровнях, то, если один уровень не срабатывает, за трафиком проследят другие.

После того, как стало понятно, в чем состояла ошибка, мы исправили ее, переконфигурировав Snort так, чтобы он собирал данные и регистрировал весь IP-трафик. Теперь мы могли собирать все передаваемые пакеты всего трафика NVP, пересылаемого как на ловушку, так и с нее. Во-первых, в пакетах трудно было разобраться; как показано на рис. 4, они маскируются или шифруются. Кроме того, разнообразные источники, используемые для маскировки (такие как army.mil) посылают множество идентичных пакетов.

Рис. 4. Записанный пакет IP-протокола NVP, присланный на ловушку, куда проник хакер. Команда закодирована, чтобы скрыть ее истинное назначение

Чтобы лучше разобраться в том, что происходит, мы извлекли исполняемый файл foo из сети-приманки, провели обратный инжиниринг этого файла и проанализировали его. Оказалось, что бинарный файл foo, выполненный на ловушке, был средством проникновения, которое давало хакеру удаленное управление над системой. Этот исполняемый файл пассивно прослушивал пакеты протокола NVP, записывал их, декодировал и выполнял команду. К примеру, после декодирования пакета, показанного на рис. 4, стало ясно, какие команды были выполнены на удаленной ловушке (см. рис. 5). Этот исполняемый файл также поддерживал различные возможности организации DoS-атак, позволяя хакеру запускать координированные, распределенные DoS-атаки посредством отсылки замаскированных пакетов IP-протокола NVP.

Рис. 5. Декодированный пакет IP-протокола NVP. Это пример удаленной передачи команд на взломанную систему. В декодированном пакете можно видеть, какие команды действительно выполняются на удаленной системе. В данном случае хакер «приказывает» взломанной системе загрузить инструментарий с другого взломанного сайта, запустить этот инструментарий, а затем удалить загруженный исполняемый модуль. В этом случае инструментарий использован для перехвата сеансов IRC

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

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

Деятельность Honeynet Project подтвердила ценность технологий создания сетей-приманок, доказав, что она заключается, прежде всего, в информации, которую они собирают. Однако реальный потенциал сетей-приманок не может быть реализован до тех пор, пока организации не смогут эффективно развертывать многочисленные сети-приманки и согласовывать информацию, которую они собирают. В этом и состоит будущее Honeynet Project. Первым шагом к нему станет создание загружаемого компакт-диска, который значительно упростит развертывание таких сетей и стандартизует собираемую ими информацию. После этого организации смогут развертывать различные сети-приманки в распределенной среде. Как только такую информацию станет возможно регистрировать в центральной базе данных, будут разработаны пользовательские интерфейсы, позволяющие легко анализировать и согласовывать накопленные данные, учитывая их крайнюю важность для организаций. У технологий сетей-приманок большие перспективы.

Литература

L. Spitzner, Honeypots: Tracking Hackers, Addison-Wesley, 2002; www.tracking-hackers.com/book.

B. Schneier, Applied Cryptography, John Wiley & Sons, 1996.

Ланс Спитцнер (lance@honeynet.org) — ведущий архитектор систем безопасности корпорации Sun Microsystems и преподаватель SANS Institute. К его основным научным интересам относится изучение сетей-приманок.

Lance Spitzner, The Honeynet Project: Trapping the Hackers. IEEE Security & Privacy, January-February 2003. IEEE Computer Society, 2003, All rights reserved. Reprinted with permission.

Содержание раздела