Promiscuous mode windows server — Ваш верный помощник с OS Windows

A Hyper-V related question that shows regularly up in the forums is how to setup virtual switch ports in promiscuous mode so that external traffic can be received / monitored on the host’s root partition or on virtual machines.

Hyper-V 2012 introduced the concept of port monitoring (also called port mirroring) which can be enabled on any virtual machine network adapter or on the host. The interesting part is that there’s quite some official documentation available if you want to setup port monitoring / mirroring between two or more VMs, but you are almost on your own if you want to capture traffic coming from an external network or from the host root partition. PowerShell APIs, which do a great job in setting up port monitoring between VMs, are quite convoluted and obscure when it comes to host monitoring settings.

This blog post has the purpose of explaining how to handle non trivial Hyper-V promiscuous mode requirements and introduces a simple PowerShell module to easily handle port monitoring settings on the host.

How does port monitoring / mirroring work?

The Hyper-V port monitoring functionality is already well explained elsewhere, so I’ll keep the basics to the minimum here. In short, unlike other virtualization solutions like VMWare ESXi where you set an entire virtual switch or group of ports in promiscuous mode, in Hyper-V you need to enable monitoring on each switch port individually, for either VM network adapters (vNICs) or host adapters (NICs).

Furthermore, Hyper-V does not let you simply set a “promiscuous mode” flag on a port, as you need to specify if a given port is supposed to be the source or the destination of the network packets, “mirroring” the traffic, hence the name.

The Hyper-V PowerShell module does a great job in making life easy from this perspective, for example:

Set—VMNetworkAdapter MyVM —PortMirroring Destination

where -PortMirroring can be Source, Destination or None. If you have multiple adapters on a VM you’d most probably want to choose which adapter to configure:

Get—VMNetworkAdapter MyVM | ? MacAddress —eq ‘xxxxxxxx’ | Set—VMNetworkAdapter MyVM —PortMirroring Destination

What about external traffic?

There are quite a few scenarios where you want to be able to receive on a VM all the traffic coming from an external network. Some of the most typical use cases include network intrusion detection systems (NIDS), monitoring tools (Wireshark, Message Analyzer, tcpdump, etc) or software defined networking (SDN) routers / switches, like for example Open vSwitch.

The PowerShell cmdlets (Add-VMSwitchExtensionPortFeature, Get-VMSystemSwitchExtensionPortFeature, etc) that can be used to manage port monitoring at the host level are not exactly user friendly and don’t cover all the relevant uses cases when it comes to internal ports. Beside the reference documentation, there are a few forum posts providing some info on how to use them, but not much more at the time of writing. Here’s an example for setting the port monitoring mode of a switch host NIC to source:

$portFeature=Get—VMSystemSwitchExtensionPortFeature —FeatureName «Ethernet Switch Port Security Settings»

# None = 0, Destination = 1, Source = 2

$portFeature.SettingData.MonitorMode = 2

Add—VMSwitchExtensionPortFeature —ExternalPort —SwitchName MySwitch —VMSwitchExtensionFeature $portFeature

With the above example, all traffic passing on the external network NIC of MySwitch will be “mirrored” to any VM whose port monitoring mode has been set to destination.

Internal switches and shared for management NICs

There are two scenarios which are not covered by the previous example: internal switches, used manly for root partition / guest communication and external switches shared for management (i.e. created with New-VMSwitch -ManagementOS $true in PowerShell).

In those cases the above example becomes:

$portFeature=Get—VMSystemSwitchExtensionPortFeature —FeatureName «Ethernet Switch Port Security Settings»

# None = 0, Destination = 1, Source = 2

$portFeature.SettingData.MonitorMode = 2

Add—VMSwitchExtensionPortFeature —ManagementOS —VMSwitchExtensionFeature $portFeature

By specifying -ManagementOS it becomes unfortunately not possible to specify the switch, so the monitoring mode will be set for every internal switch and shared management NIC port on the host!

