Promiscuous mode что это
Promiscuous mode
Из Википедии — свободной энциклопедии
Promiscuous mode или promisc mode — так называемый «неразборчивый» режим, в котором сетевая плата позволяет принимать все пакеты независимо от того, кому они адресованы.
В нормальном состоянии на Ethernet-интерфейсе используется фильтрация пакетов канального уровня и если MAC-адрес назначения в заголовке принятого пакета не совпадает с MAC-адресом текущего сетевого интерфейса и не является широковещательным, то пакет отбрасывается. В «неразборчивом» режиме фильтрация на сетевом интерфейсе отключается и все пакеты, включая непредназначенные текущему узлу, пропускаются в систему.
Большинство операционных систем требуют прав администратора для включения «неразборчивого» режима. Данный режим позволяет мониторить трафик только в данном коллизионном домене (для Ethernet или беспроводных сетей) или кольце (для сетей Token ring или FDDI), потому использование сетевых концентраторов является менее безопасным решением, чем использование коммутаторов, так как последние в нормальном режиме работы не передают трафик всем вне зависимости от адреса назначения.
Однако, есть случай, при котором коммутаторы всё равно срабатывают в отношении не широковещательных фрэймов так же, как концентраторы. Например, при отсутствии MAC-адреса получателя в таблице коммутации. В таком случае, производится отправка на все порты коммутатора сразу, порт с которого придёт ответ на этот фрэйм (с соответствующим адресом отправителя) вносится в таблицу коммутации, после чего, коммутатор отправляет фрэймы уже в соответствии с записью в таблице — конкретно на порт с приписанным MAC-адресом для этого получателя.
«Неразборчивый» режим часто используется снифферами — специализированными программами, позволяющими отображать и анализировать сетевой трафик для диагностики сетевых неполадок. Такие программы позволяют легко перехватывать пароли и конфиденциальные данные, передаваемые по сети в незащищённом виде. Чтобы избежать этого, рекомендуется использовать защищенные протоколы, в том числе SSL и различные варианты VPN/IPSec.
Promiscuous mode в микроконтроллере ESP-8266
Думаю, многие согласятся, что ESP-8266 — замечательное изобретение для DIY и Internet of things. Эдакий WiFi-датчик, которые можно подсоединить к Arduino или даже использовать вместо Arduino для отправки, как правило, погодных данных на сервер. Существует множество разных прошивок позволяющих делать это: начиная со стокового модема используемого в связке с Arduino, NodeMCU для адептов LUA, и заканчивая многочисленными веб-серверами, полностью обслуживаемыми ESP (пример).
Как правило, после получения миниатюрного микроконтроллера из Китая вы вряд ли захотите написать собственную прошивку и будете использовать одну из имеющихся. На то есть 2 причины: чтобы вы там ни задумали, это уже было реализовано и вы вряд ли захотите иметь дело с китайским SDK щедро сдобренным костылями и недокументированными возможностями. И пусть вас не сбивает с толку привлекательный дизайн сайта: написание прошивки для ESP это боль и страдания. Если же вас это не пугает, то добро пожаловать. Статья ориентирована на ардуинщика с минимальным опытом работы с ESP: вы уже умеете собирать прошивки и записывать их в микроконтроллер.
Как можно понять из заголовка, мы будем работать напрямую со стеком 802.11, насколько это вообще возможно в случае ESP. Promiscuous mode на ESP — возможность слать и принимать «чужие» пакеты данных из эфира. Сфер применения не так много: статистический анализ (сбор всяких данных, таких как загруженность в зависимости от частоты) и проникновение и взлом сетей. В последнем случае типичным времяпрепровождением script kiddie будет деаутентификация (разрыв соединения) соседа от его WiFi маршрутизатора пока он играет в доту/танки. Обычно для этого светлая голова устанавливает Kali Linux и использует набор скиптов air*-ng, мы же будем использовать миниатюрный контроллер.
Во имя сатаны, конечно.
Для этого, помимо железа, нам понадобится API (я использовал ESP8266 Non-OS SDK API Reference, ссылка может очень скоро сломаться) и замечательный проект esp-open-sdk который сделает большую часть сборки проекта за вас. Полуготовый (по этическим соображениям) проект по результатам этой заметки можно найти на github.
Итак deauth. Кто не знает — оборвать ваше WiFi соединение можно с помощью пары десятков байт данных посланных в эфир поблизости. Шифрование не спасает по чисто концептуальным причинам: deauth предусмотрен для тех случаев, когда связь плохая и пакеты теряются. Соответственно, необходим действенный механизм крикнуть клиенту «я всё, мне надоело» и начать соединение с чистого листа. И тут уж не до шифрования. В нашем случае мы притворимся, что не выдержала точка доступа и от её имени пошлём письмо счастливому клиенту. Структура пакета следующая:
Жадный до знаний сам найдет что означают магические константы, я же коротко опишу переменные:
Шаг 1: переводим ESP в режим station
Следуя ненавязчивым комментариям от друзей-китайцев, это просто необходимо (без объяснений).
Кроме всего прочего, мы здесь выставляем скорость ввода-вывода из serial для возможности прочитать отладочные сообщения, используем встроенный таймер чтобы вызывать метод deauth каждые DEAUTH_INTERVAL миллисекунд и даем возможность ESP пошуршать перед переходом ко второму этапу инициализации.
Шаг 2: переводим ESP в режим promiscuous
Для этого определяем функцию sniffer_system_init_done которая была использована ранее.
Здесь выставляем полосу WiFi (канал приема / передачи данных, смотрите инструкцию к вашей стране), записываем колбэк для приема пакетов promisc_cb и запускаем режим promiscuous. Зачем нам этот callback?
Шаг 3: вынюхиваем пакеты
Один из параметров deauth пакета, seq_n, подразумевает, что мы принимали предыдущие пакеты и знаем порядковый номер следующего. Для это нам нужно слушать чужое соединение и записывать этот seq_n.
Каскад if-ов связан с черной магией разнообразием стандартов 802.11. Конечно, ESP поддерживает только самый необходимый набор и не работает, скажем, с частотой 5Ghz. Описания всех структур доступны в документации и примерах, нам же необходимо малое: поле с данными sniffer->buf в данном случае. Мы проверяем, что пакет пришел от точки доступа и направлялся к нашей жертве и, если так, записываем 2 байта seq_n. К слову, пакеты в обратную сторону имеют отдельную нумерацию.
Шаг 4: отправка
Дело за немногим — отправить пакет.
Первая функция записывает необходимые данные в буфер, вторая — отправляет его.
Шаг 5: проверяем
Для объективного анализа можно использовать Wireshark:
Пакет виден именно в том виде, в котором мы его отправили.
Так что, это правда работает? Нет. В текущих версиях SDK это сломали пофиксили. Broadcast пакеты отправлять можно, но не более того. Но старый SDK был любовно сохранен и доступен как часть примера на GitHub. Используйте с осторожностью.
Promiscuous mode
Зачем нужен Promiscuous Mode?
Чтобы лучше понять назначение promiscuous mode, приведу практический пример. Допустим, у нас есть четыре виртуальные машины:
Прошу не заострять внимание на роли данных виртуальных машин. На самом деле, на этих ВМ стоят чистые операционные системы, и больше ничего нет. Роли расписаны для примера и полноты картины.
и сеть, которая на данный момент выглядит следующим образом:
Как видно выше, все четыре ВМ находятся в одной группе портов и прекрасно себе работают. Но в один очень хороший день вы решаете на фактически простаивающей ВМ с чистой ОС FreeBSD установить IDS, так сказать, чтобы спалось спокойно.
Для нормальной работы IDS в среде VMware vSphere (да и не только) нужно, чтобы на определенной группе портов или на виртуальном свиче был активирован Promiscuous Mode.
Настройка
Первым делом нужно создать две группы портов на vSwitch0 с одним и тем же VLAN ID:
Как только перезапустится Management Network, наша сеть приобретет вот такой вид:
Следующим шагом активируем Promiscuous Mode для группы портов VLAN-10-EPM:
Не забывайте про то, что когда вы измените для ВМ группу портов, она сразу же станет недоступна для других (внешних) сетей, если до этого вы НЕ НАСТРОИЛИ физический свич + роутер на корректную обработку VLAN.
Для этого переходим в настройки ВМ, выбираем Network Adapter и, в Network Label, выбираем VLAN-10-DPM или VLAN-10-EPM:
После всех манипуляций наша сеть будет выглядеть следующим образом:
Теперь ВМ с FreeBSD, находясь в группе VLAN-10-EPM, сможет перехватывать и анализировать (если к этому моменту стоит IDS) весь трафик, который проходит внутри группы VLAN-10-DPM. При этом ВМ, входящие в группу VLAN-10-DPM, не смогут перехватывать трафик друг друга.
Тестирование
Чтобы убедиться, что все настроено правильно, нужно протестировать. Для этого на ВМ WinXP (IP: 192.168.33.87) пускаем пинг до виртуальной машины WinXP-2 (IP: 192.168.33.28). А на FreeBSD запускаем на выполнение программу tcpdump, которая переведет сетевой интерфейс в promiscuous mode и начнет выводить на экран захваченные пакеты:
Как видно выше, FreeBSD получает пакеты, которые ей не адресованы, то есть promiscuous mode работает. А это значит, что и IDS будет работать так, как положено, анализируя весь трафик, который «бегает» внутри группы VLAN-10-DPM.
В заключение ко всему выше написанному, хочу добавить, что такое решение (с применением VLAN) потребует донастройки или даже замены (если свич/роутер не поддерживает VLAN) физического свича/роутера, что может вызвать проблемы. Это нужно заранее учитывать перед началом настройки для того, чтобы избежать возможных простоев.
Если в настройках vSwitch активировать Promiscuous Mode, то он будет активирован для всех групп портов:
Будьте очень внимательны и активируйте promiscuous mode только для тех групп портов, где это действительно необходимо.
PacketTrain.NET
Анализ сетевого трафика
Руководство по захвату сетевого трафика. Часть 3 – Сетевые карты (Перевод)
Во время моих выступлений и после них на конференциях я получаю много вопросов от слушателей. И один из самых частых ответов, который приходит в голову – «когда как…» На первый взгляд, это может показаться разочаровывающим, но суровая правда в том, что, когда речь заходит о захвате и анализе сетевого трафика, нужно учитывать очень много факторов. И поэтому, когда мы обсуждаем, а подходит ли обычная сетевая карта (например, встроенная в ноутбук или материнскую плату настольного ПК) для захвата трафика, ответ на это (как вы уже, наверное, догадались) – «когда как…»
Захват сетевого трафика – это одна из тех дисциплин, в которых «легко освоить базу, тяжело достичь высот» (“easy to learn, hard to master”). Достаточно легко захватить трафик на ПК, используя встроенную сетевую карту, но получить результат, который вы хотели, может стать задачей потяжелее или вообще обернуться настоящим испытанием. Давайте посмотрим, на что нужно обратить внимание при захвате Ethernet-трафика (WiFi будем рассматривать позже):
Права пользователя в системе
Пользователи Wireshark под ОС Windows сейчас думают «о чем это вообще. » Но пользователи Linux легко могут попасть в не очень приятную ситуацию, когда они не состоянии захватить трафик до тех пор, пока не запустят Wireshark от рутовой учетной записи. Проблема в том, что захват трафика считается потенциально опасной с точки зрения security операцией – ведь он позволяет получить доступ к данным, к которым пользователь не должен этот доступ иметь. Существуют компании, которые имеют политики безопасности, запрещающие запускать софт захвата трафика на компьютерах пользователей.
Windows
Wireshark (скорее всего, как и любой другой софт анализа трафика) в ОС Windows решает эту проблему созданием и использованием специальной службы захвата, которая выполняется с правами, достаточными для доступа к имеющимся сетевым картам. Wireshark (а точнее, dumpcap) взаимодействует с драйвером (который называется “NPF”), делая возможным захват трафика, даже если сам Wireshark запущен из-под не-админской учетной записи. В противном случае (без NPF) так бы не вышло.
Если вы захотите проверить текущий статус службы NPF, вы её не найдете в списке служб Windows. Вместо этого нужно воспользоваться утилитой “sc.exe” с командой “query” из командной строки:
Утилиту sc ещё можно использовать для того, чтобы остановить или наоборот запустить службу NPF. Но для этого нужно, чтобы командная строка была запущена с администраторскими привилегиями.
Linux
А вот с Linux ситуация немного другая. Вместо службы сам пользователь должен иметь доступ к сетевой карте для задач по захвату. Как это реализовать – зависит от дистрибутива Linux, который вы используете. Вот несколько ссылок, которые могут быть очень полезны в этом вопросе:
И запомните: не надо запускать Wireshark (или любой другой софт захвата) от рута, если есть возможность этого избежать. Причина проста: пакеты, которые вы захватываете, могут использовать уязвимость или баги софта захвата, если они сформированы специальным образом с этой целью. Тем самым они смогут вызвать компрометирование всей системы. А так как любой софт захвата/анализа пакетов – это очень сложная махина (не верите – взгляните на исходный код Wireshark), то практически нет шансов, что там не будет багов.
Фильтр MAC-адреса получателя и неразборчивый режим
Каждая сетевая карта Ethernet имеет уникальный (ну да, в теории, но давайте в это не будем сейчас углубляться) физический адрес, который ещё называется МАС-адрес, “Media Access Control address”. Это 6-байтное поле, и мы сейчас опять же не будем рассматривать разные подробности типа OID. «Проблема» с захватом пакетов состоит в том, что сетевая карта Ethernet в нормальном режиме работы принимает только пакеты (правильнее сказать «кадры», на уровне L2), которые имеют MAC-адрес получателя именно этой карты, или кадры Broadcast/Multicast. Это значит, что сетевая карта, увидев кадр с чужим МАС-адресом получателя, отфильтрует его (кадр). В то же время сетевая карта настоящего получателя, увидев совпадение, кадр пропустит:
 |
