Ферма Honeypot

По материалам SecurityFocus

За последние шесть месяцев была опубликована серия статей, рассматривающих множество вопросов касающихся honeypot. Были  рассмотрены различные вопросы, начиная с таких, как что такое honeypot, их значение, различные типы, и, заканчивая частыми заблуждениями и истинными утверждениями относительно honeypot. Тем не менее мы до сих пор не рассматривали вопрос развертывания honeypot. Как установить honeypot в вашем случае? Для небольших организаций это довольно просто - надо установить honeypot на один из компьютеров и включить его в вашу локальную сеть. Но что делать с организациями, состоящими из сотен сетей и тысяч компьютеров? Каким образом без особых проблем установить honeypot в распределенных системах такого масштаба? Одним из подходов является объединение всех honeypot в ферму honeypot.

Проблема

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

Одним из недостатков honeypot является их ограниченная область видимости - они видят только ту активность, которая связана непосредственно с honeypot. В отличие от IDS, honeypot не анализируют и не собирают весь сетевой трафик. Для работы honeypot злоумышленник должен сам его найти и начать использовать. Это значит, что для мониторинга активности в какой-то сети, honeypot должен быть установлен в этой сети. Существуют методы для перенаправления неавторизованной активности на honeypot, такие как honeytokens, hot zoning и bait-n-switch. Несмотря на это, чем больше вы установите honeypot, и чем больше IP вы отслеживаете, тем у вас больше шансов обнаружить и сохранить неавторизованную активность. Множество больших организаций имеют сотни, или даже тысячи сетей, распределенных по всему миру. Для того чтобы honeypot были эффективным в таких больших организациях, вам, скорее всего, придется устанавливать их в большом количестве. К сожалению, как и с большинством других технологий, чем больше honeypot вы хотите установить, тем больше ресурсов вам потребуется. Для настройки, развертывания и обслуживания требуются люди. Чем больше вы развернете honeypot, тем больше людей вам потребуется для их администрирования. Этот факт является проблемой для большинства технологий, таких как IDS сенсоры или файрвол шлюзы. В случае файрволов администраторы должны подсоединяться к системам по всему миру, обновлять сотни правил и просматривать огромное количество журналов файрволов. Администраторы IDS должны добавлять новые сигнатуры и просматривать тысячи предупреждений. Распределенные honeypot могут столкнуться с такими же проблемами.

Проблем становится еще больше при использовании высоко интерактивных honeypot, таких как Honeynets. Низко интерактивные honeypot, такие как KFSensor, Honeyd и Specter в большинстве случаев даже проще установить, чем IDS или файрвол. В случае использования таких простых решений, вы устанавливаете программное обеспечение, помещаете honeypot в сеть и ждете. Такие системы легко отслеживать, так как они предоставляют мало данных, но эти данные имеют очень большое значение. Их легко обслуживать, так как у них нет наборов правил, сигнатур или необходимости в изменениях каждый день или неделю. Все три упомянутых решения имеют средства удаленного администрирования и журналирования. Высоко интерактивные honeypot, являются гораздо более мощными и гибкими, но они боле сложны и требуют больше времени на обслуживание. Каждая система Honeynet представляет собой отдельную сеть изолированных систем. Кроме того, что каждый honeypot в Honeynet должен быть построен как настоящая система, и значит требует соответствующего обслуживания, архитектура Honeynet, особенно Honeynet gateway, является сложным механизмом, требующим дополнительной настройки.

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

Ферма - возможное решение

Существует возможное решение для облегчения развертывания большого количества honeypot. Это фермы honeypot. Концепция фермы проста. Вместо того, чтобы разворачивать много honeypot, или разворачивать honeypot в каждой сети, вы просто помещаете все honeypot в одно место. Эта единственная сеть honeypot становится вашей фермой honeypot - выделенным ресурсом безопасности. Злоумышленники перенаправляются на ферму, независимо от того, на какую сеть они нападают. Вспомните, honeypot не собирает сетевой трафик пассивно, поэтому он не должен быть физически подключен к сети. Honeypot достаточно виртуально находиться в вашей сети. Это осуществляется при помощи редиректоров. Редиректор выступает в роли в роли прокси. Он перенаправляет всю активность атакующего одному из honeypot, находящемуся на  ферме honeypot, и атакующий об этом никогда не узнает. Злоумышленник считает, что его жертва находится в локальной сети, в то время как на самом деле все передается на вашу ферму honeypot. Рисунок А ниже отражает концепцию перенаправления атакующего на ферму honeyopt.

