A Comprehensive Guide to Managing Firewalls on CentOS 7 Using Firewalld

Understanding how to configure and maintain a solid firewall is essential for any professional managing Linux servers. In my years as a full-stack developer and systems engineer, I‘ve deployed countless CentOS 7 servers that rely on tight firewall rules for security and operational control.

In this comprehensive tutorial, I‘ll leverage my real-world expertise to explain not just how to enable the firewall on CentOS 7, but also what firewalls are, why they matter, and provide concrete examples to properly tune and test firewall policies hands-on using the robust firewalld system integrated with CentOS.

What Exactly is a Firewall?

Before jumping into working with firewalld specifically, let‘s briefly overview what purpose firewalls serve generally.

At a basic level, a firewall is a network security system that monitors incoming and outgoing connections between your local network and external networks, analyzing the traffic against a set of security rules. This allows blocking malicious activity while permitting legitimate connections to access specified apps and services residing on protected servers.

Firewalls add a crucially important layer of protection, since vulnerabilities are constantly being discovered in server software that could enable attacks against the underlying system. Even if an application has a security flaw that gets exploited or an admin accidentally leaves an insecure configuration, the firewall acts as another barrier preventing external parties from targeting any areas that expose risk.

According to Cloudflare statistics, sites protected by firewalls see a dramatic decrease in malicious activity versus unprotected sites:

• 76% reduction in SQL injection attacks
• 82% reduction in cross-site scripting attacks
• 44% reduction in malicious bots accessing the site

Additionally, having firewall logging and alerting ensures issues get noticed so cybersecurity teams can respond appropriately. This protects the confidentiality, integrity, and availability of servers so risk is minimized from vulnerabilities, human errors, third-party component flaws, and any other threats.

Now that we‘ve covered the general importance of utilizing firewalls for security monitoring and access controls, I‘ll walk through specifics around enabling and configuring them on CentOS 7.

An Overview of Firewalld Concepts

By default CentOS 7 includes a built-in firewall manager called firewalld that greatly simplifies managing all firewall policy requirements via an easy-to-use CLI tool.

Some key capabilities provided by firewalld:

Dynamic rule updates – Rules can be modified, added, removed without dropping existing connections. Changes are instantly applied allowing for adjustments on the fly.

Zone and service definitions – Rather than managing individual ports/protocols, firewalld allows creating reusable definitions for typical service types and server roles for faster configuration.

Preserving iptables knowledge – Prior custom iptables rules are still supported and migrated transparently so no legacy policy knowledge is lost.

Backwards compatibility – Direct use of iptables is still available if needed for more advanced, low-level configurations.

So while giving us flexibility and power, firewalld also offers simplification by abstracting unnecessarily complex policy rule management that was traditionally required.

Firewalld components like zones, services, and rich rules abstract policy building blocks so we can focus on high-level requirements – like "block inbound SSH except from office" – rather than juggling protocols and port numbers.

Checking Whether Firewalld is Active

Once firewalld is installed on a CentOS 7 system, we need to check whether the service is up and running. This ensures any newly defined policies will be actively enforced.

View the status of the firewalld process:

sudo systemctl status firewalld

If it returns Active: active (running), then firewalld is currently running.

Additionally we want firewalld starting up automatically whenever the server boots, rather than having to manually run it:

sudo systemctl enable firewalld
sudo systemctl is-enabled firewalld

This both enables it now, and the second command verifies we see enabled so it persists reboots.

Optionally, we could have also started firewalld manually without rebooting:

sudo systemctl start firewalld

With the firewalld service operational, we can move on to defining the firewall policies.

Getting Details on Active Firewall Settings

Before modifying the default firewall configuration, it‘s useful to review existing settings. We can query firewalld directly for details on what pre-defined zones, services, ports and more are currently active.

Run:

sudo firewall-cmd --list-all

This outputs currently applied settings:

