A raw sapp deployment/config script shows an operator toggling `kickout_udp_stream_enabled=0` to `=1` in sapp.toml (via sed, in place on a live tsg-traffic-engine-vsys-1 install), alongside RPM upgrades of sapp's ssl/firewall/dtls/utable/libmaatframe components, and separately disabling SEND_SESSION_RECORD and SEND_FILE_STREAM_RECORD logging flags in main.conf — confirming sapp has an explicit, operator-toggleable feature to actively terminate UDP streams it flags, independent of whatever passive detection triggered the flag.
sed -ci 's/kickout_udp_stream_enabled=0/kickout_udp_stream_enabled=1/' /opt/tsg/sapp/etc/sapp.toml ... rpm -U .../libmaatframe-4.1.35.580d6fa-1.el8.x86_64.rpm --prefix=/opt/tsg/framework/ ... sed -ci '/TSG_LOG/a SEND_SESSION_RECORD=0' /opt/tsg/sapp/tsgconf/main.conf
Defense implications
- sapp can actively kill a flagged UDP stream mid-session, not just log/report it — any UDP-based transport (QUIC, Hysteria2, raw WireGuard, obfuscated-UDP designs) should assume active mid-flow termination is possible once fingerprinted, and plan a fast fallback to a non-UDP path rather than relying on the stream surviving detection.
Related findings
TSG's Ansible deployment platform ('tsg/tsg-scripts-platform') installs per-protocol firewall RPM modules -- dedicated dns, ftp, http, mail, quic, and ssl packages -- alongside the sapp DPI engine and mrzcpd packet-mirror/inject agent, confirming TSG ships a purpose-built QUIC/HTTP3 blocking module as a first-class protocol-firewall component.
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.
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.
MESA Lab internal debugging notes give the concrete sapp/MAAT config paths and JSON rule schema used for IP-based blocking: /home/mesasoft/sapp_run/TF_conf/TF_tableinfo.conf defines an IP_REGION_INFO table type (ip_plus) with a do_blacklist flag, matched against src/dst IP+port ranges.
Side-by-side internal performance comparison across Xinjiang (China Mobile carrier deployment, hostname cmcc-xj-server1-sapp-244), Fujian (domestic), and Ethiopia (E21) explicitly references the same 'app_sketch_maat' diagnostic log format at all three sites, confirming the identical AppSketch app-fingerprinting stack is used for domestic Xinjiang surveillance and for the exported Ethiopia deployment.
Real TSG session logs from device "XXG-TSG-BJ" (Beijing) show live production blocking of named commercial VPN apps by app-signature: 206 of 213 sampled sessions carry security_action "deny_quarkVPN01" against app field "quarkVPN0622.quarkVPN0619" (destination IPs in Germany, Russia, US, Australia, Bangladesh); a second log from the same device shows security_action "Deny_BeePassvpn" against app-identified BeePass VPN traffic.