What Are Ports? Common Port Numbers Every Admin Should Know

A network port is a virtual endpoint for communication on a computer. While an IP address identifies a device on a network, a port identifies a specific application or service running on that device.

Think of it this way: if an IP address is like a building's street address, a port number is like the suite number inside that building. The address gets you to the right building, and the suite number gets you to the right office.

Port numbers range from 0 to 65535. When your browser connects to a web server, it connects to the server's IP address on port 443 (for HTTPS). When you send an email, your mail client connects to the mail server on port 587 (for SMTP submission).

Ports are divided into three ranges by IANA (Internet Assigned Numbers Authority):

Well-Known Ports (0–1023): Reserved for common, standardized services. These ports are assigned by IANA and typically require administrator/root privileges to use. Examples: HTTP (80), HTTPS (443), SSH (22), FTP (21), DNS (53).

Registered Ports (1024–49151): Used by software applications and services. Vendors can register ports with IANA for their applications. Examples: MySQL (3306), PostgreSQL (5432), Redis (6379), Minecraft (25565).

Dynamic/Ephemeral Ports (49152–65535): Temporarily assigned by the operating system for outgoing connections. When your browser connects to a website, the OS assigns a random port from this range as the source port for that connection.

Ports work with two transport protocols:

TCP (Transmission Control Protocol): Connection-oriented, reliable delivery. TCP establishes a connection (three-way handshake) before sending data and guarantees that all packets arrive in order. Used for: web browsing, email, file transfer, SSH — anything where data integrity matters.

UDP (User Datagram Protocol): Connectionless, faster but unreliable. UDP sends packets without establishing a connection or guaranteeing delivery. Used for: DNS queries, video streaming, online gaming, VoIP — anything where speed matters more than perfect delivery.

Many services use both TCP and UDP. DNS, for example, uses UDP for standard queries (faster) but falls back to TCP for large responses or zone transfers.

Use LookMyIP's Port Checker tool to test whether specific ports are open and reachable on your server or network.

Close unnecessary ports: Every open port is a potential attack vector. Only keep ports open that are actively needed for services you run.

Use non-standard ports for sensitive services: Moving SSH from port 22 to a non-standard port (e.g., 2222) reduces automated brute-force attempts. This is security through obscurity — not a substitute for proper authentication, but it reduces noise.

Firewall rules: Configure your firewall to explicitly whitelist required ports and block everything else. Review open ports regularly.

Port scanning awareness: Attackers use port scanners (like nmap) to discover open ports on your network. Regular self-scanning helps you identify and close unintended exposures. Use LookMyIP's Port Checker to see what ports are visible from the outside.

Keep services updated: An open port is only as secure as the service listening on it. Outdated software with known vulnerabilities is a primary entry point for attackers.

Some services were designed for trusted internal networks and have authentication models that assume nobody hostile can reach them. Exposing these is how most opportunistic compromises happen — automated scanners find them within minutes of a host coming online.

The pattern is consistent: databases, caches and management interfaces. Every one of these should be bound to 127.0.0.1 or a private interface and reached through SSH tunnelling, a VPN, or a bastion host.

Binding correctly is the fix, and it is more reliable than firewall rules because it does not depend on a filter staying configured:

# PostgreSQL — postgresql.conf
listen_addresses = 'localhost'

# Redis — redis.conf
bind 127.0.0.1
protected-mode yes

# MongoDB — mongod.conf
net:
  bindIp: 127.0.0.1

Verify what is actually listening on a machine, and on which interface:

sudo ss -tlnp

Anything showing 0.0.0.0: or [::]: is accepting connections from anywhere the network allows. Then confirm from outside with the open port checker — the external view is the one that matters.

Discussion of ports concentrates on the server side, but every connection has two ends, and the client end causes its own category of problem.

When your browser connects to a web server, it binds a random high-numbered source port — an ephemeral port. The connection is identified by the four-tuple of source IP, source port, destination IP and destination port, which is what allows one machine to hold many simultaneous connections to the same server.

The ranges differ by platform:

