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

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

0. Продолжение первой части

Развертывание honeypot, технологии использующейся для скрытного отслеживания хакеров, это очень сложная задача. Ценность honeypot в его способности оставаться необнаруженным. В первой части этой статьи мы описали некоторые проблемы, связанные со снятием отпечатков (fingerprinting) honeypots, а также привели несколько примеров, таких как tarpits и виртуальные машины. Теперь мы продолжим описание с большим количеством практических примеров обнаружения honeypots, таких как honeypots базирующихся на Sebek, snort_inlne, Fake AP, и Bait and Switch honeypots.

Если вы еще не читали первую часть этой серии статей, пожалуйста, ознакомьтесь с ней, перед тем как продолжить чтение.

1. Практические примеры (продолжение)

1.1 Honeypots базирующиеся на Sebek

Sebek [ссылка 0] это клиент/сервер приложение, и одна из основных утилит перехвата данных, используемая администраторами honeypot для перехвата всей активности атакующего, обнаруженного внутри honeypot. Это rootkit на основе ядра, перехватывающий системный вызов read() и поэтому имеющий возможность записывать всю информацию, к которой осуществляется доступ через read(). Sebek живет полностью в пространстве ядра и имеет доступ ко всем считываемым данным, что дает доступ к большинству незашифрованных каналов связи. Например, он может вести логи SSH сессий, восстанавливать файлы, скопированные с помощью SCP, и записывать все пароли, используемые злоумышленником. Сохраненные данные тайно отсылаются по протоколу UDP на сервер Sebek, являющийся частью архитектуры клиент/сервер Sebek. Возможность передачи данных осуществлена путем изменения кода ядра для сокрытия уходящих пакетов, так чтобы их не мог видеть злоумышленник. Кроме этого, все сетевые счетчики и структуры данных адаптированы для того, что сделать обнаружение этих изменений наиболее трудным. Более подробная информация о Sebek и его архитектуре может быть найдена на сайте Honeynet [ссылка 1].

Однако Sebek можно обнаружить, используя возможности сетевого уровня. Так как Sebek сохраняет все, к чему происходит обращение через read(), и затем отсылает эти данные по сети, некоторая нагрузка на канал будет заметна при чтении больших объемов данных. Если мы прочитаем один байт с помощью read(), Sebek должен будет передать почти 100 байт данных, включая все сетевые заголовки, по сети к хосту, на котором сохраняются логи. Таким образом, если мы сделаем вызов read() несколько десятков тысяч раз в секунду, это приведет к перегрузке сети и, в конце концов, к потере пакетов.

Мы может сделать много вызовов read() с помощью команды dd:

user@honey:~ dd if=/dev/zero of=/dev/null bs=1

А также мы можем идентифицировать перегруженную сеть с помощью команды ping, как показано ниже.

Сначала мы сделает ping локального IP адреса для получения краткой информации о текущей нагрузки сети. Затем запустим dd как фоновый процесс и снова выполним команду ping. Если Sebek установлен на хосте, это вызовет существенное увеличение времени прохождения пакетов туда и обратно. На практике, среднее время прохождения пакетов туда и обратно возрастало с 0.7 миллисекунд до более 4800 миллисекунд.

Есть также другие методы обнаружения и противодействия Sebek, с использованием других уровней OSI. Эти атаки и техники будут рассмотрены в другой статье.

1.2 Snort_inline

Snort_inline [ссылка 2] это встроенный механизм модификации пакетов, позволяющий перезапись опасного содержимого безвредными данными. Эта утилита основана на модифицированной версии популярного средства обнаружения вторжений (IDS) Snort [ссылка 3], с добавленными несколькими новыми типами правил (drop, sdrop и reject), которые взаимодействуют с iptables, указывая какие пакеты нужно блокировать, отклонять, изменять, а какие пропускать на основании правила Snort.

Пример такой техники это замена строки /bin/sh в шелкоде на /ben/sh. Другой пример - замена некоторых характерных образцов в сетевом трафике, чтобы сделать бесполезными соответствующие атаки, как это показано в следующем листинге, изменяющем x86-shellcode:

