[Snort-users] Alternatives to matching on source MAC
jtrohm at ...16875...
Mon Jun 23 20:52:59 EDT 2014
Warning: List Noob.
I am looking for an alternate way to match a particular event that needs to
somehow reference the source MAC.
My company has identified a bug in some Kaspersky products that causes the
device to send a DHCP discover message with what appears to be a crafted MAC
address as the source client identifier. After further inspection, it
appears what is really going on is that the software is causing devices to
request DHCP leases for other NICs on the system.
The most common example appears to be Windows 7 Pro laptops that are plugged
in to a wired Ethernet jack. We see DHCP discover messages with a source MAC
of the wired NIC but a client ID of the wireless NIC.
The problem can be fairly easily found by running wireshark on the local
network, capturing "udp port 67" and using the filter:
without the ability to look backward into the L2 header, I'm unsure how to
match this as a Snort rule.
This symptom by itself is more of an annoyance than anything else and isn't
a situation you wouldn't run into under normal circumstances (such as an IP
helper/DHCP forwarder). However, because the packet is malformed and not
handled on return by the PC, the Windows DHCP server perceives this as a
BOOTP request and, absent accounting for this, creates a 30 day lease for
the bogus device. The end result in many cases is effectively to DoS your
network by DHCP pool exhaustion.
Looking for ways to pragmatically alert upon seeing this event.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Snort-users