| Commit message (Collapse) | Author | Age |
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Minor fixes
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
| |
wireshark, lua: add basic analysis of possible obfuscated flows
|
| |
|
| |
|
|
|
|
|
|
|
| |
Avoid forcing `DLT_EN10MB` but use the same data link type of the input
pcap.
This way, we can use extcap functionality with input traces having Linux
"cooked" capture encapsulation, i.e. traces captured on "any" interface
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Export some metadata (for the moment, SNI and TLS fingerprints) to
Wireshark/tshark via extcap.
Note that:
* metadata are exported only once per flow
* metadata are exported (all together) when nDPI stopped processing
the flow
Still room for a lot of improvements!
In particular:
* we need to add some boundary checks (if we are going to export other
attributes)
* we should try to have a variable length trailer
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
```
ivan@ivan-Latitude-E6540:~/$ tshark -C "nDPI extcap" -i ndpi -o extcap.ndpi.i:/home/ivan/svnrepos/nDPI/tests/pcap/anydesk.pcapng -Y "ndpi.protocol.name contains DNS"
Capturing on 'nDPI interface: ndpi'
62 22635386.425683 192.168.1.187 DNS.AnyDesk 192.168.1.1 128 Standard query 0xec22 A relay-3185a847.net.anydesk.com
63 22635386.439540 192.168.1.1 DNS.AnyDesk 192.168.1.187 144 Standard query response 0xec22 A relay-3185a847.net.anydesk.com A 37.61.223.15
64 22635386.721277 192.168.1.187 DNS.AnyDesk 192.168.1.1 128 Standard query 0xea89 A relay-9b6827f2.net.anydesk.com
65 22635386.732444 192.168.1.1 DNS.AnyDesk 192.168.1.187 144 Standard query response 0xea89 A relay-9b6827f2.net.anydesk.com A 138.199.36.115
4 packets captured
```
|
|
|
|
|
| |
Not sure when we (or Wireshark, or Lua...) broke it, but we can't call
tonumber() on Bool variables.
|
| |
|
|
|
|
|
| |
* Use a proper TVB to parse the nDPI trailer
* Fix some flow risks definitions
|
| |
|
|
|
|
| |
Modified NDPI_BINARY_TRANSFER_ATTEMPT in NDPI_BINARY_DATA_TRANSFER
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
A fully encrypted session is a flow where every bytes of the
payload is encrypted in an attempt to “look like nothing”.
The heuristic needs only the very first packet of the flow.
See: https://www.usenix.org/system/files/sec23fall-prepub-234-wu-mingshi.pdf
A basic, but generic, inplementation of the popcpunt alg has been added
|
|
|
|
|
|
|
|
|
|
| |
RFC 6066 3: "Literal IPv4 and IPv6 addresses are not permitted in
"HostName"."
Don't set this risk if we have a valid sub-classification (example:
via certificate)
Since a similar risk already exists for HTTP hostnames, reuse it, with a
more generic name.
|
| |
|
|
|
|
| |
about issues found on traffic.
|
| |
|
|
|
|
| |
are supported
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main goal of a DPI engine is usually to determine "what", i.e. which
types of traffic flow on the network.
However the applications using DPI are often interested also in "who",
i.e. which "user/subscriber" generated that traffic.
The association between a flow and a subscriber is usually done via some
kind of DHCP/GTP/RADIUS/NAT mappings. In all these cases the key element
of the flow used to identify the user is the source ip address.
That usually happens for the vast majority of the traffic.
However, depending on the protocols involved and on the position on the net
where the traffic is captured, the source ip address might have been
changed/anonymized. In that case, that address is useless for any
flow-username association.
Example: iCloud Private Relay traffic captured between the exit relay and
the server.
See the picture at page 5 on:
https://www.apple.com/privacy/docs/iCloud_Private_Relay_Overview_Dec2021.PDF
This commit adds new generic flow risk `NDPI_ANONYMOUS_SUBSCRIBER` hinting
that the ip addresses shouldn't be used to identify the user associated
with the flow.
As a first example of this new feature, the entire list of the relay ip
addresses used by Private Relay is added.
A key point to note is that list is NOT used for flow classification
(unlike all the other ip lists present in nDPI) but only for setting this
new flow risk.
TODO: IPv6
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add detection of AccuWeather site/app and Google Classroom.
Improve detection of Azure, Zattoo, Whatsapp, MQTT and LDAP.
Fix some RX false positives.
Fix some "Uncommon TLS ALPN"-risk false positives.
Fix "confidence" value for some Zoom/Torrent classifications.
Minor fix in Lua script for Wireshark extcap.
Update .gitignore file.
Let GitHub correctly detect the language type of *.inc files.
Zattoo example has been provided by @subhajit-cdot in #1148.
|
|
|
|
| |
Added ndpi_set_tls_cert_expire_days() API call to modify the number of days for triggering the above alert that by default is set to 30 days
|
|
|
|
| |
named NDPI_POSSIBLE_EXPLOIT
|
|
|
| |
Signed-off-by: Toni Uhlig <matzeton@googlemail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Add files via upload
* Add files via upload
* Add files via upload
* Add files via upload
* Add files via upload
* Add files via upload
* Add files via upload
* Add files via upload
* Add files via upload
* Add files via upload
* Add files via upload
* Add files via upload
* Add files via upload
* Add files via upload
* Add files via upload
Co-authored-by: Luca Deri <lucaderi@users.noreply.github.com>
|