alert ip $HONEYNET any -> $EXTERNAL_NET any 
   (msg:"SHELLCODE x86 stealth NOOP"; sid:651; 
    content:"|EB 02 EB 02 EB 02|"; 
    replace:"|24 00 99 DE 6C 3E|";)

Эта разновидность системы предотвращения вторжений (IPS) используется в GenII (второе поколение) Honeynets [ссылка 4] для идентификации и блокирования известных атак. Snort_inline также нужен для препятствия возможности атакующего использовать honeypot для атаки на другие системы. Таким образом, Snort_inline также добавляет некоторую безопасность с юридической точки зрения.

Но блокирование или модификация исходящих пакетов дает атакующему очень простой способ обнаружения Snort_inline: если исходящие пакеты блокируются, это может показаться подозрительным для атакующего. Если исходящие пакеты модифицируются, это будет обнаружено подготовленным атакующим. Он пошлет пакеты со злонамеренным содержанием на другой хост, который он контролирует, и проверит, дойдут ли пакеты до цели в неизмененном виде (хотя некоторые небольшие изменение все же будут, например, уменьшится TTL). Если содержимое пакетов будет различаться, он, вероятно, что-нибудь заподозрит. Скрытность Snort_inline может быть повышена уменьшением количества правил, но это приведет к большему количеству необнаруженных атак. Нужно найти баланс между скрытностью и безопасностью.

Кроме того, GenII Linux Honeynets обычно используют возможности netfilter/iptables [ссылка 5] для создания ограничений на количество соединений. Это предотвращает использование скомпрометированного honeypot для организации DoS атак или массового сканирования, однако позволяет атакующему загружать такие утилиты или устанавливать автоматизированных ботов. В качестве примера можно привести конфигурацию по умолчанию скрипта rc.firewall, предоставляемого Honeynet Project, разрешающего 15 исходящих TCP-соединений и 50 исходящих ICMP пакетов в день.

[...]
### Set the connection outbound limits for different protocols.
SCALE="day"
TCPRATE="15"
UDPRATE="20"
ICMPRATE="50"
OTHERRATE="15"
[...]

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

1.3 Fake AP

Fake Access Point [ссылка 6] это Perl скрипт, генерирующий поддельные 802.11b фреймы со случайными ESSID и BSSID (MAC адрес). Затем эти фреймы отсылаются по случайному каналу, что дает возможность моделировать WEP протокол. Обычная точка доступа будет "скрыта среди большого количества Fake AP's" [ссылка 6], поэтому этот тип утилит также можно использовать в качестве беспроводного honeypot: разверните одну Linux машину, на которой запущен Fake AP, рядом с вашей беспроводной сетью и наблюдайте за подозрительным трафиком. Легальным пользователям будет известен SSID сети и они смогут подключиться без проблем. Злонамеренные пользователи будут пытаться соединиться с вашей сетью, используя различные SSID, и таким образом будут легко обнаружены.

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

1.4 Bait and Switch Honeypots

Традиционно информационная безопасность следует классическим парадигмам безопасности "Защита, Обнаружение, Реагирование". Другими словами, старайтесь защищать сеть настолько хорошо, насколько возможно (например, используя брандмауэр), обнаруживайте все ошибки защиты (с помощью средства обнаружения атак) и реагируйте на эти ошибки (к примеру, уведомляя администратора по e-mail). Проблема такого подхода состоит в том, что атакующий владеет инициативой и он всегда на шаг впереди. Bait and Switch Honeypot [ссылка 7] пытается превратить honeypot в активный компонент защиты системы. Это помогает быстрее реагировать на угрозы. Для достижения этой цели, Bait and Switch Honeypot, после определения попытки вторжения, переадресовывает весь злонамеренный сетевой трафик к honeypot. Этот honeypot является частично зеркалом рабочей системы и поэтому атакующий бессознательно атакует западню вместо реальной системы. Таким образом, легальные пользователи системы могут получить доступ ко всем данным и работать с реальной системой, а атакующий находится далеко от нее. Дополнительный плюс состоит в том, что действия атакующего могут быть записаны, а затем его утилиты, методы и тактика могут быть изучены. Bait and Switch Honeypot базируется на Snort [ссылка 3], iproute2 [ссылка 8], netfilter/iptables [ссылка 5] и некотором собственном коде.

