Port Scanner

An open port scanner (also called a port checker or port forwarding tester) probes specific TCP or UDP ports on a remote host to determine whether services are reachable from the internet. Every network service binds to a port number — web servers listen on 80 and 443, SSH on 22, databases on ports like 3306 or 5432. Knowing which ports are exposed is the first step in both network troubleshooting and security hardening.

This tool scans from our external infrastructure, so results show how your target appears to the public internet — accounting for firewalls, NAT, cloud security groups, and ISP-level filtering. Use it to verify port forwarding on your router, check that your firewall rules are working, or test whether a service is accessible after deployment. Unlike netstat or ss which show local listening sockets, this tests actual reachability from outside your network.

Choose from purpose-built scan presets for common scenarios — web stack verification, cloud infrastructure auditing, attack surface assessment, IoT device scanning, DevOps exposure checks, database exposure, mail server validation, and game server connectivity — or enter custom port numbers. Both TCP and UDP protocols are supported.

This tool supports both TCP and UDP scanning, which work fundamentally differently due to the nature of each protocol:

Use TCP for most diagnostics — it's faster and more reliable. Switch to UDP when testing services that use it: DNS (53), NTP (123), SNMP (161), game servers (many use UDP), WireGuard (51820), or SIP (5060).

After provisioning a server on AWS, GCP, or Azure, the first thing to verify is which ports are actually reachable from outside. Cloud providers use security groups, network ACLs, and firewall rules that default to restrictive — but misconfigurations are the leading cause of cloud data breaches.

The Cloud Infra Audit preset checks the ports most commonly misconfigured in cloud deployments:

If any of these show as open on your cloud instance, review your security group rules immediately. Databases and caches should never be publicly accessible — use private subnets, VPC peering, or SSH tunnels instead.

The Attack Surface preset targets the ports most commonly exploited in real-world attacks. These are the same ports that automated scanners, botnets, and penetration testers probe first:

• •SMB (445) — The protocol behind EternalBlue, WannaCry, and NotPetya. Should never be exposed to the internet. If open, it indicates a severe misconfiguration.
• •RDP (3389) — A top target for brute-force and credential stuffing attacks. BlueKeep (CVE-2019-0708) allowed remote code execution without authentication. Always use a VPN or jump host.
• •Telnet (23) — Transmits credentials in plaintext. Still found on IoT devices, industrial systems, and legacy network equipment. The Mirai botnet spread primarily via default Telnet credentials.
• •Memcached (11211) — Used in the largest DDoS amplification attacks ever recorded (1.3 Tbps against GitHub in 2018). Should never face the public internet.

Run the Attack Surface scan against your own infrastructure regularly, and use the website reputation checker to verify your domain is not flagged by security vendors. If any of these ports appear as open unexpectedly, treat it as a security incident and investigate immediately.

IoT devices — cameras, routers, smart home hubs, industrial controllers — are among the most targeted endpoints on the internet. The Mirai botnet and its variants have compromised millions of devices by scanning for default credentials on exposed management ports.

The IoT & Embedded preset checks the ports most commonly left open on these devices:

• •Telnet (23) — Still the default remote access method on many IP cameras, routers, and embedded Linux devices. Credentials are transmitted in plaintext and factory defaults are widely known.
• •MQTT (1883) — The standard IoT messaging protocol. Many brokers run without authentication, allowing anyone to subscribe to sensor data or publish commands to connected devices.
• •RTSP (554) — IP cameras stream video over RTSP. Exposed cameras with default or no credentials are indexed by search engines like Shodan and Censys.
• •UPnP (1900) & Modbus (502) — UPnP can automatically punch holes in your firewall. Modbus, used in industrial control systems, has zero built-in authentication — any internet exposure is critical.

If you manage IoT devices or have smart home equipment, find your public IP address and scan it with this preset. Any open port is a potential entry point — these devices rarely receive security patches.

Container orchestration platforms, CI/CD pipelines, and monitoring tools are powerful — and catastrophic when accidentally exposed to the internet. The DevOps Exposed preset targets the management ports that should only be reachable from internal networks.

These ports should never appear as open on a public scan. If any do, your CI/CD pipeline or container platform is directly accessible from the internet — restrict access with firewall rules or private networking immediately.

Active Directory is the backbone of enterprise Windows networks — and the primary target in most corporate breaches. The Windows Domain preset checks the ports that AD domain controllers and member servers expose:

• •Kerberos (88) — AD authentication protocol. Exposed Kerberos enables Kerberoasting attacks where attackers request service tickets and crack them offline to obtain service account passwords.
• •LDAP (389) & LDAPS (636) — Directory queries can enumerate every user, group, and computer in the domain. Exposed LDAP is a goldmine for credential harvesting and reconnaissance.
• •SMB (445) & MS-RPC (135) — Used for file sharing, group policy, and remote management. Attackers use these for NTLM relay attacks, lateral movement, and ransomware deployment (WannaCry, NotPetya).
• •WinRM (5985) — PowerShell remoting over HTTP. With valid credentials, attackers can execute arbitrary commands on any domain machine. A key tool in lateral movement and living-off-the-land attacks.

AD ports should never be reachable from the public internet. If you're running a domain controller, these ports should only be accessible within your corporate network or via VPN. Any external exposure is a critical finding.

Publicly exposed databases are one of the most common causes of data breaches. The Database Exposure preset scans the default ports for every major database engine to ensure none are directly reachable from the internet.

Databases belong in private subnets with no public IP. Access should go through SSH tunnels, bastion hosts, or VPN connections. Even password-protected databases are vulnerable to brute-force attacks and protocol-level exploits when exposed directly.

The Remote Access preset checks protocols used for remote server management and VPN connectivity. Some of these are expected to be open (SSH, VPN endpoints), while others should be locked down or replaced with secure alternatives.

• •SSH (22) — The standard for secure remote access. Expected to be open on servers, but should use key-based authentication and be restricted by source IP where possible.
• •RDP (3389) & VNC (5900) — Graphical remote desktop protocols. Both are frequent brute-force targets and should be behind a VPN or zero-trust access proxy rather than directly exposed.
• •OpenVPN (1194) & WireGuard (51820) — VPN tunnel endpoints. These are expected to be open if you run a VPN server. WireGuard uses UDP and won't respond to probes unless the client presents a valid public key, so it may show as filtered even when running.

Running your own mail server requires specific ports to be open for delivery and client access. The Mail Server preset verifies the full set:

Port 25 must be open for your server to receive email, but many cloud providers block outbound port 25 by default to prevent spam. If you can't send email, check that your provider hasn't restricted it. Use the DNS Inspector to verify your MX, SPF, DKIM, and DMARC records are correctly configured alongside your mail server ports.

The Web Stack preset covers the ports used by web servers, reverse proxies, and application frameworks. On a production server, you typically want only ports 80 and 443 open — everything else should be internal.

• •HTTP (80) & HTTPS (443) — Your public-facing web ports. Port 80 should redirect to 443. If neither is open, your website isn't reachable.
• •8080 & 8443 — Common alternate ports for reverse proxies, Tomcat, API gateways, and admin panels. If these are open in production, verify they're intentional and not leaking internal services.
• •Dev ports (3000, 5173, 8000) — Development server ports for Node.js, Vite, and Django. These should never be open in production. If they appear as open, a dev server may be running on a public machine.

For a port to appear as open from the internet, every layer between the scanner and the service must allow the traffic. Understanding these layers helps diagnose why a port might show as filtered even when your service is running:

• •ISP-Level Blocking — Many residential ISPs block incoming connections on common server ports (25, 80, 443) to prevent customers from running servers. This cannot be bypassed without changing to a business-class connection or using non-standard ports.
• •Router NAT / Port Forwarding — If your server is behind a NAT router, you must configure port forwarding to map the external port to your internal server IP and port. Without this, incoming connections stop at the router.
• •Cloud Security Groups / ACLs — Cloud providers (AWS, GCP, Azure) require explicit inbound rules in security groups or network ACLs. Even if your server's firewall allows the port, the cloud-level rules must also permit it.
• •Host Firewall — Software firewalls on the server itself (iptables, nftables, ufw, Windows Firewall) are the final gate. The service must be running and the firewall must allow inbound connections on the target port.

This tool tests the entire chain from outside. If a port shows as filtered, work through each layer from the outermost (ISP) inward to find where packets are being dropped.

Hosting a game server requires the correct ports to be open and forwarded. Each game uses specific port numbers that players connect to. Some games use TCP, others use UDP, and many use both — switch between protocols using the dropdown to verify each:

When setting up a game server, configure port forwarding on your router, open the port in your firewall, then use this tool to verify it's accessible. If the port shows as open, players on the internet can connect to your server.

Every port scan result falls into one of these categories. Understanding the difference is essential for interpreting results correctly:

A well-secured server should show only intentionally exposed ports as open, with everything else filtered. Use the IP Location tool to check the security profile of IPs connecting to your services, and the Propagation Checker to verify your DNS points to the correct server before running port scans. To investigate other domains hosted on the same server, use the find domains on an IP tool.