Is the "service" field of the connection record unreliable?

Zeek
1

Hi everyone,

I have a question for the "service" field in the connection record. When I run the "testing/btest/Traces/modbus/modbus.trace" in the bro repo, it contains "MODBUS" for most of the connections except for a few. However, when I run the "testing/btest/Traces/modbus/modbusBig.pcap" trace, all of the connections have empty service fields although they are all using Modbus. The connection record I used is from the new_packet event. Does this mean the service field is quite unreliable and cannot be used to tell the service of the connection?

If I need to directly use the destination port to identify the service type, there might be other problems. For example, sometimes the destination port contained in the "id" tuple in the connection record is actually the source port. This is probably due to the connection re-establishment from the receiver side. An example can be seen in the highlighted packet in the attached screenshot (which is from the "modbus.trace" in the repo).

So my question is what's the best way to get the service of the connection from Bro. Any help and idea are appreciated. Thanks in advance.

Best,
Wenyu

Wenyu Ren
Ph.D. Candidate
Department of Computer Science
University of Illinois at Urbana-Champaign

Screenshot from 2017-06-06 14-52-51.png
Screenshot from 2017-06-06 14-52-51.png934×242 53.7 KB

2

For the service field to be filled out, there are two things that are
required. First, the relevant analyzer needs to be attached to
attached to the connection, but the modbus analyzer is only port
based. There is no signature for attaching the modbus analyzer to
connections (i.e., DPD/dynamic protocol detection) because I wasn't
able to write one that would identify modbus reliably. Secondly, the
analyzer itself has to confirm that it does in fact appear to be
analyzing the protocol. The modbus analyzer doesn't identify the
protocol as being modbus until both sides have sent modbus messages.
I suspect that you aren't seeing modbus show up as a service because
both sides aren't speaking modbus (scanners will have this problem
since they just connect to random stuff and send modbus messages).

We can certainly debate if that's the right way to do it or if only
one side sending a valid modbus message should be enough to identify
modbus. I can see the argument there for treating it that way.

  .Seth