How to fix exposed open ports (firewall and cloud rules)

What it is

Exposed ports are TCP or UDP services reachable from the public internet that should only be available to specific clients or internal networks. Common offenders are databases, admin panels, cache servers, and debug endpoints left bound to 0.0.0.0.

Why it matters

Every open port is an attack surface that gets brute forced, fingerprinted, and probed continuously. Closing or restricting ports removes whole classes of credential stuffing and exploit attempts before they reach the application.

How it is exploited

Unintended open ports expose admin panels, debug endpoints, legacy services with default credentials, and unauthenticated database listeners directly to the internet. Attackers fingerprint the service and version, then brute force credentials, replay known exploits, or connect straight into the data layer with no auth at all. A single compromised service often becomes a pivot point for deeper movement into the internal network.

How to fix it

1. Inventory what is listening. Run a port scan from outside your network and compare it to ss -tlnp or netstat on each host. The diff between expected and actual is your remediation list.
2. Lock down with a host firewall. Use ufw, iptables, or nftables to default-deny inbound traffic and allow only the ports your service truly needs. Bind services to a private interface or localhost when an external client never needs to reach them.
3. Narrow cloud security groups. In AWS, GCP, or Azure, tighten security groups and firewall rules to specific source CIDRs and ports. Avoid 0.0.0.0/0 on management ports like SSH, RDP, and database listeners.
4. Verify from the outside. Re-scan from an unauthenticated network to confirm the closed ports no longer respond. Schedule recurring scans so a future deploy or security-group edit does not silently re-expose the service.

Examples by platform

sudo ufw default deny incoming; sudo ufw allow 443/tcp

sudo iptables -P INPUT DROP
sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT
sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

aws ec2 revoke-security-group-ingress --group-id sg-0123456789abcdef0 --protocol tcp --port 22 --cidr 0.0.0.0/0
aws ec2 authorize-security-group-ingress --group-id sg-0123456789abcdef0 --protocol tcp --port 22 --cidr 10.0.0.0/16

References

• OWASP Top 10 A05:2021 Security Misconfiguration
• CWE-200

Related reading

• Fix server info disclosure (Server, X-Powered-By)
• Fix weak TLS (disable 1.0, 1.1, weak ciphers)
• How to fix subdomain takeover risk
• Run the network security check

Frequently asked questions

Why are open ports a risk?

Every public port is an attack surface that gets brute forced, fingerprinted, and probed continuously. Reachable admin panels, debug endpoints, and unauthenticated database listeners turn a single misconfiguration into direct access to the data layer.

Which ports should never be public?

Management and data-plane ports: SSH (22), RDP (3389), database listeners like 3306, 5432, 27017, 6379, 9200, internal admin UIs on 8080, 8443, 9090, and any debug or metrics endpoints. Bind them to a private interface or restrict the cloud security group to a known CIDR.

How do I scan my external ports?

Run Barrion's open ports scan or use nmap from a network that sits outside your VPC. Compare the result against ss -tlnp or netstat on each host. The diff between expected and actual is your remediation list, and re-scanning on a schedule catches future regressions.