I have a fairly simple use case. I have a database of devices, which contains a device name, manufacturer, IP addresses, and MAC address. I want to be able to take a device from that database, retrieve the MAC address, and use that to query data that has been generated by BRO.
I have successfully gotten MAC address information into the conn.log by using the roam.bro script linked from another message in this chain and extending the conn.log functionality. But, this is getting the MAC address from the DHCP table. I was hoping to get the MAC address directly from the PCAP file from which the connection object is being generated (at least that is my assumption).
My first thoughts were that the connection object that is being passed into many of these methods would get its information from the PCAP file and I could expand that functionality, but this has been a dead end for me.
Does anyone have advice for getting MAC address from a PCAP file that was used to generate different logs in BRO?
I have successfully gotten MAC address information into the conn.log by using the roam.bro script linked from another message in this chain and extending the conn.log functionality. But, this is getting the MAC address from the DHCP table. I was hoping to get the MAC address directly from the PCAP file from which the connection object is being generated (at least that is my assumption).
My first thoughts were that the connection object that is being passed into many of these methods would get its information from the PCAP file and I could expand that functionality, but this has been a dead end for me.
Bro's concept of connections is based on layer 3 and upwards (its very
TCP-like, sometimes makes it difficult to understand how UDP traffic is
abstracted). In theory layer 2 addresses are independent and might even
vary in the course of a connection. Therefore the question would be:
Which MACs of which packets do you want to log?
In general the raw_packet event (see [1]) provides access to layer 2
addresses. The current master includes a new function called
get_current_packet_header that might be more comfortable to use.
Right now the packet-level functions/events Jan mentioned are the only
option. But we've been kicking around the idea for a while to provide
access to MAC addresses similar to how Bro now makes the VLAN
information accessible as well. It shouldn't be too difficult
actually. If you anybody feels adventurous and wants to give it a try,
I can send some pointers. Otherwise I'm hoping to take a look at that
sometime soonish, but no guarantees.
Another point is that link-layer addresses could change in the course of
a "connection" (see q-in-q.trace for a minimal example). My idea would
be to handle this like the flow label and generate an event once the
addresses change (might be valuable information). I hesitated to
implement this, as this would add per-packet code, which I guess should
only be introduced if really necessary. However, if you are fine with
that extra lines I could add it and merge both solutions.
Best regards,
Jan
P.S.: Seems you forgot to commit your protocols/conn/mac-logging.bro
The main difference is that the MAC addresses follow the
originator/responder pattern, so you could correlate them to IPs.
Yeah, I can see moving them into the endpoints, that also addresses
flipping them if the connection switches roles. If you turn that into
a pull request, I'll merge it in. (I think I'd change the dynamic
allocations for orig/resp_l2_addr to static arrays to avoid the memory
operations.)
Another point is that link-layer addresses could change in the course of
a "connection" (see q-in-q.trace for a minimal example). My idea would
be to handle this like the flow label and generate an event once the
addresses change (might be valuable information).
I'm hesistant on this too, not sure that's common enough to warrant
the extra logic. It's also part of the fundamental issue that Bro's
connection-oriented nature sometimes has trouble reflecting layer-2
semantics (VLANs could in principle change too). So I would skip this
at least until a clear need arises.
P.S.: Seems you forgot to commit your protocols/conn/mac-logging.bro
Yeah, I can see moving them into the endpoints, that also addresses
flipping them if the connection switches roles. If you turn that into
a pull request, I'll merge it in. (I think I'd change the dynamic
allocations for orig/resp_l2_addr to static arrays to avoid the memory
operations.)
I will have a look this week and open a pull request.
Another point is that link-layer addresses could change in the course of
a "connection" (see q-in-q.trace for a minimal example). My idea would
be to handle this like the flow label and generate an event once the
addresses change (might be valuable information).
I'm hesistant on this too, not sure that's common enough to warrant
the extra logic. It's also part of the fundamental issue that Bro's
connection-oriented nature sometimes has trouble reflecting layer-2
semantics (VLANs could in principle change too). So I would skip this
at least until a clear need arises.
I don't know how complex the plugin logic is, but maybe plugins can be
used to support optional layer 2 stuff like this.
