A Fujian-site performance incident (single-core CPU pinned >90%, packet loss) traced to a large keyword-object list (~400 hex-encoded keywords, described as connected-vehicle-related) being scanned per-packet by components named libmaatframe, librulescan, and fw_http_plug. Removing unused keyword objects resolved the packet loss.
libmaatframe-3.5.3.dd86ba5-1.x86_64 librulescan-2.2.4.865219d-1.x86_64 fw_http_plug-4.0.12.010ebc5-1.x86_64... 用户删除关键字：车联网相关的关键字，大概有400个十六进制的
Defense implications
- Keyword-list scanning has a measurable per-object CPU cost at scale (~400 keywords was enough to pin a core) -- large/regularly-rotated keyword blocklists impose real operational cost on the censor, not just on the circumventor.
Related findings
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.
The GitLab group itself is named "K18_NTCS_WEB" (K18 = Kazakhstan), and its "nfs" web app implements per-protocol keyword-filter configuration classes (App/FTP/Mail/P2P/SSL keyword configs), an OpenVPN IP-list config, RADIUS-based logging/reporting entities, MAAT rule-sync beans, and an explicit "IP spoofing" business feature with its own "PXY仿冒地址池" (proxy spoofed-address pool) and dedicated policy-log support -- the single strongest piece of evidence in this batch tying named keyword-filtering plus IP-spoofing capabilities directly to the Kazakhstan deployment.
MAAT's compiled rule format includes explicit HTTP URL/request-body/response-body matching rule categories (NTC_HTTP_URL, NTC_HTTP_REQ_BODY, NTC_HTTP_RES_BODY) and email content/header matching categories (NTC_MAIL_BODY, NTC_MAIL_HDR), and its scanner backend supports two swappable regex engines -- a Hyperscan adapter (adapter_hs) and a 'Rulescan' adapter (adapter_rs) -- corroborating this corpus's existing understanding that MAAT falls back from Hyperscan to Rulescan above roughly 50K rules.
A crash/perf bug report reveals Geedge's MAAT rule engine (libmaatframe.so, using Intel Hyperscan for literal/regex matching) running with 545,441 FQDN blocking rules and 404,141 IP address blocking rules loaded in a single instance as of 2024; loading 500,000 new FQDN rules via the full Hyperscan path took ~95 minutes, addressed by an automatic fallback to a second engine ("Rulescan") above 50,000 rules.
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 T1/NTC (text-content DPI) node's wired-config manifest (main.conf, dated 2019-01-30) sets REMOTE_DIR=ASTANA/KAZAKHTELECOM/, directly naming Kazakhtelecom — Kazakhstan's dominant state-linked telecom operator — as the carrier context for this K18 deployment. The NTC_MAAT module's EFFECTIVE_FLAG further scopes rules to {location: Astana, isp: Tanstelecom}, naming a second Kazakhstani ISP (Transtelecom) tied to the same deployment.