Website Port Security: Which Ports Should Be Open?

TL;DR: Most websites only need ports 80 (HTTP), 443 (HTTPS), and 22 (SSH) open. Every additional open port is a potential attack vector. Common mistakes include leaving database ports (3306, 5432), admin panels, and development tools publicly accessible. Regularly scan your servers for unexpected open ports and close anything you don't explicitly need.

Think of your server like a building with many doors. Each open port is an unlocked entrance that attackers might try. A secure building only opens the doors it absolutely needs, and your server should work the same way.

What are Network Ports? {#definition}

Network ports are virtual communication endpoints that allow different services to operate on the same server. When your web server receives a request on port 443, it knows to route that traffic to your HTTPS service. When it receives traffic on port 22, it routes to SSH. Ports range from 0 to 65535, with well-known services typically using ports below 1024. Open ports accept incoming connections; closed ports reject them.

Why Port Security Matters for Indie Hackers

You're busy building your product, not managing infrastructure. Port security still deserves your attention for several important reasons.

Automated tools scan the entire internet constantly, looking for open ports with vulnerable services. Your server gets probed whether you have 10 users or 10 million. These scans happen 24/7, and attackers are patient. They'll find and exploit any weakness eventually.

A single exposed port can compromise everything. An exposed database port, unprotected admin interface, or forgotten development tool can give attackers complete access to your system, your data, and your users' information.

Cloud providers often open more ports than necessary by default. That convenient setup wizard might have enabled services you don't need, and it's your responsibility to lock things down after provisioning.

Services you installed months ago might still be listening on ports you've forgotten about. That debugging tool you enabled once? That admin panel you were testing? Without regular auditing, these forgotten services become persistent vulnerabilities.

Essential Ports for Web Applications

Most web applications need only a few ports open to function.

Port 443 handles HTTPS, which is your encrypted web traffic. This must be open for users to access your website securely. Always use HTTPS rather than HTTP for production traffic.

Port 80 handles HTTP, the unencrypted version. While you shouldn't serve actual content over HTTP, keeping port 80 open allows you to redirect users to HTTPS automatically. It's also required for some SSL certificate validation methods like Let's Encrypt's HTTP-01 challenge.

Port 22 handles SSH, which provides command-line access to your server for administration. This should be open only if you need direct server access, and you should restrict it by IP address if possible. Consider using a VPN or bastion host instead of exposing SSH directly to the public internet.

Ports That Should Usually Be Closed

Database ports should never be directly accessible from the internet. This includes port 3306 for MySQL and MariaDB, port 5432 for PostgreSQL, port 27017 for MongoDB, and port 6379 for Redis. Applications should connect to databases through localhost or private networks only. Exposed database ports are among the most common and devastating security vulnerabilities. Attackers actively scan for them and can compromise your entire database within minutes of discovery.

Mail ports like 25 (SMTP), 110 (POP3), 143 (IMAP), and 465/587 (SMTP Secure) should only be open if you're actually running your own mail server. Most web applications send email through external services like SendGrid, Mailgun, or Amazon SES and don't need these ports exposed.

Management and admin ports present significant risks. Port 21 for FTP should never be used, so use SFTP over SSH instead. Port 23 for Telnet is completely unencrypted and should never be used for anything. Port 3389 for Windows Remote Desktop is a major attack target and should be behind a VPN if needed. Ports 8080 and 8443 often host admin panels or development servers and should be closed in production.

Development and debugging ports are particularly dangerous when left exposed. Port 9000 is commonly used by PHP-FPM and Xdebug, so never expose debugging tools to the internet. Ports like 4200 (Angular), 3000 (Node.js), and 5000 (Flask) are development server defaults and should never be accessible in production environments.

How to Audit Your Server's Open Ports

Scanning From Outside

The most accurate view of your exposure is from outside your network. Use online scanners or scan from a different network to see what the rest of the internet can reach:

# Using nmap from another machine
nmap -Pn -sV yourdomain.com

# Check specific common ports
nmap -Pn -p 21,22,23,25,80,443,3306,5432,6379,8080 yourdomain.com

Checking What's Listening Locally

On your server, you can see what services are listening for connections:

# Linux - show all listening ports
sudo netstat -tlnp

# Or with ss (modern replacement)
sudo ss -tlnp

# macOS
sudo lsof -i -P | grep LISTEN

Reviewing Firewall Rules

Check your firewall configuration to understand what's allowed through:

# iptables
sudo iptables -L -n

# ufw (Ubuntu)
sudo ufw status verbose

# firewalld (CentOS/RHEL)
sudo firewall-cmd --list-all

Checking Cloud Security Groups

If you're using AWS, GCP, or Azure, review your security group or firewall rules in the cloud console. These operate independently of OS-level firewalls, so you need to check both. A permissive cloud security group can expose ports even if the OS firewall would block them.

Documenting and Justifying Each Port

For each open port, document what service uses it, why it needs to be public, and what access restrictions are in place. If you can't justify an open port, close it. This documentation becomes invaluable when troubleshooting issues or onboarding new team members.

Port Security Best Practices

Apply the principle of least privilege by only opening ports that are absolutely necessary. Start with everything closed and open ports selectively based on actual requirements rather than convenience.

Use firewalls at multiple layers by configuring both cloud security groups and host-based firewalls. Defense in depth matters because if one layer fails or is misconfigured, another layer provides protection.

Restrict SSH access as much as possible. Limit SSH to specific IP addresses if you have a static IP or use a VPN. Use key-based authentication rather than passwords, disable password authentication entirely, and consider tools like fail2ban to block repeated failed attempts. Here's an example of allowing SSH only from a specific IP range:

# UFW example: allow SSH only from specific IP
sudo ufw allow from 203.0.113.0/24 to any port 22

Never expose databases publicly. Applications should connect via localhost or private networks. If you absolutely need remote database access for administration, use SSH tunneling or a VPN rather than exposing the database port directly.

Close development ports in production. Development servers on ports like 3000 or 8080 should never be accessible in production environments. Use environment-specific configurations to ensure these ports are only open in development.

Scan your servers regularly because port exposure can change with software updates, new service installations, or configuration changes. Regular scanning catches drift before it becomes a security incident.

Common Port Security Mistakes to Avoid

Exposing database ports "temporarily" is one of the most dangerous mistakes. There's no such thing as temporary when it comes to security. Attackers scan constantly, and even brief exposure can result in complete compromise. Set up proper secure access from the start.

Opening ports for debugging and then forgetting about them is extremely common. Xdebug, remote profilers, and diagnostic tools are frequently left enabled after a debugging session. These tools often have minimal or no authentication and can give attackers complete access to your application internals.

Trusting cloud default security groups leads to problems because many cloud instances come with overly permissive defaults. Always review and restrict security groups immediately after provisioning a new server, before deploying any applications.

Using security through obscurity provides false comfort. Running SSH on port 2222 instead of 22 doesn't meaningfully improve security because attackers scan all ports as a matter of routine. Real security comes from proper authentication, key-based access, and IP restrictions, not from hiding services on non-standard ports.

Not scanning from outside your network can leave you blind to your actual exposure. Services might appear closed locally but be accessible from the internet due to cloud security group configurations or network routing. Always verify your security posture from an external perspective.

Forgetting about IPv6 leaves a significant gap. IPv6 firewall rules are completely separate from IPv4. A carefully locked-down IPv4 configuration might have wide-open IPv6, leaving your server vulnerable to anyone connecting over IPv6.

Setting Up a Proper Firewall

For Ubuntu and Debian systems using UFW:

# Start with deny all
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Allow necessary ports
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 22/tcp

# Optionally restrict SSH to specific IPs
sudo ufw delete allow 22/tcp
sudo ufw allow from 203.0.113.0/24 to any port 22

# Enable firewall
sudo ufw enable

# Check status
sudo ufw status verbose

For CentOS and RHEL systems using firewalld:

# Set default zone to drop
sudo firewall-cmd --set-default-zone=drop

# Allow HTTP/HTTPS
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https

# Allow SSH
sudo firewall-cmd --permanent --add-service=ssh

# Reload
sudo firewall-cmd --reload

# Check status
sudo firewall-cmd --list-all

How SecurityBot Helps with Port Security

SecurityBot scans your servers for open ports and alerts you to unexpected exposure. You get regular port scans that detect new services listening publicly, change alerts that notify you when port status changes, risk assessment that highlights particularly dangerous ports like databases, and historical tracking that shows how your exposure has changed over time.

You can't secure what you don't know about. Let SecurityBot monitor your attack surface continuously.

Start your free 14-day trial - port scanning included with all plans.

Frequently Asked Questions

How do I know if someone is trying to access my closed ports?

Firewall logs show blocked connection attempts. On Linux, check /var/log/ufw.log for UFW or /var/log/firewalld for firewalld. Large numbers of attempts on unusual ports indicate scanning activity, which is normal. The important thing is that the attempts are being blocked.

Is running SSH on a non-standard port worthwhile?

Only minimally. It reduces noise from automated scans targeting port 22 specifically, but it doesn't provide real security because attackers routinely scan all ports. Focus your efforts on key-based authentication, fail2ban, and IP restrictions instead.

Should I open port 80 if I'm using HTTPS only?

Usually yes. Port 80 allows you to redirect HTTP requests to HTTPS automatically, which provides a better user experience when someone types your domain without the https:// prefix. It's also needed for some SSL certificate validation methods like Let's Encrypt's HTTP-01 challenge.

Isn't my cloud provider's firewall enough?

Cloud firewalls (security groups) and host firewalls serve different purposes and protect against different threats. Cloud firewalls protect against traffic from the public internet, while host firewalls can also protect against threats from within your cloud network (like compromised neighboring instances). Use both for defense in depth.

How often should I scan my servers?

At least monthly for most sites, and immediately after any infrastructure changes. If you're running critical applications with sensitive data, consider continuous monitoring to catch changes as soon as they happen.

Last updated: January 2026 | Written by Jason Gilmore, Founder of SecurityBot