Skip to content
SECQON
How it worksWhat we checkPricingSecurity
Log inStart free

Open port check — which databases, admin panels and services are reachable from the internet

Many serious breaches start with a service that was never meant to face the internet: a database, a cache, a Kubernetes API, a remote-desktop port left open after a migration. SecQon checks 36 TCP ports where those services usually live and tells you which ones answer from the internet, graded by what the service normally is. It runs on Standard and Deep scans, and it is deliberately gentle: one TCP connection per port, closed immediately, with nothing sent.

Runs on
Standard and Deep scans. Never part of Light or the free instant check. Free accounts can launch a Standard scan manually; paid plans also run it on the daily monitoring scan.
Included from
Free plan ($0)
OWASP Top 10 (2021)
A05

What we test

Why it matters

A database or cache that answers on the public internet is one of the most direct ways data gets stolen. Some of these services ship with no password by default, and automated scanners across the internet look for them constantly. Kubernetes, kubelet and etcd are worse still: reaching them can mean reaching everything they run. These ports are rarely opened on purpose — they are left open by a firewall rule copied from staging, a quick debugging session, or a cloud security group nobody revisited.

Remote-administration ports such as SSH and RDP are a different kind of risk. They are often intentional, but every one of them is a door that attackers will keep trying passwords against. Knowing exactly which are open lets you decide whether each one should be there, restricted to a VPN or specific IPs, or closed.

The value of this check is that it looks from where an attacker looks. Your cloud console shows the rules you meant to write; this shows what actually answers from outside, on the IP addresses your verified hostname resolves to, and on paid plans it is re-checked by the daily monitoring scan, so a port that opens next month does not go unnoticed.

An example finding, and its fix

A finding of a type this check really produces. The evidence is illustrative, not taken from a customer's scan.

High

Port 6379/tcp (redis) is reachable from the internet

Evidence

TCP connect 203.0.113.24:6379 → connection established, closed immediately
No data sent, no banner read
CDN detected: no

How to fix it

Confirm whether Redis on this host needs to be reachable from the internet — almost always it does not. Block port 6379 in your cloud security group or firewall, allowing only your application servers. Bind Redis to a private interface (bind 127.0.0.1 or a private IP) and require authentication. Re-test the finding from your report; it closes when the port no longer accepts a connection.

What we don't test

  • UDP. Only TCP ports are examined.
  • All 65,535 ports. This is a curated list of 36 high-risk TCP ports, not a full port sweep.
  • Whether the service is actually unprotected. A finding means the port answers, not that it lacks a password — Redis is graded high because it is often open when public, not because we tried it.
  • Service versions or banners. We complete the TCP connection and close it; we read nothing and send nothing.
  • Cloudflare’s alternate proxy ports (2052–2096), which are not in the list and are not reported.

Every report names what its scan did and did not assess. See the full OWASP Top 10 coverage, including the two categories no external scan can assess.

Exposed ports & services: questions people ask

Does SecQon test UDP ports?

No. The port check examines 36 TCP ports only. UDP services are not tested, and the report does not suggest otherwise.

Is this a full port scan of all 65,535 ports?

No. It is a curated list of 36 ports where high-risk services usually run — databases, container control planes, admin dashboards, remote access and cleartext protocols. The report lists every port that was probed.

Is the port check safe to run against production servers?

Yes. It makes one ordinary TCP connection per port and closes it straight away. There is no SYN or stealth scanning, no banner grabbing and no data sent, and every connection is rate-limited per asset.

Does a finding mean my database is unprotected?

No — it means the port is reachable from the internet. We do not log in or test authentication. The severity reflects what that service usually means when it is exposed, and closing the port is the fix either way.

My site is behind a CDN. Why are ports 8080 and 8443 open?

Because the CDN’s edge answers on them. When we detect a CDN, the finding says the port belongs to the edge rather than your origin server, so you can tell the difference.

Can I allow-list SecQon’s traffic in my firewall?

Yes. Scans leave from a single reserved IP address, so you can allow it or recognise it in your logs.

Other checks

  • TLS & certificates

    Certificate trust and expiry, and whether your server still accepts TLS 1.0 or 1.1.

  • Security headers & cookies

    Missing or ineffective HSTS, CSP, clickjacking, nosniff and Referrer-Policy headers, plus cookie flags.

  • DNS & email security

    SPF, DMARC, CAA and DNSSEC — the records that stop spoofed email and mis-issued certificates.

  • API security

    Your API’s own schema, read as an outsider: open operations, GraphQL introspection, CORS and leaked stack traces.

  • Web application pentest

    A browser-rendered crawl plus bounded proofs for XSS, SQL injection and SSRF, and an active scanner on the pentest tier.

Last reviewed against our scanning documentation on 24 Sep 2026.

See what a scan finds on your own asset

Free for one verified asset, no card needed. Paid plans add the written report, more assets and deeper scans.

Start freeCompare plans