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 | Low (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. High-severity ports (exposed datastores, Telnet) turn the tile red. Everything else — medium (CouchDB), low (FTP, alt HTTP/HTTPS on 8080/8443) and informational (SSH) — is listed on the check detail page and named on the tile ("FTP open") but doesn't affect the check or domain state. They're hygiene notes, not incidents.
This row has moved three times. Medium ports were demoted from amber to informational on 2026-07-20, restored to amber on 2026-08-11, and demoted again on 2026-08-19 — the last change also reclassified FTP itself from medium to low. The 2026-08-11 restoration existed because the check disagreed with our own dangerous open ports reference; the current change keeps the two in step by demoting FTP in both places rather than only one, so a visitor and a customer are told the same thing.
An open FTP port therefore reads Healthy with "FTP open" named on the tile. It is still worth closing — see the guidance below — but it will not sit in "needs attention" indefinitely, which is what shared-hosting and parked domains made common.
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: low (FTP, alt HTTP) and medium (CouchDB) go to the 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.