Asep Sayyad

Posted on Sep 5 Originally published at asepsayyad007.in

Your Linux Server Has 65,000 Ports. How Many Are Actually Exposed?

#linux #ubuntu #cloud #devops

The hidden gap between listening sockets, binding interfaces, Docker NAT bypasses, and true perimeter exposure.

You set up a new Linux server, configure UFW with a default deny policy, and feel confident that your perimeter is locked down.

Then you spin up a container using docker run -d -p 6379:6379 redis, thinking your firewall will protect you from the outside world.

Two hours later, an external port scan reveals your Redis instance sitting completely open to the public internet. No password. No firewall drop. Just raw, unauthenticated access to your memory store.

How does this happen on a machine where you explicitly told the firewall to block incoming traffic?

The answer lies in how Linux handles networking under the hood. There is a massive operational gap between what software binds to, what the Linux kernel routes, what local firewalls intercept, and what external networks can actually reach.

Every Linux server has exactly 65,535 TCP ports and 65,535 UDP ports. But assuming a port is "safe" because you configured a firewall or because you only meant for it to run locally is one of the easiest ways to cause a security incident.

1. The Anatomy of 65,535: Where the Number Comes From

The number 65,535 is not arbitrary. It comes directly from the transport layer specifications in RFC 793 (TCP) and RFC 768 (UDP).

In both packet headers, the source port and destination port fields are allocated exactly 16 bits of memory:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Source Port          |       Destination Port        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

With 16 bits, the total number of possible values is 2 to the power of 16, which equals 65,536 possibilities (0 through 65,535).

The Internet Assigned Numbers Authority (IANA) divides this numeric space into three functional brackets:

Privileged Ports (1 to 1023): Historically reserved for core system daemons (SSH on 22, DNS on 53, HTTP on 80, HTTPS on 443). In Linux, binding to ports below 1024 requires root privileges or the CAP_NET_BIND_SERVICE kernel capability.
Registered User Ports (1024 to 49151): Assigned to specific applications and services, like PostgreSQL on 5432, MySQL on 3306, Redis on 6379, or Prometheus on 9090. Any standard user process can bind to these ports as long as another process has not already claimed them.
Dynamic and Ephemeral Ports (49152 to 65535): Allocated automatically by the kernel's network stack when your server initiates outbound connections to external endpoints.

What about Port 0?

In network theory, port 0 is reserved and invalid for normal network transit. But in the Linux socket programming API, port 0 serves a special purpose. If a developer tells a socket to bind to port 0, they are telling the kernel: "I do not care which port I get. Assign me any available ephemeral port from your pool."

You can check your server's ephemeral port range directly through sysctl:

cat /proc/sys/net/ipv4/ip_local_port_range
# Typical output:
# 32768   60999

Notice that Linux defaults to starting ephemeral allocation at 32,768 instead of the IANA recommendation of 49,152. This gives the kernel 28,232 dynamic ports to juggle for outbound API requests, database queries, and reverse proxy upstream calls.

If a high-throughput proxy burns through those ephemeral ports faster than sockets can exit the TIME_WAIT state, your server hits port exhaustion. Outbound connections start failing with "Cannot assign requested address", even though your CPU and RAM are sitting at 10 percent utilization.

2. The Socket Binding Trap: 0.0.0.0 vs 127.0.0.1

A common misconception among newer administrators is thinking of a port as a simple number like "port 8080".

In reality, a listening port does not exist in isolation. In the Linux kernel, a socket binds to a tuple composed of an IP address and a port number:

(Bound IP Address, Port Number)

The IP address you bind to determines which network interfaces will accept incoming packets for that application:

+-------------------------------------------------------------+
|                     LINUX NETWORK STACK                     |
|                                                             |
|   Loopback (lo)         Private NIC (eth0)    Public NIC (eth1)
|     127.0.0.1             10.0.1.15             198.51.100.4
|         |                     |                      |
|         +----------+----------+----------+-----------+
|                    |                     |
|            [ 0.0.0.0:8080 ]      [ 127.0.0.1:5432 ]
|           (All Interfaces)        (Loopback Only)
+-------------------------------------------------------------+

