Network Engineering Stack Exchange is a question and answer site for network engineers. It only takes a minute to sign up.
Sign up to join this community
Why can a packet sniffer in an Ethernet LAN obtain all packets sent over the LAN?
In a limited broadcast environment, such as in many Ethernet LANs, a packet sniffer can obtain all packets sent over the LAN.
We know if there is a Wi-Fi network, we can use a packet sniffer to catch the packets, but how about a wired Ethernet LAN?
In classic (obsolete) Ethernet, a shared wire or repeater hubs were used. So, each node physically receives every frame sent within the broadcast domain (also the collision domain in this case). Frames that are received but that are not addressed to the receiving NIC's MAC address are ignored (dropped). In a network like that, a NIC in promiscuous mode can capture all traffic.
For the last two decades or so, shared-wire or repeated Ethernet is obsolete. On switched Ethernet, each frame is forwarded only in the direction of its destination. To tap into an Ethernet communication requires listening in on the source or destination port directly or via port mirroring (aka port monitoring or SPAN) [edit after comments] and promiscuous mode on the capturing NIC, of course.[/edit]
Why in a Ethernet LAN, a packet sniffer can obtain all packets sent over the LAN?
That is not necessarily true. On switched ethernet (modern networks), you can only sniff the ethernet frames that are sent to the switch interface where your monitor device is connected. This can happen in a few ways:
Other than the above, only frames addressed to your monitor device are sent to the interface where it is connected.
Also, when using VLANs, only frames in the same VLAN can reach the interface where your monitor device is connected. To get traffic from one VLAN to another VLAN requires a router, which will strip the frames from the packets in order to forward the packets, building new frames for the next router interface.
This is achieved via one of a few possible methods...
By far, the most common is to put the interface in promiscuous mode. Almost all NICs can be placed in promiscuous mode. This removes the "filter" which ignores packets not destined for its interface. This must also be done for a wireless interface in order to "listen" to "conversations" on the network. A wireless card may also be placed in monitor mode, which differs from promiscuous mode in that the wireless interface is not associated with any AP, Ad-Hoc or other singular wireless interface, but instead listening for all decipherable packets in the air-waves (note that if an AP is encrypted via WEP/WPA(2), the packets received in monitor mode on a wireless card from devices part of that WLAN will be indecipherable (although some information may possibly be obtained that may aid in "cracking" that encryption).
Back to promiscuous mode in ethernet... while the technique is simple and requires no special utilities (on Linux at least) or changes to network topology/tap point (where the device is connected), there are, however, a few limitations. Those being: 1) the NIC can only pick up traffic on its network segment. An ethernet hub is similar to a coaxial (cable) splitter, it simply forwards packets to all interfaces (except the interface the packet was received on). So if connected to a hub, an ethernet card in promiscuous (promisc) mode would see packets sent to and from every device attached to the same hub. If the network has multiple hubs in series, the NIC would see all traffic for that segment until a smart forwarding device, such as a switch or router was reached. A switch (now pretty much making hubs obsolete- as they tremendously reduce congestion), uses a protocol known as ARP (address resolution protocol) or ND (neighbor discovery- IPv6 only) to discover the MAC addresses of all devices attached to each interface (port), and only forwards traffic to the destination interface.
All NICs will still receive broadcast packets (packets sent indiscriminately throughout the entire network- usually for network control and host discovery), and in promiscuous mode can be made to receive all multicast packets, even if the NIC does not belong to the multicast group. If configured correctly, and enabled, all anycast packets (similar to broadcast, but for non-network control protocols, and generally used on multi-use WAN networks like Cable/Broadband sharing the same medium) can also be made to be received, as well as simulcast packets in some cases (packets streamed to distinct multiple hosts). Broadcast and Multicast packets (multicast packets are primarily for IGMP- Internet group management protocol) can help get a fairly accurate picture of the network topology if correctly analysed. Additionally, pinging the network broadcast address (almost always the last IP of the network; the -b flag is necessary in linux and it fails in windows usually), your device will receive a response from every computer (that is not configured not to respond to broadcast pings, and if not blocked by a rule on an NSA) on the network. If there are multiple networks coexisting on the network, pinging the "allcast" (255.255.255.255) address can illicit a response from devices on a different subnet if the NIC is in promiscuous mode.
In Order to Receive All Traffic on an Ethernet Network
This gets a bit more complicated, depending on the network infrastructure, and there are a few ways to attain success.
As discussed before, if a network consists of only "dumb" hubs and a single segment (either via a stationless/routerless/WAN-isolated ad-hoc network of interconnected devices, or via a single WAN-to-LAN bridge feeding into a mesh of "dumb" hubs), then simply putting the NIC in promiscuous mode will suffice. If the network consists of a diverse topology, and switches rather than hubs, this is a far more complex process. First, the NIC should be placed in promiscuous mode. Then a decision must be made based on the network hardware and topology.
Options
1) Consider a standard commercial network consisting of a WAN device connected to the ISP (often called the "modem" or "router", however usually the device is actually a NAT device- which allows many internal devices to share just a single or a few public IP addresses, in IPv6 networks, these devices do usually perform IGMPv6 routing, but that's beyond the scope of this writeup), and connected to the WAN device is a main L3 (often with some L4 routing capabilities) smart, managed (configurable) switch. Ethernet extends from the main switch to different departments or floors which often have unmanaged (simple L2, sometimes with L3 filter capabilities) switches that connect to each computer, printer, wireless access point, etc.. If you have admin access to the main switch... it is possible to enable what is called port mirroring- depending on the configuration, you may be able to create a single "tap" port that has all traffic destined for other ports also forwarded to it. This is by far the most effective method, since EVERY packet on the network will flow to your promiscuous NIC, and can be captured with a program such as Wireshark. This method will also bypass security protocols that may exist in your network which could block other possible methods- such as arp spoofing, which I'll get to in a moment. Sometimes switches (usually lower end managed switches) only support mirroring a single port at a time, in this case, cloning the port on the switch connected to the WAN device should provide you with most of the traffic, as it can be assumed most traffic is headed for the internet, and even if not, the WAN device (in a complex network) is often a central, multi-protocol router, and receives almost all packets by default. Another single port to clone, if two switches are "stacked" (meaning they are interconnected via a trunk to serve as a single virtual switch- to support larger capacity), then mirroring a/the trunk port is a good option (this will also bypass certain encapsulation security encryption if the network is subdivided into VLANs, as the trunk carries all VLANs). Along those lines, it may also be necessary to ensure that if creating a universal mirror (a port that relays all traffic through the switch), your NIC may need to be configured to use the default VLAN/trunk VLAN (VLAN which carries all other VLANs), as well as promiscuous mode. Note that this will also likely put a large strain on your network, so it should only be Utilized for debugging or related purposes, not 24/7 in a construction environment (unless your switch is very high end and designed for a tap port- commonly used for connecting passive IDS/IPS and other sniffing security appliances for threat detection).
2)Another viable option is to "tap" the network mechanically. This can be accomplished by placing a network hub in between some segment of the network (either along the trunk of two stacked switches, between the main switch and the WAN or between the ISP and the WAN are all viable options- although due to NAT protocols, going between the WAN and ISP may make it difficult to determine what packet came from what device). Simply interconnect the segment with the hub in the center, using 2 extra ethernet cables- one to your listening device and another to complete the original connection (you MUST USE A HUB FOR THIS, NOT A SWITCH). There is a device especially made for this, which has some added benefits of preventing leaks from your device- keeping your sniffing hidden, preventing signal and speed degradation on the original connection and filtering VLAN headers to make configuration easier- it is made for Wireshark and I believe you can find it on their website- I think it's called the 'shark-tap' or something like that. It's pretty pricey though and not essential. This can also be achieved via 2 bridged NICs on the same computer- which can be configured as a rogue switch or router to attract packets, but for that I suggest you look at some tutorials (very similar to using two wireless NICs to create a MITM siruation).
3) Next we have an option that does not require any alteration of existing network infrastructure. There are actually 3 semi-related tactics that may need to be employed in conjunction depending on the security of your network. Again, promiscuous mode is necessary. The first is called ARP spoofing. This is very effective in most home and simpler corporate networks, but will quickly be detected by anti-intrusion/privacy-guard technologies- especially in a sophisticated smart network where each switch can communicate with each other. As I mentioned, switches work by using the ARP protocol for IPv4 and ND for IPv6. IPv4 is still the primary technology used for addressing in LANs (primarily due to the fact that network engineers are set in their ways and subletting IPv6 is much more difficult, as well as introduces a litany of new concepts to learn- IPv4 addresses are also usually much easier to remember) and therefore using ARP spoofing is usually sufficient (also ND spoofing is possible as well and uses similar concepts). There are several programs that can perform arp spoofing (almost all linux command line, you can do a search on the subject for tutorials on that). ARP is a protocol, used in computers and (importantly, for this application) switches, to associate MAC (physical addresses) with IPv4 addresses. The protocol is simple: in the absence of IGMP, the subnet broadcast address is used primarily, a request packet is sent in the form of "who has [ip address]? Tell [my IP address]" in response, usually the main switch or the device with the requested IP (however it can be any device on the network that knows the answer) replies with [the IP you were looking for] is at [MAC address]. If an answer is not received, a packet is sent on the default broadcast 255.255.255.255, in some cases, the wildcard 0.0.0.0 is queried, with IGMP, site-local and net-local addresses are also asked. Additionally, some OSs sent the request to the default gateway or default switch. ARP spoofing involves answering authoritatively to all ARP requests. In addition, ARP responses are sent aggressively, and, with IGMP enabled on the network, to all IGMP interfaces, and all broadcast addresses (if multiple subnets exist), as well as the default gateway (if desired) and/or the default switch. This results in what is known as ARP cache poisoning. That is, the network control devices (switches, routers, gateways) now either point solely to you when trying to talk to other specific devices, or more desirable, assume a network loop or fault and fallback to hub like behavior- meaning all packets destined for all other network devices are also sent directly to you/your network segment. The procedure is easy to understand, at it's roots. Then, promiscuous mode takes care of the rest and you can hear all conversations. It is also possible to impersonate only the main switch, or only the WAN device, which receives 90% of the packets traversing the network in most cases- the exception being protocols which use IPv6 (and a few rare IPv4 protocols, which usually require the creation of temporary point-to-point connections, while IPv6 always establishes local link fe80 addresses for this purpose) to circumvent network infrastructure (if on the same segment) and talk directly to each other. An example of this is the appletalk protocol for communication and services between Mac computers on the same networks segment.
The issue is, that more advanced network hardware, especially if a network firewall or more advanced NSA exists or is the primary WAN device or sits between the network/main switch and the WAN (as is the case in many situations), that device will often detect the sniffing attempt and in response, automatically block all traffic to the designated MAC (phy) or IPv4, shut down the segment entirely, or simply ignore the newly advertised location- which works well on an all desktop network where a machine's position is unlikely to change (this would be unlikely on an average home setup, where traffic would simply be routed/switched to both devices). However, because of wireless access point roaming, meaning a device can jump from segment to segment, often faster than APR caches update (user configured on managed switches and static on unmanaged ones, anywhere from 30 seconds or less for a heavily wireless network to 60 seconds for a mixed environment, up to a half hour or more for a network that infrequently changes- shorter timeouts are preferred due to faster failover tolerance and less misdirected traffic, but longer periods can save the overhead of the ARP protocol in static ethernets). This also becomes less of an issue when the main security appliance sits at the main switch or WAN- and interconnected, unmanaged switches direct traffic throughout large segments. In this case, ARP poisoning can simply affect a large segment of the network without triggering a security device. Other factors influence this, such as Protocols like STP (spanning three protocol, which is designed to update the network topology known to switches in the event of a topology change- like if a switch is moved from one port to another). Actually, in misconfigured networks with both STP and IGMP, simply unplugging a device and plugging it into a different switch port will trigger what is known as an IGMP flood, which will cause all switches to behave similar to "dumb" hubs, until the ARP cache is synchronized across devices- during which time all traffic will become visible for a period usually equal to the maximum device ARP cache timeout, on all interfaces.
Additional, or in conjunction to ARP spoofing/cache poisoning, MAC spoofing can sometimes be employed, either to fool security appliances along with ARP cache poisoning, or simply on its own. A good tactic would be to clone the MAC (macchanger command in linux) of the WAN device is often a promising technique. Sometimes setting your IP to a static IP that is the same as your target is enough to fool routing protocols into sending traffic not destined for you- again, something that can be beneficial in addition to ARP spoofing. Cloning your hostname can help avoid detection.
If your goal is to debug (or spy on) a single target machine, then you are probably best off combining everything discussed here, to the best of your ability. Attempt to place your listening device tapped into the network segment of the target device. Then all you need is promiscuous mode enabled. If that is not an option, try to get at least on the same segment from the main switch as your target and use less agressive ARP spoofing/cache poisoning and/or MAC cloning (possibly cloning the IP as well, although an interface in promiscuous mode shouldn't need an assigned IP and that may result in both devices getting forced off the network), if all else fails, use aggressive ARP poisoning. Also remember, that it is possible to perform ARP spoofing on a single target- corrupting a machine's cache, causing it to send packets to you instead of it's intended destination. This type of active ARP poisoning works best when you are actively forwarding packets to the intended deatination- or your device will simply not respond, resulting in the victim think they have a broken connection, although if multiple entries exist or conflicting responses are received to an ARP request, it is normal for the device to send packets to all devices, the one which responds becomes the semi-permanent cache entry, while, depending on the system, the offending entry is often blacklisted for a period, hence why using MITM (man in the middle) forwarding is beat practice.
If your goal if to simply debug a network, simply putting your ethernet card into promiscuous mode will allow you to glean a lot of information about your network, you'll see nearly all network control messages, get a good idea of what devices are the most active and see some unicast packets that are sent before a devices ARP table is filled. This requires no spoofing and is fully automated in wireshark and can be done with ifconfig {sudo ifconfig eth# mode promisc' orsudo ifconfig eth# promisc' (if I am thinking right)} in linux, similarly, if supported, anycast reception can also be enabled.
It should be noted, that depending on your NICs firmware, the drivers installed, if you are using win or linux, etc., simply enabling promiscuous mode on the adapter often enables a form of passive ARP spoofing to allow reception of all (or most, at least on your segment) unicast packets. However, using active, aggressive ARP cache poisoning is far more effective if monitoring all traffic on all network segments from a remote network segment is required. It is not guaranteed to do any ARP activities, however, just allow reception of all packets traveling through the wire
Note that because many security appliances rely on ARP cache poisoning to be inserted into the network and passively sniff all incoming traffic to detect odd patterns and trip alarms, and because an aggressively roaming WiFi device can be constantly associating with APs on different segments faster than the ARP cache timeout- effectively appearing as being present in two locations from a network control perspective, while it is not doing anything malicious, most network hardware will allow ARP spoofing unless it is manually disabled in high security environments (and even then, it's a tradeoff as it prevents passive listening/DPI/IPS/IDS devices. If you know the MAC of such a device, cloning your MAC to match it and performing your own ARP cache poisoning is probably your beat bet. It is also expected that, provided the rogue ARP device is on the inside (LAN facing side) of the WAN device, that physical security should prevent rogue devices from appearing internally, and thus considered less of a threat.
In the old days, when switches were new and highly expensive, and hubs were the main way of interconnecting multiple network segments, one could see all traffic from any part of even a large network, however, this obviously was less than ideal- as congestion on the network was extremely high- to the point of instability of even medium LANs
NOTE THAT MOST OF TRAFFIC NOWADAYS IS ENCRYPTED VIA TLS, SO WHILE YOU MAY BE ABLE TO CAPTURE CONNECTIONS, AND ASCERTAIN WHAT DEVICE IS CONNECTED TO WHERE, YOU WILL NOT BE ABLE TO DECIPHER 95% OF THE CONVERSATIONS.
SOME USEFUL COMMANDS LINUX (some windows): -ifconfig (check capabilities and state of network cards; put cards into promiscuous mode; set/add/delete IP, broadcast address, MTU, etc; more;; ipconfig -a in windows is similar but limited) -man [-k] (|) (learn how to use different commands, -k flag allows you to search for a specific command to do something you want; the number in parentheses tells you the section (1)standard commands/(8)administrative/system configuration commands- those are the most important (5)is for system calls & config files, which can also be useful, (3pm)perl, there's also standard C library references, python, tk/tcl, ruby, etc.;; help is a highly limited windows help; note help for some linux commands too) -sudo -i (log in to root shell as current user- so you don't need to keep typing sudo if you're using a lot of administrative commands) -arp ([-a]|[-d|-v]|[add|delete) (display/add/delete arp table entries; same in windows, flags vary; see help -h or man page for details) -netstat (display current connections) -route (show/modify routing table) -hostname (show/change machine hostname) -macchanger [-b] (change/spoof MAC address; -b flag mimics burnt in MAC, less likely to trip security) -ettercap (GUI capable of advanced capture and analysis, aggressive ARP spoofing, MITM forwarding, TLS Cert spoofing, etc.) -etherape (GUI to visualize traffic patterns on an ethernet network. Great tool) -nettop/ntop (nCurses {in-shell pseudo-GUI} network traffic live analysis, similar to the network performance monitor in windows) -ping -b (send broadcast ping- fills up ARP table; usually fails in win10) -ping or tracrtoute [-T|-U|-UL|-I] (dependent on distro, ping version; sends TCP|UDP|UDPLITE|ICMP ping or traceroute rather than default UDP traceroute/ICMP ping; ping -e flag provides information on packet encapsulation, note that ARP poisoning will not succeed through a MPLS/VPN tunnel or across an L4 routed network segment, or across VLANs, unless the sniffing device is on the default VLAN (such as 2 departments with an internal router in the middle, each on different subnets/networks- this creates a barrier which packets only traverse if they meet predefined rules made by the admin). -of course apt/yum/dnf/apt-get [search|install] or rpm -i for a pre-downloaded package on fedora/RHEL (package managers to install any missing software)
DISCLAIMER (INTENDED FOR RESPONSIBLE USE OF INFORMATION ONLY): Any information regarding potentially evading detection by security appliances, eavesdropping on a target or targets or performing any other activity which could be considered "hacking", "cracking", "impersonation" (digital or otherwise) or "spoofing", and/or any and all information provided herein which could be used in a malicious and/or illegal manner (by the most loose definition of the term and under law in any or all jurisdiction), is provided for information purposes only- not as a tutorial or advice on how to carry out such aforementioned activities. Nothing written above constitutes advice or encouragement to commit any crime or break any law, nor to cause damages to any individual. This information has been provided strictly for hypothetical purposes and therefore should and must be considered hypothetical in all regards. Any attempt by an individual to use this information in a manner prohibited herein, or otherwise, by common sense reasoning, morally unjust or wrong, or in a manner prohibited by the terms of service of the publisher, shall not reflect any liability upon either the writer of the content, nor the publisher, under any circumstance, in any jurisdictions. Except in regard to copyright, this statement fully supplements the terms of service of the publisher. Copyright notice herein (2019) superceds any claim to material by publisher. The author(s) (Cryptostack Services LLC & Dylan J Bennett) shall hold equal and all rights to copy and/or repost and/or delete this material upon request and/or desire. The author(s), named above in parentheses, shall reserve full power of copyright and all Rights under the DMCA. This is supplemental to the terms of service of the site the author is publishing on. No one may copy or republish this information on any other medium (electronic or analog) other than the original (stack-exchange sub-forum for Network related questions) posting medium. Violation of such request shall constitute damages liable for monetary reparations. Violation constitutes willful surrender by violator of right to trial by Judge or Jury in the case that the author seeks civil reparations for any damages incurred- the author however reserves right to file civil suit in Southern District of New York or other court in vicinity or to choose Arbitration by firm chosen by author in New York State, US. Publishing in this forum in no way relinquishes the author's rights to exclusive ownership, copy privileges, ability to seek damages, etc. regardless of terms of service stated by publisher. This statement is supplemental to any terms or use and/or service by publisher and shall superceded any materials predating this statement. In the case of contradiction between publisher's terms and these terms, this shall be considered superior. It is assumed that publisher is aware of and responsible for content on its medium and as such may willfully remove the entire content of this post if it is in disagreement. Failure to remove entire contents posted by author is a violation herein. Furthermore, both the author and publisher relinquish all liability from damages caused by information and methods contained in this post- as all information was compiled from other publically available sources, and therefore the goal of this post is only to serve the sole purpose of providing access to already available knowledge for the purpose of answering a question posed by an individual who, to the writer's and publisher's knowledge, poses no threat to any individual, organization or otherwise. This statement is meant to protect both author (stated above) and publisher from liability. The statement was drafted by the author (stated above) of the entirety of this post. The language of this statement is plain English and should not be over-interpreted. Common sense interpretation is required.
