Every server connected to the internet receives traffic from every direction simultaneously: legitimate user requests, automated scanning tools probing for open ports, bots attempting to guess credentials, and connections from IP addresses with known malicious histories. None of this traffic announces its intentions. Without a mechanism to examine and filter it, all of it reaches the server equally.
A firewall is that mechanism. It sits between the server and incoming network traffic, evaluating each connection against a set of rules and deciding, before the connection reaches the application, whether to allow it through or block it. For a dedicated server exposed to the public internet, a correctly configured firewall is not optional security hardening. It is the baseline.
This guide explains what firewalls do, how the different types work, how firewall rules operate in practice, and what a basic firewall configuration for a Linux dedicated server looks like.
📖 Firewall is one layer of a complete security posture
A firewall controls network access, but server security requires multiple layers. Read Dedicated Server Security: Best Practices for Protecting Your Infrastructure, a complete guide to SSH hardening, access control, monitoring, and the full security configuration that complements firewall protection.
What a Firewall Is
A firewall is a security system that monitors and controls network traffic flowing to and from a server, based on a defined set of rules. At its most basic level, it operates as a gatekeeper: allow rules let traffic through, deny rules drop it, and a default policy handles anything that matches neither.
The term “firewall” covers a wide range of implementations, from simple packet filters that inspect individual network packets in isolation to sophisticated systems that understand the full context of network sessions, inspect application-layer content, and detect behavioural patterns that suggest malicious intent. All of them perform the same fundamental function, controlling what can and cannot reach the server.
On a dedicated server, the firewall typically runs at two levels simultaneously. A network-level firewall may exist at the data centre or provider level, filtering traffic before it reaches the server. A host-based firewall runs on the server itself — implemented in Linux through tools like iptables, nftables, or UFW, providing granular control over traffic to and from that specific machine.
What Firewalls Actually Do
Understanding what a firewall does in concrete terms, rather than the abstract “it filters traffic”, clarifies why configuration matters as much as presence.
Controlling Which Ports Are Accessible
A server runs services on specific network ports. For example, the web server listens on port 80 (HTTP) and 443 (HTTPS). Additionally, the SSH daemon listens on port 22. A database might listen on port 3306 (MySQL) or 5432 (PostgreSQL), while a control panel might listen on port 8443 or 2087.
Without a firewall, all of these ports are accessible from any IP address on the internet. With a firewall, however, you can restrict access to each port precisely: open ports 80 and 443 to everyone, limit port 22 to specific administrator IP addresses, and block port 3306 entirely from public access, allowing it only from localhost or a private network.
As a result, this port restriction is the most fundamental firewall function. Reducing the number of publicly accessible ports directly reduces the attack surface — the set of entry points an attacker can attempt to exploit.
Restricting Access by IP Address
Firewall rules can allow or deny traffic based on source IP address. You can restrict administrative services: SSH, control panels, internal APIs, to specific IP ranges rather than exposing them to the entire internet. An attacker who cannot reach a service because their IP address is not in the allow list cannot attempt to exploit it, regardless of whether a vulnerability exists.
IP-based restrictions work best for services with predictable access patterns: SSH access from a fixed office IP, database access from a known application server, API access from a defined set of partner systems. For public-facing web services, IP-based restriction is not practical, but for administrative and internal services, it is among the most effective security controls available.
Blocking Malicious Traffic Patterns
Firewalls can detect and block traffic patterns associated with attacks before they reach the application. The firewall can mitigate SYN flood attacks, a denial-of-service technique that exploits TCP connection establishment, by limiting the rate of new TCP connection attempts per source IP. It can also detect port scanning, the automated probing of many ports to identify open services, and block the scanning source automatically. Repeated failed connection attempts from the same source, characteristic of credential brute-force attacks, can trigger automatic blocking.
These pattern-based protections operate at the network layer, before the traffic reaches application code, meaning they reduce load on the application and prevent resource consumption from malicious traffic without requiring application-level changes.
Types of Firewalls
Different firewall implementations operate at different levels of the network stack, with different capabilities and appropriate use cases.
Packet Filter Firewalls (Stateless)
A stateless packet filter examines each network packet independently, making an allow-or-deny decision based solely on the information in that individual packet: source IP, destination IP, source port, destination port, and protocol (TCP, UDP, ICMP).
Stateless firewalls are fast and computationally inexpensive — there is no session state to maintain, and each packet decision is independent. They are effective for straightforward filtering scenarios: block this IP, allow this port, drop all ICMP.
Their limitation is that they lack context. A packet that looks legitimate in isolation may be part of an attack when understood in the context of the broader session it belongs to. Stateless firewalls cannot make that distinction.
Stateful Inspection Firewalls
A stateful firewall tracks the state of active network connections. When a new connection is established, the firewall records it in a state table. Subsequent packets are evaluated not just against the rules, but against whether they belong to an existing, established connection.
This context-awareness improves security significantly. A stateful firewall can distinguish between a legitimate response packet arriving from an established connection and an unsolicited inbound packet on the same port, allowing the former and blocking the latter. Most modern software firewalls, including iptables in stateful mode, operate this way.
Application-Layer Firewalls (Next-Generation)
Application-layer firewalls, sometimes called next-generation firewalls (NGFW), inspect traffic at the application protocol level, understanding HTTP, DNS, SMTP, and other protocols in addition to the lower-level network information. They can filter based on URL patterns, HTTP headers, DNS request content, and other application-level characteristics.
Web Application Firewalls (WAF) are a specific type of application-layer firewall focused on HTTP/HTTPS traffic. They inspect web requests for patterns associated with SQL injection, cross-site scripting, path traversal, and other web application attack types.
Network vs Host-Based Firewalls
A network firewall operates at the infrastructure level, protecting multiple servers simultaneously, typically positioned at the edge of a data centre or network segment, filtering all traffic before it reaches any server on that segment.
A host-based firewall runs on an individual server and controls traffic specific to that machine. Host-based firewalls provide granular per-server control that network-level firewalls cannot: different rules for different services on the same server, application-specific traffic shaping, and control over outbound traffic from individual processes.
For a dedicated server, both levels are complementary. Provider-level network firewalls handle volumetric filtering and data-centre-edge protection. The host-based firewall on the server itself handles service-specific access control.
📖 How does a firewall relate to DDoS protection?
Firewalls filter individual connections, DDoS attacks overwhelm at the volume level, which requires different mitigation. Read What Is a DDoS Attack and How Does It Affect Your Website?, a complete breakdown of how DDoS attacks work and how infrastructure-level mitigation differs from firewall-level filtering.
How Firewall Rules Work
Firewall rules are the mechanism through which filtering decisions are made. Each rule specifies conditions and an action: if a packet matches these criteria, take this action (allow, deny, or log).
Rule Components
A typical firewall rule specifies some combination of:
Source – the IP address or range the traffic originates from. Can be a specific IP, a CIDR range, or “any.”
Destination – the server or interface the traffic is headed to.
Port – the specific port or port range the traffic targets. Specifying port 22 targets SSH; specifying port 80 targets HTTP.
Protocol – TCP, UDP, ICMP, or “any.” Most web traffic is TCP; DNS uses UDP; ping uses ICMP.
Action – what to do with matching traffic: ACCEPT (allow through), DROP (silently discard), or REJECT (discard and send an error response to the source).
Rule Processing Order
Firewall rules are processed in sequence, from first to last. The first rule that matches a packet determines the action taken. Rules that follow are not evaluated once a match is found.
This order matters significantly for rule design. A rule that broadly allows all traffic from a trusted IP range should typically come before a rule that blocks specific ports, otherwise the port-blocking rule matches first and the broad allow rule never applies to that traffic.
Default policies handle traffic that matches no explicit rule. The recommended default for inbound traffic is DROP — reject anything not explicitly allowed. This means new services added to a server are not publicly accessible until a firewall rule explicitly permits them, rather than being accessible by default.
A Basic Practical Configuration
For a typical dedicated server running a web application, a minimal firewall configuration allows:
- All traffic on ports 80 (HTTP) and 443 (HTTPS) from any source
- SSH on port 22 (or a custom port) from specific administrator IP addresses only
- All established and related traffic (responses to outbound connections the server initiated)
- All loopback traffic (traffic within the server itself)
- Everything else dropped by default
This configuration allows web traffic from all users, restricts administrative access to known addresses, and denies everything that does not fit a permitted pattern.
Linux Firewall Tools: iptables, nftables, and UFW
On Linux servers, the operating system running on the vast majority of dedicated servers, firewall configuration uses the kernel’s netfilter framework, accessed through several tools.
iptables is the traditional Linux firewall tool. It provides fine-grained control through a table-and-chain model and is well-documented with decades of community knowledge. It is powerful but has a complex syntax that is easy to misconfigure.
nftables is the modern replacement for iptables, providing a cleaner syntax and better performance for complex rule sets. Most current Linux distributions ship with nftables as the default, though iptables remains widely used.
UFW (Uncomplicated Firewall) is a simplified interface on top of iptables designed for easier configuration. It provides human-readable commands (ufw allow 443/tcp, ufw deny 22/tcp) that translate to iptables rules underneath. UFW is the recommended starting point for administrators who need straightforward firewall configuration without learning iptables syntax in depth.
firewalld is a dynamic firewall management tool used in Red Hat-based distributions (CentOS, AlmaLinux, Rocky Linux, Fedora). It organises rules into zones and services rather than raw port and IP specifications, and supports runtime changes without requiring a full rule reload.
What a Firewall Does Not Do
Understanding the limits of firewall protection is as important as understanding its capabilities.
A firewall controls access to network services. It does not inspect or protect the services themselves once access is permitted. If SSH is open to authorised IP addresses, the firewall has no role in preventing a weak password from being successfully guessed on that SSH connection. If port 443 is open for HTTPS, the firewall does not inspect the application logic being executed by the web application: SQL injection, authentication bypasses, and business logic vulnerabilities all occur above the layer the firewall operates at.
A firewall does not replace application security. An application with injection vulnerabilities, weak authentication, or insecure session handling is vulnerable to attackers who connect through the permitted ports. The firewall is the network perimeter; application security is required for the application itself.
So, a firewall does not protect against all network attacks. Volumetric DDoS attacks that flood the network uplink with traffic exhaust the server’s network connection before a host-based firewall can process individual packets. This category of attack requires upstream network-level mitigation rather than host-based filtering.
📖 What security practices complement firewall configuration?
Firewall configuration is the first step, server hardening covers everything that follows. Read Dedicated Server Security Checklist: How to Harden Your Server After Setup, a step-by-step guide to the complete post-provisioning security configuration.
Dedicated servers with full firewall control
Swify dedicated servers give you complete root access and full control over firewall configuration, no provider restrictions on which ports you can manage, which IP ranges you can allow or deny, or how you structure your security rules.
→ Explore Swify Dedicated ServersFrequently Asked Questions
What is the difference between a firewall and a WAF?
A firewall operates at the network layer, controlling which IP addresses and ports can establish connections to the server. It makes allow/deny decisions based on connection-level information: source IP, destination port, protocol, without inspecting the content of the traffic itself. A Web Application Firewall (WAF) operates at the application layer, inspecting the content of HTTP and HTTPS requests to detect and block attack patterns like SQL injection, cross-site scripting, and path traversal.
A network firewall can prevent an unauthorised IP from connecting on port 443. A WAF can block a legitimate IP from sending a malicious SQL injection payload through an allowed HTTPS connection. Both are useful layers, addressing different threat categories. A complete security posture uses both: a network firewall for connection-level access control, and a WAF for application-level attack detection. Read more about the full security stack in Dedicated Server Security: Best Practices for Protecting Your Infrastructure.
Does a firewall affect server performance?
A well-configured host-based firewall (iptables, nftables, UFW) has negligible performance impact on a properly specified dedicated server. The kernel processes firewall rules efficiently, and the overhead per packet is minimal for typical web traffic volumes. Stateful connection tracking, which allows the firewall to recognise returning packets from established connections, adds slightly more overhead than pure stateless filtering, but the difference is not measurable in application performance benchmarks.
Performance impact becomes more significant with very large, complex rule sets, thousands of rules that must be evaluated for each packet, or with aggressive rate limiting configured at the firewall level. For typical dedicated server deployments with standard rule sets, firewall overhead is not a meaningful performance factor. The security benefit of running a correctly configured firewall far outweighs any theoretical performance cost.
Is a firewall enough to secure a dedicated server?
No. A firewall controls network access, it does not secure the applications and services that receive traffic through permitted ports. An application with SQL injection vulnerabilities, a service with weak credentials, or an unpatched software component is exploitable through connections that the firewall correctly allows. The firewall stops what should not reach the server; application and service security determines what happens to traffic that legitimately does.
A complete server security posture combines firewall configuration with SSH hardening (key-based authentication, disabled root login), regular software updates, strong access controls, intrusion detection, log monitoring, and backup procedures. Each layer addresses threats that the others do not cover. Read the complete post-setup security guide in Dedicated Server Security Checklist: How to Harden Your Server After Setup.
What is the difference between a firewall and DDoS protection?
A firewall filters individual connections based on rules, it blocks specific IPs, restricts specific ports, and drops traffic that does not match allow rules. It operates packet by packet, making decisions based on connection-level information. DDoS mitigation addresses a fundamentally different problem: attacks that generate traffic volumes large enough to saturate the server’s network uplink entirely, making individual packet-level filtering irrelevant because the pipe is already full.
A host-based firewall cannot stop a 100 Gbps volumetric DDoS attack, the network connection is saturated before packets reach the firewall for evaluation. DDoS mitigation requires upstream network-level intervention: traffic scrubbing centres that filter attack traffic before it reaches the server’s network connection, or anycast networks that distribute attack traffic across global infrastructure. Both firewall and DDoS mitigation are useful, but they protect against different threat categories. Read more in What Is a DDoS Attack and How Does It Affect Your Website?
Should SSH always be restricted to specific IP addresses?
Yes, wherever it is operationally practical. SSH is the primary administrative access mechanism for a Linux server, and leaving it accessible from any IP address on the internet exposes it to continuous automated brute-force attempts. Restricting SSH to specific IP addresses, the administrator’s office, a VPN, a known home connection, removes the vast majority of this attack surface. An attacker cannot brute-force an SSH service they cannot connect to.
Where IP restrictions are not practical, for example, when administrators work from variable locations, the compensating controls are strong: key-based authentication rather than password authentication (so credential brute-forcing is not relevant), a non-standard port to reduce automated scanning traffic, and rate limiting on connection attempts. Combining IP restriction with key-based authentication is the strongest practical SSH security posture for most dedicated server environments. Read more about SSH hardening in Dedicated Server Security: Best Practices for Protecting Your Infrastructure.
What firewall tool should I use on a Linux dedicated server?
The right tool depends on the Linux distribution and the complexity of the required configuration. On Ubuntu and Debian, UFW (Uncomplicated Firewall) provides a straightforward interface for common configurations, allowing specific ports, restricting SSH to IP ranges, setting default deny policies, with simple commands that translate to iptables rules underneath. UFW is the recommended starting point for administrators who need reliable firewall configuration without learning iptables syntax in depth.
On Red Hat-based distributions (AlmaLinux, Rocky Linux, CentOS), firewalld is the standard tool, organising rules into zones and services. For environments requiring very granular control or complex rule logic, iptables and its modern replacement nftables provide the most flexibility. All of these tools access the same underlying kernel netfilter framework, the choice affects syntax and management interface rather than fundamental security capability. Read the full server hardening guide in Dedicated Server Security Checklist: How to Harden Your Server After Setup.