aboutsummaryrefslogtreecommitdiff
path: root/src/lib/protocols/stun.c
Commit message (Collapse)AuthorAge
...
* LRU cache: move to 64 bits long keys (#2346)Ivan Nardi2024-03-15
| | | | | | Tradeoff between key comparison efficiency (i.e. no `memcmp`) and key length. At least in the ipv4 cases, we have no more different entries with the same key.
* STUN: fix parsing of DATA attribute (#2345)Ivan Nardi2024-03-14
|
* STUN: add a parameter to configure how long the extra dissection lasts (#2336)Ivan Nardi2024-03-07
| | | Tradeoff: performance (i.e. number of packets) vs sub-classification
* Add a specific protocol id for audio/video calls made using Google apps (#2341)Ivan Nardi2024-03-07
| | | Same logic already used for Signal/Whatsapp/Line/Facebook/...
* STUN: fix category when sub-classification is set in "extra-dissection" data ↵Ivan Nardi2024-02-24
| | | | path (#2320)
* Normalization of host_server_name (#2299)Vitaly Lavrov2024-02-05
| | | | | | | | | * Normalization of host_server_name The ndpi_hostname_sni_set() function replaces all non-printable characters with the "?" character and removing whitespace characters at the end of the line. * Added conditional hostname normalization.
* STUN: fix flow risks when DTLS packets are found (#2266)Ivan Nardi2024-01-19
| | | | | When switching to (D)TLS dissector from the STUN one, we need to clear any flow risks set from the latter (because we don't have anymore `NDPI_PROTOCOL_STUN` in the classification results)
* config: move cfg of aggressiviness and opportunistic TLS to the new APINardi Ivan2024-01-18
|
* STUN: fix detection of Google Meet over IPv6 (#2241)Ivan Nardi2024-01-02
|
* Remove Google Hangouts/Duo stuff (#2233)Vladimir Gavrilov2024-01-02
| | | | | * Remove Google Hangouts/Duo support * Update protocols.rst
* STUN: rework extra dissection (#2202)Ivan Nardi2023-12-11
| | | | | | | Keep looking for RTP packets but remove the monitoring concept. We will re-introduce a more general concept of "flow in monitoring state" later. The function was disabled by default. Some configuration knobs will be provided when/if #2190 is merged.
* STUN: parsing of DATA attribute (#2179)Ivan Nardi2023-12-01
|
* STUN: fix detection of DTLS (#2187)Ivan Nardi2023-11-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | Fix a memory leak ``` ==97697==ERROR: LeakSanitizer: detected memory leaks Direct leak of 16 byte(s) in 1 object(s) allocated from: #0 0x55a6967cfa7e in malloc (/home/ivan/svnrepos/nDPI/fuzz/fuzz_ndpi_reader+0x701a7e) (BuildId: c7124999fa1ccc54346fa7bd536d8eab88c3ea01) #1 0x55a696972ab5 in ndpi_malloc /home/ivan/svnrepos/nDPI/src/lib/ndpi_memory.c:60:25 #2 0x55a696972da0 in ndpi_strdup /home/ivan/svnrepos/nDPI/src/lib/ndpi_memory.c:113:13 #3 0x55a696b7658d in processClientServerHello /home/ivan/svnrepos/nDPI/src/lib/protocols/tls.c:2394:46 #4 0x55a696b86e81 in processTLSBlock /home/ivan/svnrepos/nDPI/src/lib/protocols/tls.c:897:5 #5 0x55a696b80649 in ndpi_search_tls_udp /home/ivan/svnrepos/nDPI/src/lib/protocols/tls.c:1262:11 #6 0x55a696b67a57 in ndpi_search_tls_wrapper /home/ivan/svnrepos/nDPI/src/lib/protocols/tls.c:2751:5 #7 0x55a696b67758 in switch_to_tls /home/ivan/svnrepos/nDPI/src/lib/protocols/tls.c:1408:3 #8 0x55a696c47810 in stun_search_again /home/ivan/svnrepos/nDPI/src/lib/protocols/stun.c:422:4 #9 0x55a6968a22af in ndpi_process_extra_packet /home/ivan/svnrepos/nDPI/src/lib/ndpi_main.c:7247:9 #10 0x55a6968acd6f in ndpi_internal_detection_process_packet /home/ivan/svnrepos/nDPI/src/lib/ndpi_main.c:7746:5 #11 0x55a6968aba3f in ndpi_detection_process_packet /home/ivan/svnrepos/nDPI/src/lib/ndpi_main.c:8013:22 #12 0x55a69683d30e in packet_processing /home/ivan/svnrepos/nDPI/fuzz/../example/reader_util.c:1723:31 #13 0x55a69683d30e in ndpi_workflow_process_packet /home/ivan/svnrepos/nDPI/fuzz/../example/reader_util.c:2440:10 #14 0x55a69680f08f in LLVMFuzzerTestOneInput /home/ivan/svnrepos/nDPI/fuzz/fuzz_ndpi_reader.c:135:7 [...] SUMMARY: AddressSanitizer: 16 byte(s) leaked in 1 allocation(s). ``` Found by oss-fuzzer See: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=64564
* Keep separating public and private API (#2157)Ivan Nardi2023-11-29
| | | See: b08c787fe
* STUN: improve demultiplexing of DTLS packets (#2153)Ivan Nardi2023-11-27
| | | | | | Keep demultiplexing STUN/RTP/RTCP packets after DTLS ones. We might end up processing the session a little longer, because we will process the STUN/RTP/RTCP packets after the DTLS handshake.
* Have a clear distinction between public and private/internal API (#2137)Ivan Nardi2023-11-09
| | | | | | 1) Public API/headers in `src/include/` [as it has always been] 2) Private API/headers in `src/lib/` Try to keep the "ndpi_" prefix only for the public functions
* STUN: major code rework (#2116)Ivan Nardi2023-10-30
| | | | | | | | | | | | Try to have a faster classification, on first packet; use standard extra dissection data path for sub-classification, metadata extraction and monitoring. STUN caches: * use the proper confidence value * lookup into the caches only once per flow, after having found a proper STUN classification Add identification of Telegram VoIP calls.
* STUN: fix detection of Google Voip apps (#2031)Ivan Nardi2023-07-05
| | | Fix: 2c7fb9179
* STUN: avoid FacebookVoip false positives (#2029)Ivan Nardi2023-07-03
| | | | Attribute 0xC057 is defined in the Google public implementation of webrtc (which is used by Google products but also by other applications)
* STUN: fix Skype/MsTeams detection and monitoring logic (#2028)Ivan Nardi2023-07-03
|
* STUN: tell RTP from RTCP while in monitoring state (#2027)Ivan Nardi2023-06-27
|
* Hangout: detect Hangout/Duo/GoogleMeet/... in the STUN code (#2025)Ivan Nardi2023-06-27
| | | | | | Regardless of the name, the removed trace doesn't contain meaningful Hangout traffic. Remove last piece of sub-classifiction based only on ip addresses.
* STUN: add dissection of DTLS handshake (#2018)Ivan Nardi2023-06-26
|
* STUN: fix detection over TCPNardi Ivan2023-06-21
| | | | TCP framing is optional
* STUN: improve WhatsappCall detectionNardi Ivan2023-06-21
|
* STUN: keep monitoring/processing STUN flows (#2012)Ivan Nardi2023-06-21
| | | | Look for RTP packets in the STUN sessions. TODO: tell RTP from RTCP
* All protocols should be excluded sooner or later (#1969)Ivan Nardi2023-05-10
| | | | | For a lot of protocols, reduce the number of packets after which the protocols dissector gives up. The values are quite arbitary, tring to not impact on classification
* Add a new protocol id for generic Adult Content traffic (#1906)Ivan Nardi2023-03-20
| | | | The list has been taken from https://www.similarweb.com/top-websites/adult/ Fix a GoTo false positive.
* fuzz: some improvements and add two new fuzzers (#1881)Ivan Nardi2023-02-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove `FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION` define from `fuzz/Makefile.am`; it is already included by the main configure script (when fuzzing). Add a knob to force disabling of AESNI optimizations: this way we can fuzz also no-aesni crypto code. Move CRC32 algorithm into the library. Add some fake traces to extend fuzzing coverage. Note that these traces are hand-made (via scapy/curl) and must not be used as "proof" that the dissectors are really able to identify this kind of traffic. Some small updates to some dissectors: CSGO: remove a wrong rule (never triggered, BTW). Any UDP packet starting with "VS01" will be classified as STEAM (see steam.c around line 111). Googling it, it seems right so. XBOX: XBOX only analyses UDP flows while HTTP only TCP ones; therefore that condition is false. RTP, STUN: removed useless "break"s Zattoo: `flow->zattoo_stage` is never set to any values greater or equal to 5, so these checks are never true. PPStream: `flow->l4.udp.ppstream_stage` is never read. Delete it. TeamSpeak: we check for `flow->packet_counter == 3` just above, so the following check `flow->packet_counter >= 3` is always false.
* Some small changes (#1869)Ivan Nardi2023-01-25
| | | | | | | | All dissector callbacks should not be exported by the library; make static some other local functions. The callback logic in `ndpiReader` has never been used. With internal libgcrypt, `gcry_control()` should always return no errors. We can check `categories` length at compilation time.
* LRU caches: add a generic (optional and configurable) expiration logic (#1855)Ivan Nardi2023-01-18
| | | Two caches already implemented a similar mechanism: make it generic.
* Add protocol disabling feature (#1808)Ivan Nardi2022-12-18
| | | | | | | | | | | | | | | | | | | | | | The application may enable only some protocols. Disabling a protocol means: *) don't register/use the protocol dissector code (if any) *) disable classification by-port for such a protocol *) disable string matchings for domains/certificates involving this protocol *) disable subprotocol registration (if any) This feature can be tested with `ndpiReader -B list_of_protocols_to_disable`. Custom protocols are always enabled. Technically speaking, this commit doesn't introduce any API/ABI incompatibility. However, calling `ndpi_set_protocol_detection_bitmask2()` is now mandatory, just after having called `ndpi_init_detection_module()`. Most of the diffs (and all the diffs in `/src/lib/protocols/`) are due to the removing of some function parameters. Fix the low level macro `NDPI_LOG`. This issue hasn't been detected sooner simply because almost all the code uses only the helpers `NDPI_LOG_*`
* STUN: add detection of ZOOM peer-to-peer flows (#1825)Ivan Nardi2022-12-11
| | | | See: "Enabling Passive Measurement of Zoom Performance in Production Networks" https://dl.acm.org/doi/pdf/10.1145/3517745.3561414
* Make LRU caches ipv6 aware (#1810)Ivan Nardi2022-12-03
| | | | | | | | | | | | | Simplest solution, keeping the existing cache data structure TLS certificate cache is used for DTLS traffic, too. Note that Ookla cache already works with ipv6 flows. TODO: * make the key/hashing more robust (extending the key size?) * update bittorrent cache too. That task is quite difficult because ntopng uses a public function (`ndpi_guess_undetected_protocol()`) intrinsically ipv4 only...
* Remove unused codeNardi Ivan2022-09-28
| | | | | | | | | LRU callbacks have been added in 460ff3c7a, but they have never been used and they have never been extended to the other LRU caches. `ndpi_search_tcp_or_udp()` basically returns the classification by port/ip of the flow; calling it from the dissector is useless. The same for TOR detection: ips are checked in the generic code
* Sizes of LRU caches are now configurableNardi Ivan2022-09-23
| | | | | | | | 0 as size value disable the cache. The diffs in unit tests are due to the fact that some lookups are performed before the first insert: before this change these lookups weren't counted because the cache was not yet initialized, now they are.
* Remove classification "by-ip" from protocol stack (#1743)Ivan Nardi2022-09-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Basically: * "classification by-ip" (i.e. `flow->guessed_protocol_id_by_ip` is NEVER returned in the protocol stack (i.e. `flow->detected_protocol_stack[]`); * if the application is interested into such information, it can access `ndpi_protocol->protocol_by_ip` itself. There are mainly 4 points in the code that set the "classification by-ip" in the protocol stack: the generic `ndpi_set_detected_protocol()`/ `ndpi_detection_giveup()` functions and the HTTP/STUN dissectors. In the unit tests output, a print about `ndpi_protocol->protocol_by_ip` has been added for each flow: the huge diff of this commit is mainly due to that. Strictly speaking, this change is NOT an API/ABI breakage, but there are important differences in the classification results. For examples: * TLS flows without the initial handshake (or without a matching SNI/certificate) are simply classified as `TLS`; * similar for HTTP or QUIC flows; * DNS flows without a matching request domain are simply classified as `DNS`; we don't have `DNS/Google` anymore just because the server is 8.8.8.8 (that was an outrageous behaviour...); * flows previusoly classified only "by-ip" are now classified as `NDPI_PROTOCOL_UNKNOWN`. See #1425 for other examples of why adding the "classification by-ip" in the protocol stack is a bad idea. Please, note that IPV6 is not supported :( (long standing issue in nDPI) i.e. `ndpi_protocol->protocol_by_ip` wil be always `NDPI_PROTOCOL_UNKNOWN` for IPv6 flows. Define `NDPI_CONFIDENCE_MATCH_BY_IP` has been removed. Close #1687
* Dissectors shouldn't update `flow->guessed_host_protocol_id`Nardi Ivan2022-09-14
| | | | | | | | | | | | | | | | The field `flow->guessed_host_protocol_id` is set at the beginning of the flow analysis and it represents the "classification by ip" of the flow itself. This field should never be changed. Dissectors which want to provide an "hint" about the classification, should update `flow->guessed_protocol_id` instead. Such "hint" is useless if the dissector set the "extra-dissection" data-path. Rename such field to `guessed_protocol_id_by_ip` to better describe its role. Preliminary work necessary for #1687
* STUN: several improvementsNardi Ivan2022-09-11
| | | | | | | | | Add detection over TCP and fix detection over IPv6. Rename some variables since Stun dissector is no more "udp-centric". Stun dissector should always classified the flow as `STUN` or `STUN/Something`. Don't touch `flow->guessed_host_protocol_id` field, which should be always be related to "ip-classification" only.
* STUN: improve detection of Hangout/Duo and FB voip callsNardi Ivan2022-07-20
|
* Updated SkypeCall -> Skype_TeamsCallLuca Deri2022-05-26
|
* Make some protocols more "big-endian" friendly (#1402)Ivan Nardi2022-01-29
| | | See #1312
* STUN: fix "confidence" value for some classifications (#1407)Ivan Nardi2022-01-15
|
* Add a "confidence" field about the reliability of the classification. (#1395)Ivan Nardi2022-01-11
| | | | | | | | | | | | | As a general rule, the higher the confidence value, the higher the "reliability/precision" of the classification. In other words, this new field provides an hint about "how" the flow classification has been obtained. For example, the application may want to ignore classification "by-port" (they are not real DPI classifications, after all) or give a second glance at flows classified via LRU caches (because of false positives). Setting only one value for the confidence field is a bit tricky: more work is probably needed in the next future to tweak/fix/improve the logic.
* Update copyrightAlfredo Cardigliano2022-01-03
|
* Improve/add several protocols (#1383)Ivan Nardi2021-12-18
| | | | | | | | | | | | | | | | | | | Improve Microsoft, GMail, Likee, Whatsapp, DisneyPlus and Tiktok detection. Add Vimeo, Fuze, Alibaba and Firebase Crashlytics detection. Try to differentiate between Messenger/Signal standard flows (i.e chat) and their VOIP (video)calls (like we already do for Whatsapp and Snapchat). Add a partial list of some ADS/Tracking stuff. Fix Cassandra, Radius and GTP false positives. Fix DNS, Syslog and SIP false negatives. Improve GTP (sub)classification: differentiate among GTP-U, GTP_C and GTP_PRIME. Fix 3 LGTM warnings.
* Improve IPv6 support, enabling IPv6 traffic on (almost) all dissectors. (#1380)Ivan Nardi2021-12-04
| | | | | | | | | | | There are no valid reasons for a (generic) protocol to ignore IPv6 traffic. Note that: * I have not found the specifications of "CheckPoint High Availability Protocol", so I don't know how/if it supports IPv6 * all LRU caches are still IPv4 only Even if src_id/dst_id stuff is probably useless (see #1279), the right way to update the protocol classification is via `ndpi_set_detected_protocol()`
* Rework how hostname/SNI info is saved (#1330)Ivan Nardi2021-11-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | Looking at `struct ndpi_flow_struct` the two bigger fields are `host_server_name[240]` (mainly for HTTP hostnames and DNS domains) and `protos.tls_quic.client_requested_server_name[256]` (for TLS/QUIC SNIs). This commit aims to reduce `struct ndpi_flow_struct` size, according to two simple observations: 1) maximum one of these two fields is used for each flow. So it seems safe to merge them; 2) even if hostnames/SNIs might be very long, in practice they are rarely longer than a fews tens of bytes. So, using a (single) large buffer is a waste of memory for all kinds of flows. If we need to truncate the name, we keep the *last* characters, easing domain matching. Analyzing some real traffic, it seems safe to assume that the vast majority of hostnames/SNIs is shorter than 80 bytes. Hostnames/SNIs are always converted to lowercase. Attention was given so as to be sure that unit-tests outputs are not affected by this change. Because of a bug, TLS/QUIC SNI were always truncated to 64 bytes (the *first* 64 ones): as a consequence, there were some "Suspicious DGA domain name" and "TLS Certificate Mismatch" false positives.
* Fix writes to `flow->protos` union fields (#1354)Ivan Nardi2021-11-15
| | | | | | | | | | | | | | | | | | | | | | | | | We can write to `flow->protos` only after a proper classification. This issue has been found in Kerberos, DHCP, HTTP, STUN, IMO, FTP, SMTP, IMAP and POP code. There are two kinds of fixes: * write to `flow->protos` only if a final protocol has been detected * move protocol state out of `flow->protos` The hard part is to find, for each protocol, the right tradeoff between memory usage and code complexity. Handle Kerberos like DNS: if we find a request, we set the protocol and an extra callback to further parsing the reply. For all the other protocols, move the state out of `flow->protos`. This is an issue only for the FTP/MAIL stuff. Add DHCP Class Identification value to the output of ndpiReader and to the Jason serialization. Extend code coverage of fuzz tests. Close #1343 Close #1342
* Improved STUN and RTP detectionLuca Deri2021-10-27
|
Powered by cgit, Themed by Ted Yin.