Docs · Exposure probes
File-based scanners — Trivy, ClamAV, rkhunter, Lynis — know what's installed on your server and how it's configured at rest. They don't know how the world sees the server: what's actually listening, what content the web server is actually serving, what TLS parameters a real handshake will negotiate. Exposure probes fill that gap with active probing from inside the host.
Authored, not licensed
We don't bundle OpenVAS, Nessus, or anyone else's scanner engine. Every exposure probe is a small Go function in our open agent source tree — you can read each rule, audit each request, and know exactly what your server is being asked. We treat the Greenbone Community Feed as research input for what's worth checking, not as code we ship. No black-box scanner you can't audit.
MySQL, Postgres, Redis, MongoDB, Memcached and Elasticsearch listening on 0.0.0.0 when they should be on 127.0.0.1. Severity is downgraded one step when the host firewall is already filtering them — so a misconfigured bind protected by iptables shows as Medium rather than High.
When a Redis / Memcached / Elasticsearch service is exposed on a public interface AND accepts a read-only command without authentication, that's a separate, higher-severity finding from the binding itself. Surfaced independently so you can fix the bind and the auth posture on their own schedules.
HTTP probes for /.git/HEAD, /.env, /.DS_Store, /wp-config.php.bak, /backup.sql — the classic foot-guns. Content-signature matching, not just status codes, so a generic 200-page fallback doesn't false-positive.
Real TLS handshakes against listening HTTPS ports — does the service still accept TLS 1.0, TLS 1.1, RC4 or 3DES? File-based scanners know the OpenSSL version installed; this knows what the live socket will actually negotiate with a client.
/phpmyadmin/, /adminer.php, /manager/html (Tomcat), /server-status, /server-info, /phpinfo.php and friends. Discovers cases where the admin panel was meant to be IP-restricted but the restriction got removed during a config edit.
On top of the built-in Go probes, Astrari ships a continuously-updated set of global rules — Docker API on TCP/2375, Kubernetes API on TCP/6443, exposed Jenkins/Prometheus/pgAdmin dashboards, RDP/VNC/SMB on the public internet, and more. These apply to every customer org automatically; no setup needed.
Add rules from Settings → Exposure rules in the dashboard. Three kinds are supported — HTTP (probe a localhost URL, match a body substring), Port (flag a listening TCP/UDP port — e.g. 'MongoDB on a non-loopback interface'), and File (check a filesystem path for existence or a substring — e.g. an SSH config drift). Rules can be scoped to your org or set globally by a platform administrator.
Probes run once per agent scan cycle alongside the file-based scanners. A full pass is roughly 100 small HTTP/HTTPS GETs against127.0.0.1plus ~8 TLS handshakes — all loopback, no outbound traffic, no external service contacted. Total wall time on a production server is typically under 3 seconds.
Probe requests can look like attack reconnaissance to a WAF. Every probe carries two identifying signals:
X-Astrari-Probe: 1astrari-agent/exposure-probeEither is sufficient to match on. Combining both is robust. Most WAFs (Wordfence, ModSecurity / OWASP CRS, Imunify360, Patchstack, Sucuri) support header-based whitelisting; many will also bypass all rules for 127.0.0.1 out of the box. A concrete ModSecurity example:
SecRule REQUEST_HEADERS:X-Astrari-Probe "@streq 1" \
"id:9009100,phase:1,nolog,allow:phase,ctl:ruleEngine=Off"fail2ban whitelists 127.0.0.1 by default — no action needed unless a custom jail removed that.
If your stack runs security tooling that doesn't honour custom whitelist headers, or your access-log alerting is expensive to silence, you can disable the scanner on that host by adding one line to the agent config (/etc/astrari/agent.conf or /etc/incuswatch/agent.conf on hosts still running the legacy binary name):
disable_exposure_probes=true
Then restart the agent:
systemctl restart astrari-agent.service
Existing OPEN exposure findings on that host auto-resolve within a couple of scan cycles. Re-enable by removing the line and restarting.
Operators with Org Admin permission or higher can add custom probe rules from Settings → Exposure rules in the dashboard. Three rule kinds are supported:
/admin/legacy/) and look for a substring in the response body. Useful for forgotten admin panels, internal dashboards, or known-bad strings.127.0.0.1 won't fire. Useful for "this database port should never be reachable off-loopback".exists fires when the file is present; mode contains additionally requires a substring (first 256KB scanned). Targets accept glob patterns — *, ?, […] (but not recursive **), capped at 64 matches per rule. Useful for catching config drift across multiple version directories — e.g. /etc/postgresql/*/main/pg_hba.conf — before the next service restart.Rules can be scoped to your organisation or set globally by a platform administrator. Agents fetch the active ruleset on every checkin and run the custom rules alongside the built-in probes on the next scan.