Атакующий может обнаружить Bait and Switch Honeypot, анализируя определенные значения заголовка TCP/IP пакета, такие как время пути пакета туда и обратно (RTT), Время жизни пакета (TTL), временные метки TCP и другие. После события переключения, атакующий прекращает взаимодействовать с реальным компьютером, и начинает обмен данными с honeypot. Во время переключения с реальной системы на honeypot, может быть замечено внезапное изменение IPID. Предыдущие значения полей заголовка TCP/IP пакета также вероятно изменятся после переключения, что также может быть замечено подготовленным атакующим.

Повторюсь: tcpdump и другие подобные утилиты это ценные инструменты для атакующего, используемые для сбора информации о том, что происходит в системе. Кроме того, honeypot вероятно сильно отличается от реальной системы. Атакующий скорее всего будет пытаться найти способ идентифицировать honeypot, анализируя различия, которые могли бы быть, между реальной системой и honeypot. Имейте в виду, что некоторые атакующие будут использовать различные IP адреса в качестве источников атаки для противодействия различным типам IPS. Например, если атакующий использует щелкод, создающий соединение с IP адресом отличным от того, с которого шелкод был послан, IPS ничего не заметит. Принцип работы будет разным при каждом развертывании Bait and Switch Honeypot, поэтому администратор honeypot такого типа должен быть очень осторожным в процессе установки.

2. Обобщение

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

В этой серии статей мы показали, как ведут себя атакующие в попытке идентификации honeypot и привели несколько технических примеров использования различных методов. Мы надеемся, что эта информация будет полезной специалистам по безопасности, которые хотят установить и использовать honeypot. Важно чтобы администратор honeypot настроил и приспособил его под свои потребности. Например, MAC адрес (в случае с Labrea или User-mode Linux) или сообщения об ошибках должны быть указаны применительно к своей системе. Чтобы быть на шаг впереди атакующего, создатели honeypot ПО должны постоянно обновлять свои программы для избежания обнаружения - "гонка вооружений" между белыми и черными шляпами началась.

Обратите внимание, что есть даже коммерческие утилиты, такие как Honeypot Hunter [ссылка 9], использующие anti-honeypot технологию. Honeypot Hunter проверяет списки HTTPS и SOCKS4/SOCKS5 прокси на наличие honeypot и используется спаммерами для обнаружения tarpits и других типов honeypots/прокси. Honeypot Hunter создает локальный поддельный почтовый сервер на 25 порту (SMTP) и подключается сам с собой через прокси. Honeypot детектируется, если прокси сообщает что, подключение установлено, но утилита не смогла соединиться с эмулируемым почтовым сервером. Таким достаточно простым способом обнаруживается большинство honeypots и неработающих прокси. Но этот метод можно легко обойти, если разрешить хотя бы небольшое количество соединений с honeypot/прокси. Такая простота программы показывает, что кибер-сражение между обнаружением и скрытием honeypot такого типа еще не началась, но в будущем вероятная "гонка вооружений" предвидится.

3. Заключение

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

4. Ссылки

[ссылка 0, Sebek, by Edward Balas et al.: http://www.honeynet.org/tools/sebek/ ]
[ссылка 1, Know Your Enemy: Sebek: http://www.honeynet.org/papers/sebek.pdf ]
[ссылка 2, Snort_inline, by Rob McMillen, William Metcalf, Jed Haile and Victor Julien: http://snort-inline.sourceforge.net/ ]
[ссылка 3, Snort, by Martin Roersch: http://www.snort.org/ ]
[ссылка 4, GenII honeypots, by the Honeynet Project http://www.honeynet.org/papers/gen2/index.html ]
[ссылка 5, netfilter/iptables: http://www.netfilter.org/ ]
[ссылка 6, Fake AP tool, by Black Alchemy: http://www.blackalchemy.to/project/fakeap/ ]
[ссылка 7, The Bait and Switch Honeypot, by Jack Whitsitt: http://violating.us/projects/baitnswitch/ ]
[ссылка 8, iproute2, by Alexey Kuznetsov: ftp://ftp.inr.ac.ru/ip-routing/, http://www.linuxgrill.com/iproute2-toc.html ]
[ссылка 9, Honeypot Hunter: http://www.send-safe.com/honeypot-hunter.php ]