Site Inspector: Headers, Certificate, WHOIS and PTR

One request, four answers, each explained. Only ports 80 and 443 are contacted and private address ranges are refused — this is an inspector, not a scanner.

Common ports and what exposing them means

Reference material, not a scan of anything. If you are hardening a server, the useful question is not “which ports are open” but “which of these should be reachable from the public internet at all” — and for most of the list below, the answer is none.

PortServiceExposure riskWhy
22 SSH Medium Remote shell access. Safe when it accepts keys only; a constant target for credential guessing when it accepts passwords.
23 Telnet High Unencrypted remote shell. Anything typed, including the password, travels in clear text. There is no reason to run it today.
25 / 465 / 587 SMTP Medium Mail submission and transfer. An open relay here gets a server blacklisted quickly.
53 DNS Medium Name resolution. A resolver exposed to the internet can be conscripted into amplification attacks.
80 HTTP Medium Unencrypted web traffic. Fine as a redirect to HTTPS; not fine as the place real content is served.
443 HTTPS Low Encrypted web traffic, and the port most likely to work on a restrictive network because blocking it breaks everything.
445 SMB High Windows file sharing. Exposing it to the internet is how several worms spread; it belongs on a local network only.
3306 MySQL / MariaDB High Database access. Should listen on localhost or a private network, never the public internet.
3389 RDP High Windows remote desktop. Heavily scanned and a favourite ransomware entry point when exposed directly.
5432 PostgreSQL High Database access, same reasoning as MySQL — bind it locally and reach it through a tunnel.
6379 Redis High Often ships with no authentication at all, so an exposed instance is effectively an open door.
8080 / 8443 Alternate HTTP(S) Medium Common for admin panels and staging environments, which is exactly why scanners check them first.

A VPN does not change which ports your server exposes — that is a firewall question. What it does change is what the network between you and a service can observe, which is why administrators reach databases through a tunnel rather than opening 3306 to the world. Our privacy audit covers the other side: what a website learns about you.

Preguntas frecuentes

What does the site inspector check?

Four things in one request: which HTTP security headers a site sends and what each one is for, the TLS certificate it presents including issuer and expiry, the WHOIS registration record from the authoritative registry, and the reverse DNS name published for its addresses.

Can I use this to scan ports or scan a network?

No, and that is deliberate. Only ports 80 and 443 are ever contacted, only over http or https, and only for a public hostname. Private, loopback, link-local and reserved address ranges are refused outright, redirects are never followed, and requests are rate limited per network. The ports section further down is educational reference, not a scanner.

Why does a missing header not always mean the site is insecure?

Headers are defence in depth, not a verdict. A site with no Content-Security-Policy may still be perfectly safe if it serves no untrusted content, and a site with every header set can still have an application flaw. Treat the score as a checklist, not a security audit.

Why does the certificate check not verify the chain?

Because the useful cases are the broken ones. A connection that verifies strictly would refuse to complete against an expired or mismatched certificate, which is exactly the situation you want to see reported. We read what the server presents and tell you if it has expired or is not yet valid.

Where does the WHOIS data come from?

We ask IANA which server is authoritative for the top-level domain, then query that server directly. There is no bundled server list to go stale and no third-party WHOIS API in between. Some registries redact registrant details under privacy rules, so a sparse record is normal rather than an error.

Is a reverse DNS name proof of who owns an address?

No. Anyone controlling an address can publish any PTR name they like. We forward-confirm the result — resolving the name back to see whether it points to the same address — and label it unconfirmed when it does not, because an unconfirmed PTR is a claim rather than evidence.

Recibe gratis nuestra guia paso a paso para configurar tu VPN (PDF)