A burst of UDP traffic at a Xinjiang site (Bole-IGW -- Bole is a Xinjiang city, matching gfw.report's identification of Xinjiang as a domestic TSG deployment region) hitting monitor policies drove all packet-processing-core CPU to >99%, exhausting DPDK mbuf buffers and triggering cascading container restarts across ~10 NPB (Network Packet Broker) devices.
Bole-IGW两组共计10个NPB...在00:41左右明显出现udp新建上涨，同时monitor命中也从每秒100~300突增至9k+...触发marsio no mbuf告警导致所有pod重启
Defense implications
- A sudden burst of UDP traffic that heavily triggers monitor/policy hits can overload this system's packet-processing capacity (DPDK mbuf exhaustion) badly enough to crash-loop the traffic-tap hardware itself -- a resource-exhaustion angle distinct from evading individual-signature detection, though likely requires traffic volumes well beyond a single circumvention session.
Related findings
An internal TSG operations/troubleshooting manual lays out TSG's full traffic pipeline (NIC -> mrzcpd/marsio capture driver -> sapp DPI engine -> firewall/proxy(KNI->TFE)/active-defense/WAN-NAT policy branches) and shows engineers using maat_redis_tool to pull the live Redis-synced blocking policy tables (TSG_SECURITY_COMPILE, TSG_OBJ_IP_ADDR, TSG_OBJ_APP_ID) and filter them by numeric policy/object ID to debug why a block rule isn't firing.
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.
An internal "DPI Benchmark" methodology document names the three production components underlying TSG's DPI stack and proposes benchmarking each against open-source equivalents: Marsio (DPDK-based packet I/O) for receive/transmit, Sapp ("网络安全开发平台", a high-speed traffic-processing platform) for protocol parsing and flow-table management, and Maat (Hyperscan-class signature engine with Redis-based multi-machine config sync) for pattern scanning.
TSG ships a built-in offensive "active defense" (主动防御) module named houyi (后羿), built on the sapp/marsio/mrzcpd stack, that performs spoofed-source-IP network-layer flood attacks, DNS/NTP/Memcached reflection-amplification attacks, and application-layer (HTTP/HTTPS) CC floods against a configured target. Spoofed source IPs are drawn from named CIDR-range "profiles" (e.g. 10.1.1.0/24), and policy is distributed via Redis and issued either through an interface called "安天" (Antiy) or by directly calling a "毕方" (Bifang) API. Deployment is via Ansible from git.mesalab.cn/tsg/houyi-deploy, packaged as RPMs installed under /opt/houyi and as sapp plugins under /home/mesasoft/sapp_run/plug.
A crash backtrace from an Ethiopia-site TSG-OS node reveals internal DPI plugin architecture: a core 'sapp' binary (/opt/tsg/sapp/sapp) loads protocol-dissector plugins (dtls, tsg_master.so) chained through a 'marsio4' packet-processing worker, with a KNI/DPDK-style packet path (eth_entry -> ipv4_entry -> vxlan_entry -> gtp_entry -> dtls dissector). The specific bug was an uninitialized DTLS hello-verify cookie field.
The internal 'MAAT网络流处理配置统一描述框架' engineering manual (v3.1.20, author 郑超, 2021) documents MAAT's Redis-synced rule-compilation framework and its RuleScan/Hyperscan-based pattern-matching engine (libmaatframe.so / librulescan), and records that RuleScan's fast-scan feature caused a production outage on 2019-03-19 and has been disabled ever since.