Port Scanner
Port Scanner helps you check if specific ports are open, for routing analysis, ownership checks, and faster network troubleshooting.
Advertisement · Anuncio
Advertisement · Anuncio
Technical Analysis & Guide
What It Does
Port Scanner checks if specific TCP/UDP ports are open, closed, or filtered on a target host, helping identify running services and potential security issues.

Why It Matters
- →Service Verification: Confirm services are accessible (web, mail, etc.)
- →Security: Identify unnecessarily open ports that could be exploited
- →Firewall Testing: Verify firewall rules are working correctly
- →Troubleshooting: Diagnose connectivity issues for specific services
How to Read Results
- Open: Port accepts connections - service is running
- Closed: Port reachable but no service listening
- Filtered: Port blocked by firewall - no response
- Common Ports: 80 (HTTP), 443 (HTTPS), 25 (SMTP), 22 (SSH), 3306 (MySQL)
Technical Background
TCP port scanning works by initiating a three-way handshake (SYN → SYN-ACK → ACK) to verify if a service is listening. An open port responds with SYN-ACK; a closed port responds with RST (Reset); a filtered port produces no response — the firewall silently drops the probe. UDP port scanning is inherently less reliable because UDP is connectionless — no response could mean open or filtered, making detection ambiguous.
Port categories defined by IANA: Well-known ports (0-1023) require root/admin to bind and include: 22 (SSH), 25 (SMTP), 53 (DNS), 80 (HTTP), 110 (POP3), 143 (IMAP), 443 (HTTPS), 465/587 (SMTP+TLS), 993 (IMAPS), 995 (POP3S). Registered ports (1024-49151) are for specific applications: 3306 (MySQL), 5432 (PostgreSQL), 6379 (Redis), 8080/8443 (HTTP/HTTPS alternate), 27017 (MongoDB). Dynamic/ephemeral ports (49152-65535) are used by OS for outbound client connections.
From a security perspective, only ports serving intentionally exposed services should be open. The principle of least privilege applies: if a service is only needed internally, bind it to localhost (127.0.0.1) rather than all interfaces (0.0.0.0). Common security misconfigurations include: database ports (3306, 5432, 27017) exposed publicly without firewall rules, administrative web panels accessible on non-standard ports, RDP (3389) exposed without VPN or IP allowlisting, and development servers inadvertently left running on production hosts. Regular port scanning of your own infrastructure is a recommended security practice — it helps discover unauthorized services, shadow IT, and misconfigurations before attackers do.
Regular external port scanning of your own organizations internet-facing infrastructure is a fundamental security hygiene practice. Automated tools like Shodan, Censys, and FOFA continuously scan the internet and maintain indexes of open ports and exposed services — attackers use these to find vulnerable targets. Staying aware of what your infrastructure exposes publicly allows you to remediate before attackers discover it. Security teams should maintain an asset inventory with expected open ports, run quarterly firewall audits, and use network segmentation to limit blast radius if a service is compromised. Common attack vectors include exposed RDP (3389), Telnet (23), and database ports without authentication controls.
For web application firewall (WAF) and intrusion detection deployments, understanding expected vs unexpected open ports is fundamental. Security auditors use tools like nmap, masscan, and Shodan to map an organizations external attack surface. A zero-trust network architecture assumes breach and requires all services — even internal ones — to use encrypted connections with strong authentication regardless of network location. Containers and cloud deployments add complexity: Kubernetes, Docker Swarm, and cloud provider security groups must be audited regularly. Key ports to monitor: 22 (SSH) should be restricted to management IPs only, 3389 (RDP) should never be exposed publicly, and any database port should be behind a VPN.
Common Errors and How to Fix Them
- ProblemThe service runs and answers locally, but the check reports the port as closed.
- FixThe daemon is probably bound to 127.0.0.1 only. Check with 'ss -tlnp' (Linux) or 'lsof -iTCP -sTCP:LISTEN' (macOS) and bind to 0.0.0.0, [::] or the public interface address.
- ProblemThe host firewall allows the port, yet the check times out as closed/filtered.
- FixA second layer is dropping packets: a cloud security group, network ACL or the provider's edge firewall. Open the port there as well, ideally limited to the source ranges that actually need it.
- ProblemPort 25 on a home or small-office connection never appears open.
- FixMany residential ISPs block port 25 to curb spam. Run inbound mail on a hosted service or business line, and use port 587 with authentication for outgoing submission.
- ProblemA service behind a home router is tested by its public IP and shows closed.
- FixWithout a port-forwarding rule, the router has nowhere to send the connection. Add a forward from the public port to the internal IP and port, and check that the ISP does not place you behind carrier-grade NAT, which makes inbound connections impossible.
- ProblemThe port shows open, but clients still cannot use the service.
- FixOpen only means a TCP handshake succeeded. Verify the application itself: use the HTTP check or SSL check for web ports, an SMTP check for mail, or a protocol client, since a proxy or wrong service may be listening.
- ProblemDatabase or cache ports such as 3306, 5432, 6379 or 27017 show open to the whole internet.
- FixThese services are scanned constantly and are frequent breach sources. Close them publicly, allow access only from application servers or a VPN, and require authentication and TLS.
Frequently Asked Questions
What is the difference between 'closed' and 'closed/filtered' in the result?
'Closed' means the target actively refused the connection, usually with a TCP reset, so the host is reachable but nothing listens on that port. 'Closed/filtered' means no answer arrived within five seconds, typically because a firewall silently dropped the SYN packet. The first points to the service; the second points to a firewall or routing issue.
Can this tool test UDP ports?
No. It performs a TCP connection attempt to one port at a time. UDP is connectionless, so a missing reply could mean open, filtered or simply a service that ignores empty packets; reliable UDP testing needs a protocol-specific request, such as a DNS query to port 53. Use 'nc -vzu host port' locally as a rough first check.
The port is open here but I cannot connect from my office. Why?
The test runs from our server, so it proves the port is reachable from the public internet. Your office network may block outbound connections to that port, use a proxy, or resolve the hostname differently. Our check also prefers the IPv4 address, so an IPv6-specific problem would not appear here.
Is it legal to check ports on a server?
Checking a single port on systems you own or administer is routine troubleshooting. Scanning systems without permission may breach provider terms and, in some jurisdictions, computer misuse laws. This tool tests one port per request and refuses private, loopback and reserved addresses, so it cannot be used to probe internal networks.
Which ports should be open on a typical web server?
Usually just 80 and 443 for the public. Port 80 should only redirect to HTTPS and answer certificate validation. SSH on 22 should be restricted to known addresses or reached through a VPN or bastion host, and database, cache and admin panel ports should never face the internet.
Academic Documentation
Protocol context and primary references
REST API Documentation
v1.0GET /api/tools/port-check
curl -X POST https://epcybertools.com/api/tools/port-check \
-H "Content-Type: application/json" \
-d '{"host":"google.com","port":443}'
{
"success": true,
"results": [
{ "test": "Sample Check", "status": "pass", "message": "All clear" }
]
}
Usage Examples
# Check if port 443 is open
nc -zv example.com 443
# Scan multiple ports
nc -zv example.com 80 443 22 25
# Using curl to test HTTP port
curl -s --connect-timeout 3 telnet://example.com:25 && echo open || echo closed