Linux     32768–60999   (sysctl net.ipv4.ip_local_port_range)
Windows   49152–65535
macOS     49152–65535

Two operational issues follow.

Ephemeral port exhaustion. A busy server making many outbound connections — a reverse proxy, an API gateway, a load-testing client — can consume the entire range. New connections then fail with EADDRNOTAVAIL, usually under exactly the load conditions where you least want it. The situation is made worse by TIME_WAIT, a state that holds a closed connection's port for 60 seconds by default to catch stray packets. Check current usage:

ss -s
netstat -an | grep -c TIME_WAIT

Remedies, in order of preference: use connection pooling and keep-alive so you open far fewer connections; widen the range with net.ipv4.ip_local_port_range = 10000 65535; enable net.ipv4.tcp_tw_reuse = 1 to allow safe reuse of TIME_WAIT sockets for outbound connections. Do not enable the long-removed tcp_tw_recycle, which broke connections from clients behind NAT and was deleted from the kernel in 4.12.

Stateless firewalls need return-path rules. A stateful firewall tracks connections and automatically permits the reply. A stateless one — notably AWS Network ACLs — does not. If you allow inbound 443 but forget to allow outbound to the ephemeral range, the request arrives and the response is silently dropped, producing a hang rather than a clean error.

Moving SSH from 22 to 2222 is standard advice, and it is worth being precise about what it achieves.

What it does. It eliminates the overwhelming majority of automated noise. Bots scanning the entire IPv4 space overwhelmingly probe port 22 only, so a non-standard port removes thousands of daily authentication attempts from your logs. That is a real benefit — not because those attempts would have succeeded, but because a quiet log is one where genuine anomalies are visible.

What it does not do. It stops nobody who is targeting you specifically. A full port scan finds the service in seconds, and service fingerprinting identifies it immediately:

nmap -sV -p- example.com

Treating an unusual port as a security control rather than a noise filter is the mistake. The controls that actually protect SSH are:

Key-based authentication only. Set PasswordAuthentication no and PermitRootLogin no in sshd_config. Brute forcing becomes irrelevant, because there is nothing to brute force.

Source restriction. Allow connections only from known networks, or from a VPN.

fail2ban or equivalent. Bans an address after repeated failures.

One caution about non-standard ports: choose one below 1024 if you can, or make sure the service starts before any unprivileged user could bind the port. On Linux, ports above 1024 can be bound by any user, so if your SSH daemon fails to start on port 2222, a local user could bind it and impersonate the service.

Finally, remember that changing the port changes the client experience for everyone. Document it, and update your firewall rules and monitoring before you restart the daemon — not after.

What is the difference between a port being closed and filtered?

A closed port responds with a TCP RST, telling the client immediately that nothing is listening. A filtered port produces no response at all, because a firewall dropped the packet, so the client waits for a timeout. Scanners distinguish these, and the difference tells you whether a firewall is present.

Why is my port open according to my server but closed from outside?

Something between you and the internet is filtering. Work outward: check the service is bound to a public interface rather than localhost with ss -tlnp, then the host firewall, then any cloud security group or network ACL, then whether your ISP blocks the port. ISPs commonly block 25 (SMTP), 445 (SMB) and sometimes 80 and 443 on residential connections.

Do I need to open ports for outbound connections?

Not with a stateful firewall, which permits the return traffic automatically. With a stateless one, yes — you must explicitly allow the return path to the ephemeral port range.

How many ports can be open at once?

65,535 per protocol per IP address, since the port field is 16 bits. TCP and UDP have independent spaces, so port 53 TCP and port 53 UDP are different things — which is exactly the case for DNS, where UDP carries normal queries and TCP handles large responses and zone transfers.

Is port scanning legal?

The legal position varies by jurisdiction and is genuinely unsettled. Scanning systems you own or have written authorisation to test is clearly fine. Scanning third-party systems without permission is at best a terms-of-service violation with your provider and, in some jurisdictions, potentially an offence. Get authorisation in writing before scanning anything you do not control.