Tutoriel Linux

Open ports under Linux: netstat, ss and the commands to use today

Débutant5 min de lecture
À retenirLinux n'est pas réservé aux experts. Le bon point de départ : une distribution accessible, une sauvegarde propre et quelques commandes comprises.

Are you looking to find out which ports are open on a Linux machine? First, an important clarification: an “open” port on the server side often means listening locallyThis does not yet prove that it is accessible from the Internet, nor that a firewall allows it to pass through.

In my case, I always check in two steps: first, what is listening on the server with ss, then the service or process behind the port. netstat It remains known, but on many modern distributions, it is no longer installed by default. It’s best to use current best practices.

Tux inspects the open network ports of a Linux server

The command to use today: ss

On recent Linux, ss is the preferred command. It is part of the stack iproute2 and very often replaces netstat to inspect network sockets.

sudo ss -lntup

The options are important:

  • -L displays the listening ports.
  • -n avoids DNS resolution and keeps ports in numbers.
  • -t limited to TCP connections.
  • -u adds UDP.
  • -p displays the associated process, when you have the necessary rights.

Without sudoYou will sometimes see the port, but not always the program behind it. For a quick audit on a server, I prefer to run the command with administrator privileges and read the column directly. Process.

Read the result without making a mistake

A typical result looks like this:

State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=812,fd=3))
LISTEN 0 511 127.0.0.1:3306 0.0.0.0:* users:(("mariadbd",pid=1044,fd=21))

The column to look at first is Local Address:PortIf you see 0.0.0.0:22The service listens on all IPv4 interfaces. If you see 127.0.0.1:3306The service only listens locally. It’s not the same risk.

For IPv6, you can also see Or Again, don’t read too quickly: may mean broad listening on the IPv6 side, while stays local.

Filter a specific port

If you’re only looking for SSH, HTTP, or a database, there’s no need to scan the entire output. Filter with grep or with the filters of ss.

sudo ss -lntup | grep ':22'
sudo ss -lntup | grep ':80'
sudo ss -lntup | grep ':443'

For a more TCP-focused output, you can use:

sudo ss -ltnp '(sport = :22)'

I often keep the version with grep When I’m in a hurry, because she talks to everyone. For a clean script or diagnosis, the native filters of ss avoid false positives.

And what about netstat in all of this?

netstat It hasn’t disappeared from the admins’ memory, but it comes from the package net-tools, often absent on Debian, Ubuntu, or minimal installations. If you come across documentation that asks netstat And if the command is missing, it’s not necessarily an error on your server’s part.

netstat -lntup

The output is similar in concept: protocols, local addresses, ports, PID, and program name. But if you need to install a package just to use it netstatFirst, ask yourself if ss That’s not enough. On a recent server, my answer is almost always yes.

The manual page of ss details the available filters. That of netstat It remains useful if you still maintain old scripts.

Find the process behind a port

When a port surprises you, don’t close it randomly. First identify the process, then the associated systemd service if necessary.

sudo ss -lntup
sudo lsof -iTCP -sTCP:LISTEN -P -n

lsof is useful when you want to link a port, a PID, and a binary. With -PThe ports remain in figures. With -n, you avoid DNS resolutions that slow down or scramble reading.

If you have a PID, then trace it back to the service:

ps -p 812 -o pid,ppid,user,cmd
systemctl status ssh

For a server running with systemd, the guide on the Linux services and systemctl commands This step is completed successfully. The goal is to determine if you have an expected service, a container, an old, forgotten daemon, or a manually launched process.

A listening port does not necessarily mean an exposed port

That’s the classic trap. If ss If a port is shown as listening, you know that a program is accepting connections on the machine. You don’t yet know if this port is passing through the local firewall, cloud rules, NAT, or router.

To sort through them, check at a minimum:

  • The listening address: 127.0.0.1, 0.0.0.0, private IP, public IP;
  • the service behind the port;
  • the local firewall, for example ufw, nftables Or iptables ;
  • security rules on the hosting or cloud side;
  • a test from another machine when you need to validate the actual exposure.
sudo ufw status verbose
sudo nft list ruleset
sudo iptables -S

Do not run these commands in an automated cleanup script. Read first. On a remote server, a bad firewall rule can cut off your SSH connection faster than expected. If SSH is already unresponsive, use the method described above instead. Reinstall and verify SSH on Ubuntu.

My quick check before touching the firewall

  • sudo ss -lntup to see the listening TCP and UDP ports.
  • sudo ss -ltnp if I only want TCP.
  • sudo lsof -iTCP -sTCP:LISTEN -P -n to confirm the process.
  • systemctl status service-name to check the service behind it.
  • journalctl -u service-name -b --no-pager if the service is listening when it shouldn’t.
  • An external test only after understanding what is listening locally.

If you discover an unexpected port, don’t kill the process immediately. Note the port, PID, and service, then review the logs. (See the guide on…) journalctl at last startup will help you determine if the service starts automatically or if it is due to a recent action.

To put it simply: ss First of all, netstat only if you need to maintain old habits, and never modify the firewall before identifying the service behind the port.

sudo apt update && sudo apt upgrade