A 2024-05-17 MESA Lab / field-deployment engineering meeting documents MAAT's live rule-config pipeline in operational detail: a hard cap of 4096 hit results per query, incremental sequence-numbered config deltas reloaded on top of the last full snapshot, a documented "hit vacuum period" during config reload where partially-loaded rules silently fail to match, and separate JSON (test-only, small-scale) vs. Excel-tool-generated (production) config-authoring workflows.

certstore's own commit history documents its transparent-TLS-MITM mechanics directly: it writes the client's observed SNI into the SAN field of the leaf certificate it mints on the fly, supports ECC issuance (secp192r1/secp256r1) for those forged certs, and reads its Trusted/Untrusted decryption-keyring configuration from MAAT's DECRYPTION_KEYRING table -- confirming the interception pipeline end-to-end: client SNI in, matching forged certificate out, gated by MAAT-synced keyring policy.

Internal engineering docs detail MAAT's config/policy hierarchy (region/policy-unit -> group/policy-object -> compile/policy, a conjunctive-normal-form structure capped at 8 top-level groups), its Redis-backed one-master-many-replica config push ("MAAT Redis") with a rulescan fallback, and confirm MAAT runs non-distributed -- one instance per front-end traffic-scanning box -- invoked by sapp per-packet or per-stream (Maat_stream_scan_string_detail) with match-all-then-return semantics; recommended hardware is CentOS 7, 256GB RAM, 2TB disk, 48-core Xeon E5.

The liuxueli/install-standalone-redis repo shows MAAT's Redis config-distribution backbone deployed as a 3-tier replication topology (redis-master, redis-global-slave, redis-global-slave-master) with dedicated systemd services and a MAAT_PRE_VER initialization variable, confirming Redis is provisioned specifically as MAAT's live rule-sync layer rather than as general-purpose caching.

The MAAT rule-engine's native C initialization API (MAAT_INIT_OPT enum) confirms Redis-backed live config sync (MAAT_OPT_REDIS_IP/PORT/INDEX, with a cumulative-update mode), matching the taxonomy's maat_redis_tool description, and exposes a MAAT_OPT_ACCEPT_TAGS mechanism for attaching arbitrary JSON metadata tags -- the documented example tags a deployment with a specific Beijing district location and an ISP name.

IPReuse/mgw is a C++ NAT gateway (DNAT/SNAT) built by an IIE engineer that includes a vpn_monitor module which periodically polls a VPN server to resolve the current IP-to-user mapping, and integrates directly with the MAAT rule engine via a maat_redis handle (test_maat_redis.cpp, vendored maat-v2.3.3.tar.gz) — an early (2018) implementation of tying network-layer IP addresses to individual VPN user identity for policy purposes.

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.