| Commit message (Collapse) | Author | Age |
|
|
|
| |
Signed-off-by: Toni Uhlig <matzeton@googlemail.com>
|
|
|
|
|
| |
protocol dissector will follow
Signed-off-by: Toni Uhlig <matzeton@googlemail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Custom rules with *new* protocols are checked "first": if there is a
match, the first packet of the flow provides a complete and final
classification.
The same logic should apply to custom rules with "existing" protocols:
if there is match, nDPI shouldn't do anything else.
Remove the `tcp:3000@ntop` custom rule.
Fix the default port for ElasticSearch (in the protocol file)
|
|
|
|
|
|
|
|
| |
This way, the `ndpiReader` output doesn't change if we change the
internal logic about the order we set/check the various flow risks.
Note that the flow risk *list* is already printed by `ndpiReader`
in order.
|
|
|
|
|
|
|
| |
There are no reasons to keep entropy calculation and sanity checks code
on the "guessing" algorithm.
BTW, this change also fix the entropy calculation for non TCP/UDP/ICMP
flows
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
| |
Signed-off-by: Toni Uhlig <matzeton@googlemail.com>
|
| |
|
|
|
|
|
|
|
|
| |
Some old libpcap versions don't handle pcap files with capture length
bigger than 262144 bytes
```
ERROR: could not open pcap file: invalid interface capture length 524288, bigger than maximum of 262144
```
|
|
|
| |
Close #2738
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
| |
Close #2524
|
| |
|
|
|
|
|
| |
Try to populate the FPC-DNS cache using directly the info from the current
packet, and not from the metadata saved in `struct ndpi_flow_struct`. This
will be important when adding monitoring support
|
| |
|
| |
|
| |
|
| |
|
|
|
| |
We already set the same flow risk for invalid request messages
|
| |
|
|
|
| |
Set the classification in only one place in the code.
|
| |
|
|
|
|
| |
If we have a (potential) valid sub-classification, we shoudn't check for
DGA, even if the subclassification itself is disabled!
|
|
|
|
| |
Prelimary change to start supporting multiple DNS transactions on the
same flow
|
|
|
|
|
| |
We can't write to `flow->protos.dns` until we are sure it is a valid DNS
flow
|
| |
|
| |
|
| |
|
|
|
| |
Fix confidence value for same TCP flows
|
| |
|
|
|
| |
Allow optimal FPC even if DNS subclassification is disabled
|
| |
|
| |
|
|
|
|
|
|
| |
* Rename `NDPI_PROTOCOL_SKYPE_TEAMS_CALL` ->
`NDPI_PROTOCOL_MSTEAMS_CALL`
* Rename ip list from "Skype/Teams" to "Teams"
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
mis-mapping to s3 (#2684)
* JA4: Fix SSL 2 version constant to 0x0002
SSL 2 uses a version field of 0x0002, not 0x0200. This is confirmed not
only in the original Netscape spec [1] and RFC draft of the time [2],
but also in major implementations such as OpenSSL [3] and Wireshark [4].
An earlier version of the JA4 spec [5] also mistakenly used 0x0200 for
SSL 2 and 0x0100 for SSL 1. This was fixed in [6] in August 2024.
[1] https://www-archive.mozilla.org/projects/security/pki/nss/ssl/draft02.html
[2] https://datatracker.ietf.org/doc/html/draft-hickman-netscape-ssl-00
[3] https://github.com/openssl/openssl/blob/OpenSSL_0_9_6m/ssl/ssl2.h#L66-L71
[4] https://github.com/wireshark/wireshark/blob/release-4.4/epan/dissectors/packet-tls-utils.h#L266-L277
[5] https://github.com/FoxIO-LLC/ja4/blob/main/technical_details/JA4.md#tls-and-dtls-version
[6] FoxIO-LLC/ja4#150
* JA4: Remove fictional (and mis-mapped to "s3") SSL 1
SSL 1 was never actually deployed, the design was iterated upon to
become SSL 2 before it was released by Netscape [1] [2] [3] [4]. I
don't think it's public knowledge what the version field for SSL 1 would
have looked like, or if it even was two bytes large or at the same
offset on the wire; given that SSL 2 used 0x0002 it seems more likely to
have been 0x0001 than 0x0100.
Version field 0x0100, that is currently misattributed to SSL 1, was used
by an early pre-RFC4347 implementation of DTLS in OpenSSL before 0.9.8f
[5], when OpenSSL switched to the version field specified by RFC4347.
This use of 0x0100 is also reflected in Wireshark's TLS dissector [4]
(`DTLSV1DOT0_OPENSSL_VERSION`).
For these reasons, it seems to make sense to remove the fictional SSL 1
code entirely.
This also removes an issue where the resulting JA4 string would be "s3"
instead of the intended "s1".
An earlier version of the JA4 spec [6] also mistakenly used 0x0200 for
SSL 2 and 0x0100 for SSL 1. This was fixed in [7] in August 2024.
[1] https://www-archive.mozilla.org/projects/security/pki/nss/ssl/draft02.html
[2] https://datatracker.ietf.org/doc/html/draft-hickman-netscape-ssl-00
[3] https://github.com/openssl/openssl/blob/OpenSSL_0_9_6m/ssl/ssl2.h#L66-L71
[4] https://github.com/wireshark/wireshark/blob/release-4.4/epan/dissectors/packet-tls-utils.h#L266-L277
[5] https://github.com/openssl/openssl/compare/OpenSSL_0_9_8e...OpenSSL_0_9_8f
[6] https://github.com/FoxIO-LLC/ja4/blob/main/technical_details/JA4.md#tls-and-dtls-version
[7] FoxIO-LLC/ja4#150
* Fix tests where old DTLS (0x0100) was mis-identified as SSL 3.0
These two tests contain DTLS flows using a version field of 0x0100 as
used by OpenSSL pre 0.9.8f, before OpenSSL switched to the standardised
version code points for its DTLS implementation. The correct JA4
mapping is "d00", not "ds3".
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
It might be usefull to be able to match traffic against a list of
suspicious JA4C fingerprints
Use the same code/logic/infrastructure used for JA3C (note that we are
going to remove JA3C...)
See: #2551
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Removing JA3C is an big task. Let's start with a simple change having an
huge impact on unit tests: remove printing of JA3C information from
ndpiReader.
This way, when we will delete the actual code, the unit tests diffs
should be a lot simpler to look at.
Note that the information if the client/server cipher is weak or
obsolete is still available via flow risk
See: #2551
|