Differences between revisions 1 and 38 (spanning 37 versions)
Revision 1 as of 2005-02-12 21:47:28
Size: 6345
Editor: GuyHarris
Comment: Capture setup page for Ethernet.
Revision 38 as of 2007-10-31 12:07:14
Size: 11971
Editor: cpc2-cmbg2-0-0-cust193
Comment: Managed switches with mirrroring not as expensive as they were in the past
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:
This page will explain which points to think about when capturing packets from ["Ethernet"] networks.
Line 3: Line 4:
The following will explain capturing on ["Ethernet"] a bit. == Table of contents ==
[[TableOfContents(4)]]
Line 5: Line 7:
The Ethernet hardware on the network interface card (NIC) filters all packets received, and forwards all ["Unicast"]/["Multicast"] packets destinated to the specific host and all ["Broadcast"] packets to the software layers. == Packet Types ==
The Ethernet hardware on the network adapter filters all packets received, and delivers to the host
Line 7: Line 10:
To see/capture all packets received by the NIC, you can set your NIC into promiscuous mode, so the filter mentioned above is simply swiched off and all packets received will be forwarded to the software layers.  * all ["Unicast"] packets that are being sent to one of the addresses for that adapter, i.e. packets sent to that host on that network;
 * all ["Multicast"] packets that are being sent to a ["Multicast"] address for that adapter, or all ["Multicast"] packets regardless of the address to which they're being sent (some network adapters can be configured to accept packets for specific ["Multicast"] addresses, others deliver all multicast packets to the host for it to filter);
 * all ["Broadcast"] packets.
The driver for the adapter will also send copies of transmitted packets to the packet capture mechanism, so that they will be seen by a capture program as well.

In order to capture Ethernet traffic other than ["Unicast"] traffic to and from the host on which you're running Wireshark, ["Multicast"] traffic, and ["Broadcast"] traffic, the adapter will have to be put into promiscuous mode, so that the filter mentioned above is switched off and all packets received are delivered to the host.
Line 10: Line 18:
In the old days, Ethernet networks were shared networks, using shared media or hubs to connect the Ethernet nodes together, meaning all packets could be received by all nodes on that network. Therefore, if an Ethernet adapter on such a network is put into promiscuous mode, all packets on the network will be seen by that adapter and thus can be captured with that adapter.
Line 11: Line 20:
In the old days, Ethernets used shared networks (using shared media or hubs) to connect the Ethernet nodes together, meaning all Ethernet packets where received by all nodes on that network. attachment:Capture-shared-hub.png
Line 13: Line 22:
As all packets to all nodes are available at the receiving NIC, switching this NIC to promiscuous mode, really all packets on that Ethernet network can be captured. Today, shared networks are becoming popular again, as WLAN's are using this technique. You might have a look at ["CaptureSetup/WLAN"] for details.
Line 16: Line 25:
Today, a typical Ethernet network will use switches to connect the Ethernet nodes together. This can increase network performance a lot, but makes life much harder when capturing packets.
Line 17: Line 27:
Today, a typical Ethernet network will use switches to connect the Ethernet nodes together. This can increase network performance a lot, but makes life much harder for capturing packets. An Ethernet switch will do a similar thing to the Ethernet adapter hardware mentioned above, but inside the switch. It can infer, from traffic seen on a switch port, what ["Unicast"] address or addresses are used by the adapter connected to that port, and will forward to that port only ["Unicast"] traffic sent to that address or addresses, as well as all ["Multicast"] and ["Broadcast"] packets on the network.
Line 19: Line 29:
An Ethernet switch will do a similar thing to the Ethernet hardware mentioned above, but inside the switch. It filters all packets received, and forwards all ["Unicast"]/["Multicast"] packets destined to the specific host and all ["Broadcast"] packets to the Ethernet node. As ["Unicast"] packets not sent to that host will not be put on the switch port to which that host's adapter is connected, that adapter will not have those packets, so putting the adapter into promiscuous mode can't cause it to deliver packets to that host, and you won't see those packets even if you capture in promiscuous mode.
Line 21: Line 31:
As the network interface card doesn't even see packets not destined for it, it doesn't make any difference to switch that NIC to the promiscuous mode or not. attachment:Capture-switch-problem.png
Line 25: Line 35:
=== Capture on the machine your interested in === === Capture on the machine you're interested in ===
If you only need the capture data from a specific host, try to capture on that machine.
Line 27: Line 38:
If you only need the capture data from a specific host, try to capture on that machine. attachment:Capture-switch-same-computer.png
Line 31: Line 42:
=== Capture using an Ethernet hub ===
If you have an "old" Ethernet hub available, put it inside the Ethernet line you want to capture from. This could be the line between a switch and a node or between two switches.
Line 32: Line 45:
=== Capture using an Ethernet hub ===

