Which ports should I block on my firewall?

The short answer, as a picture: default-deny

The single most important idea in firewall design is that the wall is closed by default. Traffic is denied unless a rule explicitly lets it through. A small allowlist of ports gets a gate; everything else — the SMB, RDP, Telnet, and database ports attackers scan for constantly — hits solid wall.

* SSH (22) is allowed only from trusted management IPs, never the whole internet.

This is the exact opposite of how many people picture a firewall. You are not hunting down bad ports to block; you are keeping a short list of good ports to allow and denying the other ~65,000 automatically. This post pairs with the ports attackers scan for most — that article is the attacker's-eye view of the same list.

The block-vs-allow decision, port by port

Use this table as the default policy for a typical business network with an internet perimeter. "Block inbound" means at the internet boundary; internal segmentation may still allow a port between specific systems. "Filter egress" means restrict which internal hosts may use the port outbound.

Port(s)	Service	Block inbound?	Filter egress?	Why
23	Telnet	Block always	Block	Sends credentials in plaintext; use SSH (22) instead
21	FTP	Block always	Block	Unencrypted transfer; use SFTP over 22
137-139	NetBIOS	Block always	Block	Legacy Windows name/session services; worm and info-leak vector (135 is MS-RPC and belongs with it)
445	SMB	Block always	Block	Windows file sharing; the WannaCry / NotPetya ransomware vector — never expose
3389	RDP	Block (VPN only)	Block	Top ransomware entry point via brute force; publish only behind VPN/MFA
5900	VNC	Block always	Block	Weak or no encryption; use RDP-over-VPN or SSH
3268-3269	LDAP Global Catalog	Block	Restrict	Exposes Active Directory to enumeration; keep internal to admin systems
110 / 143	POP3 / IMAP	Block	Restrict	Unencrypted mail; migrate to 995 / 993 with TLS
25	SMTP	Block inbound (unless MX)	Block except mail server	Open relay and spam-from-compromised-host risk
1433-1434	MS SQL Server	Block always	Block	Databases must never be internet-facing; restrict to app servers
3306	MySQL / MariaDB	Block always	Block	Same as above — internal, app-server-only access
5432	PostgreSQL	Block always	Block	Same as above
27017	MongoDB	Block always	Block	Historically shipped with no auth; countless open-DB breaches
6379	Redis	Block always	Block	No authentication by default; trivial to abuse if exposed
161-162	SNMP	Block always	Block	Leaks device config; UDP amplification source
22	SSH	Allow from trusted IPs only	Restrict to known hosts	Admin access; heavily brute-forced, so never open to all
80	HTTP	Allow only if hosting web	Allow	Web traffic; ideally just redirects to 443
443	HTTPS	Allow only if hosting web	Allow	Encrypted web traffic — the main service most orgs publish
53	DNS	Allow to your resolvers only	Restrict to approved resolvers	Required, but watch for DNS tunneling / amplification
123	NTP	Block inbound	Allow	Time sync outbound is fine; amplification risk if open inbound

The pattern is consistent: almost everything is "block inbound," a tiny set is "allow," and egress filtering exists to contain a machine that has already been compromised.

Firewall Port Blocking Strategy

Firewall configuration is fundamental to network security. Rather than allowing all ports by default, modern firewalls default to blocking all traffic and explicitly allowing only necessary ports. This "deny by default" approach minimizes attack surface.

The challenge is determining which ports to block and which to allow. The answer depends on your organization, network architecture, and security posture.

Dangerous Ports to Block

Certain ports are inherently dangerous and should be blocked unless explicitly required:

Port 23 (Telnet): Transmits credentials in plaintext. Telnet is deprecated and insecure. Block completely unless legacy systems absolutely require it (and even then, consider it a critical vulnerability).

Port 21 (FTP): File transfer without encryption. Credentials and data are transmitted in plaintext. Use SFTP (port 22) or other secure alternatives. Block FTP unless legacy systems depend on it.

Port 25 (SMTP without encryption): Unencrypted email. Block from internal networks to prevent spam relay through your systems. If internal mail servers need SMTP, restrict to specific internal systems.

