When people talk about server security, the question is usually about a firewall, but first you need to understand what is reachable from outside at all. A service may listen on a port and still be unreachable from the internet, or it may be open for a forgotten reason. This article shows how to list listening ports from the inside, check them from the outside, review typical findings and close what is not needed.
«Listening» and «reachable from outside» are not the same
A service listens on a port when it is bound to an address and waits for connections. Reachability from outside also depends on the bind address, the firewall on the server and the network rules in front of it. If a service is bound to 127.0.0.1, it can be reached only from the server itself. If it is bound to 0.0.0.0, it accepts connections on all addresses, and only a firewall can keep it away from the internet. The basics of ports and sockets are covered in the article port, socket and service.
Looking from the inside: ss -tulpn
The ss command from the iproute2 package shows sockets. The options: -t is TCP, -u is UDP, -l shows listening sockets only, -p shows the process, -n prints numeric addresses and ports. To see the names of other users' processes, run it as root.
sudo ss -tulpn
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=812,fd=3))
tcp LISTEN 0 80 0.0.0.0:3306 0.0.0.0:* users:(("mysqld",pid=1044,fd=21))
tcp LISTEN 0 511 127.0.0.1:8080 0.0.0.0:* users:(("nginx",pid=930,fd=6))
tcp LISTEN 0 511 [::]:80 [::]:* users:(("nginx",pid=930,fd=7))| Address in Local Address | Meaning |
|---|---|
| 0.0.0.0 | All IPv4 addresses of the server; only a firewall limits access |
| [::] | All IPv6 addresses of the server, the same for IPv6 |
| 127.0.0.1 | Loopback only: connections are possible from this server alone |
| 192.0.2.10 | One specific server address |
In the example SSH and MySQL are bound to 0.0.0.0, Nginx on port 8080 is bound to 127.0.0.1, and on port 80 it also listens on IPv6. There is one question for such a list: every line with 0.0.0.0 or [::] needs an explanation of why it is open to the world.
Looking from the outside
The final picture is visible only from another machine: a home computer or another server. Scan your own servers only. The nmap utility shows port states, and nc quickly checks a single port:
nmap -Pn -p 22,80,443,3306 203.0.113.10
nc -zv 203.0.113.10 3306The open state means the port accepts connections; closed means the host answers but no service is listening; filtered means packets are dropped by a firewall. A difference between ss and the external check is a reason to investigate: either the firewall works or the rules were not applied. Other diagnostic techniques are described in the article network diagnostics in Linux.
Typical findings
| Finding | Why it is risky | What to do |
|---|---|---|
| Database on 0.0.0.0 | The port is open to password guessing and exploits | Bind to 127.0.0.1 |
| Panel on a non-standard port | Changing the port does not hide the panel from scanners | Close with a firewall or move behind a tunnel |
| Forgotten test service | Often has no passwords and no updates | Stop it and remove it from autostart |
| Docker port published to the outside | Docker edits iptables rules itself and can bypass firewall rules | Publish as 127.0.0.1:port |
How to close ports
The best option is not to open the port at all: bind the service to 127.0.0.1. A firewall is a second line of defence, not a replacement. These are typical parameters; after editing them, restart the service:
bind-address = 127.0.0.1
listen_addresses = 'localhost'
bind 127.0.0.1
docker run -p 127.0.0.1:3306:3306 imageThe lines belong, in order, to MySQL (the [mysqld] section), PostgreSQL (postgresql.conf), Redis (redis.conf) and starting a Docker container. Then enable a firewall that denies incoming traffic by default and allow only what is needed: the setup is shown in the article UFW for a VPS. Before enabling it, make sure the SSH port is allowed, otherwise you will lose access.
If you still need access to a closed service, publishing the port is not required. For a database, an SSH tunnel works: a port on your computer is forwarded to 127.0.0.1 on the server. For web panels there is Cloudflare Tunnel.
ssh -L 3307:127.0.0.1:3306 user@203.0.113.10While the tunnel is open, connect your database client to 127.0.0.1:3307. After any change, repeat ss -tulpn and the external check: the result should match your intent.
Frequently asked questions
How do I find out which ports are open on my server?
From the inside, run sudo ss -tulpn: it lists all listening ports and processes. Then check the server from the outside, from another machine, with nmap or nc. The external check is the final one, because only it accounts for the firewall and network rules, while ss shows only what the system itself listens on.
What does 0.0.0.0 mean in the ss output?
It means the service accepts connections on all IPv4 addresses of the server, that is, potentially from the internet. The [::] entry means the same for IPv6. The 127.0.0.1 address limits access to the server itself. Databases and internal services should use 127.0.0.1 unless they need external clients.
Is a firewall enough to close unneeded ports?
A firewall is necessary, but it is more reliable to remove the cause: a service bound to 127.0.0.1 is unreachable from the outside even if the rules contain a mistake. Treat the firewall as a second layer. Consider containers as well: Docker changes iptables rules itself, so a published port may turn out to be open despite UFW settings.
How do I connect to a closed database from my computer?
Use an SSH tunnel: the ssh command with the -L option forwards a local port on your computer to 127.0.0.1 on the server. The database client then connects to the local port. This keeps the database port closed to the internet, and only people with SSH access to the server get in.