Consumer Intelligence Pipeline and ThoughtWave SSO: What's New in SATIS
Two major areas of development have landed in SATIS over the past two weeks: a consumer intelligence pipeline that aggregates crowd-sourced anomaly reports into blockchain-published threats, and a BGP peering overhaul that makes customer-facing nodes fully auto-provisioned. We also added ThoughtWave single sign-on so users of both platforms can log in to SATIS with one click.
Consumer Intelligence Pipeline
SATIS Home devices — the lightweight feed agents that run on home routers and consumer appliances — now do more than passively consume threat feeds. They submit anomaly reports back to the platform, and those reports are aggregated and promoted to the blockchain when enough independent devices agree.
The aggregation thresholds are deliberately conservative:
- 3+ devices reporting the same target → publish to blockchain with
consumer-crowdsource - 5+ devices → severity escalates to
high - 10+ devices → severity escalates to
critical
This crowd-sourced signal is particularly valuable for detecting targets that commercial feeds miss — home routers see a different slice of the internet than enterprise sensors do. A scanning campaign that avoids well-known honeypot ranges will often hit residential CGNAT addresses first.
The aggregation engine runs on demand and is exposed via GET /api/v1/consumer/aggregation for monitoring. The confidence score is calculated from the device count, giving the threat scoring engine appropriate weight relative to higher-reliability sources like Spamhaus DROP.
DNS Sinkhole Blocklists
The GET /api/v1/consumer/blocklist endpoint now generates DNS sinkhole blocklists derived from active email threats in the platform. Four formats are supported:
# Pi-hole / hosts format (default)
GET /api/v1/consumer/blocklist?format=hosts
# dnsmasq
GET /api/v1/consumer/blocklist?format=dnsmasq
# Unbound local-zone entries
GET /api/v1/consumer/blocklist?format=unbound
# Pi-hole-specific (same as hosts but explicit Content-Type)
GET /api/v1/consumer/blocklist?format=pihole
Device tokens (tcd_) are accepted alongside API keys, so home router agents can pull the blocklist directly without requiring a customer account credential on-device. A typical cron job for Pi-hole:
# /etc/cron.d/satis-blocklist
0 */4 * * * root curl -sf -H "Authorization: Bearer tcd_your_token" \
"https://satecastronomyinc.com/api/v1/consumer/blocklist?format=pihole" \
-o /etc/pihole/lists/satis.txt && pihole restartdns
The blocklist is derived from the email threat blacklist, meaning the same data that powers DNS RPZ for enterprise mail servers also flows down to consumer-grade Pi-hole and dnsmasq installations.
Portal Email Threats Tab
Customers with Home, Professional, or Enterprise plans now have an Email Threats tab in the portal. The tab provides:
- Submit malicious email addresses and domains directly from the portal
- View your submitted threats with status and severity
- Download the DNS RPZ zone file for your mail server integration
- Collapsible setup guide with cron job examples for Pi-hole, dnsmasq, and Postfix
A dedicated /email-security page covers the full integration reference for mail server administrators.
BGP Peering Improvements
Customer-facing BGP nodes (like our NYC node setec-4) are now fully auto-provisioned. When a peering request is approved in the portal, the BGP injector daemon:
- Allocates a GRE tunnel with overlay IPv4 addresses from
100.64.0.0/10CGNAT space - Creates the tunnel interface with
ip tunnel add - Writes a persistent interface config to
/etc/network/interfaces.d/ - Generates a per-peer BIRD 2 configuration file in
/etc/bird/peers/ - Reloads BIRD without dropping other sessions
Peer configs now use the IPv4 overlay addresses for the BGP session rather than the IPv6 tunnel addresses. This is more broadly compatible — OpenBGPD, which many operators use on edge routers, does not support RFC 8950 extended next hop, so carrying IPv4 prefixes over an IPv6 BGP session requires capability negotiation that not all implementations handle. Using 100.64.x.y/31 inner addresses means any BGP implementation works out of the box.
The injector also handles GRE tunnel cleanup: when a peering session is deleted from the portal, the corresponding tunnel interface and peer config file are removed automatically on the next poll cycle.
New ansible deployments of customer-facing nodes are fully automated. The bird and bgp_injector roles generate the correct config based on bird_role: customer_facing in host vars, set PEERS_DIR=/etc/bird/peers, and use the public API URL for external nodes.
ThoughtWave Single Sign-On
SATIS now supports login and signup via ThoughtWave accounts using OAuth 2.0 with PKCE. Users with a ThoughtWave account can click Continue with ThoughtWave on the login or signup page and authenticate without creating a separate SATIS password.
The integration uses the full authorization code flow with PKCE (RFC 7636) mandatory — no implicit flow, no credential sharing between platforms. When a ThoughtWave user signs into SATIS for the first time, a Community account is automatically created using their verified ThoughtWave email. Existing SATIS accounts are matched by email and logged in directly.
ThoughtWave is treated as a trusted OAuth client, meaning the consent screen is skipped for users who already have a ThoughtWave session — the redirect and callback happen transparently in under a second.
What's Next
We're working on the SATIS Edge AMI for AWS Marketplace, SATIS Home firmware for OpenWrt-based routers, and a threat intelligence marketplace that would let organizations monetize their proprietary feed data. More on that last one soon.
SATIS is a blockchain-based real-time threat intelligence platform by Setec Astronomy, Inc. (AS23026). API documentation is available at setecastronomyinc.com/api-docs.
Back to Blog