| ПК с сетевой картой в нормальном режиме |
Это – проблема для нас, ведь мы всеми силами стремимся избежать захвата трафика локально (на самом получателе или отправителе). И нам было бы хорошо отключить фильтр МАС-адресов на сетевой карте, которой мы захватываем трафик. Отключение такого фильтра называют «неразборчивым режимом» (Promiscuous Mode). Работая в таком режиме, сетевая карта пропускает каждый кадр, который на неё приходит, пусть даже ей и не предназначенный:
 |
| ПК с сетевой картой в неразборчивом режиме |
Подытожим: в оптимальной схеме устройство захвата должно быть переведено в Promiscuous Mode, чтобы была возможность видеть и пропускать кадры, предназначенные другим получателям, а не только свои же, Broadcast’ы и Multicast’ы. Wireshark по умолчанию включает такой режим при захвате:
 |
| Включение неразборчивого режима в Wireshark |
Пассивность
Захваченный дамп всегда должен иметь определенную точность, а иначе он не будет иметь ценности для анализа производительности или безопасности. Давайте выделим два основных требования при захвате:
Пассивность – ключевая функция профессиональных карт захвата. Такие карты никогда не «шумят» в сеть и в дамп. «Обычные» сетевые карты в составе ПК или ноутбука созданы для операций приема/передачи данных, поэтому они имеют тенденцию постоянно что-то дополнительно передавать/принимать во время захвата, например, DHCP-запросы и т.д. (конечно, сама сетевая карта тут ни при чем, это фоновая активность ОС, но, тем не менее, она присутствует – прим. перев.) Для того, чтобы «успокоить» сетевую карту, можно отключить все протоколы в окне настройки.
Windows
В ОС Windows заходим в свойства сетевой карты и просто убираем все отметки возле названий протоколов:
 |