When an application binds to 127.0.0.1:8080, it tells the kernel: "Only accept traffic arriving over the loopback interface (lo)." Packets arriving from the external internet, the local private network, or a VPN tunnel are immediately dropped by the kernel network stack because they arrived on the wrong interface (eth0 or eth1).

When an application binds to 0.0.0.0:8080 (known as INADDR_ANY), it tells the kernel: "Listen on every single interface currently attached to this system, plus any interface that might be added in the future."

That means 0.0.0.0:8080 is listening on:

Your local loopback (127.0.0.1)
Your private VPC cloud subnet (10.0.1.15)
Your public static IP (198.51.100.4)
Your WireGuard or OpenVPN interface (wg0 / 10.8.0.1)
Your Docker bridge interface (docker0 / 172.17.0.1)

Many open-source tools (Node.js frameworks, Flask, Vite, Spring Boot, Redis, MongoDB) default to binding on 0.0.0.0 or provide quick guides telling you to set host: 0.0.0.0 so you can reach the service from another machine during development.

If that server has a public IP address attached directly to its network card (common on DigitalOcean, Linode, Hetzner, and AWS EC2 instances with public IPs), you just exposed that service to the entire world.

There is another insidious variant: the IPv6 dual-stack trap.

On modern Linux distributions, if an application binds to the IPv6 wildcard address [::]:8080, the kernel's IPV6_V6ONLY socket option determines whether it also claims the IPv4 address space. By default on Linux, net.ipv6.bindv6only is set to 0.

That means an application binding to [::]:8080 quietly binds to both IPv6 and IPv4 0.0.0.0:8080. Developers who think they are only testing IPv6 connectivity end up exposing their service across legacy IPv4 networks without realizing it.

If two local processes need to talk to each other on the same machine (for example, Nginx proxying requests to Gunicorn or Node.js), avoid TCP sockets altogether. Use a Unix domain socket instead:

# In your Nginx configuration:
proxy_pass http://unix:/run/app/application.sock;

Unix domain sockets bypass the TCP network stack entirely. They produce zero network packet overhead, avoid consuming ephemeral ports, and rely on standard Linux filesystem permissions (chmod and chown) for security. No external attacker can reach a Unix domain socket across a network interface.

3. The Docker Firewall Bypass: How iptables BETRAYS UFW

This is one of the most dangerous operational traps in production Linux environments.

You configure UFW (Uncomplicated Firewall) on an Ubuntu server:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw enable

You run sudo ufw status:

Status: active

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       Anywhere

Everything looks locked down. Only SSH on port 22 is permitted.

Now you deploy an application using Docker:

docker run -d -p 8080:8080 --name internal-api my-api:latest

You open your laptop, browse to http://<YOUR_SERVER_PUBLIC_IP>:8080, and the API responds instantly.

Why did UFW let that traffic through? Did UFW crash? Did the rule fail to apply?

Neither. Docker deliberately bypassed UFW by injecting rules directly into the Linux kernel's Netfilter subsystem before UFW even gets a chance to see the packet.

Here is what happens inside the kernel packet filtering pipeline:

Incoming Packet on eth0
           │
           ▼
┌──────────────────────┐
│  PREROUTING (NAT)    │ ◄── Docker modifies this chain
└──────────┬───────────┘
           │
     Routing Decision
     Is packet for this host or a container?
           │
     ┌─────┴───────────────┐
     │                     │
     ▼                     ▼
┌──────────────┐     ┌──────────────┐
│ INPUT Chain  │     │ FORWARD Chain│ ◄── Routed to docker0 bridge
└──────┬───────┘     └──────┬───────┘
       │                    │
 UFW rules live here!   Docker rules live here!

UFW hooks its defensive filtering rules into the INPUT chain. The INPUT chain only evaluates packets whose final destination is the local host operating system.

