How to Enable FirewallD and Open Ports on CentOS

When you’re running a server, one of the most important things is keeping it safe. You don’t want anyone sneaking in through open ports you forgot about. That’s why we use something called a firewall.

In CentOS, a common tool for managing your firewall is FirewallD. It helps you control which ports are open and which ones are blocked. I use it often because it’s flexible and works well with other tools on the system.

In this guide, I’ll show you how to enable FirewallD, check its status, and open or close ports. I’ll also explain some terms that might sound new, like “zones” and “services.” Don’t worry—we’ll keep it simple.


What Is a Firewall?

A firewall is like a gatekeeper. It watches traffic coming in and going out of your server. You can tell it to block some ports and allow others.

A port is just a doorway that software uses to communicate. For example:

  • Port 80 is for websites (HTTP)
  • Port 443 is for secure websites (HTTPS)
  • Port 22 is for remote access using SSH

FirewallD lets you decide which ports are open and which ones stay closed.


What Is FirewallD?

FirewallD is a tool that helps you manage firewall rules on Linux. Instead of editing files or using older tools like iptables, you can run a few easy commands.

Some reasons I like FirewallD:

  • It’s active all the time (even after reboots)
  • It uses zones to group rules
  • It supports both ports and services (which are just names for common ports)

Let’s start by checking if it’s installed.


Step 1: Install and Start FirewallD

On most CentOS systems, FirewallD comes pre-installed. But you can install it just to be sure:

sudo yum install firewalld

Once it’s installed, start the service:

sudo systemctl start firewalld

And make sure it starts every time the server boots:

sudo systemctl enable firewalld

Want to check if it’s running?

sudo firewall-cmd --state

If it says running, you’re good.


Step 2: Understand Zones

This part confused me at first, so let me explain.

Zones are just labels. Each zone has its own set of rules.

Here are a few zones you might see:

  • public — good for general servers
  • home — better for trusted networks
  • drop — drops everything unless allowed

Your system uses one zone as the default. That’s where rules go unless you say otherwise.

To see the default zone:

sudo firewall-cmd --get-default-zone

You can also see all available zones:

sudo firewall-cmd --get-zones

And to make a different zone the default:

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

I usually stick with public unless I need something special.


Step 3: Open a Port

Let’s say you want to open port 80 so your website is visible.

Here’s how:

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

Then reload to apply the rule:

sudo firewall-cmd --reload

That’s it. Your web server is now reachable.

Why --permanent? Without it, the rule disappears after reboot. I always use --permanent unless I’m just testing.


Step 4: Allow a Service Instead

Instead of remembering port numbers, you can allow services by name.

For example, to allow HTTP:

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

Or HTTPS:

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

Then reload again:

sudo firewall-cmd --reload

This is often easier than opening ports directly.


Step 5: Check Open Ports and Services

Want to double-check what’s open?

Use this:

sudo firewall-cmd --list-all

It will show you:

  • The zone being used
  • Allowed ports
  • Allowed services
  • Other settings

I like to check this often, just to be sure nothing unexpected got added.


Step 6: Close a Port or Remove a Service

Let’s say you opened something by mistake.

To remove port 80:

sudo firewall-cmd --zone=public --remove-port=80/tcp --permanent

Or remove a service like SSH:

sudo firewall-cmd --zone=public --remove-service=ssh --permanent

Then reload:

sudo firewall-cmd --reload

Be careful though—don’t lock yourself out if you’re connected over SSH.


Three Lists to Keep Handy

Useful Services You Might Want to Allow

  • http (port 80)
  • https (port 443)
  • ssh (port 22)
  • smtp (port 25 for mail)
  • dns (port 53)

Common Zones and What They’re For

  • public: default zone, blocks most by default
  • home: trusted zone for home use
  • internal: used for private networks
  • drop: silently drop all incoming
  • block: reject all except what you allow

My Tips for Managing FirewallD

  • Always use --permanent to save rules
  • Reload after changes using firewall-cmd --reload
  • Double-check your rules with --list-all
  • Test carefully when changing SSH access
  • Use service names when possible (easier to remember)

Why Use FirewallD Instead of iptables?

I used to write long iptables rules by hand. It worked, but it wasn’t fun. I had to remember every port and every syntax rule.

With FirewallD, I just run a short command. It’s easier to read, and I don’t worry as much about messing something up.

Also, it handles reboots better. I once forgot to save my iptables changes, and after a reboot, the server became wide open. Not fun.

FirewallD solves that.


Bonus: Use Rich Rules (Optional)

If you want more control, you can use rich rules. These let you allow or block based on IP address, interface, and more.

Example:

sudo firewall-cmd --permanent --add-rich-rule='rule family=ipv4 source address=192.168.1.100 port port=22 protocol=tcp accept'

This allows SSH only from a specific IP.

I don’t use these often, but they can be helpful in special setups.


Wrap-Up

Firewalls don’t have to be scary. With FirewallD, you can manage your server’s security using simple commands. It’s a good habit to check your open ports now and then and close anything you don’t need.

Here’s what we covered:

  • What FirewallD is and why it’s useful
  • How to enable and start the service
  • How to open and close ports or services
  • How to check your current rules
  • Why zones make organizing easier

Do you have a favorite FirewallD command you always use? Or did you run into a tricky firewall issue before? I’d love to hear about it.

Let me know if you’d like a follow-up guide on using rich rules or limiting SSH access with FirewallD.

Leave a Reply