Which port is attacked the most?

RDP on port 3389 and SSH on port 22 consistently top internet-wide scan and brute-force telemetry, followed by SMB on port 445. All three are remote-access surfaces that attackers can use directly once credentials or an exploit succeed.

Should I just close these ports?

If a service does not need to be reachable from the internet, yes — close it at the firewall or bind it to localhost. For services you genuinely must expose, put them behind a VPN, restrict source IPs, and enforce strong authentication.

The most commonly attacked ports (and how to secure them)

Attackers do not scan the whole internet at random — they target a short list of ports that reliably lead to compromise. Mass scanners hammer these services within minutes of a host appearing online. This post walks through the most commonly attacked ports, why each is a target, and the one hardening step that matters most for each. You can look up any of these on PortsDB or browse all ports.

Remote access: the top targets

RDP — port 3389

Remote Desktop is the single most abused entry point. Exposed RDP invites credential brute forcing and exploitation of vulnerabilities like BlueKeep (CVE-2019-0708), a wormable pre-auth flaw. It is the favorite initial-access vector for ransomware crews. #1 step: never expose port 3389 directly — put it behind a VPN or RD Gateway and require network-level authentication.

SSH — port 22

SSH faces relentless automated brute-force and credential-stuffing traffic. #1 step: disable password authentication entirely and use key-based auth, then rate-limit with fail2ban.

Telnet — port 23

Telnet sends credentials in cleartext and is a primary target for IoT botnets like Mirai. #1 step: disable Telnet completely and replace it with SSH on port 22.

VNC — port 5900

VNC servers are frequently exposed with weak or no authentication. #1 step: tunnel VNC over SSH and never bind it to a public interface.

SMB — port 445

SMB is the home of EternalBlue (MS17-010), the exploit behind WannaCry and NotPetya. It is still scanned constantly. #1 step: block port 445 and port 139 at the perimeter and patch aggressively; SMB should never face the internet.

FTP — port 21

FTP transmits credentials in cleartext and anonymous FTP often leaks data. #1 step: replace it with SFTP over port 22 or FTPS, and disable anonymous login.

Web services

HTTP — port 80

Plain HTTP on port 80 is probed for vulnerable apps, exposed admin panels, and is a launch pad for injection attacks. #1 step: redirect everything to HTTPS on port 443 and keep your web stack patched. Watch out for stray proxies on port 8080 and port 3128 too.

Databases — never expose these

Databases bound to public interfaces are a goldmine. The fix is almost always the same: bind to localhost or a private network, require authentication, and firewall the port.

MySQL — port 3306: brute forced and probed for default credentials.
MS-SQL — port 1433: targeted via xp_cmdshell and weak sa passwords. Also watch UDP port 1434.
PostgreSQL — port 5432: scanned for trust-auth misconfigurations.
Redis — port 6379: unauthenticated by default; attackers write SSH keys or cron jobs to gain RCE.
MongoDB — port 27017: the original "open database" ransom target.
Elasticsearch — port 9200: exposed clusters leak data and allow script execution.
Memcached — port 11211: abused for massive UDP reflection DDoS.

Other frequent targets

Keep an eye on SIP on port 5060 (toll-fraud scanning), the Docker API on port 2375 (unauthenticated container takeover), and SNMP on port 161 (default community strings leaking device data).

Conclusion

The pattern is consistent: remote-access and database ports get hit hardest, and the strongest defense is to not expose them at all. Put admin surfaces behind a VPN, bind databases to private networks, enforce key-based or strong authentication, and patch the wormable bugs. Reducing your internet-facing attack surface to only port 443 — and a hardened SSH — eliminates most of the risk.