If you have an "old" Ethernet hub available, put it inside the Ethernet line you want to capture from. This could be the line between a switch and a node or between two switches.
attachment:Capture-switch-hub.png
Line 40: Line 51:
Note that some "hubs" are actually "switching hubs", which are switches rather than "old" hubs, and won't help in this case, and that "dual-speed" (10/100Mb) hubs don't forward unicast traffic between 10Mb/s and 100 Mb/s ports, requiring the capturing machine to run its Ethernet at the same speed as the machines whose traffic it's trying to capture.
Line 41: Line 54:
 * Disadvantage: Will affect EthernetFullDuplex traffic  * Disadvantage: Those hubs can be hard to find (so often they're ''not'' available), will affect EthernetFullDuplex traffic
See the HubReference for information on "real" hubs.
Line 44: Line 58:
Some Ethernet switches, namely the more expensive manageable ones, have a monitor mode. This monitor mode can dedicate a port to connect your (Wireshark) capturing device. It's sometimes called 'port mirroring', 'port monitoring', 'Roving Analysis' (3Com), or 'Switched Port Analyzer' or 'SPAN' (Cisco). Using the switch management, you can select both the monitoring port and assign a specific port you wish to monitor. Actual procedures vary between switch models; you may need to use a terminal emulator, specialised SNMP client software or (more recently) a Web browser. Caution: the monitoring port must be at least as fast as the monitored port, or you will certainly lose packets.
Line 45: Line 60:
Some Ethernet switches, namely the more expensive manageable ones, have a monitor mode. This monitor mode can dedicate a port to connect your (Ethereal) capturing device. It's sometimes called 'port mirroring', 'port monitoring', 'Roving Analysis' (3Com), or 'Switched Port Analyzer' or 'SPAN' (Cisco). Using the switch management, you can select both the monitoring port and assign a specific port you wish to monitor. Actual procedures vary between switch models; you may need to use a terminal emulator, specialised SNMP client software or (more recently) a Web browser. Caution: the monitoring port must be at least as fast as the monitored port, or you will certainly lose packets.

See SwitchReference for details about specific switch models.
Note that some switches might not support monitoring ''all'' traffic passing through the switch, only traffic on a particular port. On those switches, you might not be able to capture all traffic on the network, only traffic sent to or from some particular machine on the switch.
Line 51: Line 64:
attachment:Capture-switch-monitor-port.png
Line 52: Line 67:
 * Disadvantage: Expensive switch needed, capture packet loss at high traffic  * Disadvantage: More expensive switch needed (though not as expensive as they once were), capture packet loss at high traffic
See the SwitchReference for details about specific switch models.
Line 54: Line 70:
=== Capture using a machine-in-the-middle ===
A machine with two network interface cards (NICs) can be used as a transparent bridge, capturing all the traffic to and from a single machine or a network segment. Under Linux, brcfg is the appropriate configuration tool; under the BSD family, brconfig. Apparently, Windows XP and Server 2003 also allow bridging configurations to be built; it may well prove harder to make a Windows installation 'quiet' in network traffic terms than Unix.

Running Wireshark on just one of the NICs is enough to capture all the traffic.

Many laptops have one network adaptor built-in; a second can be added using a PC card. Desktop machines are easily fitted with additional NICs.

The bridge is 'transparent' at the level of IP and similar protocols, and 'almost' transparent at the Ethernet level - it creates a small delay in packet transmission, and the Ethernet addresses of the two NICs may respond to some broadcast messages.

attachment:Capture-switch-mitm-2NIC.png

 * Advantage: requires no changes to monitored host, uses only generally available hardware
 * Disadvantage: dedicated machine configuration required
Line 55: Line 84:
Line 60: Line 88:
To use these taps, you have to capture both outputs. As Ethereal cannot capture from two interfaces at once, you have to start two Ethereal instances for capturing and merge the resulting capture files together. attachment:Capture-switch-tap.png
Line 62: Line 90:
On most Unix systems, including Red Hat, two Ethernet ports can be bonded, and Ethereal can use the bonded interface. This prevents having to run two instances of Ethereal and merging them together. For more information, check on bonding for your OS type. To use these taps, you have to capture both outputs. As Wireshark cannot capture from two interfaces at once, you have to start two Wireshark instances for capturing and merge the resulting capture files together.

On most Unix systems, including Red Hat, two Ethernet ports can be bonded, and Wireshark can use the bonded interface. This prevents having to run two instances of Wireshark and merging them together. For more information, check on "bonding", "trunking", or (less desirably) "bridging" for your OS type.
Line 65: Line 95:
 * Disadvantage: Costly, uncomfortable to work with (until Ethereal is able to capture from multiple interfaces)  * Disadvantage: Costly, uncomfortable to work with (until Wireshark is able to capture from multiple interfaces)
See [http://www.snort.org/docs/tap/ Construction and Use of a Passive Ethernet Tap] from the Snort webpage how to build a DIY tap. You can purchase network taps from simple passive ones at the size of a cigarette packet to 19" rack mounted multiple line taps which support SNMP monitoring and redundant power supply. [http://www.netoptics.com/ Net Optics] and other manufaturers provide a range of these taps.
Line 67: Line 98:
Be sure to test the power up and power down of taps. Some taps are completely transparent when they power down, but can take up to (approx) two seconds for it to power up (so for two seconds, no packets make it through).
Line 69: Line 101:
To capture packets going between two computers on a switched network, you can use a MITM attack (ARP Poisoning.) This type of attack will fool the two computers into thinking that your MAC address is the MAC address of the other machine.  This will in turn make the switch route all of their traffic to your computer where you can sniff it and then send the traffic along as if nothing ever happened.  This type of attack can cause havoc on some switches and LANs so use it carefully.  Please do not try this on any LAN other than your own. To capture packets going between two computers on a switched network, you can use a MITM attack (ARP Poisoning). This type of attack will fool the two computers into thinking that your MAC address is the MAC address of the other machine. This will in turn make the switch route all of their traffic to your computer where you can sniff it and then send the traffic along as if nothing ever happened. This type of attack can cause havoc on some switches and LANs so use it carefully.
Line 71: Line 103:
See [http://ettercap.sourceforge.net/forum/viewtopic.php?t=2392&sid=c3bd051ccaac01d54f83223155793cd3 Ettercap - ARP Poisoning HowTo] for more info. attachment:Capture-switch-mitm.png

/!\ '''Please do not try this on any LAN other than your own!'''
Line 75: Line 109:
See [http://ettercap.sourceforge.net/forum/viewtopic.php?t=2392&sid=c3bd051ccaac01d54f83223155793cd3 Ettercap - ARP Poisoning HowTo] for more info.
Line 77: Line 112:
Switches keep a translation table that maps various MAC addresses to the physical ports on the switch. As a result of this, a switch can intelligently route packets from one host to another, but it has a limited memory for this work. MAC flooding makes use of this limitation to bombard the switch with fake MAC addresses until the switch can't keep up. The switch then enters into what is known as a `failopen mode', wherein it starts acting as a hub by broadcasting packets to all the machines on the network. Once that happens sniffing can be performed easily. MAC flooding can be performed by using macof, a utility which comes with the [http://www.monkey.org/~dugsong/dsniff/ dsniff] suite.
Line 78: Line 114:
Switches keep a translation table that maps various MAC addresses to the physical ports on the switch. As a result of this, a switch can intelligently route packets from one host to another, but it has a limited memory for this work. MAC flooding makes use of this limitation to bombard the switch with fake MAC addresses until the switch can't keep up. The switch then enters into what is known as a `failopen mode', wherein it starts acting as a hub by broadcasting packets to all the machines on the network. Once that happens sniffing can be performed easily. MAC flooding can be performed by using macof, a utility which comes with the [http://www.monkey.org/~dugsong/dsniff/ dsniff] suite. attachment:Capture-switch-mac-flooding.png

/!\ '''Please do not try this on any LAN other than your own!'''
Line 82: Line 120:
Line 84: Line 121:
 
Line 86: Line 122:
 * [http://www.askapache.com/security/sniffing-on-ethernet-undetected.html Sniffing On Ethernet Undetected] article on [http://www.askapache.com askApache]
 * [http://www.linuxjournal.com/node/6222 Stealthful Sniffing, Intrusion Detection and Logging] article on [http://www.linuxjournal.com Linux Journal]
 * [http://antionline.com/showthread.php?t=233915 Stealthful Sniffing, Intrusion Detection and Logging Discussion]
 * [http://www.linuxjournal.com/article/5201 In Search of a Sniffer] article on [http://www.linuxjournal.com Linux Journal]
== See Also ==
 * [:CaptureSetup/WLAN:Capturing on 802.11 Wireless Networks]
 * [:CaptureSetup/TokenRing:Capturing on Token Ring Networks]
 * [:CaptureSetup/VLAN:Capturing on VLAN Protected Networks]
 * [:CaptureSetup/PPP:Capturing on PPP Networks]
 * [:CaptureSetup/Loopback:Capturing on the Loopback Device]
 * [:CaptureSetup/FrameRelay:Capturing on Frame Relay Networks]
 * [:CaptureSetup/DOCSIS:Capturing DOCSIS Traffic]
 * [:CaptureSetup/Bluetooth:Capturing Bluetooth Traffic]
 * [:CaptureSetup/ATM:Capturing on ATM Networks]
 * [:CaptureSetup/USB:Capturing USB Traffic]
 * [:CaptureSetup/IrDA:Capturing IrDA Traffic]
 * [:CaptureSetup/CiscoHDLC:Capturing on Cisco HDLC Networks]
 * [:CaptureSetup/SS7:Capturing SS7 Traffic]
----
CategoryHowTo

Ethernet capture setup

This page will explain which points to think about when capturing packets from ["Ethernet"] networks.

Table of contents

TableOfContents(4)

Packet Types

The Ethernet hardware on the network adapter filters all packets received, and delivers to the host

  • all ["Unicast"] packets that are being sent to one of the addresses for that adapter, i.e. packets sent to that host on that network;
  • all ["Multicast"] packets that are being sent to a ["Multicast"] address for that adapter, or all ["Multicast"] packets regardless of the address to which they're being sent (some network adapters can be configured to accept packets for specific ["Multicast"] addresses, others deliver all multicast packets to the host for it to filter);
  • all ["Broadcast"] packets.

The driver for the adapter will also send copies of transmitted packets to the packet capture mechanism, so that they will be seen by a capture program as well.

In order to capture Ethernet traffic other than ["Unicast"] traffic to and from the host on which you're running Wireshark, ["Multicast"] traffic, and ["Broadcast"] traffic, the adapter will have to be put into promiscuous mode, so that the filter mentioned above is switched off and all packets received are delivered to the host.

Shared Ethernet

In the old days, Ethernet networks were shared networks, using shared media or hubs to connect the Ethernet nodes together, meaning all packets could be received by all nodes on that network. Therefore, if an Ethernet adapter on such a network is put into promiscuous mode, all packets on the network will be seen by that adapter and thus can be captured with that adapter.

attachment:Capture-shared-hub.png

Today, shared networks are becoming popular again, as WLAN's are using this technique. You might have a look at ["CaptureSetup/WLAN"] for details.

Switched Ethernet

Today, a typical Ethernet network will use switches to connect the Ethernet nodes together. This can increase network performance a lot, but makes life much harder when capturing packets.

An Ethernet switch will do a similar thing to the Ethernet adapter hardware mentioned above, but inside the switch. It can infer, from traffic seen on a switch port, what ["Unicast"] address or addresses are used by the adapter connected to that port, and will forward to that port only ["Unicast"] traffic sent to that address or addresses, as well as all ["Multicast"] and ["Broadcast"] packets on the network.

As ["Unicast"] packets not sent to that host will not be put on the switch port to which that host's adapter is connected, that adapter will not have those packets, so putting the adapter into promiscuous mode can't cause it to deliver packets to that host, and you won't see those packets even if you capture in promiscuous mode.

attachment:Capture-switch-problem.png

The following will describe some methods to circumvent this problem.

Capture on the machine you're interested in

If you only need the capture data from a specific host, try to capture on that machine.

attachment:Capture-switch-same-computer.png

  • Advantage: Easy to use
  • Disadvantage: Other traffic not available

Capture using an Ethernet hub

If you have an "old" Ethernet hub available, put it inside the Ethernet line you want to capture from. This could be the line between a switch and a node or between two switches.

attachment:Capture-switch-hub.png

Beware that this will interrupt network traffic while you plug the cables!

This method can/will affect network performance, if you are using EthernetFullDuplex mode. This is not optimal for network troubleshooting.

Note that some "hubs" are actually "switching hubs", which are switches rather than "old" hubs, and won't help in this case, and that "dual-speed" (10/100Mb) hubs don't forward unicast traffic between 10Mb/s and 100 Mb/s ports, requiring the capturing machine to run its Ethernet at the same speed as the machines whose traffic it's trying to capture.

  • Advantage: Often such a hub is available
  • Disadvantage: Those hubs can be hard to find (so often they're not available), will affect EthernetFullDuplex traffic

See the HubReference for information on "real" hubs.

Capture using a monitor mode of the switch

Some Ethernet switches, namely the more expensive manageable ones, have a monitor mode. This monitor mode can dedicate a port to connect your (Wireshark) capturing device. It's sometimes called 'port mirroring', 'port monitoring', 'Roving Analysis' (3Com), or 'Switched Port Analyzer' or 'SPAN' (Cisco). Using the switch management, you can select both the monitoring port and assign a specific port you wish to monitor. Actual procedures vary between switch models; you may need to use a terminal emulator, specialised SNMP client software or (more recently) a Web browser. Caution: the monitoring port must be at least as fast as the monitored port, or you will certainly lose packets.

Note that some switches might not support monitoring all traffic passing through the switch, only traffic on a particular port. On those switches, you might not be able to capture all traffic on the network, only traffic sent to or from some particular machine on the switch.

Rumour has it that some switches can monitor the whole throughput of the switch. As a switch can transfer more traffic than a single line can transmit, you will be unlikely to see all traffic.

attachment:Capture-switch-monitor-port.png

  • Advantage: Easy to use if such a switch available
  • Disadvantage: More expensive switch needed (though not as expensive as they once were), capture packet loss at high traffic

See the SwitchReference for details about specific switch models.

Capture using a machine-in-the-middle

A machine with two network interface cards (NICs) can be used as a transparent bridge, capturing all the traffic to and from a single machine or a network segment. Under Linux, brcfg is the appropriate configuration tool; under the BSD family, brconfig. Apparently, Windows XP and Server 2003 also allow bridging configurations to be built; it may well prove harder to make a Windows installation 'quiet' in network traffic terms than Unix.

Running Wireshark on just one of the NICs is enough to capture all the traffic.

Many laptops have one network adaptor built-in; a second can be added using a PC card. Desktop machines are easily fitted with additional NICs.

The bridge is 'transparent' at the level of IP and similar protocols, and 'almost' transparent at the Ethernet level - it creates a small delay in packet transmission, and the Ethernet addresses of the two NICs may respond to some broadcast messages.

attachment:Capture-switch-mitm-2NIC.png

  • Advantage: requires no changes to monitored host, uses only generally available hardware
  • Disadvantage: dedicated machine configuration required

Capture using a network tap

Several vendors offer network taps, which can be plugged into a line.

These taps will have four connectors: two for the existing line and two outputs for both directions of the EthernetFullDuplex traffic.

attachment:Capture-switch-tap.png

To use these taps, you have to capture both outputs. As Wireshark cannot capture from two interfaces at once, you have to start two Wireshark instances for capturing and merge the resulting capture files together.

On most Unix systems, including Red Hat, two Ethernet ports can be bonded, and Wireshark can use the bonded interface. This prevents having to run two instances of Wireshark and merging them together. For more information, check on "bonding", "trunking", or (less desirably) "bridging" for your OS type.

  • Advantage: All packets of EthernetFullDuplex traffic can be captured, won't affect Ethernet traffic

  • Disadvantage: Costly, uncomfortable to work with (until Wireshark is able to capture from multiple interfaces)

See [http://www.snort.org/docs/tap/ Construction and Use of a Passive Ethernet Tap] from the Snort webpage how to build a DIY tap. You can purchase network taps from simple passive ones at the size of a cigarette packet to 19" rack mounted multiple line taps which support SNMP monitoring and redundant power supply. [http://www.netoptics.com/ Net Optics] and other manufaturers provide a range of these taps.

Be sure to test the power up and power down of taps. Some taps are completely transparent when they power down, but can take up to (approx) two seconds for it to power up (so for two seconds, no packets make it through).

Capture using a MITM (Man-In-The-Middle) software

To capture packets going between two computers on a switched network, you can use a MITM attack (ARP Poisoning). This type of attack will fool the two computers into thinking that your MAC address is the MAC address of the other machine. This will in turn make the switch route all of their traffic to your computer where you can sniff it and then send the traffic along as if nothing ever happened. This type of attack can cause havoc on some switches and LANs so use it carefully.

attachment:Capture-switch-mitm.png

/!\ Please do not try this on any LAN other than your own!

  • Advantage: Cheap
  • Disadvantage: Can confuse switches, capture packet loss at high traffic

See [http://ettercap.sourceforge.net/forum/viewtopic.php?t=2392&sid=c3bd051ccaac01d54f83223155793cd3 Ettercap - ARP Poisoning HowTo] for more info.

MAC Flooding

Switches keep a translation table that maps various MAC addresses to the physical ports on the switch. As a result of this, a switch can intelligently route packets from one host to another, but it has a limited memory for this work. MAC flooding makes use of this limitation to bombard the switch with fake MAC addresses until the switch can't keep up. The switch then enters into what is known as a `failopen mode', wherein it starts acting as a hub by broadcasting packets to all the machines on the network. Once that happens sniffing can be performed easily. MAC flooding can be performed by using macof, a utility which comes with the [http://www.monkey.org/~dugsong/dsniff/ dsniff] suite.

attachment:Capture-switch-mac-flooding.png

/!\ Please do not try this on any LAN other than your own!

  • Advantage: Cheap
  • Disadvantage: Will affect EthernetFullDuplex traffic, capture packet loss at high traffic

See Also

  • [:CaptureSetup/WLAN:Capturing on 802.11 Wireless Networks]

  • [:CaptureSetup/TokenRing:Capturing on Token Ring Networks]

  • [:CaptureSetup/VLAN:Capturing on VLAN Protected Networks]

  • [:CaptureSetup/PPP:Capturing on PPP Networks]

  • [:CaptureSetup/Loopback:Capturing on the Loopback Device]

  • [:CaptureSetup/FrameRelay:Capturing on Frame Relay Networks]

  • [:CaptureSetup/DOCSIS:Capturing DOCSIS Traffic]

  • [:CaptureSetup/Bluetooth:Capturing Bluetooth Traffic]

  • [:CaptureSetup/ATM:Capturing on ATM Networks]

  • [:CaptureSetup/USB:Capturing USB Traffic]

  • [:CaptureSetup/IrDA:Capturing IrDA Traffic]

  • [:CaptureSetup/CiscoHDLC:Capturing on Cisco HDLC Networks]

  • [:CaptureSetup/SS7:Capturing SS7 Traffic]


CategoryHowTo

CaptureSetup/Ethernet (last edited 2018-11-19 08:30:36 by GuyHarris)