I just started wireshark on my PC and I am noticing it is being flooded with EAPOL packets. Here is an example of one of them (they are all the same): Source: Asustekc_bb:91:3c Destination: nearest Protocol: EAPOL Length: 60 Info: Logoff There is no IPV4/6 info in the packets at all. How can I track down where these are coming from? asked 09 May '16, 15:12  jrsmith |
One Answer:
Well, the source MAC address begins with "Asustekc_" (actually, it's probably "AsustekC_", capital C), so that address belongs to "ASUSTek COMPUTER INC.", so see if there are any ASUS computers/tablets/smartphones/"ASUS O!Play" devices on your network. I'm guessing that these packets are being captured over Wi-Fi; if so, if you find any ASUS equipment of that sort, and can find out what the MAC address of its WI-FI adapter is (either from any documentation ASUS supplied with the equipment or from anything you can do from the machine's UI), check to see if any of the machines have a WI-Fi MAC address equal to the (raw) source MAC address in those packets. (Sorry, I don't think there's an easier way to do it.) answered 09 May '16, 23:18  Guy Harris ♦♦ showing 5 of 9 show 4 more comments |
...and if the EAPOL packets come over wire, the steps are essentially the same, except that it is easier to perform a physical inventory of boxes connected to your network by wire. The WiFi box may e.g. belong to one of your neighbours. I've also heard a real story of an AP forgotten running behind the furniture.
Theoretically, you should also look into the packet dissection details so that you can see another six hexadecimal digits instead of
AsustekC_, because several MAC address "prefixes" may have been assigned to ASUSTek Computer Inc. over time, so there is an unlikely chance you could have two boxes from Asus which share the second half of the MAC address and differ in the first one.Thanks, you are correct it is a capital "C". Anyways, the packets are saturating our whole private network. I have traced them to originate from our public wifi network...and here's the thing though, they are on a separate vlan, so somehow these packets are breaking through vlan10 to vlan1...which should be impossible, right? or perhaps I've discovered some kind of bug with these switches. And yes I have done my due diligence, I have traced the packets to two ports that are on a separate vlan. When I unplug those two cables the traffic immediately stops on my wireshark trace.
I've converted your post from an Answer to your original Question (which it was not) into a Comment to @Guy Harris' Answer, as this is how this site works.
To the subject: could you post an example pcap file with one such EAPOL frame? The point is that on the wire, the EAPOL packets should have a specific Ethertype value (0x888E), and such value is normally the reason why Wireshark chooses to dissect the frame as EAPOL.
It is also a reason why any switch which is clever enough to support VLANs, and thus should also be clever enough to look at Ethertype and act accordingly, should just drop these EAP frames if it doesn't support 802.1X (or if it is not configured on that particular port), or first encapsulate them into RADIUS packets and only then send them to the authentication server if it does support 802.1X on that port. But forwarding EAP frames as-is is a nonsense even if it would happen inside the port's own VLAN.
So I could imagine that what Wireshark shows you as an "EAPOL" frame is actually something more complex where EAPOL is the topmost application layer, as this is how Wireshark labels the frames in packet list. In such case, the transport layer could be IP, and so the packets could be routed from VLAN1 to VLAN10.
"To post a pcap file" means to publish it, login-free, somewhere like at Cloudshark (preferred by this site's community), Dropbox, Google Drive, ... and provide a link to it here.
Thanks for the help sindy.
Here is a link to my pcap log: https://onedrive.live.com/redir?resid=6BCFFC9886CA2433!35608&authkey=!AE0M5GTqT-CeLAo&ithint=file%2cpcapng
Edit: I should also mention these packets have caused most of our dlink switches to not respond to ping requests, making it extra difficult to find the mac address by port number.
@jrsmith
Your "answer" has been converted to a comment as that's how this site works. Please read the FAQ for more information.
apologies now I get it :-)
OK, so my optimistic assumption that the reason why you can see those frames where you shouldn't is some exotic encapsulation was wrong, and the most likely cause then is that the switch understands neither the specific Ethertype value nor the reserved value of the destination MAC address and forwards the frame as if it was a regular one; as the destination MAC has (logically) never been seen as a source one on any of the ports of the switch, the switch sends the frame to all ports except the one to which it has arrived.
At this point I'm afraid Wireshark has told you all it could, and the only thing more it can help you with is to verify whether your eventual workaround works. So your next stop is the manual of the switch, and the settings I'd look for would be 802.1X (or EAP) configuration, Ethertype filtering, and MAC address filtering, in this exact order.
Another assumption of mine is that the switch only filters by VID (VLAN ID) frames which have Ethertype value 0x8100 (indicating presence of VLAN tag) and adds the VLAN tags only to ingress frames of those Ethertypes it recognizes, and forwards all the other ones regardless the VLAN settings for non-tagged frames on the port (default VLAN ID for non-tagged ingress frames, keep/strip tag for default VLAN's egress frames).
Oh yes, and I'd also give a deep look to the AP which also shouldn't forward EAP frames this way (or maybe generate them itself?).
Well I haven't found the source of the packets (yet), but I found a way to stop the flow to other parts of our network. On the Dlink DGS-1210 series I went to AAA>802.1X>802.1X Global Settings>Forward EAPOL PDU and I changed the radio button to "disabled". Kind of a dangerous thing to be enabled by default in my opinion!
Investigating another issue, I've found some interesting points:
logoff packets may be spoofed (sent with MAC address of someone else as source) with the intention to deny that someone access to the network; the reason why this kind of attack works is that logoff packets are not authenticated. So it could be this if you would use 802.1X in your network - but as you don't, it is rather a broken piece of equipment,
the 802.1X forwarding does make sense where a "clever" switch permits authentication of several client boxes on a single port (and such switches do exist), so dumb, "802.1x transparent" switches may be used to save ports on the clever switch. That way, the core network is protected against unauthorized access as much as 802.1X can protect it, but the individual client boxes at the dumb switch are not protected from one another.