Auditing a Linux Server for Open Ports and Unnecessary Services in 2026

Every Linux server you manage has a growing list of open ports, listening services, and background processes. Most of them are necessary. Some of them are leftovers from a quick test that became permanent. And a few of them are wide-open doors that you forgot existed.

Auditing a Linux server for open ports and unnecessary services is the process of finding every one of those doors, deciding which ones you actually need, and locking the rest. I have spent years managing Linux servers in production environments, and I can tell you that open ports accumulate silently. A developer spins up Redis for testing, binds it to 0.0.0.0, and walks away. Three months later, that Redis instance is still running, still listening on every interface, and still unauthenticated.

This guide walks through the entire audit process step by step. You will learn how to list every listening port with ss, lsof, and netstat. You will identify unnecessary services with systemctl. You will verify your firewall rules, scan your server from the outside with nmap, and set up automated auditing so this never sneaks up on you again.

Whether you manage a single VPS or a fleet of production servers, the commands and procedures here apply universally across Ubuntu, Debian, CentOS, RHEL, Fedora, and most other Linux distributions.

Why Every Open Port Is a Security Risk?

Every open port on your server is a potential entry point for an attacker. That is not fear-mongering. It is the basic principle of attack surface management. The more services you expose, the more opportunities exist for exploitation.

Consider what happens when a vulnerability is disclosed in a service you forgot was running. If you do not know it is listening, you do not patch it. If you do not patch it, an attacker finds it first. This exact scenario plays out constantly in the wild. Databases like Elasticsearch, MongoDB, and Redis have been found exposed on thousands of internet-facing servers, often because someone set them up for testing and never locked them down.

The forum discussions I have followed on r/linuxadmin and r/sysadmin echo this pattern repeatedly. Administrators describe finding services that nobody on the team remembered installing. Temporary changes become permanent. Test environments left exposed. Nobody realized the service was listening externally.

Reducing your attack surface means closing ports that do not need to be open and disabling services that do not need to run. It is the single most effective security hardening step you can take, and it costs nothing but your time.

How to Check Open Ports on a Linux Server

Checking open ports is the first step in any server audit. Linux gives you three primary tools for this job: ss, lsof, and netstat. Each shows you what is listening, but they present the information differently. I recommend running all three during an audit because each one catches details the others might miss.

Using the ss Command

The ss command is the modern replacement for netstat. It is faster, more detailed, and installed by default on virtually every current Linux distribution. It pulls data directly from the kernel, which means it sees sockets that older tools sometimes miss.

Run this command to see every listening TCP and UDP port along with the process using it:

ss -tulpn

Here is what each flag does:

• -t shows TCP sockets

• -u shows UDP sockets

• -l shows only listening sockets

• -p shows the process using the socket

• -n prevents DNS resolution, showing raw IP addresses and port numbers instead

The output will look something 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=653,fd=3))
LISTEN 0 128 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=890,fd=6))
LISTEN 0 128 127.0.0.1:3306 0.0.0.0:* users:(("mysqld",pid=1024,fd=21))
LISTEN 0 128 0.0.0.0:6379 0.0.0.0:* users:(("redis-server",pid=1150,fd=4))

Pay close attention to the Local Address column. This tells you what the service is binding to. An address of 0.0.0.0 means the service is listening on every network interface, making it reachable from the internet if your firewall allows it. An address of 127.0.0.1 means the service is bound to localhost only, which is much safer.

In the example above, MySQL is correctly bound to localhost on port 3306. But Redis is listening on 0.0.0.0:6379, which means it is accessible from every interface. That is a problem if the server faces the internet.

Using lsof to Find Open Ports

The lsof command lists open files, and in Linux, network sockets are files. This makes lsof an excellent cross-referencing tool. Run it alongside ss to catch anything that might be hiding.

lsof -i -n -P

The flags here are straightforward:

• -i shows network connections

• -n disables DNS resolution for faster output

• -P shows raw port numbers instead of service names

lsof is especially useful when you want to see which user owns a particular connection or when a process has a socket open that ss does not clearly show. I use it regularly to track down services that are in a half-open or established state rather than actively listening.

Using netstat for Legacy Systems

netstat is deprecated on modern Linux distributions, but you will still find it on older servers and in many tutorials. If ss is not available for some reason, netstat does the same job with identical flags.

netstat -tulpn

The flags match ss exactly, and the output format is similar. The key difference is that netstat reads from /proc files, which makes it slower on busy servers. On a system with thousands of connections, netstat can take several seconds while ss returns instantly.

If netstat is not installed, you can add it with apt install net-tools on Debian-based systems or dnf install net-tools on Fedora-based systems. But I recommend using ss instead and treating netstat as a fallback.

