Open Ports on Your Server: How to Check and Close What Shouldn't Be Exposed

In 2022, a MongoDB database with no authentication was found exposed on the internet containing 275 million records of Indian citizens — names, phone numbers, emails, employment history. No sophisticated attack was required. Port 27017 was open to the world, with no password. Anyone who knew where to look could access it.

This kind of incident is not the exception. It is the most common result of servers configured without attention to exposed ports. MySQL on 3306, Redis on 6379, admin panels on undocumented ports — every service running with its port publicly accessible is an attack surface that doesn't need to exist.

What Are TCP Ports and What Do They Do

When a server receives a network connection, the operating system needs to know which service should handle it. TCP ports solve this problem: they are numbers from 0 to 65535 that identify specific services running on the same machine.

When you visit yoursite.com, your browser connects to the server's IP on port 443 (HTTPS). The server knows that connections on that port should be handled by the web server. If it were port 25, it would be the mail server. Port 22 means SSH.

Open ports mean there is a process listening for connections at that address. An open port that shouldn't be publicly accessible is a vulnerability — not a hypothetical one, but real and exploitable.

Ports are divided into three ranges:

Well-known ports (0–1023): reserved for standard services — HTTP (80), HTTPS (443), SSH (22), FTP (21)
Registered ports (1024–49151): used by applications — MySQL (3306), PostgreSQL (5432), Redis (6379), MongoDB (27017)
Dynamic ports (49152–65535): used temporarily by the OS for outbound connections

Ports That Should Be Open vs. Dangerous Ports

Not every open port is a problem. The challenge is distinguishing what is necessary from what is unnecessary risk.

Ports that should be publicly accessible

Port	Service	Reason
80	HTTP	HTTPS redirects and certificate validation
443	HTTPS	Encrypted web traffic
25 / 587 / 465	SMTP	Email sending (if the server is an MTA)

Ports that should never be publicly exposed

Port	Service	Risk
3306	MySQL/MariaDB	Direct database access — credentials via brute force or exploits
5432	PostgreSQL	Same risk as MySQL, with a history of remote execution vulnerabilities
6379	Redis	No authentication by default in older versions; allows arbitrary writes to server files
27017	MongoDB	No authentication by default in older installations; unrestricted read/write on databases
11211	Memcached	Used in DDoS amplification attacks; no native authentication
9200	Elasticsearch	REST API with no authentication by default; exposes all indexed data
22	SSH	Should exist, but restricted by IP or replaced by VPN; never open to any source

The practical rule: databases, caches, and infrastructure services should not have ports accessible from the public internet. They should only be reachable from the internal network or via VPN.

How to Check Open Ports on Your Server

FlashMon's Online Port Scanner

The fastest way to check which ports on your server are externally visible is to use FlashMon's Port Scanner. Unlike local tools like nmap, FlashMon's scanner tests port visibility from the internet's perspective — meaning what an external attacker would see.

The tool checks 19 common ports and offers three presets to speed up the analysis:

Web: ports 80, 443, 8080, 8443 — ideal for application servers
Email: ports 25, 110, 143, 465, 587, 993, 995 — for mail servers
Database: ports 3306, 5432, 6379, 27017, 9200 — the most critical from a security standpoint

Results show for each port:

Open: port is accessible — a service is responding
Closed: port is not externally accessible — correct for internal services
Filtered: port is blocked by a firewall, but the IP is still visible

For deeper use in a controlled local environment, nmap remains the reference tool:

# Check the most common ports
nmap -sV yourserver.com

# Check all ports
nmap -p- yourserver.com

# Check with service and version detection
nmap -sV -sC -p 22,80,443,3306,6379,27017 yourserver.com

How to Close Unnecessary Ports

Found a port that shouldn't be open? The process depends on where you're running your server.

Linux with iptables

iptables is the default firewall on older Linux distributions. To block external access to port 3306 (MySQL) while keeping local access:

# Block external access to port 3306
iptables -A INPUT -p tcp --dport 3306 -j DROP

# Allow only connections from localhost (app on the same server)
iptables -A INPUT -p tcp --dport 3306 -s 127.0.0.1 -j ACCEPT

# Save the rules (Ubuntu/Debian)
iptables-save > /etc/iptables/rules.v4

Linux with UFW (Ubuntu/Debian)

UFW is a simplified interface over iptables, more common on modern servers:

# Enable UFW
ufw enable

# Allow only SSH, HTTP, and HTTPS
ufw allow 22
ufw allow 80
ufw allow 443

# Block everything not explicitly allowed
ufw default deny incoming

# Check the status
ufw status verbose

Cloud: Security Groups (AWS, GCP, Azure)

In cloud environments, port control is handled through the platform's security groups or firewall rules — and this control layer should be the first line of defense, independent of the OS-level firewall.

In the AWS console, for example:

Go to EC2 → Security Groups
Select the group associated with the instance
Under "Inbound rules," remove any rule that allows access to database ports with source 0.0.0.0/0 (any IP)
Replace them with rules that only allow access from the application's security group or a specific VPN IP

The same principle applies to GCP (VPC Firewall Rules) and Azure (Network Security Groups).

Configure the Service to Listen Only on Localhost

Beyond the firewall, configure the service itself to not listen on public interfaces. For MySQL, in /etc/mysql/mysql.conf.d/mysqld.cnf:

bind-address = 127.0.0.1

For Redis, in /etc/redis/redis.conf:

bind 127.0.0.1 ::1

This configuration ensures that even if the firewall is misconfigured, the service will not accept external connections.

Further Checks: Beyond Ports

Closing the right ports is the most important step, but a server's security posture involves other layers. After confirming that database ports are closed, it's worth checking:

HTTP security headers: use FlashMon's Security Headers checker to confirm your web server is sending Strict-Transport-Security, Content-Security-Policy, and other headers that protect against client-side attacks
SSL certificate: FlashMon's SSL Checker verifies that your certificate is valid, the trust chain is correct, and that old protocols (TLS 1.0, 1.1) have been disabled

Run the Scan Now

Checking for open ports is one of the simplest security audits with the highest direct impact. It takes under a minute, requires no software installation, and immediately reveals whether you have exposed services that shouldn't be.

Check your server's open ports now — it's free

Keep going

Lock the HTTP layer next: the guide to HTTP security headers and the Security Headers checker close the gaps that an open-port audit won't catch.
Verify your TLS configuration with the SSL Checker.