Hello.
I’m using known-services to build a list of observed network conversations and the protocols being used. Known-services detects the TCP conversations, but I want to include UDP conversations as well. Known-services.bro seems to use a global variable, “services”; services, however, does not hold UDP conversation protocol labels. I’ve searched for the script that populates “services”, to no avail.
Where do I find that script? Alternatively, is there a better way to build an all-inclusive conversation vs. protocol mapping?
The service field is a component of DPD (dynamic protocol detection) and the analyzer code in general. You can find the script that actually populates that field here though:
https://github.com/bro/bro/blob/master/scripts/base/protocols/conn/main.bro#L182
That’s going to be a little misleading though because it’s just pulling data from deeper in the connection record into the log. The real story is that this is done as part of DPD where protocols are guessed at with signatures and then a parser is attached. Once the parser positively confirms that the protocol is in fact that protocol that the signature matched then it will indicate the service.
The right way to think about the service field is to think of it as an indicator that a connection was successfully analyzed by a particular analyzer.
.Seth
Thanks, Seth.
That helps a lot. When I run DPD, the various logs show that traffic is being correctly parsed. It seems that the information should appear in conn.log's service column, particularly when DPD is invoked from the command line. This, however, is not the case. What am I overlooking?
Best Regards,
Earl Eiland,
Sr. Cyber Security Engineer,
Emerging Technologies, root9B,
San Antonio, Texas
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity named. If you are not the named addressee you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. Please notify the sender immediately by email if you received this email in error and delete this email from your system. Any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of root9B LLC.
Could you show a little more concretely how you’re running Bro? Ideally you could provide a pcap that shows what you’re seeing although I understand if you’re unable to do that.
.Seth
Unfortunately, we don't have permission to share our test data. However, it is an industrial control system (ICS). Most of the traffic is MODBUS, although we expect to be deploying the detector on ICSs using DNP3 and IEC 61850. In addition to MODBUS, our test data also has some TDS and HTTP traffic, and of course, the usual network management traffic (DNS, ICMP, DHCP, etc.).
ICS traffic tends to be quite regular. Our goal is to develop a detector that can flag a conversation using an anomalous communication protocol.
Best Regards,
Earl Eiland,
Sr. Cyber Security Engineer,
Emerging Technologies, root9B,
San Antonio, Texas
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity named. If you are not the named addressee you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. Please notify the sender immediately by email if you received this email in error and delete this email from your system. Any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of root9B LLC.
Hello, Seth.
the services field in conn.log does report http and dns, so I looked in their sripts for references to the services variable. There doesn't appear to be one, so how is the services variable populated?
Best Regards,
Earl Eiland,
Sr. Cyber Security Engineer,
Emerging Technologies, root9B,
San Antonio, Texas
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity named. If you are not the named addressee you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. Please notify the sender immediately by email if you received this email in error and delete this email from your system. Any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of root9B LLC.
Earl Eiland,
Sr. Cyber Security Engineer,
Emerging Technologies, root9B,
San Antonio, Texas
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity named. If you are not the named addressee you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. Please notify the sender immediately by email if you received this email in error and delete this email from your system. Any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of root9B LLC.
The use of email signature block legal disclaimers is a bit disturbing on a public mailing list.
Chuck