Как перевести сетевую карту в promiscuous mode

Обновлено: 07.07.2024

В компьютерных сетях , смешанный режим является режимом для проводного контроллера сетевого интерфейса (NIC) или беспроводного контроллера сетевого интерфейса (WNIC) , что приводит к тому , контроллеру передавать весь трафик он получает в центральном процессоре (CPU) , а не передавая только кадры что контроллер специально запрограммирован на прием. Этот режим обычно используется для сниффинга пакетов, который происходит на маршрутизаторе или на компьютере, подключенном к проводной сети или являющейся частью беспроводной локальной сети . Интерфейсы переводятся в беспорядочный режим с помощью программных мостов, часто используемых с аппаратной виртуализацией .

В сетях IEEE 802, таких как Ethernet или IEEE 802.11 , каждый кадр включает в себя MAC-адрес назначения . В режиме без неразборчивой связи, когда сетевая карта получает кадр, она отбрасывает его, если только этот кадр не адресован MAC-адресу этой сетевой карты или не является кадром с широковещательной или многоадресной адресацией . Однако в неразборчивом режиме сетевая карта пропускает все кадры, позволяя компьютеру считывать кадры, предназначенные для других машин или сетевых устройств.

Многие операционные системы требуют прав суперпользователя для включения неразборчивого режима. Не-маршрутизации узла в смешанном режиме обычно может только отслеживать трафик к и от других узлов в пределах одной и той же области широковещательной передачи (для Ethernet и IEEE 802.11) или кольца (для Token Ring ). Этому требованию удовлетворяют компьютеры, подключенные к одному концентратору Ethernet , поэтому сетевые коммутаторы используются для борьбы с злонамеренным использованием неразборчивого режима. Маршрутизатор может контролировать весь трафик , что это маршруты.

Беспорядочный режим часто используется для диагностики проблем с подключением к сети. Существуют программы, которые используют эту функцию, чтобы показать пользователю все данные, передаваемые по сети. Некоторые протоколы, такие как FTP и Telnet, передают данные и пароли в виде открытого текста, без шифрования, и сетевые сканеры могут видеть эти данные. Поэтому пользователям компьютеров рекомендуется держаться подальше от небезопасных протоколов, таких как telnet, и использовать более безопасные, такие как SSH .

Содержание

Обнаружение

Поскольку неразборчивый режим может использоваться злонамеренно для перехвата частных данных при передаче по сети, специалисты по компьютерной безопасности могут быть заинтересованы в обнаружении сетевых устройств, которые находятся в неразборчивом режиме. В неразборчивом режиме некоторые программы могут отправлять ответы на фреймы, даже если они адресованы другой машине. Однако опытные снифферы могут предотвратить это (например, используя тщательно разработанные настройки брандмауэра). Пример - отправка эхо-запроса (эхо-запрос ICMP) с неправильным MAC-адресом, но правильным IP-адресом. Если адаптер работает в нормальном режиме, он отбрасывает этот кадр, и стек IP никогда не видит его и не отвечает на него. Если адаптер находится в беспорядочном режиме, кадр будет передан, и IP-стек на машине (для которой MAC-адрес не имеет значения) ответит, как на любой другой эхо-запрос. Сниффер может предотвратить это, настроив брандмауэр для блокировки трафика ICMP.

Думаю, многие согласятся, что 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 предусмотрен для тех случаев, когда связь плохая и пакеты теряются. Соответственно, необходим действенный механизм крикнуть клиенту «я всё, мне надоело» и начать соединение с чистого листа. И тут уж не до шифрования. В нашем случае мы притворимся, что не выдержала точка доступа и от её имени пошлём письмо счастливому клиенту. Структура пакета следующая:

Жадный до знаний сам найдет что означают магические константы, я же коротко опишу переменные:

  • two_random_bytes будут перезаписаны микроконтроллером;
  • client_MAC_address 6 байтов физического адреса MAC устройства клиента;
  • ap_MAC_address 6 байтов физического адреса MAC устройства сервера (роутера, точки доступа);
  • seq_N_lo,hi младший и старший байты seq_n, порядкового номера пакета, умноженного на 16 (самые младшие 4 бита зарезервированы для возможности пересылки того же пакета еще раз)
Шаг 1: переводим ESP в режим station

Следуя ненавязчивым комментариям от друзей-китайцев, это просто необходимо (без объяснений).

