Firewall Configuration (iptables, firewalld)

In the Linux ecosystem, network security is paramount for operations. While modern distributions often enable the graphical firewall tool firewalld by default, a deep understanding of the underlying rule engine iptables remains critical for advanced network management and troubleshooting. These two tools are not mutually exclusive; rather, they exist in a hierarchical relationship: iptables provides the low-level raw interface, while firewalld serves as a high-level management framework built upon iptables. Mastering the configuration logic of both enables system administrators to flexibly address complex network environment requirements.

Relationship and Selection Strategy between iptables and firewalld

To begin configuring a firewall, it is essential to first clarify the positioning differences between the two. iptables (Internet Packet Traffic Filter) is the core component within the Linux kernel responsible for processing network packet filtering. It directly operates the Netfilter framework, offering extremely fine-grained control granularity. Through iptables, administrators can manually define chains (Chain), rules (Rule), and actions (Action), implementing complex logic based on dimensions such as source/destination IP, port, and protocol.

In contrast, firewalld is a user-friendly tool that encapsulates the complexity of iptables. It introduces concepts such as Zones, Services, and Source Lists. When using firewalld, administrators simply need to declare actions like "allow SSH access" or "open HTTP ports," and the system automatically adds the corresponding rules to iptables.

In actual operations, the choice between the two depends on the specific scenario. For scenarios requiring automated script deployment for batch management, handling temporary test environments, or performing low-level network analysis, using iptables directly is often more efficient and controllable. Conversely, for daily maintenance in production environments, managing via firewalld's graphical interface or command-line tools is more intuitive and secure, as it automatically handles rule conflicts and prevents configuration errors.

Basic Rule Configuration Using iptables

When direct manipulation of underlying network traffic is required, iptables offers a rich set of command options. A typical configuration process involves setting default policies, adding specific rules, and saving the configuration.

First, set the default policy for the FORWARD and INPUT chains to DROP. This serves as a security baseline, ensuring that only explicitly allowed traffic can pass through. Subsequently, add allow rules based on business requirements. For example, to allow SSH connections from any source, one can specify the protocol using -p tcp, the source address with -s, the destination address with -d, and combine them with the -j ACCEPT action.

# Set default policy to DROP all (exercise caution in production environments)
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP

# Allow local loopback traffic
iptables -A INPUT -i lo -j ACCEPT

# Allow established connections and related reverse connections
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Allow SSH (port 22) access from any IP
iptables -A INPUT -p tcp --dport 22 -j ACCEPT

# Save configuration to file (commands may vary slightly across distributions; e.g., CentOS/RHEL uses 'service iptables save')
service iptables save

When executing the above operations, it is crucial to be aware of the risks associated with the -P parameter for setting default policies. Improper configuration can block all inbound traffic, rendering the system unable to respond to any external requests, including administrative remote connections. Therefore, it is recommended to verify in a test environment first or adopt a "whitelist" mode (default allow, reject only specific risky sources) to minimize the impact of accidental misconfigurations.

Zone and Service Management Using firewalld

Compared to directly writing iptables rules, firewalld provides a declarative configuration method that significantly reduces the probability of errors. Its core concept is the "Zone," where each zone defines specific security policies. Common zones include public (Public Zone, default policy), trusted (Trusted Zone), and work (Work Zone).

During configuration, administrators typically do not need to memorize specific port numbers or protocol parameters but instead enable corresponding functions by defining service names. For instance, to allow a web server to provide external services, one simply needs to instruct the system to open the http and https services; to restrict access from specific IP segments, one must specify the source address list.

# View current zone and status
firewall-cmd --get-zones
firewall-cmd --state

# Set current zone to public (default)
firewall-cmd --set-default-zone=public

# Add services: allow httpd (HTTP) and ssh services
firewall-cmd --zone=public --add-service=http,ssh --permanent

# Add custom port rule: open port 8080
firewall-cmd --zone=public --add-port=8080/tcp --permanent

# Reject access from specific IP segment (e.g., 192.168.1.0/24)
firewall-cmd --zone=public --add-rich-rule='rule family="ipv4" source address="192.168.1.0/24" reject' --permanent

# Reapply configuration (critical step; otherwise modifications will not take effect)
firewall-cmd --reload

The advantages of firewalld are further highlighted by its rich "Rich Rules" functionality. These rules allow judgment based on more complex conditions, enabling the combination of fine-grained access control policies based on source address, destination address, or time ranges. Additionally, it automatically detects service dependencies, avoiding situations where relevant protocols are missed during manual port configuration.

Best Practices and Precautions in Production Environments

Whether choosing iptables or firewalld, implementing firewall strategies in production environments should follow the principle of least privilege. This means that all ports should not be opened by default; instead, only traffic essential for business operations should be permitted. For database services (such as MySQL, Redis), access is typically restricted to application server IP segments, and direct exposure to the outside world must be strictly prohibited.

Simultaneously, attention must be paid to the performance impact of firewall rules. An excessive number of rule chains can lead to increased packet processing latency, particularly in high-concurrency scenarios. Regularly reviewing and cleaning up unused rules is necessary maintenance work. If firewalld is enabled, it is recommended to periodically check zone status and service lists to ensure configurations align with expectations. Furthermore, when making changes involving core business systems, rule logic must be verified in a test environment first; only after confirming no anomalies should the changes be executed in the production environment, with complete operation logs retained for audit purposes.

By reasonably leveraging the flexibility of iptables and the ease of use of firewalld, system administrators can construct a network defense system that is both secure and efficient, providing solid assurance for the stable operation of Linux systems.