IP & Network

Server banner-grab check

Scan which services (HTTP, FTP, SSH, SMTP) are running.

About this tool

A server check goes one step beyond a port scan. We connect to a fixed list of common service ports on your host — HTTP, HTTPS, SSH, FTP, SMTP, IMAP, POP3, DNS, MySQL, PostgreSQL, Redis, RDP — and read whatever the daemon says first. Most plaintext services announce their product and version in the first line of the conversation; the open ones come back with a real fingerprint, the closed ones come back honest, and the firewalled ones time out at 3 seconds.

For each open port we record the raw banner, our parsed verdict on the product (e.g. nginx/1.25.3, OpenSSH_8.9p1, vsFTPd 3.0.5) and how long the dial took. HTTP and HTTPS are probed with a real HEAD / request so we can capture the Server header rather than guess from the port number; HTTPS uses TLS without certificate validation so self-signed development hosts still report.

What you can do with it

  • See what is actually exposed. A port may be open on a port scanner, but the server-check tells you exactly which daemon is listening — which is often the difference between "expected" and "rogue".
  • Spot outdated versions in seconds. If your nginx still answers Server: nginx/1.18.0 after the security advisory you read about, you have a CI/CD problem to fix.
  • Verify a hardening change. Tightened ServerTokens on Apache or set server_tokens off on nginx? A re-run should now report just nginx or Apache with no version — proof the directive landed.

Reading the result

"Open + banner" is the gold case: a service spoke and we recognised it. "Open + no banner" is normal for binary protocols (RDP, MySQL handshake, PostgreSQL startup) — we report the port is reachable but cannot fingerprint it without speaking the wire format. "Closed" means the kernel said RST — the service is not running. "Filtered" means a firewall ate the SYN — many of these are on purpose (closed-source admin VPN), some indicate misconfiguration. Results are cached for 15 minutes per host so re-loads do not re-dial the world.

Frequently asked questions

How is this different from the port checker?

The port checker only asks "is the TCP handshake completing?". Server check goes further: it does a real banner-grab — reading the greeting that SSH/FTP/SMTP/POP3/IMAP send on connect, plus a real HEAD request for HTTP/HTTPS — so we can name the product and (when not stripped) the version. Port checker is faster for a long custom port list; server check is the right tool when you want to know what is on each port, not just that something is.

Why do some open ports have no banner?

Binary protocols — RDP, MySQL pre-auth handshake, PostgreSQL startup, raw Redis without RESP greeting — do not send a human-readable line on connect. We mark these as open with no fingerprint. To identify versions of these services you need a protocol-aware client (e.g. mysqladmin, nmap -sV with the right script). Configuration that hides banners (Apache ServerTokens Prod, nginx server_tokens off) similarly shows up as "open, product only, no version".

Are private IPs supported?

No. RFC 1918 private ranges, loopback, link-local (169.254/16), CGN (100.64/10) and cloud-metadata endpoints are refused — same SSRF policy as the rest of our tools. Server check is for hosts that are publicly reachable. To audit an internal host run a banner-grab tool from inside your network.

Why is HTTPS reported even with a bad certificate?

We disable certificate validation deliberately. The point of the check is to find out what is on the port, not to validate trust — many development and self-signed hosts have no valid public chain but are still legitimate scan targets. If you want a trust verdict, the upcoming SSL Checker tool runs full chain validation, expiry, and issuer checks; this tool only reads the Server: header.

How long does a scan take?

Worst case roughly 45 seconds — 15 services × 3-second timeout — when every port is firewalled. In practice typical hosts respond on a handful of ports in under 5 seconds total. Results stream in as each service answers, so you do not wait for the slow ones to learn about the fast ones; the result is cached for 15 minutes per host so a refresh is instant.