Add new dissector for iris protocol

[BryanProg]

Please sign (check) the below before submitting the Pull Request:

• I have signed the ntop Contributor License Agreement at https://github.com/ntop/legal/blob/main/individual-contributor-licence-agreement.md
• I have read the contributing guidelines at https://github.com/ntop/nDPI/blob/dev/CONTRIBUTING.md
• I have updated the documentation (in doc/) to reflect the changes made (if applicable)

Link to the related issue:

Describe changes:

[IvanNardi]

@BryanProg, thanks for your contribution
Some small adjustments are required; see below.
Can you provide a pcap as example of this new protocol?

[IvanNardi]

@BryanProg , I rework the detection logic (the protocol is found if the message type is valid AND the length is valid too) to avoid the false positives with SSH traffic, and I simplified the pcaps, keeping only the two iris flows.
Do you agree with that?

[BryanProg]

@IvanNardi I agree with you, but the message_type only exists in request packets. When it comes to a response message, the message type is not included. That's why I used the TCP payload length and the Iris header length to check the response messages, hence port 1972. I believe only Iris uses that port by default.

If we continue like this, only request messages will be recognized.

[IvanNardi]

@BryanProg, looking closely at the pcap, it seems that:

• length check can be performed on req and respo boths
• the message type is present only in the requests, but in the responses these two bytes are always zero

With this logic we should be able to detect both directions, without false positives (hopefully)
What do you think?

[I fixed the detection on big endian archs]

[BryanProg]

@IvanNardi These two bytes in the response that you saw are the request's error code. When it is 0 it is because there was success, but I do not know all the other values ​​of the error code and that is why I did not check with this information.

So I compared the size of the iris payload (tpc payload size minus 14bytes which is the iris header) with the information that the iris header brings (the first 4 bytes of the iris header are the size of the iris payload information) and I only took advantage of this protocol (In main use, this protocol only uses port 1972) using this port 1972 with the TCP method. Don't you think that's all it takes? Do you think there could be false positives?

Even if I define that in these cases the nDPI trust is NDPI_CONFIDENCE_MATCH_BY_PORT or NDPI_CONFIDENCE_DPI_PARTIAL??

Thanks for to fix the detection on big endian archs

[IvanNardi]

@BryanProg, let me check if I understood it right.
You are proposing to:

• check only TCP flows on port 1972
• use only the packet length logic
• remove the checks on message types

Is that correct? [BTW, I think that should work...]

[BryanProg]

@IvanNardi

I propose the following:

• Check only TCP flows on port 1972 -> YES

• Use only packet length logic -> More/less. Here we can to use packet length logic AND message type check for REQ messages, but for RESP messages use ONLY packet length logic, as message type check is not available for RESP.

• Remove message type checks -> Yes, But only RESP message. To ignore message type for RESP messages and rely on packet length logic and TCP port == 1972 this cases.

That's it. What do you think?

NOTE: For REQ message to use the message_type lends more confidence to this packet. Because we are certain that it uses the Iris protocol.

[IvanNardi]

@BryanProg, what do you think of the latest version?

[nicmorais]

@BryanProg, what do you think of the latest version?

Greetings Ivan!

I'm a coworker of Bryan. He's on vacation.

One thing: I'd rename the check_msg_type_or_error_code() function to something like iris_check_msg_type_or_error_code(), just to make it clear it is not a common function, but something related only to the Iris protocol. Up to you.

Otherwise, looks good to me.

Also, I think it is worth mentioning the Iris database can be tested for free with the intersystems/iris-community Docker image (in case someone wants to assist in reverse engineering the protocol).

[IvanNardi]

One thing: I'd rename the check_msg_type_or_error_code() function to something like iris_check_msg_type_or_error_code(), just to make it clear it is not a common function, but something related only to the Iris protocol. Up to you.

Done

Also, I think it is worth mentioning the Iris database can be tested for free with the intersystems/iris-community Docker image (in case someone wants to assist in reverse engineering the protocol).

Added to the documentation

Thanks!

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[IvanNardi]

Thanks, everyone!