Потенциальные преимущества такого подхода бесчисленны. Развертывание honeypot становится донельзя простым. Вместо того чтобы заставлять людей на другом полушарии устанавливать, настраивать и обслуживать honeypot для каждой сети (вспомните, что некоторые организации имеют тысячи сетей), вы централизованно устанавливаете и обслуживаете ферму honyepot. Эта ферма honeypot станет вашим SOC (Security Operation Center), где у вас есть ресурсы, уже выделенные на построение такой системы. Вы можете на месте обучить профессионалов, которые будут обслуживать ферму. Теперь honeypot не разбросаны по всему миру, а собраны в одном месте. Ферма может состоять из низко интерактивных honeypot, или включать в себя огромные Honeynet, состоящие из сотен реальных систем и приложений, ожидающих атаки. Централизация делает обслуживание, стандартизацию и анализ данных honeypot значительно проще. Для <виртуальной> установки вашего honeypot в других сетях, вы просто отсылаете редиректоры сетевым администраторам сетей, в которые вы хотите включить свои honeyopt. После того, как редиректоры будут физически размещены в сети, они будут перенаправлять злоумышленников и другую неавторизованную активность на вашу централизованную ферму honeypot, где персонал SOC будет отслеживать и анализировать полученную информацию в реальном времени. Для установки редиректоров, вы просто поставляете по одному редиректору каждому сетевому администратору отслеживаемых сетей. Эти редиректоры могут представлять собой не более чем черный ящик, который администратору надо включить в свою локальную сеть. Не требуется никакого конфигурирования, так как все уже настроено персоналом SOC. Этот черный ящик может отслеживать заданные заранее IP (или динамически отслеживать неиспользуемые IP). Как только злоумышленник попытается обратиться к этим IP или попытается неавторизованными путями обратиться к системам, черный ящик сразу перенаправит его на ферму honeypot. Такой подход упрощает развертывание распределенных honeypot решений до простой посылки редиректора сетевым администраторам при помощи FedEx.

Обновление и администрирование ваших honeypot (в особенности высоко интерактивных honeypot), также становится намного проще. Вместо того чтобы удаленно работать с каждой системой, администратор обновляет honeypot, собранные в одном месте. Вместо того чтобы обслуживать много Honeynet, распределенных по всему миру, достаточно иметь только одну физическую Honeynet, что сохраняет огромное количество времени, требуемого на обслуживание. Это время может быть потрачено на разработку более совершенных honeypot, отражающих реальную структуру ваших сетей. Например, вместо того, чтобы содержать honeypot, эмулирующий Solaris систему и SQL, вы можете в сэкономленное время поставить приманку с настоящим Solaris и Oracle. Затем вы можете заполнить базу данных ложной информацией и потом наблюдать, как атакующий будет работать с базой данных, и какие данные он пытается получить. Фермы honeypot могут экспоненциально повысить эффективность honeypot, особенно в случае высоко интерактивных решений, таких как Honeynets.

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

Реализация honeypot ферм

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

Приведем простой пример, использования возможностей Honeyd. Honeyd является honeypot с открытыми исходными текстами и имеет возможность отслеживать неиспользуемое в сети пространство IP. Любая попытка соединения к неиспользуемому IP рассматривается как атака и перехватывается Honeyd, который и общается с атакующим. Honeyd  может выступать в роли прокси для перехваченных соединений и перенаправлять их на другой адрес. Используя эту возможность, соединение злоумышленника может быть перенаправлено на honeypot ферму, в этом случае содержащую Honeynet. Таким образом мы объединили достоинства Honeyd (низко интерактивного honeypot) и Honeynet (высоко интерактивного honeypot). Honeyd отслеживает неиспользуемые IP, которых могут быть тысячи. Перенаправляя любую попытку соединения к неиспользуемому IP на Honeynet, мы значительно повышаем возможность обнаружения и захвата активности злоумышленника. Возникает такой эффект, как будто мы установили сотни Honeynet, но физически она лишь одна. При помощи Honeynet, мы можем получить гораздо больше информации, чем могли бы используя только Honeyd, так как Honeynet предоставляет атакующему реальные операционные системы и приложения. Конечно, все еще остается много нерешенных вопросов, например, не заметит ли атакующий перенаправления, или поведет ли себя honeypot так, как ожидает от атакуемой системы злоумышленник. Этот пример демонстрирует некоторые достоинства и трудности использования ферм honeypot.

Другим решением для honeypot фермы является NetBait. NetBait является коммерческим решением для реализации honeypot ферм (которые они называют ServerFarms). Вы можете помещать в эти фермы любые системы, какие захотите. Существуют редиректоры, переносящие активность атакующего на определенные системы из ServerFarm. Злоумышленник пробует атаковать какой-либо IP. После этого он продолжает взаимодействовать с этим же IP, но на самом деле взаимодействие происходит с одним из компьютеров физически размещенных на ServerFarm. NetBait идет даже дальше и в качестве услуги предлагает использовать их ферму honeypot. Они будут обслуживать honeypot ферму для организации. Все что нужно сделать организации это установить редиректоры в своих сетях, которые будут перенаправлять подозрительную активность на ферму NetBait. Вместо инструмента, honeypot фермы становятся предоставляемой услугой. Организациям больше нет нужды обслуживать или анализировать данные honeypot и волноваться за риски. Теперь они могут использовать все достоинства honeypot с минимальными затратами ресурсов и с минимальными рисками.

Заключение.

Фермы Honeypot являются абсолютно новой концепцией с огромным потенциалом. Они представляют собой один из новейших методов развертывания распределенных honeypot систем, особенно таких высоко интерактивных решений как Honeynets. Следует ожидать повышенной активности среди разработок в этом направлении.