Tous les articles

security

How to Close Open Ports on Linux You Don’t Need

A plain-English guide to finding open Linux ports, deciding what should stay reachable, and closing the rest safely.

  • security
  • firewall
  • linux
A Linux server panel sends only one approved green port through a firewall while unused ports are locked closed.

An open port you forgot about can feel like a side door left unlocked: maybe nobody notices, but you still do not want it sitting there.

Short version: To close open ports on Linux, first find what is listening, then either stop the service that opened the port or block the port with a firewall such as ufw or firewalld. Keep only the ports your server actually needs, usually SSH, HTTP, and HTTPS, and check again afterward so you know the door is really closed.

What is an open port on Linux?

A port is like a numbered service desk inside your server. When software wants to receive traffic from the internet, it listens at one of those desks.

For example, websites usually listen on port 80 for HTTP and port 443 for HTTPS. SSH, the remote login service, usually listens on port 22. A database might listen on 5432 for PostgreSQL or 3306 for MySQL.

An open port means something is ready to answer there. That may be exactly what you want for a website. Or it may be an old test app, admin panel, database, or dashboard that should never be reachable from the public internet.

Closing a port means one of two things:

  • The program behind it is stopped, so nobody is listening.
  • A firewall blocks outside traffic before it reaches the program.

Both are useful. Stopping the program removes the desk. A firewall is the locked door in front of it.

Which ports should stay open?

Most small servers need very few public ports.

For a normal website, you usually keep:

  • 22 for SSH, unless you use another access method or changed the SSH port.
  • 80 for HTTP, often needed for redirects and certificate checks.
  • 443 for HTTPS, the secure version of your site.

Everything else deserves a question: who needs to reach this from the internet?

A database often does not. A cache such as Redis often does not. A private admin tool often does not. Those services may need to talk to your app inside the server, but that is different from being open to everyone online.

Think of it like a building. The front entrance can be public. The kitchen, records room, and electrical closet should not have their own street-facing doors.

If you are still setting up the basics, our firewall guide explains the bigger picture: How to set up a firewall on your server.

How do you close open ports on Linux safely?

Do this in a calm order. The mistake to avoid is locking yourself out before you know which port keeps your access alive.

First, list listening services. A common tool is ss, which shows network sockets — the technical name for active network endpoints:

bashsudo ss -tulpn

Look for lines that say LISTEN. The important parts are the local address, the port number, and the process name. If you see 0.0.0.0:8080, that usually means port 8080 is listening on all network interfaces. If you see 127.0.0.1:5432, that usually means PostgreSQL is listening only inside the server, which is much less exposed.

You can also check from the outside with nmap from another machine:

bashnmap your-server-ip

Once you find a port you do not need, decide whether to stop the service or firewall it.

If the service should not be running at all, stop it. For example, if an old web server is opening a port and nothing depends on it, stopping the service is cleaner than merely hiding it. On many Linux systems, services are managed by systemd, using systemctl.

If the service is needed locally but should not be public, block it with a firewall. On Ubuntu, many people use ufw, short for Uncomplicated Firewall:

bashsudo ufw deny 8080

On CentOS, AlmaLinux, Rocky Linux, and Fedora-style systems, you may see firewalld instead:

bashsudo firewall-cmd --permanent --remove-port=8080/tcp
sudo firewall-cmd --reload

Afterward, check again. Run ss locally and nmap externally if you can. You are looking for proof, not hope.

Also be careful with SSH. If you block the port you use to log in, you can lock yourself out. Before changing SSH rules, make sure you have another way back in, such as your hosting provider’s console.

If your site stops loading after a firewall change, the problem is often one of three layers: domain, server, or app. This troubleshooting guide can help you narrow it down: Why isn’t my website loading?.

FAQ

Does closing a port delete the app? No. Blocking a port only stops network access. Stopping or removing the service is a separate action.

**Is port 22 always dangerous?** No. SSH is normal, but it should be protected with strong login settings and only left open if you actually need it.

Should databases be open to the internet? Usually no. Most web apps can reach the database privately on the same server or private network.

What does “Connection refused” mean? The server answered, but nothing accepted the connection on that port, or a rule rejected it.

What does “timed out” mean? Traffic may be blocked or dropped before an answer comes back. Firewalls often behave this way.

The shortcut

Server Manager helps you avoid the usual port mess by keeping each project’s public entry points clear. You are less likely to leave an old test port exposed, point traffic at the wrong app, or have one project break another because their boundaries were never obvious.

It also helps the setup stay understandable months later. Instead of wondering why port 8080 is open or whether a forgotten admin panel is still reachable, you can see the shape of the server in plain terms and clean up with confidence.

The real benefit is not having to remember every small decision forever. The server remains legible, so closing what you do not need becomes maintenance rather than detective work.

What do you gain when unused ports are closed?

You reduce the number of ways your server can be poked from the outside. That does not make security automatic, but it removes unnecessary risk.

You also make troubleshooting easier. When only the right doors are open, strange traffic, broken apps, and website loading problems are easier to reason about.

A tidy server is quieter. You know what is public, what is private, and what no longer belongs there.