When you launch a container with -p 8080:8080, Docker creates a Network Address Translation (NAT) rule in the PREROUTING chain of the nat table. When an incoming packet destined for port 8080 hits eth0, the kernel rewrites the destination IP from your server's public IP to the container's internal private IP on the docker0 bridge (like 172.17.0.2).

Because the destination IP has been rewritten to an IP belonging to the bridge network, the kernel routes the packet through the FORWARD chain, completely skipping the INPUT chain where UFW lives.

Docker installs its own forwarding rules inside the FORWARD chain that explicitly allow this traffic.

You can see this happening by inspecting the raw nat table directly:

sudo iptables -t nat -L DOCKER -n -v

You will see an entry matching this:

Chain DOCKER (2 references)
 pkts bytes target     prot opt in     out     source      destination
    8   480 DNAT       tcp  --  !docker0 *     0.0.0.0/0   0.0.0.0/0   tcp dpt:8080 to:172.17.0.2:8080

Docker told the kernel: "Whenever any packet from anywhere arrives for port 8080 on any interface except docker0, translate its destination directly to the container."

To stop Docker from exposing containers publicly, you have three primary options:

First, always bind your container ports explicitly to loopback:

# Secure: Only accessible from localhost on the host machine
docker run -d -p 127.0.0.1:8080:8080 --name internal-api my-api:latest

In your docker-compose.yml, write it like this:

services:
  database:
    image: postgres:16
    ports:
      - "127.0.0.1:5432:5432"

Second, if you run Docker behind a reverse proxy on the same server, place them on the same internal Docker bridge network and do not publish host ports at all:

services:
  web:
    image: nginx:alpine
    ports:
      - "80:80"
      - "443:443"
    networks:
      - internal_net

  api:
    image: my-backend
    # No ports exposed to the host!
    networks:
      - internal_net

networks:
  internal_net:
    driver: bridge

Third, you can configure Docker daemon globally to stop manipulating iptables by adding "iptables": false to /etc/docker/daemon.json. But beware: disabling Docker's iptables engine breaks container-to-internet outbound NAT masquerading unless you write manual iptables forward rules yourself.

4. The Internal View: Inspecting Sockets with ss

When you need to see what is running on your server right now, older tutorials tell you to run netstat -tulnp.

Do not use netstat. The netstat binary was deprecated over a decade ago. It reads network state by parsing raw files in /proc/net/tcp line by line. On a production system under heavy load with tens of thousands of active socket connections, netstat can pause execution and consume significant CPU cycles just parsing text.

Use ss (Socket Statistics) instead.

ss communicates directly with the kernel via the Netlink sock_diag subsystem. It retrieves binary state data straight from the kernel socket tables, making it orders of magnitude faster.

Here is the essential command every Linux engineer should know:

sudo ss -tulnp

Let us break down those flags:

-t: Display TCP sockets.
-u: Display UDP sockets.
-l: Show only listening sockets (ignore established client connections).
-n: Show numeric port numbers instead of resolving them to names (prevents slow DNS lookups and confusing service name translations like domain instead of 53).
-p: Show the process ID and program name holding the socket file descriptor (requires sudo).

Here is what typical output looks like:

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=842,fd=3))
tcp    LISTEN  0       511            0.0.0.0:80          0.0.0.0:*      users:(("nginx",pid=1204,fd=6))
tcp    LISTEN  0       4096         127.0.0.1:5432        0.0.0.0:*      users:(("postgres",pid=912,fd=7))
tcp    LISTEN  0       100          127.0.0.1:25          0.0.0.0:*      users:(("master",pid=1450,fd=13))
tcp    LISTEN  0       128               [::]:22             [::]:*      users:(("sshd",pid=842,fd=4))
udp    UNCONN  0       0              0.0.0.0:68          0.0.0.0:*      users:(("dhclient",pid=650,fd=6))

Look closely at the Local Address:Port column.