• Default zone (drop, block, public, etc)
• Interfaces binding to zones
• Allowed services by name
• Ports opened directly by number

And any rich rules, direct chains or other advanced configuration.

Knowing what policies are already permitting traffic allows us to determine what additional access is necessary without redundant or conflicting rules.

Opening Required Ports in the Firewall

Nearly any server will need additional custom firewall ports opened beyond the OS defaults.

Common examples include allowing:

• Web traffic on TCP port 80 and 443 for internet-facing web servers
• SSH admin access on TCP port 22 for remote management
• VPN tunnels using UDP port 500/4500 for secure remote connections

The firewalld command to open ports is straight-forward. For example, to open TCP 22:

sudo firewall-cmd --zone=public --add-port=22/tcp

This instantly applies the change. However it would get reverted on a reboot. To persist it permanently:

sudo firewall-cmd --zone=public --add-port=22/tcp --permanent

Now SSH will remain accessible after restarting, which is crucial for remote administration needs.

We could also open an entire range of ports at once:

sudo firewall-cmd --zone=public --add-port=8000-8050/tcp --permanent

And don‘t forget to reload after making updates for them to fully activate:

sudo firewall-cmd --reload

This dynamically applies changes without disrupting mappings or connectivity for a smooth rollout.

Restricting Access with Blacklist Rules

In addition to explicitly allowing ports, we can leverage "rich language" rules to blacklist traffic by source IP, interface, application and other criteria. This provides a simple, flexible way to lock things down.

For example, restrict all SSH traffic except from internal office IPs:

sudo firewall-cmd --zone=public --add-rich-rule=‘rule family="ipv4" source NOT address="203.0.113.0/24" service name="ssh" reject‘

Or prevent access from specific hostile countries to mitigate brute force attacks:

sudo firewall-cmd --zone=public --add-rich-rule=‘rule family="ipv4" source address="95.211.0.0/16" reject‘

We can combo this with opened ports to simultaneously whitelist some access while blacklisting all other attempts. Constructing rules this way simplifies managing complex policies.

Leveraging Firewall Services Over Ports

Defining firewall access by specific service names rather than ports streamlines configuration considerably.

For example, rather than needing to know HTTP uses ports 80 and 443, we can simply run:

sudo firewall-cmd --zone=public --add-service=http --permanent

Firewalld handles translating this into the necessary protocols and ports under the covers.

Common examples services to open:

Web traffic:

sudo firewall-cmd --zone=public --add-service=http --permanent
sudo firewall-cmd --zone=public --add-service=https --permanent

Secure remote access:

sudo firewall-cmd --zone=public --add-service=ssh --permanent
sudo firewall-cmd --zone=public --add-service=openvpn --permanent 

File sharing:

sudo firewall-cmd --zone=public --add-service=samba --permanent
sudo firewall-cmd --zone=public --add-service=nfs --permanent

We can query all predefined service names that firewalld recognizes:

ls -1 /usr/lib/firewalld/services

This makes managing access requirements much more intuitive.

Working with Predefined Zones

Firewalls tend to get increasingly complex on servers handling multiple roles – like web apps, databases, APIs, etc.

We can simplify huge allow/deny rulesets by utilizing predefined zones that bundle standard policy sets.

For example, separating a web server zone from a sensitive backend database zone.

Some common predefined zones that come built-in include:

• drop – Default deny all incoming connections
• block – Only deny specific listed connections
• public – For externally accessible services like websites
• home – For basic home/office networks
• work – For trusted enterprise office subnets
• dmz – For isolated servers needing internet access

To assign a network interface to a zone:

sudo firewall-cmd --zone=public --change-interface=eth0

Zones allow easily reusing policy sets across server groups (web, db, api, etc) that share common access needs rather than redefining the same rules repeatedly.

We could lock down an untrusted zone further by blacklisting traffic:

sudo firewall-cmd --zone=untrusted --add-rich-rule=‘rule family="ipv4" source address="192.168.100.0/24" service name="http" reject‘