К сожалению, user-defined логика может обрабатываться ESP только ограниченно число тактов за раз, поскольку WiFi пакеты из эфира ждать не будут, а памяти у микроконтроллера немного. Если вы переборщите с while(1) то встроенный watchdog перезагрузит микроконтроллер.
Шаг 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 в контексте виртуального свича (vSwitch), а, точнее, группы портов на этом свиче, то данный режим позволит перехватывать все пакеты, проходящие через данную группу портов, любой виртуальной машине, непосредственно присоединенной к ней.

Зачем нужен Promiscuous Mode?

Чтобы лучше понять назначение promiscuous mode, приведу практический пример. Допустим, у нас есть четыре виртуальные машины:

  1. FreeBSD - на этой ВМ стоит чистая FreeBSD 8.2
  2. WinXP - MySQL Primary
  3. WinXP-2 - MySQL Secondary
  4. Debian - Внешний веб-сервер

Прошу не заострять внимание на роли данных виртуальных машин. На самом деле, на этих ВМ стоят чистые операционные системы, и больше ничего нет. Роли расписаны для примера и полноты картины.

и сеть, которая на данный момент выглядит следующим образом:

Как видно выше, все четыре ВМ находятся в одной группе портов и прекрасно себе работают. Но в один очень хороший день вы решаете на фактически простаивающей ВМ с чистой ОС FreeBSD установить IDS, так сказать, чтобы спалось спокойно.

Для нормальной работы IDS в среде VMware vSphere (да и не только) нужно, чтобы на определенной группе портов или на виртуальном свиче был активирован Promiscuous Mode.

Казалось бы, что проще: нужно всего лишь активировать promiscuous mode для группы портов "VM Network" и установить на FreeBSD какую-нибудь IDS. Но у данного подхода есть очень большой минус - при этом все виртуальные машины, входящие в данную группу портов, смогут перехватывать пакеты, им не адресованные. А это очень большая брешь в безопасности. Тогда как же быть? Как повысить безопасность? Ответить на эти вопросы и решить проблему с безопасностью нам помогут VLAN'ы. Поэтому переконфигурируем нашу сеть, используя для достижения поставленной цели VLAN'ы.

Настройка

Первым делом нужно создать две группы портов на vSwitch0 с одним и тем же VLAN ID:

Чуть выше мы создали группу портов VLAN-10-DPM (DPM - Disable Promiscuous Mode) и VLAN-10-EPM (EPM - Enable Promiscuous Mode). Чтобы изменения вступили в силу, перезапускаем Management Network (перезапустить можно непосредственно через консоль сервера, либо в окне терминала, выполнив dcui):

Как только перезапустится Management Network, наша сеть приобретет вот такой вид:

Следующим шагом активируем Promiscuous Mode для группы портов VLAN-10-EPM:

Затем перенастраиваем ВМ FreeBSD на группу портов VLAN-10-EPM, а остальные три виртуальные машины - на группу VLAN-10-DPM.

Не забывайте про то, что когда вы измените для ВМ группу портов, она сразу же станет недоступна для других (внешних) сетей, если до этого вы НЕ НАСТРОИЛИ физический свич + роутер на корректную обработку 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 только для тех групп портов, где это действительно необходимо.

Не пинайте, я еще ламер. У меня Free4.5/

Надо перевести карточку в promiscuous режим.
Причем так, чтобы это желательно было сделано в процессе загрузки системы.
Сия необходимость опеределена странностью провайдера. Пока я не запускаю tcpdump -i rl1 то ping с моего шлюза на провайдера не идет. При запуске tcpdump на консоли пишется /kernel . promiscuous mode enabled.

Конечно, можно в rc.d написать скрипт с командой tcpdump) Но.
И еще. Где pptp найти для Free 4.5?
Помогите чем могите.

>Не пинайте, я еще ламер. У меня Free4.5/
>
>Надо перевести карточку в promiscuous режим.
>Причем так, чтобы это желательно было сделано в процессе загрузки системы.
если мне память не изменяет, то у ifconfig есть такой параметр

>Сия необходимость опеределена странностью провайдера. Пока я не запускаю tcpdump -i rl1
>то ping с моего шлюза на провайдера не идет. При запуске
>tcpdump на консоли пишется /kernel . promiscuous mode enabled.
но я бы сначала попинал провайдера, что бы он убрал у себя такие странности :)

