| Commit message (Collapse) | Author | Age |
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Follow-up of f56831336334dddcff00eaf2132e5e0f226f0e32: now the
configuration is for flow-risk, not global
|
| |
|
|
|
| |
Co-authored-by: Leonardo Teixeira Alves <leonardo.alves@zerum.com>
|
|
|
|
| |
For the most common protocols, avoid creating the string message if we
are not going to use it
|
|
|
|
| |
Add a new fuzzer to test it
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
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
|
| |
|
|
|
| |
Fix confidence value for same TCP flows
|
|
|
| |
Extend file configuration for just subclassification.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In some scenarios, you might not be interested in flow metadata or
flow-risks at all, but you might want only flow (sub-)classification.
Examples: you only want to forward the traffic according to the
classification or you are only interested in some protocol statistics.
Create a new configuration file (for `ndpiReader`, but you can trivially
adapt it for the library itself) allowing exactly that. You can use it
via: `ndpiReader --conf=example/only_classification.conf ...`
Note that this way, the nDPI overhead is lower because it might need
less packets per flow:
* TLS: nDPI processes only the CH (in most cases) and not also the SH
and certificates
* DNS: only the request is processed (instead of both request and
response)
We might extend the same "shortcut-logic" (stop processing the flow
immediately when there is a final sub-classification) for others
protocols.
Add the configuration options to enable/disable the extraction of some
TLS metadata.
|
| |
|
|
|
|
|
|
|
|
| |
Last step of removing JA3C fingerprint
Remove some duplicate tests: testing with ja4c/ja3s disabled is already
performed by `disable_metadata_and_flowrisks` configuration.
Close:#2551
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
|
|
| |
Updtae pl7m code (Fix swap-direction mutation)
|
|
|
| |
In the same flow, we can have multiple multimedia types
|
| |
|
| |
|
|
|
|
|
| |
* fixes SonarCloud complaint
Signed-off-by: Toni Uhlig <matzeton@googlemail.com>
|
|
|
| |
Add fuzzer to test `ndpi_quick_encrypt()` and `ndpi_quick_decrypt()`
|
|
|
| |
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
|
| |
|
| |
|
|
|
| |
See: 9d07cf281
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
Some fuzzers don't really need a real and complete local context.
Try to avoid setting it up, creating a simpler fake version with only the
features really needed.
That is a kind of experiment: if it works, we can extend the same logic
to other fuzzers
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Updtae pl7m code (fix a Use-of-uninitialized-value error and add GTP
support)
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Moving from 4.8 to 4.10 (and so, from 4.9 to 4.11 for development builds)
made some paths one character longer; that triggers an error with tar
when running `verify_dist_tarball.sh` script:
```
tar: libndpi-4.11.0/fuzz/corpus/fuzz_filecfg_config/flow_risk.anonymous_subscriber.list.protonvpn.load.txt: file name is too long (max 99); not dumped
```
As a quick fix, reduce the length of that file name.
|