An easier way to set host NIC monitoring mode in PowerShell

The complications and limitations of the PowerShell cmdlets outlined above led to writing a simplified set of PowerShell commands, where enabling port monitoring on external or internal switches gets as simple as:

Import—Module .\VMSwitchPortMonitorMode.psm1

Set—VMSwitchPortMonitorMode —SwitchName MySwitch —MonitorMode Source

The module is available here.

How to check the status of port monitoring on a given switch:

PS C:\Dev> Get—VMSwitchPortMonitorMode MySwitch

PortType MonitorMode

——— ————

External Source

Disabling monitoring is also very easy:

Set—VMSwitchPortMonitorMode —SwitchName MySwitch —MonitorMode None

In case of external switches shared for management, you can set different port monitoring settings for the external and internal NICs by simply adding the -PortType parameter specifying either Host or Internal.

Edit (Dec 5th, 2020): Starting with Windows Server 2019, consider setting the destination VM network adapter in trunk mode, as described below, even if you don’t use VLANs. Many thanks to Gian Maria for bringing this up!

How to monitor VLAN tagged traffic?

Traffic generated on a VM with a vNIC set to tag traffic with a VLAN id cannot be directly monitored on another VM, unless trunking is set on the target. For example, let’s say that we want to monitor the traffic between two VMs (VM1 and VM2) on a third VM (VM3), with packets tagged with VLAN id 100.

VM1 and VM2:

Set—VMNetworkAdapterVlan VM1 —Access —VlanId 100

Set—VMNetworkAdapter VM1 —PortMirroring Source

Set—VMNetworkAdapterVlan VM2 —Access —VlanId 100

Set—VMNetworkAdapter VM2 —PortMirroring Source

VM3 (monitoring):

Set—VMNetworkAdapterVlan VM3 —Trunk —AllowedVlanIdList «100,101» —NativeVlanId 0

Set—VMNetworkAdapter VM3 —PortMirroring Destination

Monitoring traffic on VM3 while pinging VM2 from VM1 will show something like the following tcpdump output, where the packets 802.1Q (VLAN) info is highlighted by the red ellipse:

Источник

Adding Filters to nmcap

You can filter the nmcap capture based on protocols, ports, IP addresses, and MAC or Ethernet addresses. The following table shows some common uses with these filters.

Filtering Traffic Commands	Comments
Capture traffic based on specific protocols. /capture protocol-list nmcap /network * \| adapter-name filter-protocol /file filename. cap:size C:\>nmcap /network * /capture icmp /file dccap.cap:10mb C:\>nmcap /network * /capture ldap /file dccap.cap:10mb C:\>nmcap /network * /capture !ldap /file dccap.cap:10mb C:\>nmcap /network * /capture (ldap and icmp and dns) /file dccap. cap:10mb	You can add protocols to filter in the nmcap/capture switch. after the The first example captures only ICMP traffic and ignores all other traffic. The second example captures only LDAP traffic. The third example captures all traffic except for LDAP traffic. Tip The ! character is used as a Boolean NOT character. In other words, if you want to capture LDAP traffic, use ldap as the filter. If you want to capture everything but LDAP, use !ldap (read as NOT ldap). The fourth example captures all LDAP, ICMP, and DNS traffic. You can use as many Boolean ANDs in the filter as desired. For example, it can be ldap and icmp and ftp, and so on.
Capture traffic based on a specific port. /capture tcp\|udp.port==port-number C:\>nmcap /network * /capture tcp.port==80 /file dccap.cap:10mb C:\>nmcap /network * /capture udp.port==53 /file dccap.cap:10mb C:\>nmcap /network * /capture (tcp.port==80 and udp.port==53) /file dccap.cap:10mb	You can specify traffic to capture based on the TCP or UDP port used. The first example captures traffic using TCP port 80, the second example captures traffic using UDP port 53, and the third example captures traffic from both TCP port 80 and UDP port 53. Note The == is two equal symbols put together.
Capture traffic based on IP addresses. /capture ipv4.address==IP-address C:\>nmcap /network * /capture ipv4.address==192.168.1.5 /file dccap.cap:10mb	You can add a filter for specific IP addresses. The example captures only traffic to or from the system with the IPv4 address of 192.168.1.15.
Capture traffic based on MAC addresses. /capture ipv4.address==IP-address C:\> nmcap /network * /capture ethernet.address==00-03-ff-62-13-d7 /file dccap.cap:10mb	You can also filter based on Ethernet addresses (also called MAC addresses or physical addresses). The example captures only traffic to and from the system with the specified MAC address.