>если мне память не изменяет, то у ifconfig есть такой параметр

немного думает, а потом говорит promisc: bad value. Ну думает, потому что тормоз 333 целерон.

>но я бы сначала попинал провайдера, что бы он убрал у себя
>такие странности :)

Да. Я согласен. Кроме того, он кроме IP раздает еще и MAC адреса!

>>если мне память не изменяет, то у ifconfig есть такой параметр
>
>немного думает, а потом говорит promisc: bad value. Ну думает, потому что
>тормоз 333 целерон.
>
>>но я бы сначала попинал провайдера, что бы он убрал у себя
>>такие странности :)
>
>Да. Я согласен. Кроме того, он кроме IP раздает еще и MAC
>адреса!

Раскажи как он раздает МАС адреса?


Смысл какой. У него внутренняя сеть 172.16.0.0 Подключена к инету. Его адрес 80.82.167.23.
Так вот он подключает своих клиентов по выделенке, раздавая им IP адреса своей внитренней сетки, а чтобы эти клиенты не могли сменой IP "подсидеть" другого - то и придумал раздачу MAC адресов. При этом проблему решают в винде настройкой сетевой карты в свойствах сети, а во Free я решил настройкой ifconfig. Но не тут-то было! Им надо еще, чтобы стоял promiscuous mode и вообще через свою сеть в интренет они организовали туннель pptp. Вот так )))
>>если мне память не изменяет, то у ifconfig есть такой параметр
>
>немного думает, а потом говорит promisc: bad value. Ну думает, потому что
>тормоз 333 целерон.
ну это не тормоз, если X-ы не запускать.
думает, видимо, потому что пытается с сетевухой договориться.
какая сетевуха?
некоторые сетевухи не понимают стандартный способ задания настроек, им можно задать настройки через параметры драйвера, но сам я так не делал, читал где-то.

>Да. Я согласен. Кроме того, он кроме IP раздает еще и MAC адреса!
а это уже вообще ни в какие ворота не лезет! стрелять таких провайдеров!

>думает, видимо, потому что пытается с сетевухой договориться.
>какая сетевуха?
Может быть.

пятница, 22 октября 2010 г.

Standard vSwitch - часть 2

Продолжаем знакомиться с вирутальной сетевой инфраструктурой VMware vSphere. В этом посте мы рассмотрим расширенный функционал, предлагаемый VMware для vSwitch.

  • Security
    • Promiscuous mode enable/disable
    • MAC Address Change enable/disable
    • Forged Transmit enable/disable


    VLAN A - любой VLAN от 1 до 4094, а VLAN B - любой другой VLAN от 1 до 4094, но не равный A. Конкретные числа не имеют значения, достаточно того, что VLAN'ы не совпадают.

    Итак, чтобы увидеть, кто с кем может общаться:


    Если vSwitch сконфигурирован с включенным режимом "Promiscuous Mode", то vNIC в PG_VGT сможет увидеть весь трафик vSwitch. В то же время, vNIC из PG_EST сможет увидеть только трафик внутри своей портгруппы (или любой другой портгруппы в EST режиме, VLAN = 0). В остальном таблица довольно проста для понимания, за исключением колонки PG_VGT. Строки PG_VLA, PG_VLB и PG_VLB1 содержат и "Yes" и "No" - vNIC в PG_VLA (например) сможет увидеть трафик только для VLAN A, который может включать в себя трафик для PG_VGT.

    MAC Address Change

    • В VDI окружении при большом количестве создаваемых и включаемых ВМ
    • В среде, где ВМ стартуют на хосте-стартовой площадке, а в дальнейшем перераспределяются по другим хостам с помощью DRS.

    Forged Transmit

    Параметр Forged Transmit схож по своему действию с MAC Address Change, с той лишь разницей, что он затрагивает исходящий, а не входящий трафик. При "Accept" vSwitch будет обрабатывать и пересылать пакеты с "подделанным" (forged) MAC адресом. "Reject" соотв. запрещает пересылку пакетов от MAC адреса, не совпадающего с прописанным в .vmx, и заставляет vSwitch игнорировать подобные пакеты. Точно так же, без уведомления гостевой ОС.

    Параметры Forged Transmit и MAC Address Change необходимо установить в "Accept" для поддержки Unicast NLB.

    Читайте также: