| 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>
|
|
|
|
| |
For the most common protocols, avoid creating the string message if we
are not going to use it
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
One list is from ingress nodes (used for protocol classification) and
the second one is from exit nodes (used for flow risk check)
|
|
|
| |
Signed-off-by: Toni Uhlig <matzeton@googlemail.com>
|
| |
|
|
|
| |
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
|
|
|
|
| |
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
|
| |
|
| |
|
|
|
|
| |
Updated (C)
|
| |
|
|
|
|
|
|
|
|
| |
No significant changes:
* Move around some fields to avoid holes in the structures.
* Some fields are about protocols based only on TCP.
* Remove some unused (or set but never read) fields.
See #2631
|
|
|
|
|
| |
(#2709)
See: c669bb314
|
| |
|
|
|
| |
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.
|
|
|
| |
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"
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
We calculate HTTP entropy according to "Content-type:" header, see
`ndpi_validate_http_content()` on HTTP code
|
|
|
|
|
|
| |
* detect `chisel` SSH-over-HTTP-WebSocket
* use `strncasecmp()` for `LINE_*` matching macros
Signed-off-by: Toni Uhlig <matzeton@googlemail.com>
|
| |
|
|
|
| |
Add a new variable to keep track of internal partial classification
|
|
|
|
|
| |
Classification "by-port" is the latest possible shot at getting a
classification, when everything else failed: we should always use
the configured ports (as expected by the users, IMO)
|
| |
|
|
|
|
|
| |
ESNI has been superseded by ECH for years, now.
See: https://blog.cloudflare.com/encrypted-client-hello/
Set the existing flow risk if we still found this extension.
|
|
|
|
| |
messages when used to browse (old) network devices
|
| |
|
|
|
| |
In the same flow, we can have multiple multimedia types
|
| |
|
|
|
|
| |
port that was supposed to be used as default
|
| |
|