| Commit message (Collapse) | Author | Age |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Adde basidc OS detection based on TCP fingerprint
|
|
|
| |
Extend configuration of raw format of JA4C fingerprint
|
|
|
| |
Build fix
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allow nDPI to process the entire flows and not only the first N packets.
Usefull when the application is interested in some metadata spanning the
entire life of the session.
As initial step, only STUN flows can be put in monitoring.
See `doc/monitoring.md` for further details.
This feature is disabled by default.
Close #2583
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Changed the default to IPv4 (used to be IPv6) in case of DNS error response
|
|
|
|
| |
Padding is usually some hundreds byte long. Longer padding might be used
as obfuscation technique to force unusual CH fragmentation
|
|
|
|
| |
Allocate heuristics state only if really needed.
Fix memory leak (it happened with WebSocket traffic on port 443)
|
|
|
|
|
|
|
|
| |
Add configurable options for whether to include client port or client IP
in the flow's protocol guesses. This defaults to include both client
port/IP if the protocol is not guessed with the server IP/port.
This is intended for when flow direction detection is enabled, so we
know that sport = client port, dport = server port.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Based on the paper: "Fingerprinting Obfuscated Proxy Traffic with
Encapsulated TLS Handshakes".
See: https://www.usenix.org/conference/usenixsecurity24/presentation/xue-fingerprinting
Basic idea:
* the packets/bytes distribution of a TLS handshake is quite unique
* this fingerprint is still detectable if the handshake is
encrypted/proxied/obfuscated
All heuristics are disabled by default.
|
| |
|
| |
|
| |
|
|
|
|
| |
Add dpi.guess_ip_before_port which when enabled uses classification
by-ip before classification by-port.
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Revert "Added fix for handling Server Hello before CLient Hello"
This reverts commit eb15b22e7757cb70894fdcde440e62bc40f22df1.
* TLS: add some tests with unidirectional traffic
* TLS: another attempt to process CH received after the SH
Obviously, we will process unidirectional traffic longer, because we are
now waiting for messages in both directions
|
| |
|
| |
|
|
|
|
|
|
| |
"Invalid DNS Header"-risk should be set only if the flow has been
already classified as DNS. Otherwise, almost any non-DNS flows on port 53
will end up having the `NDPI_MALFORMED_PACKET` risk set, which is a little
bit confusing for non DNS traffic
|
|
|
|
|
|
|
|
|
|
|
|
| |
Based on the paper: "OpenVPN is Open to VPN Fingerprinting"
See: https://www.usenix.org/conference/usenixsecurity22/presentation/xue-diwen
Basic idea:
* the distribution of the first byte of the messages (i.e. the distribution
of the op-codes) is quite unique
* this fingerprint might be still detectable even if the OpenVPN packets are
somehow fully encrypted/obfuscated
The heuristic is disabled by default.
|
| |
|
| |
|
|
|
|
| |
We can do definitely better, but this change is a big improvements
respect the current broken code
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Allow sub-classification of OpenVPN/Wireguard flows using their server IP.
That is useful to detect the specific VPN application/app used.
At the moment, the supported protocols are: Mullvad, NordVPN, ProtonVPN.
This feature is configurable.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
(#2541)
Signed-off-by: Toni Uhlig <matzeton@googlemail.com>
|
| |
|
|
|
|
|
|
|
| |
On extra-dissection data-path we only need to look for the hash (the
flow is already classified as Bittorrent).
As a nice side-effect, the confidence is now always with the right
value.
|
| |
|
| |
|