Хакер - Спецвыпуск журнала «Хакер» #47, октябрь 2004 г.

Сетевой сенсор чаще всего реализуется на базе UNIX-подобной ОС, а для мониторинга информации используется утилита tcpdump или ее аналоги. В зависимости от конфигурации сети сенсор может как находиться на одном из узлов данного сегмента локальной сети, так и являться маршрутизатором, расположенным перед приманкой. Иногда сетевой сенсор совмещается непосредственно с самой приманкой. Это существенно упрощает и удешевляет систему honeypot'а, однако ослабляет ее иммунитет (захватив управление приманкой, атакующий быстро обнаружит сенсор и сделает ему харакири). Размещение сенсора внутри широковещательного сегмента обеспечивает ему наибольшую скрытость. Сетевой интерфейс сенсора может и не иметь собственного IP-адреса, прослушивая трафик в Stealth-режиме, что достигается путем физического обрезания передающего провода на сетевой карте (см. статью о сниферах в этом номере). Маршрутизатор в этом смысле намного более заметен, однако определить, работает ли на нем сетевой сенсор или нет, в общем случае невозможно.

Дампы tcpdump'а обрабатываются различными анализаторами (например, IDS), во-первых, распознающими сам факт атаки, а, во-вторых, определяющими IP-адрес нарушителя. Накапываемая информация оседает в коллекторе, сердцем которого является база данных. Это самое уязвимое место honeypot'а. Необходимо заранее выбрать четкие критерии, позволяющие однозначно определить, какие действия являются нормальными, а какие – нет. В противном случае администратор будет либо постоянно дергаться, вздрагивая от каждого сканирования портов, либо пропустит слегка видоизмененный вариант известной атаки. Есть и другая проблема. Если приманка не имеет никакого другого трафика, кроме хакерского (что легко определить по характеру изменения поля ID в заголовках IP-пакетов, подробнее о котором рассказывается в статье о брандмауэрах), то атакующий немедленно распознает ловушку и не станет ее атаковать. Если же приманка обслуживает пользователей внешней сети, непосредственный анализ дампа трафика становится невозможным и хакеру ничего не стоит затеряться на фоне легальных запросов. Достаточно эффективной приманкой являются базы данных с номерами кредитных карт или другой конфиденциальной информацией (естественно, подложной). Всякая попытка обращения к такому файлу, равно как и использование похищенной информации на практике, недвусмысленно свидетельствует о взломе. Существуют и другие способы поимки нарушителей, но все они так или иначе сводятся к жестким шаблонам, а значит, в принципе, не способны распознать хакеров с нетривиальным мышлением.

Короче говоря, опытный взломщик может обойти honeypot'ы. Попробуем разобраться как.

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

Явно уязвимые сервера лучше сразу отбросить – с высокой степенью вероятности среди них присутствуют honeypot'ы, дотрагиваться до которых небезопасно. Исключение составляют публичные сервера компаний, расположенные в DMZ-зоне – совмещать их honeypot'ом никому не придет в голову, правда, на них вполне может работать IDS.

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

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

Естественно, артобстрел необходимо вести через защищенный канал.