Здорово, дружище! Соскучился? 🙂 В любом случае, я надеюсь, что ещё не успел промозолить тебе глаза :)) Сегодня я заведу разговор о методах обнаружения снифферов в локальных сетях.
Во многих уже существующих и вновь возводимых сетевых коммуникациях EtherNet Media Type, начальство принимает "законы", запрещающие использование снифферов. Это солидно обламывает кульхацкеров, любителей подглядывать
чужой траффик, да и вообще всякого, кому сниффер необходим для проведения более серьёзных мероприятий. С другой стороны, озадаченные начальством необходимостью отлавливать кульхацкеров-сниффофилов сисадмины напрягаются изысканиями средств обнаружения этих самых снифферов. Самые ленивые скачивают что-то вроде antisniff.c, запускают его на своих роутерах и отчитываются перед начальством, а всем остальным, уверен, тоже будет интересно читать эту статью.
Я постараюсь ответить на два основных вопроса, 1) как обнаружить работающий в сегменте сниффер, 2) как обеспечить невидимость работающего в сегменте сниффера. Я не буду нагружать текст дампами пакетов, потому что разговор пойдёт довольно простой и понятный.
САМЫЙ ПРОСТОЙ
Самый простой и очевидный трюк по отлову снифферов из сегмента основывается на детской наивности, с которой кул хацкеры запускают чужой софт. Такие кул хацкеры (которым, как правило, недосуг прочесть документацию к снифферу) являются самой лёгкой добычей для админов.
Вся муля в том, что многие снифферы (среди которых находится, кстати, популярный tcpdump) по умолчанию резольвят неизвестные локальному DNS-кэшу DNS-имена IP-адресов отлавливаемых кадров данных. Ведь, по логике создателей снифферов, программа не должна прятаться по умолчанию, а найденные DNS-имена нужны для того, чтобы придать больше смысла парсингу прослушиваемого траффика.
Иными словами, если дефолтный сниффер поймает какое-нибудь сообщение с неизвестным ему IP-адресом (причём, совершенно не важно, Source это или Destination), он моментально вызовет gethostbyaddr() или нечто аналогичное и ядро отправит DNS-запрос дефолтному DNS-серверу на резольвинг интересующего IP-адреса.
Стало быть, админу нужно запустить сниффер на прослушивание либо DNS-сервера, либо самого кул хацкера, и отправлять в сетевую среду провокационные сообщения с заранее предусмотренными IP-адресами, которых в теории нет и не должно быть в DNS-кэше кул хацкера. Например, 1.2.3.4 :)))
Логика поведения сисадмина зависит от настроек BPF-фильтра, предпринятого кул хацкером. Если хацкер слушает всю сеть, то можно отправлять буквально любое сообщение, а если он настроен лишь на один адрес (протокол, порт, сигнатуру), то нужно отправлять сообщения, которые поместятся в рамки этого фильтра. Но, в общем случае, это не доставляет неудобств сисадмину.
Если кул хацкер хочет обезопасить себя от обнаружения и позорного отключения от сети по статье "хакерство" (как в сети, где я работаю сейчас), то ему нужно просто-напросто отключать DNS-резольвинг. В tcpdump'e, например, это делается с помощью ключа '-n' 🙂
САМЫЙ НЕОДНОЗНАЧНЫЙ
Эффективность следующего метода далеко не так однозначна, как предыдущего. То есть, нельзя утверждать, будто он будет работать со всеми системами, ядро которых обслуживает запущенный сниффер. Статистикой по этому методу я не обладаю, знаю лишь наверняка, что это работает на Windows 98 и со старыми ядрами Linux.
Рассмотрим сам метод. Если сетевой адаптер кул хацкера находится в promiscious mode, то сисадмин может определить работающий сниффер, отправляя на сниффящий хост провокационные сообщения следующего толка:
Source MAC Address сисадмина
Destination MAC Address выбирается отличным от MAC Address'a кул хацкера
Source IP Address сисадмина (или принимателя ответа, т.е. это может быть любой фэйковый адрес)
Destination IP Address кул хацкера
...
ICMP/ping
Ядро кул хацкера с интерфейсом, работающем в нормальном режиме, такой кадр данных попросту проигнорирует. Так вот, по идее, если интерфейс переведён в promiscious mode, он, как ни в чём не бывало, этот кадр данных пропустит и передаст ядро. А ядро, в свою очередь,
на полученный пинг должно ответить.
САМЫЙ КОНДОВЫЙ
Эффективность самого кондового метода весьма умозрительна. У меня она проявилась лишь в стомегабайтной сети, при чуть ли не пиковой её нагрузке (10.000 кадров данных в секунду). Мой tcpdump недополучал больше половины сетевого траффика и машинка (p2-300/192RAM) изрядно при этом тормозила.
Итак, необходим провокационный траффик, такой, чтобы никто, кроме предполагаемого кул хацкерского сниффера, его не получал. Грубо говоря, совершенно любой мусор с Destination MAC Adddress'ами, отличными ото всех имеющихся в сети.
В таком случае, имеющиеся машинки будут этот траффик игнорировать и, например, отвечать на пинги очень быстро (миллисекунда или даже меньше), а кульхацкерский хост будет либо отвечать на пинги с солидной задержкой (как у меня, порядка двух-трёх сотен миллисекунд), либо даже и вовсе не отвечать на некоторые из них. Лучше всего отправлять мелкие пакеты провокационного траффика.
В провокационный траффикогенератор можно встроить балансировщик нагрузки, чтобы измерять динамику ответов на нормальные пинги провоцируемого хоста.
СНИФФЕР-НЕВИДИМКА
По совету одного злобного хакера (мнению которого я весьма доверяю), если ты не хочешь, чтобы кто-нибудь смог обнаружить твой сниффер в принципе, просто сними поддержку TCP/IP с интерфейса, на котором ты поднимаешь сниффер. Либо запрети любую реакцию ядра на входящий TCP/IP'шный траффик. Либо сочно настрой файерволл.