Enabling Promiscuous Mode in nmcap

By default, Network Monitor and nmcap capture only traffic sent directly to or coming from the local IP address and broadcast traffic. However, you frequently want to be able to capture all traffic that reaches the NIC. To do so, you need to enable promiscuous mode, or P-Mode, with the /disablelocalonly switch.

Enabling Promiscuous Mode with nmcap	Comments
Enable Promiscuous Mode. /disablelocalonly C:\>nmcap /network * /capture /file dc3cap.cap:10mb /disablelocalonly	Disables local-only capture, which enables promiscuous mode, or P-Mode. All frames that reach the network cards are captured regardless of their source and destination IP addresses.

Windows, Windows Server 2008

Источник

Mar 12, 2016

What Is The Promiscuous Mode?

By default when a network card receives a packet, it checks whether the packet belongs to itself. If not, the interface card normally drops the packet. But in promiscuous mode, the card doesn’t drop the packet. Instead, it will accept all the packets which flows through the network card.

Some Network Interface Cards (NICs) may not allow network traffic after you create a Network Bridge. This is due to the inability of NIC to automatically enable Promiscuous Mode when creating a Network Bridge. Following are the steps to enable it manually.

Process

1. In the Start Menu search bar type cmd and press SHIFT + CTRL + ENTER to launch with Elevated Privileges.

2. Enter the following command to know the ID of your NIC

netsh bridge show adapter

In this example we see will assume the NIC id is 1.

3. When you know the NIC ID enter the following command to enable the Promiscuous Mode, remember to add the relevant NIC ID,

netsh bridge set adapter 1 forcecompatmode=enable

4. The above step will enable the Promiscuous Mode. Enter the command we used in Step 2, Now the Force Compatibility Mode (Promiscuous Mode) will display “enabled”.

Conclusion

Promiscuous Mode is automatically enabled when Bridging is activated, but some NIC models have some issues which can be solved by enabling it manually.

Источник

In this post I describe how to configure a Hyper-V virtual network switch into promiscuous mode. This mode allows you to monitor external traffic, eg. Needed for  Microsoft Defender for IoT.

Assuming you already created an dedicated virtual network switch, you have to run these four steps.

Turn off Allow management operation system to share this network adapter
Turn off Enable virtual machine queue
Set port mirroing mode to Destination
Configure the Ethernet Switch Port Security Settings

My setup:

Hyper-V Host – HOME-NUC01
Virtual Network Switch – Span4IoT
Virtual Machine – MD4IOT

Open Hyper-V Manager > Select Action > Virtual Switch Manager > (your NIC) > External Network
clear option Allow management operation system to share this network adapter

Virtual Switch Manager

Open Hyper-V Manager > (your VM) > Settings > (your NIC) > Hardware Acceleration
clear option Enable virtual machine queue

Virtual Machine Settings

Open Hyper-V Manager > (your VM) > Settings > (your NIC) > Advanced Features
Port mirroring > Mirroing mode > Destination

Virtual Machine Settings

Run the following PowerShell cmdlets on the hyper-v host (not in the virtual machine)

