Picture your server as a building. Every door on the outside is a way in — and every door you leave unlocked, or worse, wide open, is something an attacker can try. On a server those doors are called ports, and the rooms behind them are the services that listen for connections. Most break-ins don’t start with some genius hacker defeating your encryption. They start with a door nobody remembered was open.
That’s why “securing ports and services” is one of the highest-value things you can do for a server, and one of the easiest to get right once you understand it. The whole game comes down to a simple idea: the safest port is one that isn’t open, and the safest service is one that isn’t running. Let’s build that up from the basics.
What a port actually is
A port is a numbered channel on a machine that lets a specific service receive network traffic. Your server has one IP address, but it can run many services at once — a web server, a database, a remote-login service — and ports are how the operating system tells their traffic apart. Think of the IP address as a building’s street address, and the port as the suite number inside.
Some port numbers are conventions almost everyone follows:
- 22 — SSH, the encrypted remote login you use to administer a server.
- 80 — HTTP, plain web traffic.
- 443 — HTTPS, encrypted web traffic.
- 3306, 5432 — common database ports.
- 6379, 27017 — common ports for in-memory and document stores.
None of these numbers are magic. A service can listen on any port; these are just the defaults that tools expect. If you’ve already met ports in the context of IP addresses and ports, this is the same idea, now viewed through a security lens. For the deeper protocol side, ports and protocols covers how TCP and UDP fit in.
What a service is, and why it matters
A service (sometimes called a daemon) is a long-running program that sits in the background waiting for work. A web server is a service. A database is a service. The SSH server you log in with is a service. Each one binds to a port, which means it claims that port and starts listening for connections on it.
Here’s the link that makes everything click: a port is only “open” to the outside world if a service is listening on it and nothing is blocking it. Three things have to line up for a port to be a real entry point:
service running → bound to a port → reachable through the network
│ │ │
(it exists) (it's listening) (firewall lets it in)Take away any one of those and the door is effectively shut. Stop the service and the port closes. Bind the service to localhost only and the outside world can’t reach it. Block the port at the firewall and traffic never arrives. You have three independent ways to close a door — and good security usually uses more than one.
Listening on localhost vs. listening on the world
There’s a huge difference between a service bound to 127.0.0.1 (localhost) and one bound to 0.0.0.0 (every network interface). The first can only be reached by programs on the same machine — perfect for a database that only your app needs to talk to. The second is reachable by anyone who can route packets to your server. Databases left bound to 0.0.0.0 with a weak password are one of the most common ways data gets stolen. Bind internal services to localhost unless they genuinely need to be public.
See what’s actually listening
You can’t secure what you can’t see, so the first real skill is taking an honest inventory of what’s open. On a standard Linux server, one command shows you every listening socket:
# List listening TCP/UDP sockets with the owning program
ss -tulpnThe output tells you, for each open port, which address it’s bound to and which program is holding it. A typical safe-looking result might be:
Netid State Local Address:Port Process
tcp LISTEN 0.0.0.0:22 sshd
tcp LISTEN 0.0.0.0:443 nginx
tcp LISTEN 127.0.0.1:5432 postgresRead that carefully and you’ve learned a lot. SSH and the web server are open to the world (expected). The database is bound to 127.0.0.1, so it’s reachable only from the machine itself — exactly what you want. Now imagine instead you saw 0.0.0.0:5432: that’s a database exposed to the entire internet, and it would jump straight to the top of your fix-it list.
The question to ask for every single line
For each listening port, ask: “Do I know what this is, and does it need to be reachable from outside?” If you can’t name the service, find out what it is before doing anything else. If it doesn’t need outside access, bind it to localhost or block it. If it shouldn’t be running at all, stop and disable it. Three honest answers per line and you’ve done most of the work.
The core discipline: close what you don’t use
Everything about securing ports and services flows from one principle — reduce your attack surface. Your attack surface is the total set of ways someone could try to get in. Every open port, every running service, every piece of software is part of it. The fewer of those you have, the fewer things can go wrong. This is the same instinct behind the least privilege principle, applied to the network instead of permissions.
In practice the discipline has four moves, roughly in order of how often you’ll use them:
1. Stop and disable services you don’t need
A fresh server often ships with services you’ll never use — a mail transfer agent, a printing service, sometimes an old remote-access tool. If you don’t need it, don’t just stop it; disable it so it doesn’t come back after a reboot. Managing services this way is exactly what systemd basics walks through, and the broader idea of background programs lives in processes and services.
# Stop a running service now, and prevent it starting at boot
sudo systemctl stop someservice
sudo systemctl disable someserviceA service that isn’t running has no open port, no code accepting input, and nothing to exploit. It is the cleanest possible “closed door.”
2. Bind internal services to localhost
If a service must run but only needs to talk to other programs on the same machine — the classic case is a database used by your own app — configure it to listen on 127.0.0.1 instead of all interfaces. Now even if the firewall has a hole, the port simply isn’t exposed to the network. This is defense in depth: two unrelated mistakes have to happen before anyone gets in.
3. Block everything else at the firewall
For the services that do face the public, a firewall is your gatekeeper. The right policy is default-deny: block all incoming traffic, then open only the specific ports you decided to allow. The exact rules belong in a dedicated walkthrough — firewall configuration covers the how, and firewalls explains the concept — but the mental model is simple:
DEFAULT-DENY FIREWALL
incoming traffic ──► [ is the port on my allow-list? ]
│ │
yes no
│ │
let it in drop itA typical public web server’s allow-list is short: 22 for SSH, 80 and 443 for the web, and nothing else. Everything you don’t explicitly allow is silently dropped, which means a forgotten service that starts listening on some odd port still can’t be reached from outside.
4. Move or protect the doors you must keep open
Some ports have to stay open, and those deserve extra care. SSH on port 22 is the obvious one: it’s open to administer the server, but it’s also the single most-attacked port on the internet, hammered constantly by automated scanners. You can’t simply close it, but you can harden it — key-only login, no root login, and so on — which is the entire subject of SSH security. The lesson generalizes: a door you must keep open should be locked, watched, and as small as possible.
Changing the port number is not real security
A popular trick is to move SSH off port 22 to something like 2222 to dodge automated scanners. It does cut log noise, but treat it as tidiness, not protection — this is security through obscurity. A determined attacker scans all ports in seconds and finds your service wherever it hides. Obscurity can sit on top of real defenses, but it must never replace them. The actual security comes from strong authentication, a default-deny firewall, and not running services you don’t need.
A quick end-to-end example
Imagine ACY Partner Indonesia spins up a fresh server to host a web app with a private database behind it. Here’s the secure shape, start to finish:
THE INTERNET
│
│ only 80/443 (web) and 22 (SSH) allowed in
▼
┌─────────────── FIREWALL (default-deny) ───────────────┐
│ │
│ :443 web server ──► serves the app (public) │
│ :22 SSH ──► admin only, key-only login │
│ :5432 database ──► bound to 127.0.0.1 (private) │
│ │
└────────────────────────────────────────────────────────┘The web server is public because it has to be. SSH is open but locked down to key-based login. The database is running, but it’s bound to localhost and its port isn’t in the firewall’s allow-list — two separate reasons it can’t be reached from outside. Every other service on the box has been stopped and disabled. That’s a small, well-understood attack surface, which is the whole goal.
When Jane Doe later adds a caching service that the app needs, she follows the same checklist: does it need to be public? No — so bind it to localhost, leave its port out of the firewall, and move on. The discipline scales because it’s the same three questions every time.
Why this is worth doing first
Securing ports and services gives you an enormous amount of safety for a small amount of effort. It doesn’t require deep cryptography or expensive tools — just a clear inventory and the willingness to turn things off. It also makes everything else easier: a server running five well-understood services is far simpler to monitor, patch, and reason about than one running thirty mystery processes. A small attack surface is a gift you give your future self every time you have to investigate something at 2 a.m.
It pairs naturally with the rest of server hardening. Closing unused doors is step one; keeping the doors you keep up to date — through keeping software updated — and starting from a sane baseline with server hardening basics complete the picture. None of it is exotic. It’s just good housekeeping done deliberately.
Wrapping up
Here’s the whole idea in one place:
- A port is a numbered channel a service uses to receive network traffic; a service is the program listening on it.
- A port is only a real entry point when a service is running, bound to a reachable interface, and not blocked by a firewall — break any link and the door is shut.
- The guiding principle is to reduce your attack surface: the safest port is one that isn’t open, and the safest service is one that isn’t running.
- The four moves, in order: disable services you don’t need, bind internal services to localhost, default-deny at the firewall and allow only what you chose, and harden the doors you must keep open.
- Always inventory first with a tool like
ss -tulpn, and for every listening port ask whether you know what it is and whether it truly needs to face the outside. - Changing a port number is tidiness, not security — real protection comes from strong auth, a default-deny firewall, and running less.
Closing unused doors handles the network layer. The next pieces of the picture are protecting the data that lives behind those doors — with SSL and encryption at rest — so that even if someone does get further than they should, what they reach is unreadable.
