Are Your Database and Server Ports Exposed? Port Security Guide

Why open ports are the #1 target for automated botnets

Every computer connected to the internet communicates through 65,535 TCP and UDP ports. While web servers must keep ports 80 (HTTP) and 443 (HTTPS) open to serve public web traffic, leaving sensitive database, management, or caching ports exposed to the public internet is one of the most common causes of catastrophic data breaches.

Automated threat networks (such as Shodan, Censys, and malicious botnet scanners) constantly scan the entire IPv4 address space. When a database port is detected open:

1. Brute-Force Attacks: Botnets launch credential-stuffing dictionaries against default usernames (root, admin, postgres).
2. Unauthenticated Access: Many databases (such as Redis or Elasticsearch) historically have no authentication enabled by default, allowing attackers to dump entire customer databases or wipe tables in seconds.
3. Ransomware Extortion: Automated scripts drop ransomware notes into exposed databases, export your records, delete your live tables, and demand payment in Bitcoin.

High-risk ports that should never be public

Unless you have an extraordinarily specific architectural requirement, the following ports should never listen on public interfaces (0.0.0.0):

| Port | Service | Risk Level | Threat Scenario | | :--- | :--- | :--- | :--- | | 3306 | MySQL / MariaDB | CRITICAL | Direct database exfiltration, SQL brute-force attacks, root escalation. | | 5432 | PostgreSQL | CRITICAL | Automated password cracking, unauthorized query execution, table destruction. | | 27017 | MongoDB | CRITICAL | Unauthenticated collection dumps, automated ransomware wiping. | | 6379 | Redis Cache | CRITICAL | In-memory session theft, remote code execution (RCE) via cron overwrites. | | 9200 | Elasticsearch | CRITICAL | Full-text indexing leaks, proprietary customer document downloads. | | 22 | SSH | HIGH | Relentless automated brute-force attacks, SSH daemon vulnerability exploits. | | 21 | FTP | HIGH | Plaintext credential transmission, directory traversal exploits. | | 3389 | RDP (Windows) | CRITICAL | BlueKeep exploits, full interactive desktop takeover, ransomware deployment. | | 8080 / 8443 | Dev / Staging Web | MEDIUM | Leaking unpatched staging apps, administrative consoles, and internal APIs. |

How to scan your server ports online

Before attackers scan your infrastructure, audit your exposed attack surface using our free Open Port & Firewall Status Checker.

The tool performs non-destructive TCP socket connection tests across your public IP or domain name, checking:

• Standard web ports (80, 443).
• Administrative consoles (8080, 8443, 22).
• Critical database services (3306, 5432, 27017, 6379, 9200).
• Provides instant firewall remediation snippets for any exposed sensitive services.

Verifying locally via netstat and lsof

You can also inspect which services are listening on your server's network interfaces directly via SSH:

# View all listening TCP ports and associated processes
sudo ss -tulpn | grep LISTEN

Look closely at the Local Address column:

• 127.0.0.1:3306 → SAFE: Listens only on local loopback. Outside internet connections are blocked.
• 0.0.0.0:3306 or :::3306 → DANGEROUS: Listens on all public interfaces. Open to the entire world!

How to lock down exposed ports with UFW and iptables

1. Bind your database service to localhost only

The most robust fix is configuring your database daemon to listen exclusively on loopback (127.0.0.1 or localhost).

For MySQL / MariaDB (/etc/mysql/my.cnf or mysqld.cnf):

[mysqld]
bind-address = 127.0.0.1

For PostgreSQL (/etc/postgresql/<version>/main/postgresql.conf):

listen_addresses = 'localhost'

For Redis (/etc/redis/redis.conf):

bind 127.0.0.1 ::1
protected-mode yes

Restart the service after editing to apply the change.

2. Configure a default-deny firewall with UFW (Ubuntu/Debian)

If you manage a Linux VPS, enable Uncomplicated Firewall (UFW) with a strict default-deny policy:

# Set strict default incoming policy
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Allow only standard web traffic
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Restrict SSH (port 22) to your office/home static IP
sudo ufw allow from 203.0.113.50 to any port 22 proto tcp

# Enable the firewall
sudo ufw enable

3. Use Cloud Security Groups (AWS, GCP, DigitalOcean)

If your instance runs on AWS EC2, Google Cloud, or DigitalOcean:

• In your cloud management console, navigate to your Security Group or Cloud Firewall.
• Ensure Inbound Rules permit only port 80 and 443 from 0.0.0.0/0.
• Delete any inbound rules opening ports 3306, 5432, or 6379 to 0.0.0.0/0.

Best practices for secure remote database access

If developers or BI reporting tools genuinely need to connect to your database from external locations, use one of these secure connection patterns rather than exposing raw database ports:

1. SSH Port Forwarding (SSH Tunneling): Connect to your database securely through an encrypted SSH tunnel without opening database ports:

   ssh -L 3307:127.0.0.1:3306 user@yourserver.com
   

   Now point your database client (such as DBeaver, TablePlus, or DataGrip) to 127.0.0.1:3307.
2. Private VPC & Bastion Host: Keep all database instances in an isolated private subnet with no public IP address. Connect through an authenticated VPN or bastion jump box.
3. Tailscale / WireGuard Mesh VPN: Connect all servers and developer laptops into a zero-trust WireGuard mesh network. Database traffic travels over a private overlay network invisible to public internet scanners.