What is a default-deny firewall policy?

Default-deny means the firewall blocks all inbound traffic unless a rule explicitly allows it. You open only the specific ports a service needs, rather than blocking known-bad ports one by one. It is the safest baseline for any internet-facing host.

Is it safe to expose RDP if I use a strong password?

No. RDP on port 3389 is constantly scanned and brute-forced, and has had wormable vulnerabilities like BlueKeep. Even with strong credentials, put RDP behind a VPN or bastion host and never expose it directly.

Why should databases never be reachable from the internet?

Database ports such as 3306, 5432, 1433, 27017 and 6379 often ship with weak or no authentication and expose all your data in one place. They should only be reachable from application servers on a private network.

Which ports should you block at the firewall?

A firewall's job is not to block a list of "bad" ports — it is to allow only what you need and deny everything else. Still, some services are so dangerous when exposed that they deserve a named place on your block list. This guide walks through the ports you should never see open to the internet, the risk each one carries, and what to do instead.

Start with default-deny inbound

The single most important rule is default-deny inbound: block all incoming connections, then open only the specific ports a service genuinely needs (typically port 443 for HTTPS and perhaps port 80 for redirects). Everything below assumes you are auditing an environment where that baseline slipped. You can browse all ports to look up anything you find listening.

Never expose SMB on port 445 or the legacy NetBIOS ports port 137 and port 139 to the internet. SMB has a long history of wormable bugs — EternalBlue (WannaCry, NotPetya) targeted exactly this. What to do instead: keep SMB strictly internal, and reach file shares over a VPN.

Remote access: RDP and Telnet

Port 3389 (RDP) is one of the most attacked ports on the internet, brute-forced around the clock and hit by wormable flaws like BlueKeep. Port 23 (Telnet) is worse still: it sends credentials in cleartext and has no place on a modern network. What to do instead: put RDP behind a VPN or bastion host, and replace Telnet with SSH on port 22.

Databases

Database ports are a top target because one breach exposes everything. Block all of these at the perimeter:

port 3306 — MySQL / MariaDB
port 5432 — PostgreSQL
port 1433 — Microsoft SQL Server
port 27017 — MongoDB
port 6379 — Redis
port 9200 — Elasticsearch

What to do instead: bind them to a private interface and allow access only from your application servers.

Unauthenticated and management services

Some services ship with little or no authentication and are catastrophic when exposed:

port 6379 — Redis historically has no auth by default; an open instance is a remote-code-execution risk.
port 2375 — the unencrypted Docker API gives full root-equivalent control of the host.
port 10000 — Webmin and similar admin panels are heavily targeted.
port 11211 — Memcached has been abused for massive UDP amplification attacks.

What to do instead: enable authentication and TLS, bind to localhost, and administer over a VPN.

Legacy and cleartext protocols

Older protocols send data — including passwords — in the clear:

port 21 — FTP (use SFTP over port 22 instead)
port 23 — Telnet
port 69 — TFTP, which has no authentication at all

What to do instead: disable them entirely and use encrypted replacements.

UDP amplifiers

Connectionless UDP services can be abused to reflect and amplify DDoS traffic. If you do not need them publicly, block:

port 53 — DNS (only authoritative servers should answer the world)
port 123 — NTP
port 161 — SNMP
port 1900 — SSDP

What to do instead: restrict these to trusted networks and disable recursion or monlist-style features where possible.

Conclusion

Firewalls work best as gatekeepers, not blocklists: deny inbound by default and expose only the handful of ports a service truly requires. But the ports above — SMB, RDP, Telnet, databases, unauthenticated admin interfaces, cleartext legacy protocols, and UDP amplifiers — are common enough mistakes that they are worth checking for by name. When in doubt, keep the service private and reach it through a VPN or bastion host.