How to use the VPS Security Scanner

  1. Type the domain or public IP address of a server you own or have permission to test.
  2. Tick the box confirming that, and press Scan.
  3. Wait up to 25 seconds while the ports, TLS, HTTP headers and mail records are checked.
  4. Fix the findings from the top, most serious first, and scan again after ten minutes.

What an external security scan shows

An external scan connects to your server from the internet and reports what answers: which ports accept a connection, which TLS versions and certificate the HTTPS port offers, and which security headers the site sends. It shows exactly what an attacker’s scanner sees, and an exposed database, Redis, Docker API or Elasticsearch port is the most serious thing it can find.

This scan runs from Shipown’s server, not from your browser, so it sees your server the way the rest of the internet does. Only scan servers you own or have written permission to test. Nothing is stored: the report is kept in memory for ten minutes, so the same host is not scanned again, and then dropped.

What is checked

  • 26 ports, by a plain TCP connection with a two-second timeout: FTP, SSH, Telnet, SMTP, HTTP, POP3, IMAP, HTTPS, SMB, the mail submission ports, SQL Server, the Docker API (2375), port 3000, MySQL, RDP, PostgreSQL, VNC, Redis, 8080, 8443, Elasticsearch, Memcached and MongoDB. No other ports are tried and no service is logged into.
  • TLS on 443: the best protocol the server offers, whether TLS 1.0 and 1.1 are still accepted (both deprecated by RFC 8996), the certificate’s expiry date, issuer, whether it covers the name you typed, and whether the chain is trusted.
  • HTTP: whether http:// redirects to https:// with a permanent 301 or 308, and the headers Strict-Transport-Security, Content-Security-Policy, X-Frame-Options (or frame-ancestors), X-Content-Type-Options, Referrer-Policy and Permissions-Policy, plus Server and X-Powered-By headers that give away versions.
  • Mail DNS for a domain: whether SPF and DMARC records exist. The DNS lookup tool audits them in full.

Redirects to another host are reported, never followed, and only the response headers are read, never the page.

An outside scan sees only what the firewall lets through

A closed port here means the firewall dropped or refused the connection, not that nothing listens behind it. To see what is listening on the server itself:

sudo ss -tlnp            # every TCP port listening, and the program holding it
sudo ufw status verbose  # what the firewall allows

A service bound to 0.0.0.0 or :: listens on every interface and is reachable whenever the firewall allows it. Bind databases and caches to 127.0.0.1 so that a firewall mistake cannot expose them.

Docker is the usual surprise: a port published with -p 6379:6379 is opened through Docker’s own iptables rules and bypasses ufw. Publish it on loopback instead, as -p 127.0.0.1:6379:6379.

Checking the same things by hand

nmap -Pn -p 21,22,23,3306,5432,6379,27017 your-server.example   # from another machine
openssl s_client -connect example.com:443 -tls1_1 </dev/null    # succeeds only if TLS 1.1 is still on
curl -sI https://example.com | grep -i -E 'strict-transport|content-security|x-frame'

Common findings and how to fix them

  • A database port is open. Set bind-address = 127.0.0.1 (MySQL), listen_addresses = 'localhost' (PostgreSQL), bind 127.0.0.1 (Redis) or net.bindIp: 127.0.0.1 (MongoDB), restart it, and reach it through an SSH tunnel.
  • The certificate chain is not trusted. Usually Nginx points at cert.pem instead of fullchain.pem, so the intermediate certificate is missing.
  • Headers missing on some pages. Nginx drops add_header lines from the server block in any location that has its own add_header, and leaves them off error responses (4xx and 5xx) unless they end in always.
  • TLS 1.0 or 1.1 accepted. Set ssl_protocols TLSv1.2 TLSv1.3; and reload Nginx.
  • Port 25 shows as filtered. Many cloud providers block outgoing connections to port 25, so a result for 25 from any cloud scanner is not conclusive.

A host behind Cloudflare or another proxy shows the proxy’s ports and certificate, not your server’s. IPv6-only hosts may not be reachable from the scanner.

Checking from inside the server

Shipown connects over SSH and manages ufw or firewalld from the desktop app, showing the ports actually listening next to the firewall rules, so you can see what is open from the inside as well as from here. It also installs and runs fail2ban to ban addresses that keep failing to log in.

Frequently asked questions

Is it legal to scan a server?

Laws differ between countries, so scan only servers you own or have written permission to test. This tool asks you to confirm that, checks a fixed list of ports and logs into nothing.

Why is my port closed here but open on the server?

The scan sees only what the firewall lets through from the internet. Run sudo ss -tlnp on the server to see what is listening behind it.

Why is an open Redis or MongoDB port critical?

Both are often run without a password, and automated scans find exposed instances within hours. Data is read, wiped or held for ransom, and Redis can be used to write files onto the server.

Does the scanner store my results?

No. The report is held in memory for ten minutes so the same host is not scanned again, then dropped, and the server log records only the host and its grade.

How often can I run a scan?

Three scans per visitor every ten minutes. A host scanned in the last ten minutes gets the same report back instead of a new scan.

Why does the scanner say my site is behind Cloudflare?

With the proxy on, the internet reaches Cloudflare, not your server, so the ports and certificate are Cloudflare’s. Scan the origin’s own IP address to see what it exposes directly.