Free Online Port Scanner
Every service listening on the internet is a door. This scans your perimeter from outside - the same perspective an attacker has - and tells you which doors are open.
Run the scan
Start here: the free port scan runs an external port and service sweep against any target you own - an IP address or hostname - and shows you exactly what an attacker sees when they look at your perimeter. It's the same first step I take on an engagement, minus the exploitation: probe the common ports, identify what's listening, grab service banners, flag what's exposed. Results in minutes, no signup, nothing to install.
One rule before you type anything in: scan only what you own or are explicitly authorized to test. Your own public IPs, your VPS, your office connection - fine. A client's network without paperwork, a competitor, a stranger's server - not fine. Scanning a system you don't have permission to touch is illegal in most jurisdictions regardless of intent, and I was just checking has never held up as a defense. Authorization first, always.
What an open port means
A port is just a number a service uses to accept connections. When a scan reports a port as open, it means a program on that host is listening - bound to a network interface, answering anyone who knocks. Every listening service is attack surface: code someone wrote, exposed to the entire internet, with its own vulnerabilities, its own defaults, its own patch history.
That reframes the question you should be asking. Is port 3306 open? is trivia. Why is a database reachable from the internet at all? is security. Most exposed services I find in external scans were never meant to be public - someone installed software, it listened on every interface by default, and nobody told the firewall. The scanner isn't finding a vulnerability so much as a mistake.
Attackers run the same scan you can run here, at internet scale, continuously. The only difference is what they do with the list.
The ports worth knowing
These are the ports that show up most in external scans, and what my reaction is when I see each one:
- 21 - FTP. Should almost never be public. Credentials and files cross the wire in plaintext; use SFTP instead.
- 22 - SSH. Acceptable if it's key-only with password auth disabled. If passwords are on, it's being brute-forced right now.
- 23 - Telnet. Plaintext everything, no security at all. Kill it - there is no excuse in 2026.
- 25 / 587 - Mail. Legitimate if you actually run a mail server; make sure it isn't an open relay.
- 53 - DNS. Fine on your name servers; closed everywhere else.
- 80 / 443 - Web. The normal ones. The question is what's behind them and how well it's maintained.
- 110 / 143 - Legacy mail. POP3 and IMAP without encryption. Use 995 and 993 with TLS instead.
- 445 - SMB. Never expose this to the internet. EternalBlue and WannaCry lived here, and ransomware crews still scan for it daily.
- 1433 - Microsoft SQL Server. Belongs behind your VPN, not on the public internet.
- 1521 - Oracle DB. Same story - internal only.
- 3306 - MySQL. Databases don't belong on the internet. VPN or nothing.
- 3389 - RDP. The single most-abused entry point in ransomware incidents. VPN only, never naked on the internet.
- 5432 - PostgreSQL. Internal only.
- 5900 - VNC. Frequently weak authentication and rarely patched. VPN only.
- 6379 - Redis. No authentication by default. Never expose it - open Redis instances get hijacked for crypto-mining within hours.
- 27017 - MongoDB. Historically no auth out of the box, and a favorite of data-extortion crews.
- 9200 - Elasticsearch. Older versions shipped with no authentication. Attackers love it for data theft and ransomware leverage.
How to read your results
Three states matter. Open means a service accepted the connection - something is listening and talking. Filtered means you got no answer at all: a firewall dropped the probes silently. Closed means the host responded to say nothing is listening. Open ports are your real exposure. Closed ports are mostly noise - they confirm a host exists, which attackers already know. Filtered is the interesting middle: someone deliberately put a rule in front of that port, which usually means there's something behind it worth hiding, and it's worth asking whether the rule is doing its job.
The scan also grabs service banners - the short greeting a service sends when you connect: software name, version, sometimes the OS. Treat banners as hints, not proof. They can be outdated, misleading, or deliberately faked. An old OpenSSH banner on port 22 still means you should check the actual version; a missing banner doesn't mean the service is safe.
When you read your results, rank them by risk, not by port number. Anything you can't immediately name and justify goes to the top: database ports (1433, 3306, 5432, 6379, 27017), remote access ports (23, 3389, 5900), and anything above 1024 that nobody remembers configuring. A mystery port is a finding until proven otherwise.
Found something open that shouldn't be?
Don't just firewall it and move on. Closing the port stops future scans from seeing it, but it doesn't answer the questions that matter. Was the service patched? Anything exposed for a year is a patch-year behind, whatever it is. Does it keep logs - and do those logs go back far enough to show who connected? And the question nobody wants to ask: was it already abused? Exposed databases get copied and dumped. Exposed Redis gets hijacked within hours. Exposed RDP gets sold, then used.
If the honest answer to that last question might be yes, treat it as an incident, not a configuration error: isolate the host from the network, preserve evidence and logs before you reboot or reinstall anything, and rotate every credential that host could reach - from a clean device, because a compromised host is not a safe place to change passwords. I've laid out those first steps in order on the what to do if you've been hacked page.
If you'd rather have someone else do the digging - review the logs, verify patches, confirm whether anyone actually got in - that's what network penetration testing is for.
Going further
A port scan is reconnaissance, not a penetration test. It tells you which doors exist; it can't tell you which ones can be forced. The app behind your open 443 might be well-tested, or it might hand an attacker your internal network on the first request - no scanner knows the difference. That gap between exposed and exploitable is the difference between a vulnerability scan and a penetration test, and it's worth understanding before you decide you're done.
When you want the doors actually tested - someone trying to get through them and reporting exactly how far they'd get - that's a penetration test. Start on the services page to see what's covered.
Port scanning FAQ
Scanning your own systems is legal. Scanning someone else's without permission is not - in most jurisdictions it violates computer-misuse or anti-hacking law even when the scan causes no damage, because you're accessing a system you have no authorization to touch. Written permission is the line. If you're unsure whether you're authorized, you're not - ask first.
Only with explicit permission from whoever owns it or is responsible for it. Being reachable on the internet is not an invitation. If you want to test a client's perimeter, get written authorization that names the targets and the timeframe first - that's what I require before any engagement, and it's what protects you legally.
Closed means the host responded and told you nothing is listening on that port. Filtered means you got no answer at all - a firewall or filter silently dropped your probes. Filtered is the more interesting result: it usually means someone deliberately put a rule in front of that port, which suggests there's something behind it worth hiding.
Most often it's rate limiting or an intrusion-prevention system. Many firewalls drop or slow traffic that looks like a scan, so results vary with timing, source address, and how aggressive the scan is. It can also mean the service was restarted or the firewall rules changed. Re-run the scan and compare - a port that flip-flops between open and filtered is a configuration issue, not gremlins.
No. An open port means a service is reachable - it's exposure, not compromise. What matters is what the service is, whether it should be public at all, and whether it's patched and monitored. An open, patched, key-only SSH port is fine. An open Redis or RDP port is an incident waiting to happen. Exposure tells you where to look; it doesn't tell you what you'll find.
Open ports you can't explain?
Unknown services on your perimeter are how incidents start. Get them reviewed.