| Выключение протоколов в Windows |
Wireshark, как и любой другой софт захвата трафика, и после отключения протоколов сможет использовать данную карту, а вот передавать карта уже ничего не сможет.
Linux
Для Linux я обычно использую установки, которые прописаны в дистрибутиве SecurityOnion. Они переводят карту в Promiscuous Mode и отключают всякую паразитную активность. Для этого надо править конфиг /etc/network/interfaces. Примерный конфиг может выглядеть следующим образом:
Кратко суть происходящего: выставляем режим «IP-адрес вручную», но не задаем сам адрес; включаем Promiscuous Mode; при помощи утилиты ethtool в цикле выключаем все дополнительные встроенные функции сетевой карты.
Дополнительные вычислительные возможности сетевой карты
Сетевую карту вполне можно считать маленьким компьютером внутри большого. Этот «маленький компьютер» ограничен рамками приема/передачи, а также обработки сетевых пакетов.
Обработка и связанные с ней вычисления включают:
Не забывайте, что карта также является неким «сторожем»: она может принимать решения, какие пакеты передавать компьютеру для обработки, а какие отбросить. Причем в случае «отбросить» ваш ПК даже понятия не будет иметь, что эти пакеты вообще стучались в сетевую карту.
Раньше мы уже рассмотрели, что карта выкинет все пакеты/кадры, у которых был «не наш» destination MAC, если она не в Promiscuous Mode. Но также запомните, что обычная сетевая карта выкинет все кадры, у которых не сходится контрольная сумма, все кадры слишком большого размера (“oversize”), все слишком маленькие (“runt”). Или любые, поврежденные как-либо иначе. И вам тут Promiscuous Mode никак не поможет. Что это означает? То, что вы не сможете траблшутить проблемы на втором уровне модели OSI без профессиональной карты. Только такие карты смогут пропустить битые кадры дальше на обработку. Но, к счастью, траблшутингом на втором уровне модели OSI при помощи захвата трафика практически не занимаются – обычно это задача тестировщиков кабелей или администраторов сети, которые проверяют счетчики ошибок на портах коммутаторов/маршрутизаторов.
Тип пакетов и эффективность захвата
Продвигаемся дальше. Один из самых распространенных вопросов, который задают читатели: «а сколько примерно мегабит в секунду можно захватить моей обычной гигабитной сетевой картой?» А ответ (как вы, наверное, уже догадались) – «когда как!» Казалось бы, имея гигабитную сетевую карту, можно бы ожидать, что нормально захватится примерно до гигабита в секунду сетевого трафика. Правильно? Ну… иногда – да.
Проблема с обычными картами в том (мы уже это обсуждали), что они разрабатываются для обмена трафиком, а не для захвата. Обычная карта не ожидает, что её начнут заваливать кадрами, которые ходят между чужими узлами. И это – проблема, потому что в обычном режиме работы сетевой стек, использующий карту, когда видит, что у той начинаются неприятности с загрузкой, может управлять режимом, потоками. Сетевой стек может убавить скорость или подождать немного и наполнить отправляемые кадры больше. Но в случае захвата чужого трафика карта, на которую валится цунами из кадров, ничего не может с этим сделать. В сети есть несколько записанных сессий, посвященных вопросу максимальной скорости захвата обычных карт, например сессия Криса (Chris Greer) на Sharkfest под названием «At what point do laptops start dropping packets?»
Обычно стоит принять за правило, что гигабитная сетевая карта вряд ли потянет скорость больше 200-300 Мбит/с, но может повезти и больше. Для многих становится неожиданным тот факт, что в вопросе «а сколько я смогу захватить без дропов?» больше важно не количество мегабит в секунду, а количество пакетов в секунду. Даже захват почти полного гигабита в секунду возможен, если у вас трафик – большие, напакованные кадры (как правило, размером в 1518 Байт включая контрольную сумму Ethernet). Но такой фокус уже не пройдет, если вы попытаетесь захватить поток очень маленьких кадров (вплоть до 64 Байт размером). Если линк насыщен мелкими кадрами, скорее всего, карта не вытянет больше нескольких сотен мегабит в секунду. Это не то, для чего она разрабатывалась. Такая ситуация похожа, как если бы вы пытались съесть полную тарелку супа чайной ложкой – это сработает, но эффективность не впечатлит. Но если у вас нет нормальной большой ложки – маленькая тоже выполнит свою работу, не столь эффективно, конечно.
И что же делать? Есть два варианта на выбор:
Некоторые “подводные камни”
Есть несколько дополнительных моментов, которые очень легко недооценить или вообще упустить из внимания. В то же время, они запросто могут помешать сделать захват обычной сетевой картой.
VLAN-теги: есть карты, которые беспроблемно захватывают тегированные кадры, но некоторые могут повести себя не совсем предсказуемо, например:
Поэтому лучше проследите за поведением вашей карты в таких условиях заранее.
Размер кадров: обычная карта скорее всего проигнорирует кадр, больший, чем 1518 Байт (или 1522 Байта в случае, если есть VLAN-тег) и не доставит его дальше по стеку (стоит ли говорить, что в дамп такие кадры не попадут). Будет неприятно, если у вас в линке бегают подобные кадры, и они вам нужны для анализа (например, это могут также быть Jumbo Frames, или какое-нибудь шифрующее оборудование, добавляющее пару байтов к нешифрованному кадру). Проверьте, доступна и включена ли функция приема Jumbo frames в настройках сетевой карты.
Receive Offloading: как мы уже упоминали, многие современные карты берут на себя часть задач при отправке трафика, например, расчет контрольных сумм. Не так широко известно, что некоторые карты делают подобные вещи и при приеме – например, могут собирать несколько кадров в большие куски, и уже их передавать процессу захвата. В итоге в дампе вы увидите кадры огромного размера, которых по факту никогда и не было в самом линке. Бороться с этим можно – выключите эти функции в настройках (только не спешите бросаться и делать это на production-сервере, ведь нагрузка на ЦП может непредсказуемо вырасти – прим. перев.)
Нарушенный порядок кадров (Out-of-Order frames): если вы производите захват больше, чем одним портом сетевой карты одновременно (например, пытаетесь захватить полностью загруженный гигабитный линк двумя гигабитными портами карты) – можно получить нарушенный порядок кадров. Например, кадры поочередно приходят на порты 1-2-1-2, а в дампе у вас почему-то 2-1-1-2 или что-то похожее. В некоторых случаях это очень неприятное явление, оно может подбавить элементов случайности в результаты анализа 🙂 Характерный индикатор сбоя в порядке кадров – отрицательные Delta Times в дампе:
 |
| Нарушенный порядок пакетов |
У меня есть хорошая и плохая новости: возможно, удастся восстановить такой дамп при помощи утилиты командной строки reordercap. Но – бывает, что порядок кадров нарушен, а Delta Times при этом положительные. Тогда все грустно – дамп уже не восстановить.
Заключение
Захват при помощи обычной пользовательской сетевой карты – это нормально, если:
Ну, а если нет – вам нужна профессиональная карта. Признаюсь, все последние захваты трафика за последние пару лет, кроме случаев захвата на ПК конечного пользователя (то есть, каждый раз, когда мне нужно было идти в датацентр), я проводил только при помощи профессионального оборудования. Просто это совсем не смешно – звонить заказчику и говорить «ну.. мой дамп оказался не очень хорошим, и нам лучше бы сделать все заново…» Особенно, когда процедура захвата трафика потребовала много времени и усилий на согласование.
Статья переведена и опубликована с разрешения автора (Jasper Bongertz) только для сайта packettrain.net
Использование материала статьи без согласования запрещено!