A MESA engineer wrote a SAPP business-layer plugin (v1 shipped to GitLab) that fingerprints network scanning/probing tools, producing a "scanning/probing tool fingerprint-database construction report." The companion fingerprint report documents Nmap's default host-discovery probe sequence (ICMP echo request, TCP SYN to port 443, TCP ACK to port 80, ICMP timestamp request) captured against a live target.
在SAPP上编写业务层插件,实现扫描器识别,完成V1版代码...扫描探测工具指纹库构建报告,上传至mesalab
Defense implications
- TSG/SAPP maintains a fingerprint database purpose-built to identify scanning/measurement tools by their probe-burst signature (e.g. Nmap's 4-packet host-discovery pattern) -- any Lantern-side active health-check or measurement traffic resembling a multi-probe host-discovery burst risks being flagged and treated differently by the gateway.
Related findings
A user manual for a 'Malicious Service IPv6 Address Discovery and Assessment System' documents a sapp application-layer plugin (ipv6_domain.c) that extracts the HTTP Host header, TLS SNI, and DNS AAAA-record domain from live traffic and matches them against a malicious/blocked-domain list to resolve each hit's IPv6 address, alongside a separate active-probing pipeline (ZMapv6 + Entropy/IP-based address-space generation) used to discover IPv6 DNS resolvers and malicious-site IPv6 presence at internet scale.
Crash-dump stack traces reveal TSG's core packet-processing engine (sapp) architecture: a custom multi-threaded C engine using 'marsio' as the DPDK-style packet-I/O driver, a plugin system for protocol handlers (confirmed: plug/protocol/http/http.so), and a libdocumentanalyze component that actively decompresses gzip content and parses ZIP/document formats found inside HTTP bodies -- i.e. inspection goes beyond headers into reconstructed application content.
TSG implements heuristic tunnel-protocol detection distinguishing Teredo (IPv6-over-UDP, default port 3544) from GTP tunneling based on UDP payload inspection, used to decide 'innermost' session attribution for firewall matching.
A June 2021 internal report measures a live in-network TLS-interception pilot: one sapp instance ingests raw ciphertext via mrzcpd while a second ingests plaintext from a "third-party decryption platform" over a Unix domain socket, and one hour of production traffic on a live front-end (10.187.0.2) shows the decryption platform successfully produced plaintext for 4.85% of raw traffic bytes and 7.4% of all port-443 TCP connections, with an average end-to-end decrypt latency of 1741ms (median 460ms, up to 6000ms) between first ciphertext byte and the resulting plaintext HTTP GET.
sapp's plugin API exposes explicit enforcement primitives -- MESA_kill_tcp()/MESA_rst_tcp() to inject a single RST, and MESA_set_stream_opt() with MSO_TCP_RST_REMEDY/MSO_DROP_STREAM to make RST-injection or packet-dropping persist for the remaining lifetime of a flow -- with a global sapp.toml auto_remedy toggle and a per-stream option controlling whether a lone RST is reinforced repeatedly for as long as the flow keeps sending data.
An internal "sapp" developer guide (marked "Geedge Networks Confidential And Proprietary") documents that MESA's core DPI/traffic-processing platform has gone through four generations since roughly 2005 -- start -> papp -> sappv3 -> sappv4 -- with sappv4 (introduced 2019) now the sole actively maintained branch, while some sappv3 deployments still run unless a critical bug forces an upgrade.