A firewall is the traffic policy at the edge of a system. It decides which connections are welcome, which require closer inspection, and which should never reach the service.

For a website or business network, that decision is essential. Every exposed port creates an opportunity for unwanted access, automated scanning, credential attacks, and exploitation of vulnerable software.

What a firewall actually does

A firewall evaluates network traffic against a set of rules. Those rules can use source, destination, protocol, port, connection state, application behavior, or identity to allow, reject, or log a request.

Four firewall layers you may encounter

Network or perimeter firewall

This protects the boundary between networks, such as the connection between an office and the internet. It can control traffic for many devices at once.

Host firewall

This runs on an individual server or workstation. It protects the machine even when traffic has already passed the network edge.

Web application firewall

A WAF examines HTTP and HTTPS requests for application-level threats. It complements a network firewall by understanding web patterns such as malicious payloads and abusive requests.

Cloud firewall or security group

Cloud platforms use virtual rules around servers and services. These controls should be treated as part of the architecture, not as a setting to leave at its default.

A practical baseline for web hosting

• Make ports 80 and 443 public when the server hosts a website.
• Restrict SSH, RDP, control panels, and database administration to trusted IP addresses or a VPN.
• Keep database ports private unless there is a reviewed operational requirement.
• Open mail ports only when the server actively provides those mail services.
• Separate public applications from internal management tools.
• Log denied connections and successful administrative access without collecting unnecessary sensitive data.
• Document every exception, its owner, and the reason it exists.

Build rules without locking yourself out

Firewall changes should be staged carefully. Keep a provider console or other recovery method available, apply the management-access rule first, and test a second administrative session before closing the original one.

For remote servers, schedule high-risk changes during a support window and record the rollback commands in advance. A secure rule set is not useful if the administrator cannot recover the system.

Firewall security is a continuing process

Review rules after migrations, new application launches, staff changes, and service retirements. Remove temporary openings promptly. Update firewall software, watch for unusual patterns, and test whether exposed services match the documented design.

A firewall also works best as one layer in a wider defense: secure passwords, multi-factor authentication, timely updates, backups, malware monitoring, and least-privilege access all remain necessary.