Port 135-139 (NetBIOS): Windows network services over unencrypted protocols. Particularly dangerous on internet-facing systems. Should be blocked from external networks and segmented internally.

Port 445 (SMB): Windows file sharing. Extremely dangerous if exposed to the internet—major ransomware vector. Block from internet access absolutely. Segment internally for workstation access only.

Port 3389 (RDP): Remote Desktop Protocol. Frequently targeted for brute-force attacks. Block from internet. If remote access is needed, use VPN first, then RDP only from VPN.

Port 5900 (VNC): Remote desktop without modern encryption. Old and vulnerable. Use RDP or SSH instead. Block unless legacy systems require it.

Port 3268/3269 (LDAP): Directory services. Expose internal directory to attackers if accessible externally. Block from internet. Restrict internally to administrative systems.

Port 143/110 (IMAP/POP3): Email protocols. Should use encrypted versions (587 with TLS, 993, 995). Block unencrypted versions or migrate to encrypted alternatives.

Port 5432/3306 (PostgreSQL/MySQL): Database ports. Never expose these to the internet. Block completely from external networks. Restrict internally to authorized database clients only.

Port 1433/1434 (SQL Server): Microsoft SQL Server. Block completely from internet. Restrict internally to authorized systems.

Port 27017 (MongoDB): NoSQL database. Block from internet. Restrict internally.

Reasonable Default Block List

For most organizations, a reasonable default block list includes:

Telnet and Legacy Protocols:

• 21 (FTP) - use SFTP instead
• 23 (Telnet) - use SSH instead
• 69 (TFTP) - insecure file transfer

Windows Sharing:

• 135-139 (NetBIOS)
• 445 (SMB)
• 3268-3269 (LDAP)

Remote Access:

• 5900 (VNC)
• 5985 (WinRM without encryption)

Database Ports:

• 1433 (SQL Server)
• 3306 (MySQL)
• 5432 (PostgreSQL)
• 27017 (MongoDB)
• 6379 (Redis)

Email:

• 110 (POP3 unencrypted)
• 143 (IMAP unencrypted)
• 25 (SMTP unencrypted, from internet)

SNMP and Management:

• 161-162 (SNMP unencrypted)
• 514 (Syslog unencrypted)

Other Dangerous Ports:

• Any ports your organization doesn't actively use

Ports to Allow (Minimal Set)

Instead of listing all dangerous ports to block, establish which ports to allow and block everything else:

Standard Web Protocols:

• 80 (HTTP) - often needed for web traffic
• 443 (HTTPS) - secure web traffic, needed for most internet access

Email:

• 25 (SMTP outbound, restricted to mail servers)
• 587 (SMTP with encryption)
• 993 (IMAPS)
• 995 (POP3S)

DNS:

• 53 (DNS queries)

Remote Access (with restrictions):

• 22 (SSH) - restricted to administrative networks
• 3389 (RDP) - only for internal access or through VPN

NTP:

• 123 (Network Time Protocol)

Everything else should be blocked by default.

Ingress vs. Egress Filtering

Firewall rules differ for inbound and outbound traffic:

Ingress (Inbound): Block all by default, allow specific services:

Allow TCP 80 (HTTP) from anywhere
Allow TCP 443 (HTTPS) from anywhere
Allow TCP 22 (SSH) from trusted IPs only
Block everything else

Egress (Outbound): Block dangerous outbound services but allow general internet access:

Allow TCP 80 (HTTP)
Allow TCP 443 (HTTPS)
Allow UDP 53 (DNS)
Allow UDP 123 (NTP)
Block TCP 25 (SMTP outbound) - prevent spam
Block database ports outbound - prevent data exfiltration
Block common backdoor ports outbound - prevent C2 communication

Egress filtering prevents compromised systems from contacting attackers or exfiltrating data.

Port Blocking by Network Segment

Different network segments require different port policies:

Internet Boundary:

• Allow: 80, 443, 53
• Block: Everything else

Corporate Network:

