Skip to content
itsorted.online
Cybersecurity guide

Which Ports Should Be Open on Your Server? A Firewall Check

Most small business servers need only two ports open to the whole internet: 80 and 443 for the website. Everything else, from SSH to databases and admin panels, should be closed or limited to known addresses. Attackers scan the whole internet continuously for open ports, so a database or Docker API left exposed is usually found quickly. This guide lists which ports to open, which to close, how cloud firewalls and server firewalls fit together, and how to check what is really reachable from outside in about fifteen minutes.

By IT Sorted teamReviewed 7 min readHow we write guides
in

Key takeaways

  • A public website usually needs only ports 80 and 443 open to all; everything else should be restricted.
  • SSH should accept only your office or VPN IP addresses, with key-only login.
  • Databases, Redis, the Docker API and admin panels should never be reachable from the internet.
  • Docker-published ports can bypass UFW, so use your cloud firewall as the outer wall.
  • Always check from outside the server: what you configured and what is reachable can differ.
In this guide · 8 sections
  1. 01Which ports should be open: a quick reference
  2. 02Cloud firewall vs host firewall: use both
  3. 03The Docker and UFW trap
  4. 04How to check which ports are open on your server
  5. 05Safe SSH and admin access without leaving ports open
  6. 06What a CIS benchmark adds
  7. 07Do it yourself or get help?
  8. 08Frequently asked questions

Short answer

For a typical web server, open 80 and 443 to everyone, allow SSH (22) only from your office or VPN IP, and keep databases (3306, 5432, 6379, 27017), the Docker API (2375) and admin panels closed to the internet. Set it in your cloud firewall and add UFW on the server.

Which ports should be open: a quick reference

A port is a numbered door on your server that a service listens on. The rule is simple: open a door only if strangers on the internet need it. For a business website, that is the web traffic ports and nothing else.

PortServiceOpen to
80HTTP (redirects to HTTPS)Everyone
443HTTPS (your website)Everyone
22SSH (server admin)Your office or VPN IP only
25, 465, 587, 993Mail server (only if you run one)Everyone, only if this server handles email
3306, 5432MySQL, PostgreSQL databasesNobody outside; local or private network only
6379, 27017Redis, MongoDBNobody outside
2375, 2376Docker Remote APINobody outside; use SSH or TLS with client certificates
3389Windows Remote DesktopVPN only
2083, 2087, 8443, 8080cPanel, WHM, Plesk, app admin panelsYour IP only, with 2FA
21FTPClose; use SFTP over SSH instead
Default port numbers; your server may use different ones. Check what is actually listening.

Cloud firewall vs host firewall: use both

There are two places to block ports. A cloud firewall is set in your provider's dashboard and filters traffic before it reaches the server. A host firewall such as UFW or firewalld runs on the server itself.

Cloud firewall

Outer wall
  • DigitalOcean Cloud Firewalls are free and block everything not allowed by a rule
  • Lightsail and AWS security groups work the same way
  • Not affected by Docker or software on the server
  • Still protects if the server's own firewall is switched off

Best for: Every VPS and cloud server.

Host firewall (UFW, firewalld)

Inner wall
  • Ubuntu's default tool is ufw, disabled until you enable it
  • Can rate-limit SSH and log blocked connections
  • Works even if the provider has no firewall
  • Docker-published ports can bypass it

Best for: A second layer and fine-grained rules.

DigitalOcean says its Cloud Firewalls are provided at no additional cost and block all traffic that is not expressly permitted. AWS notes in its Lightsail firewall guide that new Linux instances allow SSH on port 22 from all IP addresses by default, and that if two rules cover the same port the more permissive one wins. Check and tighten those defaults.

The Docker and UFW trap

Many small business apps now run in Docker. Docker's own packet filtering documentation warns that Docker and ufw are incompatible: when you publish a container port, traffic is routed before it reaches the chains ufw uses, "effectively ignoring your firewall configuration".

