Common Ports Attackers Target, and How to Harden Them

Every service on a network listens on a port, a numbered doorway that lets traffic reach the right program. When an attacker scans a host, they are reading which doorways are open, which service answers, and what version it runs. That fingerprint decides where they push next.

This is a defensive reference. The port numbers below are the IANA-registered or de facto defaults, the ones you should recognise on sight in a firewall log or a scan result. The value of knowing them is speed: when you see 3389 open to the internet, you should already feel the alarm before you look anything up.

The ports attackers scan for first

The table groups the ports most consistently probed in internet-wide scan data. Protocol is the transport (TCP unless noted). The hardening note is the single highest-value action, not the full checklist.

The pattern repeats across the table. The two failure modes are a cleartext protocol that leaks whatever passes through it, and a service that should have been private facing the open internet with weak or absent authentication.

Why exposure is the common thread

Most of the hardening notes above reduce to one instruction: take the service off the public internet. Management ports (SSH, RDP, VNC), Windows internals (RPC, SMB, NetBIOS), and databases (MSSQL, MySQL, Postgres, Redis, Mongo, Elasticsearch) almost never have a legitimate reason to accept connections from arbitrary hosts on the internet.

Internet-wide scanners index every reachable service continuously. An exposed RDP endpoint or an authentication-free MongoDB is found in minutes, not months. The defensive win is structural: put these services behind a firewall, a VPN, or a bastion host, and the scanners simply cannot reach them.

Encrypted alternatives handle the cleartext problem. SFTP replaces FTP, SSH replaces Telnet, HTTPS replaces HTTP, and the mail and directory protocols all have TLS variants. Moving to the encrypted version removes the credential-capture risk that the cleartext port carries by design.

From open port to real risk

An open port is an invitation, and which invitations matter depends on what the service is worth and how exploitable it is right now. Our Exploit Intelligence dashboard tracks which port-facing services carry actively exploited vulnerabilities, so you can tell an exposed but patched service from one that is under live pressure. Pair the exposure map below with that live view to sort your remediation queue.

How ports actually work

Recognising the numbers is more useful once you know what a port is at the protocol level. A port is a sixteen-bit number, so the range runs from 0 to 65535. It exists so that a single host with one IP address can run many services at once and still send each incoming packet to the right program. The combination of source IP, source port, destination IP, and destination port, together with the transport protocol, uniquely identifies a connection, which is how your machine keeps dozens of simultaneous conversations straight.

The range is split by convention. Ports 0 to 1023 are the well-known ports, assigned by IANA to standard services, and on many systems only a privileged process may bind to them. Ports 1024 to 49151 are the registered ports, assigned to specific applications on request. Ports 49152 to 65535 are the dynamic or ephemeral ports, which clients use as the temporary source port for outbound connections. When your browser connects to a web server on port 443, your side of the connection uses a high ephemeral port as its source, and the server's side uses 443 as its destination.

Transport protocol matters as much as the number. TCP is connection-oriented, with a handshake that establishes state before data flows, which is why services that need reliable ordered delivery, such as web and mail, run on it. UDP is connectionless, sending datagrams without a handshake, which suits DNS lookups, some VPNs, and streaming. A port number can be used by both protocols independently, so TCP 53 and UDP 53 are distinct, and DNS uses both for different purposes. When you read a scan result, the protocol next to the number is part of the identity of the service, not a detail to skip.

What a scan actually sees

An attacker or a defender scanning a host is probing ports to learn their state, and a port reports as one of three things. Open means a service accepted the connection and is listening. Closed means the host is reachable but nothing is listening on that port, so the connection is refused. Filtered means a firewall dropped or blocked the probe, so the scanner cannot tell whether anything is behind it. The difference between closed and filtered is meaningful: a closed port tells an attacker the host is alive and that this service is absent, while a filtered port tells them a firewall is in the way and reveals less.

Beyond the state, a scanner tries to fingerprint the service. It reads banners, the greeting text many services send on connection, and it compares subtle behaviours to a database to guess the software and version. That version guess is what drives the next move, because a known version maps to known vulnerabilities. This is why exposure and version together decide risk, and why simply knowing a port is open is only the first step of the read. For the mechanics of how scanning tools probe and infer, see Port Scanning Explained.

The defensive mirror of this is that you can and should scan yourself the same way. An external unauthenticated scan shows what the internet sees. An internal authenticated scan shows what is really running, including services bound only to internal interfaces. The gap between the two views is precisely your externally reachable attack surface, and closing that gap is often the single highest-value hardening action available.

Reading the two failure modes in depth

The table earlier collapses into two recurring failure modes, and understanding each in depth explains why the hardening notes look so repetitive.

The first failure mode is cleartext. Protocols like Telnet, FTP, plain HTTP, and the non-TLS mail and directory protocols send their data, including credentials, without encryption. Anyone positioned on the network path, whether on the same local network, at an internet exchange, or on a compromised router, can read everything that passes. Capturing a password from a cleartext login requires no exploit and no vulnerability in the ordinary sense. The protocol is doing exactly what it was designed to do; the design simply predates the assumption that networks are hostile. The fix is migration to the encrypted equivalent, which is why SSH replaced Telnet, SFTP and FTPS replaced FTP, HTTPS replaced HTTP, and every legacy mail and directory protocol gained a TLS variant.

The second failure mode is unnecessary exposure. Management interfaces, Windows internal services, and databases are designed to be reached by a small, trusted set of clients, and many ship with weak defaults, optional authentication, or a history of remotely exploitable bugs. When one of these faces the open internet, continuous internet-wide scanning finds it quickly, and the combination of a valuable service and a weak or absent authentication requirement is a standing invitation. The fix is structural: put the service behind a firewall, a VPN, or a bastion host so that arbitrary hosts cannot reach it at all. A service that cannot be reached cannot be attacked from the outside, regardless of its patch level.