Identifying Unnecessary Services Running on Your Server

Finding listening ports is half the audit. The other half is figuring out which services are running on your server in the first place, whether or not they have open ports. A service that is running but not listening externally still consumes resources and may start listening after a reboot or configuration change.

Listing All Enabled Services with systemctl

On any modern Linux distribution using systemd, systemctl is your primary tool. This command lists every service on the system and its startup state:

systemctl list-unit-files --type=service

The output shows each service with a state of enabled, disabled, or static. Enabled services start automatically at boot. Disabled services do not. Static services have no install section and are typically started as dependencies of other services.

Focus on the enabled services. Ask yourself whether each one is necessary for the server’s purpose. A web server needs its HTTP daemon and SSH, but it probably does not need Bluetooth, CUPS (printing), or an Avahi daemon.

Checking What Is Actually Running Right Now

Being enabled does not mean a service is currently running. To see what is active at this moment, run:

systemctl list-units --type=service --state=running

This shows only services that are currently active. It is a quick way to see what is consuming CPU and memory right now. Compare this list against what you expect to be running, and investigate anything unfamiliar.

Checking Services on Non-systemd Systems

If you are managing older servers or minimal containers that do not use systemd, you have alternatives. On older CentOS or RHEL systems, use chkconfig --list to see service startup states. For SysVinit systems, service --status-all gives you a list of running services with plus and minus indicators.

Another approach that works everywhere is simply reviewing what is running:

ps aux

Scan the output for unfamiliar processes. I have found forgotten services this way more times than I can count. A process running under a service account that nobody recognizes is worth investigating immediately.

Which Ports and Services Should Raise Immediate Concern

Some ports on a server are expected and normal. Port 22 for SSH, port 80 or 443 for web traffic, port 25 for mail on a mail server. But certain ports and services should immediately trigger questions when you find them listening, especially on internet-facing servers.

Here is a quick reference of ports that commonly indicate problems:

• Port 23 (Telnet) sends credentials in plain text. There is almost no reason to run Telnet in 2026. Replace it with SSH immediately.

• Port 21 (FTP) also transmits data unencrypted. Use SFTP or SCP instead.

• Port 3306 (MySQL/MariaDB) should never be listening on 0.0.0.0 unless you have a specific multi-server architecture. Bind it to localhost.

• Port 5432 (PostgreSQL) same rule applies. Restrict to localhost or a specific internal interface.

• Port 6379 (Redis) should never face the internet. Redis has been at the center of numerous data breaches because administrators left it unauthenticated on public interfaces.

• Port 27017 (MongoDB) has been found exposed on tens of thousands of servers. Always bind to localhost and require authentication.

• Port 9200 (Elasticsearch) exposed instances have led to massive data leaks. Bind to localhost or an internal network.

• Port 11211 (Memcached) was abused in some of the largest amplification DDoS attacks ever recorded.

• Port 8080, 8443 (Admin panels) often indicate Jenkins, Tomcat manager, or other administrative interfaces that should not be publicly accessible.

The pattern is clear. Database and cache services should never listen on external interfaces unless you have a deliberate, documented reason for it. Administrative panels need to be behind a firewall, a VPN, or an authentication proxy.

How to Disable Unnecessary Services in Linux

Once you have identified services you do not need, the next step is removing them from your attack surface. Linux gives you three levels of service management, from softest to hardest: stop, disable, and mask.

Step 1: Stop the Service Immediately

Stopping a service kills it right now without preventing it from starting on the next boot. This is your first move when you want to cut off access immediately but have not decided on a permanent solution yet.

sudo systemctl stop servicename

For example, to stop the Bluetooth service: sudo systemctl stop bluetooth

Step 2: Disable the Service at Boot

Disabling a service removes it from the boot sequence. It will not start automatically when the server reboots, but it can still be started manually if needed.

sudo systemctl disable servicename

You can combine stop and disable in one command: sudo systemctl stop servicename && sudo systemctl disable servicename

This is the right approach for most unnecessary services. It removes them from your attack surface without permanently removing the software. If you later discover you need the service, you can enable and start it again.

Step 3: Mask the Service for Complete Removal

Masking goes further than disabling. A masked service cannot be started manually or as a dependency of another service. It is completely hidden from systemd.

sudo systemctl mask servicename

Use masking when you are certain a service will never be needed and want to prevent any process from accidentally starting it. This is the strongest option short of uninstalling the package entirely.

Step 4: Restrict Instead of Removing

Sometimes a service needs to run but should not be listening on every interface. Instead of disabling it entirely, change its bind address. Most services have a configuration file where you can set the listen address from 0.0.0.0 to 127.0.0.1.

For example, in a Redis configuration file (/etc/redis/redis.conf), change:

bind 0.0.0.0 to bind 127.0.0.1

Then restart the service: sudo systemctl restart redis

This is the principle of least privilege applied to network services. Run what you need, but restrict it to the smallest possible audience.

Verifying Your Firewall Configuration

Disabling services is only half the battle. Even a necessary service can become a vulnerability if your firewall is misconfigured or missing rules. Firewall verification is a non-negotiable part of any server audit.

The three main firewall tools on Linux are ufw (Ubuntu and Debian), firewalld (CentOS, RHEL, Fedora), and iptables (the underlying engine for all of them). The tool you use depends on your distribution.

Checking UFW on Ubuntu and Debian

UFW (Uncomplicated Firewall) is the default firewall interface on Ubuntu. To see its status and all rules, run:

sudo ufw status verbose

The output shows whether the firewall is active, the default policies for incoming and outgoing traffic, and every rule you have configured. A healthy output looks like this:

Status: active
Default: deny (incoming), allow (outgoing)
22/tcp ALLOW IN Anywhere
80/tcp ALLOW IN Anywhere
443/tcp ALLOW IN Anywhere

If the status shows inactive, your server has no firewall protection at all. Enable it immediately with sudo ufw enable, but first make sure SSH is allowed or you will lock yourself out.

Checking Firewalld on CentOS and RHEL

Firewalld is the standard on Red Hat-based distributions. Check its status with:

sudo firewall-cmd --state

To see all active rules, zones, and services:

sudo firewall-cmd --list-all

The output shows your default zone, allowed services, open ports, and source addresses. Review each entry carefully. If you see a service or port listed that you do not recognize, investigate it.

Checking Raw iptables Rules

If your server uses raw iptables without a wrapper like UFW or firewalld, you can see all rules with:

sudo iptables -L -n -v

The -n flag prevents DNS resolution, and -v adds verbose output showing packet and byte counts. Look at the INPUT chain to see what inbound traffic is allowed. Pay attention to rules that allow traffic on specific ports and verify each one matches a service you intend to expose.

A common mistake I see is firewall rules created during setup that are never reviewed again. Someone opens port 8080 for a staging environment, the staging environment moves, and the firewall rule stays open forever. This is why verifying your firewall is part of the audit, not a one-time setup task.

Scanning Your Server from the Outside with Nmap

Internal commands like ss and lsof show you what your server thinks is open. But the only way to know what an attacker actually sees is to scan your server from the outside. Nmap is the industry standard tool for this, and it should be a core part of every server audit.

Install nmap on a separate machine, not the server you are auditing. The whole point is to get an external perspective.

Running a Basic Port Scan

To scan all 65,535 TCP ports on your server, run:

nmap -Pn -p- your.server.ip.address

The -Pn flag skips host discovery, assuming the host is online. The -p- flag tells nmap to scan every port, not just the top 1,000 that it scans by default. This takes longer but catches services running on non-standard ports.

Sample output might look like this:

PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
443/tcp open https
6379/tcp open redis

If you see a port like 6379 (Redis) in your external scan results, that is an immediate red flag. Redis should never be reachable from an external machine.

Service Version Detection

Add the -sV flag to make nmap probe each open port for version information:

nmap -Pn -sV -p- your.server.ip.address

This tells you not just that a port is open, but what software and version is running behind it. Version information helps you identify whether a service is outdated and vulnerable.

UDP Port Scanning

TCP gets most of the attention, but UDP services can also be exposed. Scan common UDP ports with:

sudo nmap -sU your.server.ip.address

UDP scanning is slower and less reliable than TCP scanning, but it is worth doing during a full audit. Services like DNS, SNMP, and Memcached use UDP, and exposed UDP services have been weaponized for amplification attacks.

After your external scan, compare the results with what your internal ss output showed. If nmap found a port that ss showed as listening on localhost only, your firewall is doing its job. If nmap found a port that should have been blocked, you have found a misconfiguration to fix.

Commonly Overlooked Sources of Attack Surface

Standard port scanning catches the obvious problems. But experienced administrators know that attack surface hides in places that basic commands do not check. Here are the sources most audits miss.

Container and Docker Exposure

Docker containers can publish ports to the host that then become accessible externally. A developer runs docker run -p 8080:8080 someapp and walks away. The container publishes port 8080 on all host interfaces, and if the host firewall allows it, that port is now internet-accessible.

Check which ports Docker is publishing:

docker ps --format "table {{.Names}}t{{.Ports}}t{{.Image}}"

Review each container’s port mapping. Any port published to 0.0.0.0 is exposed on all interfaces. Use 127.0.0.1:8080:8080 instead if the container only needs to be accessible locally.

Administrative Panels