Line 3 shows PostgreSQL listening on 127.0.0.1:5432. That is safe from outside traffic.

Line 2 shows Nginx listening on 0.0.0.0:80. That is intentionally public.

Line 1 shows SSH listening on 0.0.0.0:22 and [::]:22. That is accessible to any network that can route packets to this server.

Now examine the Recv-Q and Send-Q columns.

On established connections, these columns show the number of bytes queued in the socket receive and send buffers. But on a socket in the LISTEN state, the kernel reinterprets their meaning:

Send-Q: The maximum backlog queue size for this socket (the maximum number of completed TCP handshakes waiting for the application to call accept()).
Recv-Q: The current number of connections currently waiting in that backlog queue.

If you run ss -tuln on a busy web server and see Recv-Q matching Send-Q (e.g., 128 128), your application process is frozen or saturated. It cannot call accept() fast enough, and the kernel is dropping new incoming TCP connection attempts.

When debugging port conflicts or identifying unknown listeners, two more utilities are invaluable:

# Find exactly which process is clinging to port 8080
sudo lsof -i :8080

# Or use fuser to instantly grab the PID and kill it
sudo fuser 8080/tcp
sudo fuser -k 8080/tcp

While developing my open-source project AiroShare (a high-performance local media and DLNA streaming engine), managing port conflicts was a major runtime hurdle. Services like DLNA and SSDP demand specific broadcast and HTTP control ports (ports 9900 and 2121).

If a previous background daemon crashed without properly releasing its socket descriptor, or if another local streaming server had claimed port 9900, attempting to bind on startup threw an immediate EADDRINUSE exception.

Adding automated pre-launch socket verification (querying the local interface binding state and gracefully negotiating fallback ports or clearing stale zombie listeners) transformed a brittle startup routine into a resilient production service.

5. The Outside-In View: Perimeter Scanning with Nmap

Just because ss -tulnp shows a service listening on 0.0.0.0:3306 does not mean the outside world can actually connect to it.

Your server might sit behind:

A cloud security group (AWS EC2 Security Groups, GCP Firewall Rules, Azure Network Security Groups)
A perimeter hardware firewall or load balancer
Host-level packet filter rules (nftables or iptables)

To know what is truly exposed, you must test from the outside looking in using nmap.

# Run a TCP SYN scan from an external machine
nmap -sS -p- -T4 198.51.100.4

Notice the -p- flag. By default, nmap only scans its top 1,000 common ports. If an engineer runs a vulnerable management interface on port 8443, 9000, or 27017, a default nmap <IP> command will miss it entirely. The -p- flag tells Nmap to scan all 65,535 ports.

When Nmap probes your server, every port lands in one of four distinct states:

Open: The target host replied with a TCP SYN-ACK packet. An application is actively listening, and the firewall permitted the packet to reach it.
Closed: The target host replied with a TCP RST (reset) packet. No application is listening on that port, but the packet successfully reached the operating system. Crucially, this proves that your firewall allowed the packet through!
Filtered: Nmap received no reply at all (the probe timed out), or received an ICMP error code like "Destination Unreachable (Communication Administratively Prohibited)". A firewall or security group dropped the packet before it ever reached the host OS.
Unfiltered: Nmap received a response, but cannot determine if the port is open or closed (typically seen during raw ACK scans -sA).

Understanding the difference between closed and filtered is vital for server hardening.

Look at this Nmap scan output:

PORT     STATE    SERVICE
22/tcp   open     ssh
80/tcp   open     http
3306/tcp closed   mysql
8080/tcp filtered http-proxy

Port 8080 is filtered. The cloud security group or firewall silently dropped the SYN packet. The outside world cannot tell if the machine even exists on that port.

Port 3306 is closed. There is no MySQL daemon listening on port 3306. But because the port is reported as closed rather than filtered, the server responded with an active RST packet.

That tells an attacker two critical pieces of intelligence:

The firewall permitted incoming traffic on port 3306.
The host operating system is alive and processing packets.

