Kazakhstan

pangu_valve.conf explicitly binds the 'PanguValve' traffic-control daemon (阀门, ASMIS_PROC_NAME=Pangu/PanguValve) to the Astana, Kazakhstan (K18) site — REMOTE_DIR=ASTANA and a MAAT_EFFECTIVE_RANGE tag of location=Astana — and configures it to receive live rule updates from a MAAT Redis backend rather than static files, tying this enforcement component directly to a real-time MAAT rule-dispatch pipeline at a named export deployment.

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.

The tango/adc_hardware repo ([email protected], 2019-2021) contains a dedicated "K18 演示环境交换板配置" (K18 demo-environment switch board config) commit and a nezha_monitor_K18/ directory of NEZHA monitoring dashboards/alert rules for "ADC" hardware. This is direct evidence that Geedge's ADC compute-board hardware line (documented elsewhere as used for the Pakistan/WMS-UTR site) is also deployed for the K18 (Kazakhstan) site.

A recurring weekly 'Tiangou Secure Gateway — Server IP and Location of Overview' report, spanning Jan 2023 through Jan 2024 in this batch alone, tracks per-app top server IPs/geolocations/bytes for named foreign platforms (Instagram, Netflix, Reddit, Skype, Pinterest, Quora, Line, Likee, Medium, Pandora). Top consumer-side IP rows consistently resolve to Kazakhstan cities (Almaty, Pavlodar, Nur-Sultan/Astana), matching the K18 site codename. Processed-row counts grow roughly 10x over the year (889B rows/week in Jan 2023 to 9.4T rows/week in Jan 2024), and one instance reports Total Bytes Transferred of 14.66 PB and an average of 218.34 Gbps for a single week.

A custom Prometheus-backed infrastructure-monitoring platform (MySQL schema dumped from source "nz-prometheus", schema "nz-temp", dated 2020-10-16) has its sys_area reference table seeded with exactly the five Kazakhstan cities named in the K18 site-codename entry — Aktau, Almaty, Nur-Sultan (the pre-2022 name for Astana), Karaganda, and Zhezkazgan — and a companion live alert-message dump (dated Nov 2020) shows real "endpoint down" P2 alerts tagged Data center: Nur-Sultan / Aktau, Project: ADC, across modules named MXN-NODE and MCN0-3-NODE/SRV, pushing the earliest confirmed evidence of the K18 Kazakhstan deployment back to at least October-November 2020.

Commit history for the K18 (Kazakhstan) argus-ntc console reveals its concrete feature set: a scheduled "网页关键字定时器" (webpage-keyword timer/scheduler) for keyword filtering, ASN/IP block-list configuration pages, a "BGP泛收" (BGP wide-collection) page, an SSL-interception config toggle, a file-scanning results page with MALWARE TYPE/MALWARE NAME columns, app-identification entries including a WhatsApp rename, and a VoIP business-config approval workflow, with blocking actions relabeled from "阻断" (block) to "封堵(丢弃)" (interdict/drop).

tsg/cli-deploy is an Ansible deployment repo for "tsg-cli" host monitoring (tsg-monitor service, rsyslog forwarding) targeting named production hosts, including hosts.astana and astana_ADC_IPlist_V1.xlsx, with a commit explicitly adding "astana部署环境IP" (Astana deployment-environment IPs) and a later branch for reading ADC hardware chassis IDs into the device serial-number scheme — concrete deployment evidence for the K18 (Kazakhstan, Astana) site.

The "comm_audit" (通信审计, communications audit) C++ tool ships a country-specific MaxMind GeoIP database file, db/Kazakhstan_v4.mmdb, alongside generic all_ip_info_v4.mmdb/all_ip_only_coun_v4.mmdb databases, directly tying this MESA Lab traffic-audit component to a Kazakhstan deployment (matches the K18 site codename).

Production network-topology docs for the Astana and Almaty (Kazakhstan / K18) sites show a live decrypted-traffic forwarding pipeline between an ADC front-end and an ASEM front-end over a direct fiber link, plus a distinct 'IP Spoofing' business function and dedicated static/dynamic proxy interception business lines, and a certificate-management endpoint (port 9991) — confirming operational TLS interception (MITM) infrastructure in production, not just lab capability, at both K18 sites.

The AV/frag_monitor tool (headers AV_kill_connection.h + Maat_rule.h/Maat_command.h, i.e. a MAAT-integrated flow classifier with active connection-termination capability) ships per-deployment JSON templates including frag_monitor_k_online.json — explicitly defaulted to "K project" per a 2018-12 commit, matching taxonomy's K18/Kazakhstan site codename — plus a dedicated frag_monitor_k_online_youtube.json template and a "zhongxin" (中信)-named template, indicating per-target (YouTube) and per-site blocking profiles built on top of an active kill-connection primitive.

