| Commit message (Collapse) | Author | Age |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Adde basidc OS detection based on TCP fingerprint
|
|
|
| |
Extend configuration of raw format of JA4C fingerprint
|
|
|
| |
* Added further memory checks
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
|
|
|
| |
Changed the default to IPv4 (used to be IPv6) in case of DNS error response
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
master or app) is not recognized
|
|
|
|
|
|
|
|
|
|
|
|
| |
bool ndpi_is_proto(ndpi_master_app_protocol proto, u_int16_t p);
bool ndpi_is_proto_unknown(ndpi_master_app_protocol proto);
bool ndpi_is_proto_equals(ndpi_master_app_protocol to_check, ndpi_master_app_protocol to_match, bool exact_match_only);
u_int16_t ndpi_get_proto_by_name(struct ndpi_detection_module_struct *ndpi_mod, const char *name);
char* ndpi_get_proto_by_id(struct ndpi_detection_module_struct *ndpi_mod, u_int id);
extern ndpi_master_app_protocol ndpi_get_protocol_by_name(struct ndpi_detection_module_struct *ndpi_str, const char *name);
Removed (duplicate of ndpi_get_proto_by_name)
int ndpi_get_protocol_id(struct ndpi_detection_module_struct *ndpi_mod, char *proto);
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
|
|
|
| |
If the flow is classified (via DPI) after the first packet, we should
use this information as FPC
|
| |
|
|
|
|
| |
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>
|
| |
|
| |
|
| |
|
| |
|