Jenkins, Grafana, Kibana, RabbitMQ management, and similar administrative panels are frequently exposed by accident. These tools provide powerful administrative capabilities and often have weak default authentication or none at all.

Check your ss output for common admin panel ports: 9090, 3000, 5601, 15672, 8500. If any of these are listening on 0.0.0.0, verify that they are protected by a firewall rule, a VPN requirement, or a reverse proxy with authentication.

Cloud Metadata Service Exposure

If your server runs in AWS, GCP, or Azure, it has access to a metadata service at the IP address 169.254.169.254. This service provides instance credentials, IAM roles, and configuration data. A vulnerability in an application running on the server can allow an attacker to query this endpoint and steal cloud credentials.

While you cannot firewall the metadata service itself on most cloud platforms, you should be aware of its presence and ensure applications are not vulnerable to SSRF attacks that could reach it. On newer AWS instances, consider using IMDSv2, which requires token-based requests.

IPv6 Exposure

Many administrators carefully lock down IPv4 and completely forget about IPv6. If IPv6 is enabled on the server, services may be listening on IPv6 addresses that are reachable from the internet even when their IPv4 counterparts are firewalled.

Check IPv6 listeners specifically:

ss -6 -tulpn

If you are not using IPv6 intentionally, consider disabling it. If you are using it, make sure your firewall rules cover IPv6 traffic as well as IPv4.

Automating Your Linux Server Security Audit

A manual audit is thorough but it is a snapshot in time. Services accumulate between audits. The only way to stay on top of your attack surface is to automate the checking process so problems are caught early.

Setting Up a Daily Port Check with Cron

A simple but effective approach is to run ss daily and compare the output to a baseline. If new ports appear, you get an alert. Here is a basic script structure:

#!/bin/bash
ss -tulpn > /tmp/current_ports.txt
diff /tmp/baseline_ports.txt /tmp/current_ports.txt > /tmp/port_changes.txt
if [ -s /tmp/port_changes.txt ]; then
  mail -s "Port changes detected" [email protected] < /tmp/port_changes.txt
fi

Add this to a daily cron job and you will know within 24 hours whenever a new port opens on your server.

Using Lynis for Comprehensive Auditing

Lynis is an open-source security auditing tool that checks hundreds of security controls on your server. It reports open ports, weak configurations, missing updates, and much more in a single run.

Install and run it:

sudo apt install lynis on Debian-based systems, or download directly from the Lynis GitHub repository.
sudo lynis audit system

Lynis produces a detailed report with a hardening index score and specific recommendations. Run it monthly and track your score over time. As you close ports, disable services, and tighten configurations, your score will improve.

OSQuery for Continuous Monitoring

OSQuery turns your server’s state into a database you can query with SQL. You can ask it which ports are open, which services are running, and which processes are listening, all through standard SQL queries.

For example, to list all listening ports:

SELECT * FROM listening_ports;

OSQuery integrates with fleet management tools, making it suitable for organizations managing multiple servers. It enables continuous monitoring rather than periodic spot checks.

How Often Should You Audit Linux Servers

This is one of the most common questions I see in administrator forums, and the answer depends on your environment. There is no universal schedule, but there are clear guidelines that work well in practice.

For production servers facing the internet, I recommend a full port and service audit at least once a month. Internet-exposed servers are under constant scanning by automated tools, and new services can appear quickly through updates, deployments, or human error.

For internal servers that are not directly internet-accessible, a quarterly audit is reasonable. The attack surface changes less frequently, but services still accumulate over time.

Run an audit immediately after any of these events:

• Deploying a new application or service

• Adding a new team member with server access

• Running a software update that may have changed configurations

• After a security incident, even a minor one

• Before and after decommissioning a service

Document your baseline after each audit. Save the output of ss -tulpn, systemctl list-unit-files, and your firewall rules to a file. On the next audit, compare current state against this baseline to spot changes quickly.

Frequently Asked Questions

Audit Checklist and Next Steps

Auditing a Linux server for open ports and unnecessary services comes down to a repeatable process. Run ss -tulpn to find every listening port. Check systemctl list-unit-files for services you do not need. Disable or mask those services. Verify your firewall with ufw, firewall-cmd, or iptables. Scan from the outside with nmap. Document your baseline, automate the checks, and repeat regularly.

The servers that get compromised are rarely the ones with zero security. They are the ones with forgotten services, open ports nobody knew about, and firewall rules that were set up once and never reviewed. A thorough audit takes an hour or two. The alternative, finding out about an exposed service from a breach notification, is far more expensive.

Start with a single server today. Run ss -tulpn, look at every line, and ask whether each service belongs there. That first scan will likely surprise you, and fixing what you find is the most productive security work you can do this week.