A short history of why these defaults exist

Many of the ports on the list carry the assumptions of an earlier, more trusting internet. Telnet, FTP, and the original mail protocols were standardised when networks were small, mostly academic, and largely trusted, so encryption was an afterthought and often absent. SMB and the Windows RPC services grew up on local networks that were assumed to sit safely behind a perimeter, so exposing them to the internet was never part of the design. Databases historically shipped with permissive defaults because the expectation was that a database lived on a protected internal network, reachable only by application servers.

The internet outgrew those assumptions. Ubiquitous connectivity, cloud hosting that puts a public IP on almost anything, and automated mass scanning turned yesterday's convenient defaults into today's exposed attack surface. The encrypted replacements arrived precisely because the cleartext originals were unsafe on an open network, and the modern guidance to keep management and database ports off the internet exists because the old assumption of a trusted perimeter no longer holds. Reading the list as a set of historical accidents, each with a modern correction, makes the hardening notes feel less like arbitrary rules and more like a coherent response to how the environment changed.

Detection signals

For a defender, the port map is also a set of things to watch. Certain patterns in traffic and logs are strong signals of trouble.

Outbound connections from a server to unusual ports can indicate command and control or exfiltration, especially when a machine that should only serve traffic starts initiating connections outward. Inbound connection attempts to management and database ports from unexpected sources suggest scanning or an attempt at direct access. A spike of failed authentications on SSH or RDP is the signature of a brute-force or credential-stuffing campaign. Traffic on port 53 that carries far more data than normal DNS, or long, high-entropy names, can indicate DNS tunnelling used to smuggle data past a firewall. Large UDP responses from services like Memcached or from misconfigured DNS resolvers can indicate participation in an amplification denial-of-service attack.

Common mistakes

A recurring mistake is trusting the port number to tell you the service. Administrators move services to non-standard ports for convenience or in a misguided attempt at security through obscurity, and attackers do the same to hide. SSH on port 2222 is still SSH, and a web server on port 8080 is still a web server. Always confirm what is actually answering with your own scan rather than assuming from the number.

A second mistake is treating security through obscurity as real protection. Moving SSH off port 22 reduces log noise from opportunistic scanners, but it does not stop a targeted attacker, who will find the service quickly. Obscurity is a minor convenience layered on top of real controls like key-based authentication and source restrictions, never a substitute for them.

A third mistake is hardening the perimeter and ignoring the interior. Segmenting the internal network matters because an attacker who lands on one internal host will pivot across flat internal space using exactly the SMB, RPC, and database ports that face inward. Internal segmentation and authentication limit that lateral movement, which maps to the Remote Services technique in MITRE ATT&CK, T1021.

A fourth mistake is closing exposure but never patching. Taking a service off the internet removes most of the risk, and it is the right first move, but a service reachable from inside still needs current patches, because an attacker who gets a foothold will target it. Exposure first, then version, is the priority order, and version is not optional.

Frequently asked questions

What is the difference between a port and a service? A port is a numbered endpoint that lets traffic reach a specific program on a host. A service is the program itself. A service usually listens on a default port by convention, but it can be moved, so the port is a strong hint about the service rather than a guarantee. Confirm the actual service by fingerprinting what answers.

Are the well-known ports the only ones attackers scan? No. Attackers scan the full range when it is worthwhile, including high registered ports where databases, admin panels, and application servers often live. The well-known ports are simply the most consistently probed because so many standard services default to them. Do not assume a high port is safe from scanning.

Does changing the default port improve security? Only marginally. Moving a service reduces noise from untargeted scanners and can slow casual discovery, but a determined attacker finds the service quickly. Treat a non-standard port as minor obscurity on top of real controls, never as a defence in its own right.

Why is exposure more important than the patch level? A service that arbitrary hosts on the internet cannot reach cannot be attacked from the outside, no matter what vulnerabilities it carries. Removing exposure closes the whole external attack surface at once, while patching addresses known bugs one at a time. Close the exposure first, then keep the service patched for the threats that remain from inside.

What is the safest way to allow remote management? Put management services behind a VPN or a bastion host, require strong authentication such as SSH keys or multi-factor login, and restrict the source addresses that may connect. This removes the service from open internet reach while still allowing legitimate administrators in through a controlled path.

How do I tell an exposed service is actually dangerous right now? Combine three facts: is it reachable from the internet, does it require strong authentication, and does the running version carry an actively exploited vulnerability. A service that is exposed, weakly authenticated, and running a version under live exploitation is an emergency, while an exposed but patched and well-authenticated service is a lower priority. Live exploit intelligence is what separates the two.

How to use this reference

1. Recognise the port on sight. In a log or alert, the number should immediately tell you the likely service and its risk profile. That is the point of memorising the common ones.
2. Check exposure first, version second. Whether a service faces the internet matters more than which patch level it runs. Close the exposure, then patch.
3. Prefer the encrypted twin. Where a cleartext protocol has a TLS or SSH-tunnelled equivalent, migrate to it and disable the old one.
4. Gate management and database ports. SSH, RDP, VNC, and every database port belong behind a VPN or bastion, restricted to known source addresses.
5. Verify, do not assume. Confirm what is actually listening with your own scans. Attackers and admins both move services off their default ports.

Ports are the map of your attack surface. Knowing the common ones by heart turns a wall of scan output into a quick read of what is exposed, what leaks, and what to fix first.

Related guides

• Network Security Fundamentals
• SMB Security Explained
• RDP Security Guide
• How SSH Works
• Port Scanning Explained