| Commit message (Collapse) | Author | Age |
... | |
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
* detect `chisel` SSH-over-HTTP-WebSocket
* use `strncasecmp()` for `LINE_*` matching macros
Signed-off-by: Toni Uhlig <matzeton@googlemail.com>
|
|
|
|
|
| |
In very old (G)QUIC versions by Google, the user agent was available on
plain text. That is not true anymore, since about end of 2021.
See: https://github.com/google/quiche/commit/f282c934f4731a9f4be93409c9f3e8687f0566a7
|
| |
|
|
|
|
|
| |
Even if it is only the proposed value by the client (and not the
negotiated one), it might be use as hint for timeout by the (external)
flows manager
|
| |
|
|
|
| |
In the same flow, we can have multiple multimedia types
|
|
|
|
| |
Let's see if we are able to tell audio from video calls only looking at
RTP Payload Type field...
|
|
|
|
| |
Implemented Mikrotik JSON serialization
|
|
|
|
| |
Testing pcaps courtesy of https://github.com/virtalabs/tapirx.git
|
|
|
|
| |
(#2618)
|
| |
|
| |
|
|
|
| |
Extend configuration of raw format of JA4C fingerprint
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
| |
as follows:
ndpiReader --cfg=dpi.address_cache_size,1000 -i <pcap>.pcap
In the above example the cache has up to 1000 entries.
In jcase ndpiReader exports data in JSON, the cache hostname (if found) is exported in the field server_hostname
|
| |
|
|
|
| |
wireshark, lua: add basic analysis of possible obfuscated flows
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Example:
./example/ndpiReader -i tests/pcap/safari.pcap --cfg=tls,metadata.ja4r_fingerprint,1
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
| |
The Train Real Time Data Protocol (TRDP) is a UDP/TCP-based communication protocol designed for IP networks in trains, enabling data exchange between devices such as door controls and air conditioning systems. It is standardized by the IEC under IEC 61375-2-3 and is not related to the Remote Desktop Protocol (RDP).
|
|
|
|
|
|
|
| |
See also #2523
---------
Co-authored-by: Nardi Ivan <nardi.ivan@gmail.com>
|
|
|
| |
ISO/IEC 14908-4 defines how to tunnel Control Network Protocol (CNP) over IP networks. It encapsulates protocols like EIA-709, EIA-600, and CNP, making it a versatile solution for building automation and control systems.
|
| |
|
|
|
|
| |
Add printing of fpc_dns statistics and add a general cconfiguration option.
Rework the code to be more generic and ready to handle other logics.
|
|
|
|
|
|
|
|
|
| |
Use DNS information to get a better First Packet Classification.
See: #2322
---------
Co-authored-by: Nardi Ivan <nardi.ivan@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix detection of WebDAV and Gnutella (over HTTP)
Fix detection of z3950
Add two fuzzers to test `ndpi_memmem()` and `ndpi_strnstr()`
Remove some dead code:
* RTP: the same exact check is performed at the very beginning of the
function
* MQTT: use a better helper to exclude the protocol
* Colletd: `ndpi_hostname_sni_set()` never fails
Update pl7m code (fix a Use-of-uninitialized-value error)
|
|
|
| |
See: #2484
|
|
|
| |
Signed-off-by: Toni Uhlig <matzeton@googlemail.com>
|
|
|
|
|
| |
Since 070a0908b we are able to detect P2P calls directly from the packet
content, without any correlation among flows
|
| |
|
|
|
|
|
|
|
|
|
|
| |
After a flow has been classified as RTP or RTCP, nDPI might analyse more
packets to look for STUN/DTLS packets, i.e. to try to tell if this flow
is a "pure" RTP/RTCP flow or if the RTP/RTCP packets are multiplexed with
STUN/DTLS.
Useful for proper (sub)classification when the beginning of the flows
are not captured or if there are lost packets in the the captured traffic.
Disabled by default
|
| |
|
|
|
|
|
|
| |
RFC4571 is not the only way to wrap RTP messages in TCP streams.
For example, when RTP is encapsulated over TURN flows (i.e. via DATA
attribute) there is no additional framing.
See also 6127e0490
|
|
|
| |
Signed-off-by: Toni Uhlig <matzeton@googlemail.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
Removed
- int ndpi_load_ipv4_ptree_file(ndpi_ptree_t *tree, const char *path, u_int16_t protocol_id);
- int ndpi_load_ipv6_ptree_file(ndpi_ptree_t *tree, const char *path, u_int16_t protocol_id);
Added (it supports both IPv4 and v6)
+ int ndpi_load_ptree_file(ndpi_ptree_t *tree, const char *path, u_int16_t protocol_id);
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
There is some overlap between RTP and Raknet detection: give precedence
to RTP logic.
Consequences:
* Raknet might require a little bit more packets for some flows (not a
big issue)
* some very small (1-2 pkts) Raknet flows are not classified (not sure
what do do about that..)
|
| |
|
| |
|