SERVER HARDENING
June 24, 2026

How to Audit Open Ports on Your Server

7 min read
Author
CloudStick Team
Server Infrastructure
Share this article
Audit Open Ports
CloudStick
Audit Open Ports on Your Server

Why You Need to Audit Open Ports

Every open port on your server is a potential entry point for attackers. Services that bind to 0.0.0.0 (all interfaces) are accessible from the public internet unless your firewall explicitly blocks them. On a freshly provisioned server, a surprising number of services listen on public interfaces by default — MySQL, Redis, Memcached, and various admin interfaces all have histories of being discovered and exploited on servers where the admin assumed they were only accessible locally.

A port audit answers three questions: What is listening? On which interface? Is that expected? Run this audit before writing firewall rules, and run it again periodically to catch service configuration drift.

List Listening Ports with ss and netstat

The ss command (socket statistics) is the modern replacement for netstat on Linux. Both show listening ports and the process associated with each one.

# List all listening TCP and UDP ports with process names
sudo ss -tulpn
# Flags: -t TCP, -u UDP, -l listening, -p process, -n numeric
# Example output lines to watch for:
# tcp LISTEN 0.0.0.0:3306 → MySQL on ALL interfaces (bad!)
# tcp LISTEN 127.0.0.1:3306 → MySQL on loopback only (good)
# tcp LISTEN 0.0.0.0:6379 → Redis on ALL interfaces (bad!)
# Alternative with netstat (if installed)
sudo netstat -tulpn

The Local Address column is what matters. 0.0.0.0 or * means the service is accessible on all network interfaces including the public one. 127.0.0.1 means loopback only — not accessible remotely.

External Scan with Nmap

An internal ss scan shows what is listening. An external Nmap scan shows what is actually reachable from the internet — the firewall may be blocking ports that ss shows as open. Running both gives you the complete picture.

# Install nmap
sudo apt install nmap -y
# Scan from the server itself (internal view)
sudo nmap -sV -p- localhost
# From a second machine, scan the server public IP (external view)
nmap -sV your-server-ip
# Quick top-1000 ports scan
nmap -F your-server-ip

TIP: Only scan servers you own or have explicit permission to scan. Use a second VPS or your local machine to run the external scan — scanning from the same server will not cross the firewall boundary and will not accurately reflect what attackers see.

Cross-Reference with UFW Rules

After listing open ports internally and externally, compare against your firewall allow list. Every externally reachable port should correspond to a deliberate allow rule:

# View current UFW rules with port numbers
sudo ufw status verbose
# Expect to see only:
# 22/tcp (or custom SSH port)
# 80/tcp
# 443/tcp
# Any other ports you explicitly need

If your external Nmap scan shows a port that is not in your UFW allow list, investigate — it may be a service that bypasses UFW (some services install iptables rules directly) or a misconfiguration where UFW is not enabled.

Close Unwanted Ports

For services that should only be accessible locally (MySQL, Redis, MongoDB, Memcached), bind them to 127.0.0.1 rather than relying solely on the firewall to block them. This is defense in depth — even if UFW is misconfigured, the service itself is not publicly reachable.

# MySQL — edit /etc/mysql/mysql.conf.d/mysqld.cnf
bind-address = 127.0.0.1
# Redis — edit /etc/redis/redis.conf
bind 127.0.0.1 -::1
# Restart services after changes
sudo systemctl restart mysql redis
# Stop and disable services you do not need at all
sudo systemctl stop servicename
sudo systemctl disable servicename

CloudStick Firewall and Port Management

CloudStick's firewall panel shows the active UFW rules for each connected server and lets you add or remove rules from the dashboard. When CloudStick provisions a new server, it configures MySQL and Redis to bind to loopback only by default — so internal services are never accidentally exposed to the internet. This is part of the security baseline applied at agent install time.

Leave a comment
Full Name
Email Address
Message
On this page

We use cookies to improve your experience

CloudStick uses cookies to personalise content, analyse traffic and keep you signed in. Cookie Policy · Terms of Service

Manage cookies