In practice, a line like `ports: "5432:5432"` in a docker-compose file can expose your database to the internet even though UFW says port 5432 is denied. Two fixes:

  • Bind internal services to localhost only, for example `127.0.0.1:5432:5432`, or do not publish them at all and let containers talk over a Docker network.
  • Rely on the cloud firewall as the outer wall, since Docker cannot bypass a filter that sits outside the server.

Our guide to the CARBONATO Docker botnet covers checking a Docker host for signs of compromise.

How to check which ports are open on your server

Check from both sides: what the server is listening on, and what the internet can actually reach.

  1. List what is listening on the server

    Run `sudo ss -tulpn`. Anything listening on 0.0.0.0 or [::] accepts connections on every network interface. Anything on 127.0.0.1 is local only, which is what you want for databases.

  2. Review the cloud firewall rules

    In your provider's dashboard, list every inbound rule. Remove rules for ports you do not recognise and change "all IPs" to your office IP for SSH and admin panels.

  3. Review the host firewall

    Run `sudo ufw status verbose`. Ubuntu's firewall guide shows how to allow a port only from one address, for example SSH from your office IP.

  4. Scan from outside

    From a different network (home connection or a separate VPS), run `nmap -Pn your-server-ip`, or use an online port scanner. Only scan servers you own or are authorised to test.

  5. Fix and re-scan

    Close anything unexpected, then scan again. Compare the result with your list of services that should be public.

  6. Repeat after every change

    New apps, Docker updates and control panel installs often open ports. Re-check after each deployment and at least monthly.

Safe SSH and admin access without leaving ports open

SSH is the most common port people leave open to the world. Restricting it does not mean losing access.

Admin access checklist

If your office IP changes often, a small VPN or a zero-trust access tool lets staff reach admin ports without opening them to everyone. CSA's Cyber Essentials mark also expects secure configuration and limited admin access, so these steps count towards it.

What a CIS benchmark adds

The Center for Internet Security publishes free CIS Benchmarks, detailed hardening guides for Ubuntu, Debian, Windows Server, Docker and cloud platforms. They include firewall rules and much more: services to disable, logging, file permissions and account settings.

A full benchmark is long, and not every control suits a small web server. A practical approach is to apply the firewall, SSH and update sections first, then work through the rest as time allows, recording any control you deliberately skip and why.

Do it yourself or get help?

If you are comfortable on the command line, the steps above take under an hour for one server. If the server was set up by a developer who has moved on, runs Docker, or you are not sure what each open port does, get it reviewed before closing things, so you do not break the site.

IT Sorted is a Singapore-based team of developers with over 10 years of experience. Our Software & Server Protection Setup (S$590 for one server) sets up UFW or your cloud firewall with only the ports you need, key-only SSH with root login off, brute-force protection, automatic security updates, daily malware scans and a written runbook, all on tools in your own account. Security testing that tries to break in is not included and needs a CSA-licensed provider.

Frequently asked questions

For a typical business website, only ports 80 and 443 need to be open to everyone. Port 80 should redirect to HTTPS on 443. SSH on port 22 should be limited to your own IP addresses. Databases, caches, the Docker API and admin panels should not be reachable from the internet at all.

Leaving SSH open to the whole internet invites constant password-guessing attempts. With key-only login and brute-force protection the risk is lower, but the safest setup allows port 22 only from known office, home or VPN addresses. Changing the port number reduces log noise but is not a security control on its own.

Not reliably. Docker's documentation says published container ports are routed before traffic reaches the chains ufw uses, so ufw rules can be ignored. Bind internal services to 127.0.0.1, avoid publishing ports that do not need to be public, and use your cloud provider's firewall as the outer layer.

Run a port scan from a different network, for example with nmap from your home connection or a second server, or use an online port scanner. Compare the result with the ports you expect to be public. Only scan servers you own or have written permission to test.

It is best to use both. The cloud firewall blocks traffic before it reaches the server and cannot be bypassed by Docker or misconfigured software. The host firewall is a second layer that still works if a cloud rule is changed by mistake, and can rate-limit SSH and log blocked attempts.

Rather have it done for you?

Fixed price, set up in your own accounts.

Order online, get a written scope, and keep full ownership of everything we set up. Questions first? Ask us in writing.