Open ports check
DomainCare scans 11 ports daily (datastores, admin panels, FTP, Telnet) and alerts when a dangerous port becomes reachable.
Open ports check
The open ports check resolves your domain's A record, then runs a parallel TCP connect scan against eleven well-known ports with a 2-second timeout each. A previously-closed port becoming reachable triggers an alert; a previously-open port closing fires a recovery event.
Ports scanned
| Port | Service | Severity if reachable |
|---|---|---|
| 3306 | MySQL | Critical |
| 5432 | PostgreSQL | Critical |
| 6379 | Redis | Critical |
| 27017 | MongoDB | Critical |
| 9200 | Elasticsearch | Critical |
| 23 | Telnet | Critical |
| 5984 | CouchDB | Medium (informational) |
| 21 | FTP | Medium (informational) |
| 8080 | Alt HTTP (admin panels) | Low |
| 8443 | Alt HTTPS (admin panels) | Low |
| 22 | SSH | Info (legitimate but tracked) |
How often it runs
The check runs once every 24 hours (defaultIntervalSeconds: 86_400). Paid plans can override this per domain via per-check controls.
Check status. Only high-severity ports (exposed datastores, Telnet) turn the tile red. Medium-severity ports (CouchDB, FTP), low-severity ports (alt HTTP/HTTPS on 8080/8443), and informational ports (SSH) are listed on the check detail page but don't affect the check or domain state — they're hygiene notes, not incidents. (Medium ports were demoted from amber to informational on 2026-07-20 so that common shared-hosting FTP exposure doesn't keep every domain in "needs attention".)
Alerts this check produces
| Event | Tone | When it fires |
|---|---|---|
dangerous_port_exposed | Failure | A port that was closed last run is now reachable. Severity scales with the port: medium (FTP, CouchDB — daily digest) up to critical (databases, Telnet — immediate alert) |
dangerous_port_closed | Recovery | A port that was open last run is now closed. Informational |
Caveat — egress IPs
Probes leave from a fixed set of egress IPs. Some hosts rate-limit or block traffic from non-residential IP ranges, which means a probe can register as "closed" even when the port is genuinely reachable from the public internet. If your firewall logs show DomainCare connect attempts being dropped, treat the result as advisory.
What to do when dangerous_port_exposed fires
- Datastore ports (MySQL, Postgres, Redis, MongoDB, Elasticsearch). Bind the database to localhost (or a private network), or restrict to your application servers via a firewall. Most exposed-database breaches happen because the service was started with
bind_address = 0.0.0.0for convenience. - Telnet (port 23) or FTP (port 21). Disable. Both are unencrypted and have safe replacements (SSH for shell access, SFTP for file transfer).
- Alt HTTP/HTTPS (8080 / 8443). These often expose admin panels, dev servers, or unfinished setups. Either move them behind authentication + a VPN, or shut them down.
- SSH (port 22). Legitimate but worth noting — make sure password auth is disabled, only key auth allowed, and consider moving to a non-standard port + fail2ban if you face brute-force attempts.