If someone subsequently starts a container or service that binds to 0.0.0.0:3306, that service will become instantly accessible to the world without any firewall configuration changes.

This is why you should always configure your host firewall to DROP packets rather than REJECT them:

# In iptables:
sudo iptables -A INPUT -p tcp --dport 3306 -j DROP

A DROP rule makes the port appear filtered. A REJECT rule sends a RST or ICMP error packet back to the sender, confirming your server's presence.

6. Ghost Ports and Systemd Socket Activation

Sometimes you will run ss -tulnp and find a port listening that belongs to a service you thought was completely stopped.

Consider systemd socket activation.

Under systemd, services do not need to run continuously in background memory to listen on network ports. Instead, systemd creates a listening socket on their behalf at boot time:

# Check active systemd sockets
systemctl list-sockets

Output:

LISTEN               UNIT                        ACTIVATES
/run/systemd/journal/stdout systemd-journald.socket     systemd-journald.service
[::]:22              sshd.socket                 sshd.service
127.0.0.1:631        cups.socket                 cups.service

Notice sshd.socket listening on port 22.

In this architecture, the sshd daemon is not running. It consumes zero megabytes of RAM and zero CPU cycles.

Instead, PID 1 (systemd) holds open the network socket descriptor. When an incoming TCP SYN packet arrives on port 22, the Linux kernel wakes systemd, which spawns sshd.service on the fly and hands off the active socket descriptor via the sd_listen_fds() API.

If you run systemctl stop sshd hoping to close port 22, the port stays wide open! The moment someone connects to port 22, sshd.socket detects the incoming packet and boots the service right back up.

To genuinely close a socket-activated service, you must stop both the unit and its underlying socket:

sudo systemctl stop sshd.service
sudo systemctl stop sshd.socket
sudo systemctl disable sshd.socket

7. The UDP Blindspot

Most security audits focus obsessively on TCP ports. TCP is connection-oriented: you send a SYN, you get a SYN-ACK or RST, and you know where you stand.

UDP is stateless. There is no three-way handshake.

When you send a UDP packet to an open UDP port, the application receives the data. But unless that specific application is programmed to send a reply back for that specific payload, it remains completely silent.

If a UDP port is closed, the host operating system kernel sends back an ICMP packet: Type 3, Code 3: Destination Unreachable (Port Unreachable).

However, the Linux kernel strictly rate-limits how many ICMP Port Unreachable packets it will send per second to prevent denial-of-service amplification:

# Check Linux ICMP rate limit settings
cat /proc/sys/net/ipv4/icmp_ratelimit
# Default is typically 1000 milliseconds (1 second)

Because of this rate limit, scanning all 65,535 UDP ports with Nmap (nmap -sU) takes hours. Most packets receive neither a payload response nor an ICMP unreachable packet, forcing Nmap to classify them as open|filtered:

PORT     STATE         SERVICE
53/udp   open          domain
68/udp   open|filtered dhcpc
123/udp  open          ntp
5353/udp open|filtered zeroconf

Common UDP listeners that quietly expose systems:

Port 5353 (mDNS / Avahi): Automatically advertises server hostnames and services on the local subnet. If bound to a public interface, it leaks internal host information.
Port 123 (NTP): Time synchronization daemons. Older, unpatched NTP daemons were notorious for being weaponized in UDP reflection amplification attacks.
Port 51820 (WireGuard): WireGuard is completely silent. If you send an unauthenticated UDP packet to a WireGuard port, it drops the packet without sending any response. To a scanner, a live WireGuard port looks 100 percent dead.

To audit UDP listeners locally, always check ss -ulnp:

sudo ss -ulnp

Look for any unexpected UDP sockets bound to 0.0.0.0 or [::]. If a service like avahi-daemon or an unneeded DHCP client is listening on a static public server, disable it immediately:

sudo systemctl stop avahi-daemon
sudo systemctl disable avahi-daemon

8. A Hardening Protocol: How to Audit Your Exposure in 5 Minutes

