Полностью готовую к употреблению функцию, подготавливающую сырой сокет к работе с переводом интерфейса в неразборчивый режим и поддерживающую большое количество различных операционных систем, как то: SunOS, Linux, FreeBSD, IRIX и Solaris, можно легко выдрать из снифера, исходный текст которого находится по адресу: http://packetstormsecurity.org/sniffers/gdd13.c.
Перевод интерфейса в неразборчивый режим не проходит бесследно и легко обнаруживается утилитой ifconfig, отображающей его статус, правда, для этого администратор должен иметь возможность удаленного запуска программ на машине атакующего, чему атакующий может легко воспрепятствовать или модифицировать код ifconfig (и других аналогичных ей утилит) так, чтобы она выдавала подложные данные. Кстати говоря, засылая снифер на какой-либо компьютер, всегда нужно помнить, что его присутствие в подавляющем большинстве случаев обнаруживается именно по ifconfig!
Многие легальные сниферы автоматически резолвят все полученные IP-адреса, выдавая атакующего с головой. Администратор посылает пакет на несуществующий MAC-адрес от/на несуществующего IP. Узел, поинтересовавшийся доменным именем данного IP, и будет узлом атакующего. Естественно, если атакующий использует собственный снифер, вырубит DNS в настройках сетевого соединения или оградит себя локальным брандмауэром, администратор останется наедине со своей задницей.
Как вариант, администратор может послать на несуществующий MAC-адрес пакет, предназначенный для атакующего (с действительным IP-адресом и портом отвечающей службы, например, ICMP ECHO, более известной как ping). Работая в неразборчивом режиме, сетевая карта передаст такой пакет на IP-уровень, и тот будет благополучно обработан системой, автоматически генерирующей эхо-ответ. Чтобы не угодить в ловушку, атакующий должен отключить ICMP и закрыть все TCP-порты, что можно сделать с помощью того же брандмауэра, конечно, при условии, что тот не открывает никаких дополнительных портов (а большинство брандмауэров их открывают).
Между прочим, грабеж трафика требует ощутимых процессорных ресурсов, и машина начинает заметно тормозить. Ну, тормозит, и фиг с ней – какие проблемы? А вот какие. Администратор делает узлу атакующего ping и засекает среднее время отклика. Затем направляет шторм пакетов на несуществующие (или существующие) MAC-адреса, после чего повторяет ping. Изменение времени отклика полностью демаскирует факт перехвата, и, чтобы этому противостоять, атакующий должен либо запретить ICMP ECHO (что вызовет серьезные подозрения), либо стабилизировать время отклика, вставляя то или иное количество холостых задержек (для этого ему придется модифицировать код эхо-демона).
Разумеется, существуют и другие способы обнаружения пассивного перехвата трафика. Например, администратор пускает по сети подложный пароль, якобы принадлежащий root'у, а сам залегает в засаду и ждет, что за зверь в эту ловушку попадется, после чего направляет по соответствующему адресу бригаду каратистов быстрого реагирования.
Отправляя пакет на заданный IP-адрес, мы, очевидно, должны доставить его какому-то узлу. Но какому? Ведь сетевая карта оперирует исключительно физическими MAC-адресами, а про IP ничего не знает! Следовательно, нам необходима таблица соответствия MAC– и IP-адресов. Построением такой таблицы занимается операционная система, и делает это она при помощи протокола ARP (Address Resolution Protocol – протокол разрешения адресов). Если физический адрес получателя неизвестен, в сеть отправляется широковещательный запрос типа: «Обладатель данного IP, сообщите свой MAC». Получив ответ, узел заносит его в локальную ARP-таблицу, для надежности периодически обновляя ее (фактически ARP-таблица представляет собой обыкновенный кэш). В зависимости от типа операционной системы и ее конфигурации интервал обновления может варьироваться в диапазоне от 30 сек. до 20 мин.
Никакой авторизации для обновления ARP-таблицы не требуется, более того, большинство операционных систем благополучно переваривают ARP-ответы, даже если им не предшествовали соответствующие ARP-запросы (SunOS – одна из немногих, кто не позволяет обмануть себя подобным образом, и потому подложный ARP-пакет должен быть отправлен только после соответствующего ARP-запроса, но до прихода подлинного ответа).
Для захвата чужого IP атакующему достаточно послать подложный ARP-запрос, который может быть как целенаправленным, так и широковещательным (для отправки/приема ARP-пакетов необходим доступ к сырым сокетам или специальному API операционной системы, подробности можно расковывать в утилите arp). Допустим, атакующий хочет перехватить трафик между узлами «A» и «B». Он посылает узлу «A» подложный ARP-ответ, содержащий IP-адрес узла «B» и свой MAC-адрес, а узлу «B» – ARP-ответ с IP-адресом узла «A» и своим MAC-адресом. Оба узла обновляют свои ARP-таблицы и все отправляемые ими пакеты попадают на узел злоумышленника, который либо блокирует, либо доставляет их получателю (возможно, в слегка измененном виде, то есть работает как прокси). Если послать подложный ARP-пакет маршрутизатору, атакующий сможет перехватывать и пакеты, приходящие извне данного сегмента сети. Атака такого типа называется MiM (сокращение от «Man-In-the-Middle» – человек посередине).
Как вариант, можно послать подложный ARP-ответ с несуществующим MAC-адресом. Тогда связь между «A» и «B» будет утеряна, впрочем, через некоторое время она автоматически восстановится (ведь ARP-таблица динамически обновляется!), и, чтобы этого не произошло, атакующий должен направить на жертву мощный поток подложных пакетов.
Кстати, если маршрутизатор не успевает маршрутизировать поступающие пакеты, он автоматически переключается в широковещательный режим, становясь обычным хабом. Загрузив маршрутизатор работой по самые помидоры (или дождавшись пиковой загрузки сети), атакующий может преспокойно снифать трафик и в пассивном режиме.
Активная природа ARP-атаки демаскирует злоумышленника, и сетевые анализаторы типа arpwatch легко обнаруживают перехват. Они смотрят все пролетающие по сети пакеты (то есть работают как снифер), вытаскивают ARP-ответы и складывают их в базу данных, запоминая, какому MAC-адресу принадлежит какой IP-адрес. При обнаружении несоответствия администратору отправляется e-mail, к моменту получения которого нарушитель обычно успевает скрыться со всем награбленным трафиком. К тому, же в сетях с DHCP (сервером динамической раздачи IP-адресов) arpwatch выдает большое количество ложных срабатываний, так как одному и тому же MAC-адресу назначаются различные IP-адреса.
Некоторые операционные системы самостоятельно обнаруживают факт захвата своего IP-адреса посторонним узлом, но только в том случае, если злоумышленник использовал широковещательную рассылку (очень зря). К тому же, по малопонятным для меня мотивам ОС не отправляет ARP-ответ, отбирая похищенный IP-адрес назад, а просто отделывается многоэтажным предупреждением, смысл которого до рядового пользователя все равно не дойдет.
Статическая ARP-таблица, формируемая вручную, в этом плане выглядит намного более привлекательной, правда, даже после перехода на нее многие операционные системы продолжают принимать подложные ARP-ответы, безропотно отдавая себя в лапы злоумышленника, и убедить их не делать этого очень трудно, особенно если ты не гуру.