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.
"分中心 hbase zookeeper地址" (branch-center HBase zookeeper address) vs "国家中心 hbase zookeeper" (national-center HBase zookeeper) in subscriber-config.properties; topology.tick.tuple.freq.secs=300; PullHBaseUtils scans table "sub:"+hBaseTable with a rolling time-range filter and PushHBaseUtils writes the delta into the branch-center table every tick.
Defense implications
- Subscriber-correlation data is not siloed per datacenter — it is centrally aggregated at a national level and fanned back out to regional sites roughly every 5 minutes, so a subscriber's identity linkage established at one datacenter becomes available at other regional datacenters on a similarly short lag, not just locally where the RADIUS session was first observed.
Cited artifacts
mesalab_git—galaxy/tsg_olap/storm/log-subscriber-hbase-datacenter.bundle:src/main/java/cn/ac/iie/bolt/SubscriberIdBolt.java(source-code)mesalab_git—galaxy/tsg_olap/storm/log-subscriber-hbase-datacenter.bundle:src/main/java/cn/ac/iie/utils/hbase/PullHBaseUtils.java(source-code)mesalab_git—galaxy/tsg_olap/storm/log-subscriber-hbase-datacenter.bundle:src/main/java/cn/ac/iie/utils/hbase/PushHBaseUtils.java(source-code)mesalab_git—galaxy/tsg_olap/storm/log-subscriber-hbase-datacenter.bundle:properties/subscriber-config.properties(config)mesalab_git—galaxy/tsg_olap/storm/log-subscriber-hbase-datacenter.bundle(git-commit-log)
Provenance pointers only — no leak content is rehosted. Raw material: Enlace Hacktivista.
Related findings
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.
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.
The Flink rewrite of the DoS-detection job introduces a `DosVsysId` model (a single `vsysId` integer field) and a corresponding "bifang" policy-server endpoint (/v1/system/vsys/), indicating TSG's DoS detection/policy configuration is partitioned by "vsys" (virtual system) — consistent with multi-tenant or per-customer/per-segment logical isolation elsewhere in the TSG product. The vsys field is defined but not yet wired into the actual detection logic in the code reviewed, suggesting the tenancy dimension was being added at the config layer ahead of the detection logic catching up.
Release 24.04 (28 APR 2024) adds province/city-granularity ("administrative area") geo-tagging to every session and security-event log for both client and server -- client_country/client_super_administrative_area/ client_administrative_area/client_sub_administrative_area and the server-side equivalents -- plus Client ASN/Server ASN as dedicated Statistics Rule Metric datasets, confirming sub-national geolocation is a standard enrichment field across TSG's logging pipeline, not a specialized lookup.
The app_recommend Flink job (Recommendation.java, job name "RECOMMENDATION-APP-CIP") keys incoming traffic by (app_label, client_ip), computes a sliding-window top-N of active client IPs per identified application via TopnHotItem's priority queue, and HbaseSink persists the result as an app-to-client-IP-list association -- row key MD5(app_label), columns app_label/client_ip_list/last_update_time -- in HBase. This is the source of the "Recommend App Active Client IP" troubleshooting lookup referenced in galaxy-troubleshooting-api's Release 21.12 changelog.
galaxy-troubleshooting-api's Postman collection defines a full "DoS Threat Map" dashboard API suite (folder-scoped request names: dos-threat-map-top- source-countries, dos-threat-map-top-destination-countries, dos-threat-map- top-victims, dos-threat-map-attack-type, dos-threat-map-severity, dos-threat- map-destination-ip-distribution, dos-threat-map-attack-connection, dos-threat-map-attack-volume-summary, dos-threat-map-attack-volume-trend), plus a separate DNS-amplification "Resolver" detection dataset and a per-victim-IP historical traffic-trend query -- confirming Galaxy exposes operator-facing DDoS-detection/geolocation dashboards built on top of TSG telemetry, distinct from its censorship/content-blocking function.