From: Ярослав Клюкин <bulldozer@skintwin.no-ip.com>
Newsgroups: void.ru
Date: Mon, 5 Oct 2003 14:31:37 +0000 (UTC)
Subject: Обнаружение пакетных снифферов
Оригинал: http://void.ru/content/1131
Прим. редактора : на проекте Void.Ru уже публиковалась статья http://void.ru/content/652
об определении снифферов - тогда появилась первая утилита для решения
подобных задач - AntiSniff от L0pht. Сейчас доступно большее
количество методов и инструментов. Об этом и пойдет речь в статье.
Метод пинга.
------------
Большинство пакетных снифферов работают на обычных компьютерах с
обычныс стеком TCP/IP. Это значит, что если ты отправишь запрос на эти
компьютеры, они ответят. Суть в том, чтобы отправить запрос к IP
адресу компьютера, а не на его Ethernet адаптер.
Иллюстрация:
Машина, подозреваемая в использовании пакетного сниффера имеет адрес
10.0.0.1, и Ethernet адрес 00-40-05-A4-79-32. Ты находишься на том же
Ethernet сегменте, что и подозреваемый компьютер (помни, что Ethernet
используется только для коммуникации внутри сегмента, а не удаленно в
интернет). Поменяй MAC адрес слегка, скажем на 00-40-05-A4-79-33.
Передай "ICMP Echo Request" (ping) с IP адресом и этим новым MAC
адресом. Помни, что никто не должен видеть этот пакет, так как в то
время как фрейм проходит по линии, каждый Ethernet адаптер сравнивает
MAC адрес со своим собственным MAC адресом. Если ни один не совпадает,
они все игнорируют этот фрейм. Если же ты видишь ответ, значит
подозреваемый не использовал "фильтр MAC адресов" на карте, и значит
прослушивает линию.
Существуют пути защиты от этого. Сейчас, когда эта техника широко
опубликована, новые хакеры используют виртуальный фильтр MAC адресов в
своем коде. У многих машин (в особенности Windows) обладают MAC
фильтрами в драйверах. (Существует модификация для Windows: многие
драйверы просто проверяют первый байт, так что MAC адрес
FF-00-00-00-00-00 выглядит как FF-FF-FF-FF-FF-FF (широковещательный
адрес, который примут все адаптеры). Однако, некоторые адаптеры
используют multicast таким образом, что этот адрес будет давать
совпадение, как адрес multicast, который является любым адресом, чей
первый байт - нечетное число. Все это может давать ложный
положительный результат.
Эта техника будет обычно работать c switch/bridge Ethernet. Когда
свичи видят неизвестный MAC адрес первый раз, они разбросают этот
фрейм по всем сегментам.
Метод пинга, часть 2.
Метод пинга может быть улучшен несколькими способами:
* Любой протокол, который генерирует ответ, может быть использован,
будь то запрос на установление соединения TCP или протокол UDP,
такой как порт 7 (echo).
* Любой протокол, который может генерировать ошибку на целевую
машину может быть использован. Например, неправильные значения в
заголовке IP могут быть использованы для генерации ошибки ICMP.
* Иногда адрес broadcast (будь то "местный broadcast" вроде
255.255.255.255 или же "направленный broadcast" вроде 10.0.0.255)
требуется для использования для того чтобы миновать программную
фильтрацию IP адресов. Это в свою очередь создает другую проблему
в том, что многие машины не отвечают на broadcast запросы (такие
ответы создают сетевые проблемы, такие как 'smurf').
Метод ARP
---------
Метод ARP похож на метод ping, только ARP пакеты используются вместо
ping. Объяснение (по Испански) дается по адресу:
http://www.apostols.org/projectz/neped/ на котором так-же есть
программа, названная neped для детектирования этим методом.
Наипростейший метод ARP передает ARP на не-broadcast адрес. Если
машина отвечает на такой ARP своим IP адресом, значит должно быть что
она в прослушивающем режиме.
Вариация этой техники использует факт, что машины кэшируют ARP
таблицы. Каждый ARP содержит полную информацию об отправителе и
получателе, а так же информацию о цели. Другими словами, когда я
отправляю простой ARP на broadcast адрес, я включаю в него свою
собственную информацию о принадлежности IP Ethernet. Все остальные,
находящиеся на линии, запоминают эту информацию на следуюшие несколько
минут. Таким образом ты можешь сделать что-то вроде отправки
не-broadcast ARP, затем broarcast ping. Любой, кто отвечает на твой
ping, без отправки тебе ARP, мог получить твой MAC адрес только из
прослушенного ARP фрейма. (Чтобы еще раз убедиться в этом, используйте
другой MAC адрес в ping'е)
Метод DNS
---------
Многие прослушивающие программы автоматически делают запросы обратного
DNS IP адресов, которые они видят. Таким образом прослушивающий режим
может быть обнаружен при помощи просмотра DNS траффика, который он
создает.
Этот способ может обнаружить машины с двойным подключением и может
работать удаленно. Тебе нужно просматривать входящие запросы к DNS
серверу твоей организации. Просто сделай ping всех машин в компании в
отношении машин, о которых известно, что они не существуют. Любой, кто
делает запросы обратного DNS тех адресов, пытаются найти адрес IP,
увиденный в ARP пакетах, что делают только программы прослушивания.
Та же самая техника работает местно. Сконфигурируй детектор в
прослушивающем режиме, потом отправь датаграммы IP на плохие адреса и
следи за запросами DNS.
Одна интересная проблема с этой техникой заключается в том, что
хакерские программы прослушивания имеют тенденцию резолвить IP адреса
как только они появляются, в то время как коммерческие программы
откладывают поиски в DNS на время просмотра пользователем
раскодирования протокола.
Метод исходящего маршрута.
--------------------------
Другая техника включает в себя конфигурацию информации о маршруте
источника внутри заголовка IP. Это может быть использовано для
детектирования снифферов в соседних сегментах.
Создай пакет ping, но включите отдельный маршрут в него, чтобы он был
отправлен через другую машину в том-же сегменте. У этой машины должна
быть отключена маршрутизация, таким образом что она фактически на
будет передавать пакет на целевой компьютер. Если ты получаешь ответ,
то скорее всего что целевой компьютер прослушал пакет из линии. В
ответ, проверь поле TTL для того чтобы определить причину, по которой
пакет вернулся. ( был ли он прослушен, или же просто был
промаршрутизирован )
Детальное пояснение:
--------------------
При использовании отдельного маршрута источника, добавляется опция к
IP заголовку. Маршрутизаторы проигнарируют IP адрес назначения и
вместо этого направят пакет на следуюший IP адрес, указанный в опции
маршрута источника. Это значит то, что когда ты отсылаешь пакет, ты
можешь сказать "пожалуйста отправь пакет Бобу, но перешлите его через
Анну сначала".
В этом сценарии оба "Анна" и "Боб" находятся в сегменте. Анна не
перенаправляет пакеты, таким образом отбросит пакет при получении.
Значит "Боб" ответит только если он прослушал пакет из линии.
В случае же если Анна на самом деле перенаправляет пакеты, (в таком
случае Боб ответит), тогда TTL поле может быть использовано чтобы
проверить что Боб ответил из-за передачи через Анну, или же ответил
напрямую.
Метод ловушки.
--------------
В то время как ping или ARP методы работаю только во внутренней сети,
метод ловушки работает везде.
Так как так много протоколов разрешают пароли "открытым текстом", и
хакеры используют фильтры для поиска этих паролей, метод ловушки
удовлетворяет эту необходимость. Он просто состоит из настройки
клиента и сервера на любой части сети, которая используется клиентом
для выполнения скрипта подключения используя telnet, pop, imap, или
любой другой незашифрованный протокол. Сервер настроен с аккаунтами,
которые не имеют реальных привелегий, или же сервер полностью
виртуальный ( в этом случае аккаунты просто не существуют ).
Как только хакер отфильтрует имена пользователей/пароли из линии, он
или она попытается подключиться, используя эту информацию. Обычные
системы обнаружения вторжений или отслеживания аудитом могут быть
настроены на то чтобы записывать в лог такие явления и давать сигнал о
том, что прослушивающий хаккер нашел траффик и попытался использовать
эту информацию.
http://www.zurich.ibm.com/~dac/Prog_RAID98/Full_Papers/sniffer_detector.html/index.htm
Метод хоста (определение сниффера на локальном компьютере)
----------------------------------------------------------
Когда хакеры взламывают твою системы, они часто оставляют программы
жучки, выполняемые на заднем плане для того чтобы прослушивать пароли
и аккаунты пользователей из линии. Проверка:
# ifconfig -a
lo0: flags=849<UP,LOOPBACK,RUNNING,MULTICAST> mtu 8232
inet 127.0.0.1 netmask ff000000
hme0: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,PROMISC,MULTICAST> mtu 1500
inet 192.0.2.99 netmask ffffff00 broadcast 192.0.2.255
ether 8:0:20:9c:a2:98
Флаг PROMISC говорит о том, что интерфейс находится в режиме
прослушивания.
Инструменты для определения наличия снифферов:
* AntiSniff http://www.l0pht.com/antisniff/
Самая общирная утилита определения снифферов.
* CPM (Проверка ружима прослушивания на машине ЮНИКС)
ftp://coast.cs.purdue.edu/pub/tools/unix/cpm/
ftp://ftp.cerias.purdue.edu/pub/tools/unix/sysutils/cpm/ifstatus
* neped http://www.apostols.org/projectz/neped/
Утилита для определения пакетных снифферов запущенных на локальном
сегменте.
* Другие ресурсы по определению снифферов:
http://www.securiteam.com/unixfocus/Detecting_sniffers_on_your_network.html
Перевел и отредактировал Ярослав Клюкин.
Автор: Ярослав Клюкин <bulldozer@skintwin.no-ip.com>
Источник: http://www.robertgraham.com/pubs/sniffing-faq.html#detect
Vova