A Kazakhstan-specific push service (galaxy/K18/galaxy-push-service) tracks per-geographic-area protocol blocking (AreaBlockProtocol, BlockingArea, EventsBlock domain classes) and pushes Top-N blocking analytics on a schedule, indicating K18's blocking is administered and reported at sub-national (area) granularity rather than applied uniformly nationwide.

The Galaxy Trouble Shooting API's versioned Postman test-collection repo added a Kazakhstan-specific test environment file ("kz_postman.postman_environment.json") in the v20.11-rc3 release, with a commit message "add kz enviroment" dated 2020-12-19 -- direct engineering evidence that Kazakhstan (K18) was an active customer/test target for this platform API by December 2020, earlier than other dated evidence for the K18 relationship elsewhere in this corpus.

A recurring weekly 'Tiangou Secure Gateway / Server IP and Location of Overseas APP' report series tracks per-app server-IP geolocation for Instagram, Snapchat, Telegram, and Likee traffic, with entries repeatedly geolocated to Almaty, Pavlodar, and Nur-Sultan, Kazakhstan across late 2023-early 2024 -- consistent with (though not conclusive proof of on its own, given ambiguity over whether the geolocated IPs are CDN edge nodes or another artifact) an operating Kazakhstan TSG deployment continuously monitoring named social/messaging platforms.

An internal 'Data Platform Cluster Deployment Document' (数据平台集群部署文档) for the Galaxy component (Hadoop/HBase/Kafka/Storm/Zookeeper stack, package galaxy_component_install) explicitly names a 'KZ项目' (KZ Project) with its own pre-prepared regional config directory 'config-KZ' and a per-site config file 'component-NUR.conf', and instructs deployers to set the host timezone to Asia/Almaty -- direct internal confirmation of a Kazakhstan deployment matching the leak's K18 codename.

TSG's "IP Learning" subsystem (wanglihui/ip-learning-graph, ArangoDB + Spark/Java) builds a Subscriber-IP-FQDN correlation graph (vertices Subscriber/Ip/Fqdn; relationships LocateSubscriber2Ip, LocateFqdn2Ip, VisitIp2Fqdn) fed by RADIUS session-activity data, and its commit history documents a dedicated "tsg kz" (Kazakhstan) build, directly tying this subscriber-identity correlation infrastructure to the K18 Kazakhstan deployment.

The BaiyangLi/IPLocator repo, a fork of the open-source libmaxminddb library, ships purpose-built db/v4/Kazakhstan_v4.mmdb and db/v6/Kazakhstan_v6.mmdb databases alongside generic all-IP databases, indicating a Kazakhstan-specific IP geolocation database was built for internal tooling -- consistent with the K18/Kazakhstan deployment documented elsewhere in this corpus.

K18_NTCS_WEB/argus-ntc is a large (4,879-file, 3,454-commit) Java/JSP web management console, GitLab-namespaced under "K18" (Kazakhstan), backed by a database literally named "argus_ntc", with UI internationalization files maintained in both Chinese and Russian. This is direct, sustained (2019+) evidence of a dedicated customer-facing management console built specifically for the Kazakhstan deployment, distinct from the generic TSG-web frontend.

The same K18-labeled platform (argus-service/maat_service) defines dedicated log tables and paired monitor/block business-rule IDs for face recognition (人脸识别, rule 0x10E/0x18E), speaker recognition (说话人识别, 0x10C/0x18C), TV-channel logo/watermark detection (台标识别, 0x10D/0x18D), and porn image/audio/video level scoring (MmPornVideoLevelLog, MmPornAudioLevelLog, MmSamplePicLog) — a biometric/media-content-classification capability distinct from conventional protocol-level DPI, with a monitor variant and a separate block variant for each rule.

The 'PanGu/DeployEnv' repository's Kazakhstan production configuration is literally named with the leak's 'K18' site codename (k18_consul_kv snapshot) and documents parallel Astana and Almaty (backup) deployments -- including a 'national proxy' decrypted-traffic-forwarding receiver, dual-site TLS certificate management, and Consul/Telegraf/Grafana service topology -- directly confirming K18 = Kazakhstan with deployment-architecture detail beyond the taxonomy's site list.

The same K18 (Kazakhstan) Galaxy-service backend defines log entities for automated multimedia content analysis -- porn-content audio/video level classification (MmPornAudioLevelLog/MmPornVideoLevelLog), face recognition (MmFaceRecognizationLog), speaker recognition (MmSpeakerRecognizationLog), and logo/watermark detection (MmLogoDetectionLog) -- indicating the exported analytics platform includes biometric and adult-content classification of intercepted media, not just protocol/keyword filtering.