Zones handle binding common allow/deny policies while letting us override for specific subnetworks.

Blocking Everything Except Specified Access

A common secure baseline is to deny all incoming connections by default, then selectively allow specific traffic. This way new vulnerabilities that arise are blocked by default rather than accidentally exposing unknown risks.

First, set the default zone to drop all inbound:

sudo firewall-cmd --set-default-zone=drop

Then selectively allow inbound traffic by opening just required ports and services, keeping access lean.

If following this model, its crucial to have emergency SSH access available that gets processed earlier in the rules so it remains accessible if incorrectly configuring policies that block you out.

Testing Connectivity Post Firewall Changes

After making updates, how do we test everything is still working as expected?

Testing from the server outbound

To verify we still have internet connectivity after clamping down rules:

ping google.com
curl ipinfo.io/ip 
nslookup linuxhaxor.net

Telnet to required destination ports helps check connectivity:

telnet linuxhaxor.net 80

And services like web browsers and SSH should work normally.

Any connectivity issues indicate misconfigured rules that are too strict.

Testing inbound externally

To validate remote access from other hosts, try:

• Browsing to the public IP on opened web ports
• SSHing to the server IP on port 22
• Using PsPing or traceroute to check ICMP transmission
• Port scanning tools to check range accessibility

I also recommend an automated monitoring system that attempts connections to flagged destination ports on schedules and alerts if issues arise. This way you find out immediately if a misconfiguration breaks intended external accessibility.

Examining Firewall Logs for Traffic Analysis

Beyond just connectivity checks, we gain invaluable data by processing firewall log files.

CentOS 7 logs firewalld messages to a log directory, usually at /var/log/firewalld.

Running a manual check of the logs:

sudo cat /var/log/firewalld

Reveals allowed and denied connection attempts like:

ALLOW IN= public OUT= SRC=192.168.0.5 DST=192.168.0.10 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=54986 DF PROTO=TCP SPT=56422 DPT=22  

IN=public OUT= MAC= SRC=198.51.100.4 DST=203.0.113.5 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=4133 DF PROTO=TCP SPT=43573 DPT=22 WINDOW=65535 RES=0x00 SYN URGP=0 

Feeding this into analytic systems gives visibility like:

• Malicious scanning activity to blacklist
• Spikes on DDoS attempts across IP ranges
• Suspicious traffic probing non-public ports
• Overall connection accept/deny ratios
• Protocol and country traffic patterns

Getting metrics around firewall activity often exposes issues and security events that might have otherwise been missed.

Disabling Firewalls Where Necessary

While firewalls provide substantial protection, there are some temporary cases where we need to disable them – especially when troubleshooting connectivity or service issues.

To disable firewalld without disrupting existing connections:

sudo systemctl stop firewalld

To keep it disabled across server restarts:

sudo systemctl disable firewalld

Later when ready to enable again:

sudo systemctl enable firewalld
sudo systemctl start firewalld

Its recommended to re-enable the firewall as soon as the temporary need expires. Some common reasons for short-term disabling include:

• Resolving network problems between tiered app servers
• During software testing or debugging sessions
• Troubleshooting platform integration issues
• When network tunnels get misconfigured

But other than narrow exceptions like these, firewalls should remain actively protecting production systems.

Conclusion

I hope this guide has boosted your skills not only using firewalld for simple CentOS 7 enablement, but also understanding the broader landscape and strategic considerations around leveraging Linux firewalls securely.

The key concepts we covered included:

• Checking status and enabling on boot
• Granularly opening ports and services
• Using zones to enforce standard policy sets
• Testing for connectivity after applying rules
• Logging and analytics to expose hidden threats
• Temporarily disabling when required

Configuring comprehensive firewall policies remains incredibly important for securing infrastructure against modern sophisticated attacks. Mastering firewalld rules now will ensure your servers, data and customers continue operating safely.

Let me know if you have any other questions!