The same feature spec adds a "定向攻击检测" (targeted-attack detection) mechanism: the front-end tracks per-rule (configID) hit counts against a threshold/interval, and once exceeded can throttle or fully suppress emission of RST/block packets and logs for that rule (action codes include "do not send block packets," "sample block packets") -- an explicit rate-limiting countermeasure against the operator's own RST-injection infrastructure being weaponized for reflection/availability attacks, the same attack class (Bock et al., "Weaponizing middleboxes"; "Your censor is my censor") cited in this same lab's own literature survey (see companion finding 2026-mesa-censorship-research-survey-f8c349).
对高命中配置定向攻击进行监测与防护...动作类型: 1:不发日志 2:采样发日志...4:不发FD包 8. 采样发FD包
Defense implications
- The RST-injection/blocking pipeline auto-throttles once a single rule's hit rate crosses an operator-set threshold within a time window -- any technique that tries to induce high-volume RST injection against a third party to weaponize this middlebox (reflection/amplification style) should expect automatic rate suppression rather than sustained amplification.
Related findings
A production feature spec ("加密协议JG") requires detection-and-control capability for QUIC, ESNI, and ECH, with a per-connection log field c_encrypt_type explicitly distinguishing ClientHello encryption (0=unencrypted, 1=ESNI, 2=ECH) and a DF_QUIC_REGION rule table matching QUIC by SNI. The system computes a per-rule "CT" (穿透/penetration) rate from paired mirror-vs-functional RST-packet logs (TF-RST-LOG / TF-MIRROR-RST-LOG) to grade each block rule's effectiveness, and runs continuous active-verification probes against its own rules, deliberately varying the probe 4-tuple each run "to ensure it doesn't hit the blacklist" so the verification traffic itself reaches the target.
An official "Geedge Networks Confidential And Proprietary" sapp/mrzcpd operations manual documents the packet-injection API (MESA_kill_tcp / MESA_inject_pkt) used for both out-of-band mirror-tap RST injection (relies on the local box's own IP routing table to send) and inline in-path injection (requires mrtunnat.conf tunnel-tracking state -- use_recent_tunnel, use_link_info_table -- keyed on outer/inner MAC and link_id/link_dir), plus the Marsio DPDK-based driver's I/O sub-modes (marsio4, marsio_vxlan, pag_marsio, agent_smith) and its role extracting VXLAN/GTP encapsulation metadata and stamping link/circuit identifiers into mirrored packets' MAC field for session-log correlation.
relationship-gtpc-user derives a single per-subscriber correlation key as Hashkey = md5(IMEI + IMSI + phone_number + vsys_id) from mobile-core GTP-C signaling, and a separate per-tunnel key gtp_uuid = md5(uplink_teid + "|" + downlink_teid). On every update it writes not just the primary user<->TEID row (tsg_galaxy:relation_user_teid) but up to four additional secondary-index rows into tsg_galaxy:gtpc_knowledge_base, one per identifier (IMEI, IMSI, phone number, APN) with a type-digit prefix ("0"/"1"/"2"/"3") and — for phone number and APN — the value's characters reversed before use as the row key, a range-scan-friendly key design that lets any of the four identifiers be used to look up the associated tunnel/session independently.
log-subscriber-hbase-datacenter is a Storm topology that, on a 300-second tick, scans a "national center" HBase cluster (national.hbase.zookeeper.servers) for subscriber_id/account rows changed in that window and replicates them into a separate "branch/regional datacenter" HBase cluster (center.hbase.zookeeper.servers, table sub:subscriber_info) — confirming a two-tier, hub-and-spoke data-federation architecture where subscriber-account correlation data is centrally maintained at a national level and periodically pushed down to per-datacenter local copies for regional/site-level querying.
radius-relationship-hbase (galaxy/tsg_olap) builds a bidirectional, MD5-keyed RADIUS accounting index in HBase — a framed-IP-to-account table and its account-to-IP mirror — so any subscriber account or assigned IP can be looked up in O(1) from either direction, per multi-tenant vsys_id. Each direction is fronted by a Guava write-through cache (10M-entry cap, 24h TTL) so lookups do not hit HBase on the hot path.
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.