The 'galaxy/K18/galaxy-service' repository -- filed under the leak's Kazakhstan 'K18' site codename -- defines backend log/report entities for OpenVPN, L2TP, IPsec, and PPTP VPN-protocol detection (NtcOpenvpnLog, NtcL2tpLog, NtcIpsecLog, NtcPptpLog) plus keyword-filtered URL logging (NtcKeywordsUrlLog), confirming VPN-protocol identification and keyword-URL filtering were part of the analytics/reporting layer customized for the Kazakhstan customer.

The internal project code 'K18' is confirmed to correspond to a Kazakhstan deployment: a customer fault report about ADC-relayed traffic to amazon.com/twitter.com references testing against 'Nur-Sultan' (Kazakhstan's capital name 2019-2022), corroborating the taxonomy assumption that Geedge's Kazakhstan customer relationship maps to the 'K'-prefixed project codes (K18, K24, etc.) seen elsewhere in this ticket set.

K18_NTCS_WEB/NTC (git.mesalab.cn) is the Java/Spring web console for Kazakhstan's (K18) National Traffic Control System. Its domain model implements per-protocol keyword filtering (App/ASN/DNS/FTP/Mail/P2P/SSL keyword configs), an HTTPS proxy-MITM object (PxyObjTrustedCaCert.java), and explicit content-manipulation templates for HTTPS Redirect and Replace (complex/IP-based) plus Hijack/Insert actions, all managed through this customer-facing K18 control panel.

Within the same K18 (Kazakhstan) NTC platform, a 2019-07-02 commit extends the HTTP manipulation policy's Hijack/Insert action with a "SubscriberID" field while the platform separately collects/reports RADIUS AAA logs (NtcCollectRadiusLog.java, NtcRadiusReport.java) — showing RADIUS-based subscriber-identity correlation tied directly to live content-injection actions in the Kazakhstan deployment, extending the previously-documented Pakistan-only "CyberNarrator" subscriber-correlation pattern to a second export market.

A repo path-labeled "K18_NTCS_WEB" (backend service "argus-service", originally developed as "maat_service") defines per-protocol raw-log and business-rule types spanning HTTP, SSL, DNS, SSH, FTP, Mail, P2P, and VoIP, and the VPN/tunnel protocols PPTP, L2TP, IPsec, and OpenVPN, plus a dedicated keyword-based URL log (NtcKeywordsUrlLog) and a RADIUS collection log (NtcCollectRadiusLog) — showing the K18 (Kazakhstan)-labeled monitoring platform logs keyword-hit URLs and carrier RADIUS data alongside full protocol-specific traffic logs.

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.

A Navicat MySQL dump (source schema "nz-temp", host 192.168.40.42, dated 2020-10-16) for an internal IDC/asset-management tool ("nz-prometheus") seeds its sys_area geo table with exactly 18 Kazakhstan cities — Aktau, Aktubinsk, Almaty, Nur-Sultan, Atyrau, Karaganda, Kokshetau, Kostanay, Kyzylorda, Pavlodar, Petropavl, Semey, Shymkent, Taldykurgan, Taraz, Uralsk, Ust-Kamenogorsk, Zhezkazgan — plus a full embedded Kazakhstan provincial-boundary GeoJSON map, and no other country's entries. This substantially broadens the known K18 (Kazakhstan) deployment footprint beyond the 5 cities already in the taxonomy notes (Astana, Almaty, Karaganda, Zhezkazgan, Aktau) to essentially nationwide coverage.

The K18-labeled platform's MAAT business-rule catalog includes explicit proxy content-manipulation rule types "PXY IP替换" (proxy IP replacement/substitution) and "PXY管控文件策略" (proxy file-control policy) alongside "PXY 证书管理" (proxy certificate management), giving concrete confirmation that the certificate-based MITM proxy (PXY) module supports IP-substitution and file-policy content manipulation, not merely pass/block/log actions.

The tango/tfe repository carries a long-lived branch "develop-21.09-K18" (K18 is the established Kazakhstan site codename), showing the core TLS-interception/HTTP-hijack/DoH-redirect engine (TFE) had dedicated customer-specific engineering for the Kazakhstan export deployment, not just generic TSG builds.

A MESA Lab Minio object-storage cluster repo (zhangchengwei/MinioRelated) provisions and Prometheus/Grafana-monitors separate environments explicitly named "Astana" and "Almaty" — the two primary Kazakhstan site codenames documented under K18 — confirming dedicated per-city storage and monitoring infrastructure for the Kazakhstan deployment as far back as 2018-2019.

The IPReuse/mrl tool -- a NAT link-learning daemon integrated with Marsio (which fills VXLAN headers using MRL-supplied virtual link IDs) and MAAT (shared 'maat_feather' candidate/nominee tables) -- ships a Kazakhstan-specific MaxMind-format IP geolocation database (Kazakhstan_v4.mmdb) directly in its own config directory and again inside its bundled IPLocator dependency. Commit history describes self-learning of link info, SNAT/DNAT policy support, and sending virtual link IDs to 'the platform' for Marsio's VXLAN encapsulation.

The 'nezha/nezha-fronted' internal infrastructure-monitoring dashboard (a customized fork of the open-source Nezha monitoring tool) carries a distinct '2.0-kz' branch/tag lineage dated from June 2021 -- a further, independent data point placing Kazakhstan ('kz') as a named, separately-maintained deployment as early as mid-2021, corroborating the K18 Kazakhstan evidence found elsewhere in this batch.

Three independent internal ops/monitoring codebases — nms/nmsweb, nms/oam ("gloam"), and nezha/nz-web — each maintain a dedicated Kazakhstan-specific branch (nmsweb/oam: "k18-1.0"; nezha: "2.0-kz-2021-07-05" and later kz tags), and nmsweb additionally ships Russian-language localization (globalMessages_ru_RU.properties) plus topology icons for named inline-device hardware models (ADC-A016, ASEM-T102) and generic network elements (BlockRouter, ISPnInlineDevice, CoreSwitch) — confirming K18 = Kazakhstan (per existing taxonomy) received custom-built monitoring/OAM software, not just shared config.

The NMS network-monitoring-server repo (nms/nmsserver) maintains a dedicated, long-lived "k18-1.0" branch (K18 = Kazakhstan codename) alongside its generic dev/master branches, evidencing a customer-specific fork/release line of the monitoring-server product built for the Kazakhstan TSG deployment.

Internal site codename "K18" is confirmed as the Kazakhstan TSG deployment, running TSG21.09 as of February 2024, via an internal ticket coordinating a timezone migration in response to Kazakhstan's real 2024 government-mandated single-timezone change.

Kazakhstan (K18) required a formal written response to its "进出口" trading-company intermediary about an unspecified "中间人" (man-in-the-middle) problem, resolved via a sapp upgrade. The generic "进出口" intermediary language recurs across K18 and E21 threads, consistent with CEIEC as a shared export channel.

Internal project code "K18" is a Kazakhstan TSG deployment: a 2022-10 ticket requests updating the "Data-Center" field in ADC device provisioning files from "Nur-Sultan" to "Astana", directly tying K18 to Kazakhstan. A separate cabling-documentation ticket references a physical site in Aktau, a Kazakh Caspian port city.

Internal tickets name an Astana ("K18现场") datacenter by the Kazakh capital's name directly, plus wiring tickets for Karaganda and Zhezkazgan and a training outline describing an Almaty backup datacenter -- corroborating and adding city-level specificity to the Kazakhstan TSG deployment already in this corpus from secondary reporting.

Internal project codenames decode to specific customers: M22 = Myanmar (operators Mytel, Ooredoo Myanmar, and ATOM; sites YGN=Yangon, MDY=Mandalay), K18 = Kazakhstan (site renamed Nur-Sultan to Astana in OLAP config), E21 = Ethiopia (operator Safaricom Ethiopia; sites ADAMA-PE/SSM-PE to KLT-IGW/SHQ-IGW), WMS-UTR = Pakistan.

pzx/tensor-k18 packages a MAAT-integrated processing component ("tensor") with three separate customer/site config profiles (IPZY, T1-2, YSP), each with its own maat_redis.conf, and the repo itself is named "tensor-k18" — direct evidence this component is built and configured specifically for the K18 (Kazakhstan) deployment.

Four separate TSG "Server IP and Location of Overseas APP" reports (Instagram/Facebook CDN traffic) list Kazakhstan locations (Almaty, Pavlodar) as significant contributors to top-50-by-bytes tables alongside US/France/Hong Kong entries, consistent with a TSG vantage point that has substantial visibility into Kazakhstan-bound consumer traffic — corroborating the corpus's existing K18 (Kazakhstan) site attribution with independent network-traffic evidence.

The tsg_master core DPI/blocking daemon's GitLab repository carries a dedicated long-lived branch "dev-K18" alongside version-numbered TSG-OS release branches, confirming Kazakhstan (K18) receives its own customer-specific development branch of the product's core traffic engine, not just configuration-level customization.

The tsg-scripts Ansible deployment repo (git.mesalab.cn:tsg/tsg-scripts) contains dedicated per-city deploy configs for well over a dozen Kazakhstan locations (Astana/Nur-Sultan, Almaty, Karaganda, Zhezkazgan, Aktau, Shymkent, Petropavl, Pavlodar, Semey, Taraz, Kostanay, Taldykorgan, Uralsk, Kokshetau, Ust-Kamenogorsk, Aktobe/Aktubinsk, Kyzylorda), consistent with and substantially extending the K18 Kazakhstan site codename. A single 2020-10-24 commit was authored directly from a '[email protected]' account 'at K18-2 Control Center', concretely tying CEIEC (China National Electronics Import & Export Corp) to on-site K18/Kazakhstan deployment access.