Packetman saysWelcome to the exposed services page. I'm Packetman. Let me explain why this is one of the most useful capabilities DataStun ships, and why it's included on every tier including the no-cost one. Every breach post-mortem in the last decade includes some variant of "an internal service was reachable on the public internet that should never have been" — a database, an admin panel, a remote-management interface, a file share. The traditional way to catch this is a perimeter port scan from the outside, run on a schedule, finding what's exposed today. The DataStun way is different: every agent already watches outbound flows, so the moment any of your machines opens a session to a public-internet IP on a port that should never serve the public internet — MSSQL on 1433, MongoDB on 27017, Redis on 6379, RDP on 3389, SMB on 445 — the agent tags it instantly. Critical matches alert your tenant admins at flow-open. Lower-confidence matches show on the device's Exposed tab. One click in the dashboard pushes a block to every agent on your tenant within 60 seconds. The detection is at the agent's outbound observation, not from a perimeter scanner — so it works for cloud workloads, remote agents, and VPN-routed traffic the perimeter scanner can't reach. We give it away because it's a safety feature, not a premium one.169 services across 8 categories. Caught at the agent on every outbound flow, not by a perimeter scanner. Critical hits alert your tenant admins instantly; warn-level hits land on the device’s Exposed tab. One click blocks across every agent in 60 seconds.
Every flow your machines open carries a destination IP, port, and protocol — the agent already collects that. The catalog of 169 known infrastructure services lives on the agent and refreshes from the platform automatically; no agent reinstall needed when the catalog grows.
If the destination is RFC1918 / link-local / inside your tenant’s configured private networks, nothing happens — that’s normal traffic. If the destination is a public IP and the port matches a catalog service, the flow gets tagged with the service identity and a severity (critical or warn).
Critical match → instant tenant-admin alert (email + webhook + dashboard badge). Admin clicks Block → every agent on the tenant picks up the override on its next poll (within 60 seconds) and the OS firewall enforces it. No re-deploy, no firewall rule to write.
Of 169 catalog entries: ~60 are unambiguous never on the internet (critical), ~60 are legitimate public use exists but shouldn’t for you (warn), and the rest cover edge cases. A representative cross-section:
| Service | Port | Category | Severity | Why it matters |
|---|---|---|---|---|
| Microsoft SQL Server | tcp/1433 | Databases | Critical | Direct database access. No legitimate public-internet use. |
| PostgreSQL | tcp/5432 | Databases | Critical | Same as MSSQL — database server should not answer the public internet. |
| MongoDB | tcp/27017 | Databases | Critical | Default-no-auth historic posture. Public-internet exposure has caused many incidents. |
| Redis | tcp/6379 | Databases | Critical | Cache / queue. Default no-auth; trivially exploited. |
| Elasticsearch | tcp/9200 | Databases | Critical | Full data + cluster API on a single port. Should be VPN-only. |
| Microsoft RDP | tcp/3389 | Remote management | Critical | Brute-force and credential-stuffing magnet. Common ransomware entry point. |
| SMB | tcp/445 | File sharing & storage | Critical | Windows file-share protocol. Should never traverse the public internet. |
| VNC | tcp/5900 | Remote management | Critical | Often unauthenticated or weakly authenticated. Public exposure is exploitation-ready. |
| RabbitMQ management | tcp/15672 | Message queues | Critical | Admin web UI for queue infrastructure. Internal-only by design. |
| Active Directory LDAP | tcp/389 | Directory & auth | Critical | Enumeration target. Reachable LDAP from the internet leaks the org chart. |
| SSH | tcp/22 | Remote management | Warn | Legitimate public use exists, but for most fleets the policy is “VPN only.” Surfaced for review. |
| vCenter / iLO / iDRAC web UI | tcp/443 (matched by host) | Virtualization / Remote management | Warn | Hypervisor / out-of-band management. Sometimes intentionally public, usually a mistake. |
| Grafana | tcp/3000 | Internal web | Warn | Often reachable for legitimate reasons; flagged so an admin can decide. |
The full 169-entry catalog is distributed to agents over HTTPS from the tenant platform — agents 0.4.7 and up automatically pick up new services as we add them, with no re-install.
A worked example. Tuesday afternoon, an emergency change leaves RDP open during a maintenance window.
An agent on WIN-DBG-04 sees an inbound RDP session establish from a public IP. Catalog match: tcp/3389 → Microsoft RDP → critical.
Tenant admins receive an email + webhook + dashboard badge: “Critical exposure detected: RDP on WIN-DBG-04 from public IP 203.0.113.42.” No 5-minute sweep wait — the alert fires at flow-open.
From the alert, the admin opens the device’s Exposed tab, sees the matched flow with destination, process, PID, and timing. Clicks Block this destination. A tenant-scoped firewall override is staged.
Every agent on the tenant picks up the override on its next blocklist poll (60-second worst case). The OS firewall — Windows Firewall, Linux ipset/iptables, macOS pf — enforces it the same way it enforces the global blocklist. No new firewall rule to manage.
RDP attempts to WIN-DBG-04:3389 from any source, on any agent, are refused at the kernel firewall. The flow record on the agent shows the block enforcement; the dashboard shows zero successful subsequent connections.
Total time from exposure to enforced block: ~2 minutes. Without an exposed-services detector, the same incident is typically caught on the next perimeter scan (hours to days), or in a post-incident forensic review (weeks).
Same reason the global IP blocklist is included on every tier. Tier-gating a safety feature is hostile when the cost of missing the catch is so much higher than the cost of delivering it.
Individual-tier customers on a single agent get the same catalog and the same instant alert as Enterprise customers running a 5,000-agent fleet. Agent capacity, retention, and analytics scale with tier — the safety floor doesn’t.
A perimeter scanner asks “what is currently reachable from outside my network?” — a question answered by an attacker-perspective probe of your public IP space. Useful, but it has blind spots: cloud workloads with dynamic IPs, remote-worker laptops, agents behind NAT, anything VPN-routed. Perimeter scans also run on a schedule (nightly, weekly), so the gap between exposure and detection is bounded by that interval.
Exposed Services is the inverse: the agent is on the machine, watching the flows the machine actually opens. We see what the machine sees, in the moment it sees it. The detection works whether the machine is in your data center, a coffee shop, an airline lounge, or a customer’s site — the agent observes the same outbound flow regardless. The two approaches are complementary; this one closes the cloud / remote / VPN gap that perimeter scanning can’t reach.
Sign up free, enroll one agent, and any matching outbound flow shows up on that device’s Exposed tab in the moment. Most teams find at least one surprise on the first day.
Part of the Security lane · alongside AI Governance and the executable-reputation cluster.