#get VMSwitch Settings
Get-VMSwitch | ft Name, SwitchType, NetAdapterInterfaceDescription, AllowManagementOs
#
# configure the corresponding switch for monitorting
$VMSwitch = "Span4IoT"
$portFeature=Get-VMSystemSwitchExtensionPortFeature -FeatureName "Ethernet Switch Port Security Settings"
$portFeature.SettingData.MonitorMode = 2
Add-VMSwitchExtensionPortFeature -ExternalPort -SwitchName $VMSwitch -VMSwitchExtensionFeature $portFeature

Источник

Во время моих выступлений и после них на конференциях я получаю много вопросов от слушателей. И один из самых частых ответов, который приходит в голову – «когда как…» На первый взгляд, это может показаться разочаровывающим, но суровая правда в том, что, когда речь заходит о захвате и анализе сетевого трафика, нужно учитывать очень много факторов. И поэтому, когда мы обсуждаем, а подходит ли обычная сетевая карта (например, встроенная в ноутбук или материнскую плату настольного ПК) для захвата трафика, ответ на это (как вы уже, наверное, догадались) – «когда как…»

Захват сетевого трафика – это одна из тех дисциплин, в которых «легко освоить базу, тяжело достичь высот» (“easy to learn, hard to master”). Достаточно легко захватить трафик на ПК, используя встроенную сетевую карту, но получить результат, который вы хотели, может стать задачей потяжелее или вообще обернуться настоящим испытанием. Давайте посмотрим, на что нужно обратить внимание при захвате Ethernet-трафика (WiFi будем рассматривать позже):

Права пользователя в системе
Фильтр MAC-адреса получателя и неразборчивый режим (“Promiscuous Mode”)
Пассивность
Возможности и функции сетевой карты
Тип трафика и эффективность захвата

Права пользователя в системе

Пользователи Wireshark под ОС Windows сейчас думают «о чем это вообще?..» Но пользователи Linux легко могут попасть в не очень приятную ситуацию, когда они не состоянии захватить трафик до тех пор, пока не запустят Wireshark от рутовой учетной записи. Проблема в том, что захват трафика считается потенциально опасной с точки зрения security операцией – ведь он позволяет получить доступ к данным, к которым пользователь не должен этот доступ иметь. Существуют компании, которые имеют политики безопасности, запрещающие запускать софт захвата трафика на компьютерах пользователей.

Windows

Wireshark (скорее всего, как и любой другой софт анализа трафика) в ОС Windows решает эту проблему созданием и использованием специальной службы захвата, которая выполняется с правами, достаточными для доступа к имеющимся сетевым картам. Wireshark (а точнее, dumpcap) взаимодействует с драйвером (который называется “NPF”), делая возможным захват трафика, даже если сам Wireshark запущен из-под не-админской учетной записи. В противном случае (без NPF) так бы не вышло.

Если вы захотите проверить текущий статус службы NPF, вы её не найдете в списке служб Windows. Вместо этого нужно воспользоваться утилитой “sc.exe” с командой “query” из командной строки:

[C:\]sc query npf