• Allow: 80, 443, 22 (SSH), 3389 (RDP)
• Block: Database ports, file sharing ports, telnet

Development/Testing:

• Allow: 80, 443, 22, 3306, 5432, custom ports
• Monitor: Unusual port activity

Production Databases:

• Allow: Database port (3306, 5432) from web servers only
• Block: Everything else including internet access

Stateful Filtering

Modern firewalls use stateful inspection, allowing responses to outbound connections:

Outbound rule: "Allow TCP 443 outbound" Automatic return: Responses to that connection (TCP ACK packets) are automatically allowed back without explicit ingress rule

This approach allows internet browsing without explicitly allowing inbound connections.

High-Numbered Port Strategy

High-numbered ports (>49152) are dynamic ports, often considered less dangerous than well-known ports because they're less likely to contain standard services. However, this isn't a security reason to allow them:

Avoid blanket blocking of high ports: Some legitimate applications use them Instead, apply specific rules: If services require high ports, allow them explicitly Monitor high ports: Activity on unusual high ports might indicate compromise

Egress Blocking for Threat Prevention

Blocking certain egress ports prevents compromised systems from communicating with attackers:

Outbound SMTP (Port 25): Prevents spam from compromised systems Outbound SSH (Port 22): Prevents SSH-based backdoors from communicating Outbound RDP (Port 3389): Prevents RDP backdoors from operating Dynamic port ranges: Some organizations restrict outbound dynamic ports to prevent unauthorized communication

DNS Port Considerations

DNS uses port 53 but has special considerations:

TCP vs UDP: Standard DNS uses UDP 53, but larger queries use TCP 53. Allow both.

Recursive DNS: Block DNS responses from the internet (prevent DNS amplification attacks)

DNS tunneling: Some malware uses DNS for command and control. Advanced DNS filtering detects and blocks suspicious DNS queries.

Rate Limiting and Brute Force Protection

Beyond port blocking, apply rate limiting to ports like SSH and RDP to prevent brute-force attacks:

Allow SSH (port 22) but limit to 5 connections per minute per IP
Allow RDP (port 3389) but limit to 3 connections per minute per IP

Rate limiting slows attackers without blocking legitimate traffic.

Documenting Firewall Rules

Proper documentation is critical:

• Document why each port is allowed or blocked
• Document which systems require exceptions
• Document change history
• Review periodically for necessary ports

Without documentation, firewall configurations become impossible to maintain as staff changes.

Firewall Exceptions and Risk Management

Sometimes you must allow dangerous ports for business reasons:

Scenario: Legacy database system requires access from remote office Risk: Exposing database directly to internet Mitigation Options:

• Use VPN so database access is internal-only
• Restrict database access to specific IPs
• Use SSH tunneling to secure the connection
• Require multi-factor authentication
• Monitor database access closely

Document exceptions thoroughly and regularly review them for necessity.

Testing Firewall Rules

After configuring firewall rules, test them:

# Test port is blocked (should timeout)
nc -zv example.com 23
nc: connect to example.com port 23 (tcp) failed: Connection timed out

# Test port is allowed (should connect)
nc -zv example.com 443
Connection to example.com 443 port [tcp/https] succeeded!

Tools for testing:

• netcat (nc)
• nmap
• telnet
• Custom test applications

Before you push a rule set to production, it helps to validate the logic itself—evaluating which packets a given ordered rule list will allow or deny. Our firewall rule simulator lets you model an allow/deny ruleset and test sample traffic against it, so you can catch shadowed rules and unintended permits before they reach a live firewall.

Conclusion

Block dangerous ports by default: telnet, unencrypted protocols, database ports, remote access ports, and any non-essential services. Allow only required ports: web (80, 443), SSH (22) for administration, and DNS (53). Use stateful filtering to allow responses to outbound connections without explicit inbound rules. Apply segmentation so different network areas have different port policies. Document all rules and exceptions. Regularly review and update firewall configurations as business needs and threats evolve. A well-configured firewall blocking unnecessary ports is one of the most effective security controls available.