Port Scanner

• What This Tool 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 the 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.