SERVICE_NAME: npf
 TYPE               : 1  KERNEL_DRIVER
 STATE              : 4  RUNNING
                         (STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
 WIN32_EXIT_CODE    : 0  (0x0)
 SERVICE_EXIT_CODE  : 0  (0x0)
 CHECKPOINT         : 0x0
 WAIT_HINT          : 0x0

Утилиту sc ещё можно использовать для того, чтобы остановить или наоборот запустить службу NPF. Но для этого нужно, чтобы командная строка была запущена с администраторскими привилегиями.

Linux

А вот с Linux ситуация немного другая. Вместо службы сам пользователь должен иметь доступ к сетевой карте для задач по захвату. Как это реализовать – зависит от дистрибутива Linux, который вы используете. Вот несколько ссылок, которые могут быть очень полезны в этом вопросе:

https://wiki.wireshark.org/CaptureSetup/CapturePrivileges

https://blog.wireshark.org/2010/02/running-wireshark-as-you/

https://ask.wireshark.org/questions/7976/wireshark-setup-linux-for-nonroot-user

http://askubuntu.com/questions/74059/how-do-i-run-wireshark-with-root-privileges

И запомните: не надо запускать Wireshark (или любой другой софт захвата) от рута, если есть возможность этого избежать. Причина проста: пакеты, которые вы захватываете, могут использовать уязвимость или баги софта захвата, если они сформированы специальным образом с этой целью. Тем самым они смогут вызвать компрометирование всей системы. А так как любой софт захвата/анализа пакетов – это очень сложная махина (не верите – взгляните на исходный код Wireshark), то практически нет шансов, что там не будет багов.

Фильтр MAC-адреса получателя и неразборчивый режим

Каждая сетевая карта Ethernet имеет уникальный (ну да, в теории, но давайте в это не будем сейчас углубляться) физический адрес, который ещё называется МАС-адрес, “Media Access Control address”. Это 6-байтное поле, и мы сейчас опять же не будем рассматривать разные подробности типа OID. «Проблема» с захватом пакетов состоит в том, что сетевая карта Ethernet в нормальном режиме работы принимает только пакеты (правильнее сказать «кадры», на уровне L2), которые имеют MAC-адрес получателя именно этой карты, или кадры Broadcast/Multicast. Это значит, что сетевая карта, увидев кадр с чужим МАС-адресом получателя, отфильтрует его (кадр). В то же время сетевая карта настоящего получателя, увидев совпадение, кадр пропустит:

ПК с сетевой картой в нормальном режиме

Это – проблема для нас, ведь мы всеми силами стремимся избежать захвата трафика локально (на самом получателе или отправителе). И нам было бы хорошо отключить фильтр МАС-адресов на сетевой карте, которой мы захватываем трафик. Отключение такого фильтра называют «неразборчивым режимом» (Promiscuous Mode). Работая в таком режиме, сетевая карта пропускает каждый кадр, который на неё приходит, пусть даже ей и не предназначенный:

ПК с сетевой картой в неразборчивом режиме

Подытожим: в оптимальной схеме устройство захвата должно быть переведено в Promiscuous Mode, чтобы была возможность видеть и пропускать кадры, предназначенные другим получателям, а не только свои же, Broadcast’ы и Multicast’ы. Wireshark по умолчанию включает такой режим при захвате:

Включение неразборчивого режима в Wireshark

Пассивность

Захваченный дамп всегда должен иметь определенную точность, а иначе он не будет иметь ценности для анализа производительности или безопасности. Давайте выделим два основных требования при захвате:

Захват лучше всегда производить устройством, которое не участвует в обмене данными (т.е., выделенным, обособленным устройством). Исключением может быть только случай, когда нет такой возможности, и при этом вы должны осознавать все побочные эффекты. Запомните, захват на любом устройстве, которое принимает активное участие в обмене данными (т.е., на брандмауэре, роутере, балансировщике нагрузки, WAN-акселераторе, прокси и т.д.) будет считаться «локальным», а потому очень нежелательным.
Обособленное устройство захвата должно быть жестко настроено в режим listen only – только прием кадров. Оно никогда не должно отправлять в сеть свои собственные пакеты, искажая тем самым картину.

Пассивность – ключевая функция профессиональных карт захвата. Такие карты никогда не «шумят» в сеть и в дамп. «Обычные» сетевые карты в составе ПК или ноутбука созданы для операций приема/передачи данных, поэтому они имеют тенденцию постоянно что-то дополнительно передавать/принимать во время захвата, например, DHCP-запросы и т.д. (конечно, сама сетевая карта тут ни при чем, это фоновая активность ОС, но, тем не менее, она присутствует – прим. перев.) Для того, чтобы «успокоить» сетевую карту, можно отключить все протоколы в окне настройки.

Windows

В ОС Windows заходим в свойства сетевой карты и просто убираем все отметки возле названий протоколов:

Выключение протоколов в Windows

Wireshark, как и любой другой софт захвата трафика, и после отключения протоколов сможет использовать данную карту, а вот передавать карта уже ничего не сможет.

Linux

Для Linux я обычно использую установки, которые прописаны в дистрибутиве SecurityOnion. Они переводят карту в Promiscuous Mode и отключают всякую паразитную активность. Для этого надо править конфиг /etc/network/interfaces. Примерный конфиг может выглядеть следующим образом:

auto eth1
iface eth1 inet manual
up up link set $IFACE promisc on arp off up
down ip link set $IFACE promisc off down
post-up ethtool -G $IFACE rx 512; for i in rx tx sg tso ufo gso gro lro; do ethtool -K $IFACE $i off; done
post-up echo 1> /proc/sys/net/ipv6/conf/$IFACE/disable_ipv6

Кратко суть происходящего: выставляем режим «IP-адрес вручную», но не задаем сам адрес; включаем Promiscuous Mode; при помощи утилиты ethtool в цикле выключаем все дополнительные встроенные функции сетевой карты.

Дополнительные вычислительные возможности сетевой карты

Сетевую карту вполне можно считать маленьким компьютером внутри большого. Этот «маленький компьютер» ограничен рамками приема/передачи, а также обработки сетевых пакетов.

Обработка и связанные с ней вычисления включают:

Расчет контрольных сумм (IP, TCP, UDP).
Дробление больших кусков информации на части определенного размера, который определяется средой передачи.
Наоборот, сливание входящих пакетов в большие куски, которые передаются вверх по стеку.

Не забывайте, что карта также является неким «сторожем»: она может принимать решения, какие пакеты передавать компьютеру для обработки, а какие отбросить. Причем в случае «отбросить» ваш ПК даже понятия не будет иметь, что эти пакеты вообще стучались в сетевую карту.

Раньше мы уже рассмотрели, что карта выкинет все пакеты/кадры, у которых был «не наш» 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-теги: есть карты, которые беспроблемно захватывают тегированные кадры, но некоторые могут повести себя не совсем предсказуемо, например:

полностью игнорировать тегированные кадры и отбрасывать их;
взять и обрезать 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 при этом положительные. Тогда все грустно – дамп уже не восстановить.

Заключение

Захват при помощи обычной пользовательской сетевой карты – это нормально, если:

Она не инжектирует в сеть свои собственные кадры (DHCP, ARP, IPv6 Multicast,…).
Вы можете пережить тот факт, что нет возможности захватить битые кадры.
Вы можете включить Promiscuous Mode на карте.
Ваша карта достаточно быстра, чтобы захватить всё, что вы хотите (её процент дропов в пределах допустимого для вас).

Ну, а если нет – вам нужна профессиональная карта. Признаюсь, все последние захваты трафика за последние пару лет, кроме случаев захвата на ПК конечного пользователя (то есть, каждый раз, когда мне нужно было идти в датацентр), я проводил только при помощи профессионального оборудования. Просто это совсем не смешно – звонить заказчику и говорить «ну.. мой дамп оказался не очень хорошим, и нам лучше бы сделать все заново…» Особенно, когда процедура захвата трафика потребовала много времени и усилий на согласование.

Статья переведена и опубликована с разрешения автора (Jasper Bongertz) только для сайта packettrain.net

Использование материала статьи без согласования запрещено!

Оригинал статьи находится по адресу: https://blog.packet-foo.com/2016/11/the-network-capture-playbook-part-3-network-cards/

This article has been translated and published with author’s (Jasper Bongertz) permission. For packettrain.net website only!

Original article can be found at: https://blog.packet-foo.com/2016/11/the-network-capture-playbook-part-3-network-cards/

Источник