Here is a practical, step-by-step routine to verify your server's true exposure:

Step 1: Run the Internal Socket Audit

Log into the server and run:

sudo ss -tulnp

Scan the Local Address:Port column. Flag any internal service (Redis, Postgres, MySQL, Memcached, Elasticsearch, Prometheus metrics exporters like Node Exporter on 9100) bound to 0.0.0.0 or [::].

Step 2: Fix Configuration Bindings

For any internal service, change its configuration file to listen exclusively on localhost:

In Postgres (postgresql.conf): listen_addresses = 'localhost'
In Redis (redis.conf): bind 127.0.0.1 ::1
In MySQL (my.cnf): bind-address = 127.0.0.1

Step 3: Audit Docker Port Publishing

Inspect all running containers for wildcards:

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

If you see 0.0.0.0:8080->8080/tcp, update your docker-compose.yml or launch command to specify 127.0.0.1:8080:8080.

Step 4: Scan from the Outside

From an external computer (not inside the same VPC or subnet), run a full TCP scan:

nmap -sS -p- -T4 <YOUR_SERVER_PUBLIC_IP>

Verify that only the intended ports (typically just 22, 80, and 443) report as open. Any other port should report as filtered.

Step 5: Add an Instant Audit Alias

Add this alias to your ~/.bashrc on servers you manage:

# Add to ~/.bashrc
alias exposed='sudo ss -tulnp | grep -E "0\.0\.0\.0|\[::\]"'

Running exposed will immediately filter out localhost listeners and display only the processes actively listening on all interfaces.

Interesting Fact

In the original BSD 4.2 Unix network implementation in 1983, developers created "raw sockets" (SOCK_RAW), allowing user processes with root privileges to bypass the transport layer entirely and construct arbitrary IP packets from scratch.

Because of raw sockets, port numbers are purely software conventions enforced by operating system kernels. A custom packet generator can send TCP packets with port number 0, invalid checksums, or reserved TCP flag combinations (like SYN+FIN or "Christmas Tree" packets with FIN+URG+PSH all turned on simultaneously).

Security analysts and attackers use these malformed packets to fingerprint remote operating systems: Linux, FreeBSD, and Windows each handle illegal port numbers and flag combinations with subtle differences in their TCP/IP stack implementations.

Conclusion

Security on a Linux server is not defined by how many services you have installed. It is defined by how those services bind to your network interfaces and what the kernel allows through its routing chains.

A default firewall policy in UFW is not an impenetrable shield. If Docker rewrites your nat table, or if a database daemon binds to 0.0.0.0 on a public IP, your service is open to automated vulnerability scanners crawling the IPv4 address space within minutes.

Check your listening sockets with ss -tulnp. Bind internal services to 127.0.0.1. Force Docker to publish only to loopback. And always verify your exposure from the outside with Nmap.

Question to Reader

Have you ever found a Docker container or development database accidentally exposed to the public internet because of an unexpected 0.0.0.0 bind?

About the Author

Asep Sayyad is a Linux and DevOps engineer passionate about Linux administration, automation, cloud technologies, containers, and open-source software. He enjoys solving real-world infrastructure challenges and sharing practical knowledge through in-depth technical articles, tutorials, and hands-on guides.

His goal is to help aspiring and experienced engineers build stronger Linux and DevOps skills with content focused on real production scenarios rather than theory alone.

Connect with Me

Portfolio: asepsayyad007.in
Blog: asepsayyad007.in/blogs
GitHub: github.com/asepsayyad007
LinkedIn: linkedin.com/in/asepsayyad
Medium: asepsayyad007.medium.com

Enjoyed this article?

If you found this guide helpful, consider:

Starring my open-source projects on GitHub.
Sharing this article with fellow Linux and DevOps engineers.

You can also follow me for more practical content on Linux, DevOps, Cloud, Containers, Automation, and Open Source. Thanks for reading, and enjoy your learning!

DEV Community