RED HAT ENTERPRISE LINUX

Firewall & SELinux

Controlling Network Access to Services

College-Level Course Module | RHEL System Administration

Learning Objectives

Understand firewalld concepts

Zones, services, ports, and runtime vs permanent configuration

Configure firewall rules with firewall-cmd

Allow services, open ports, manage zones

Manage SELinux port bindings

Allow services to bind to non-standard ports

Troubleshoot network access issues

Diagnose firewall blocks and SELinux denials

Defense in Depth

Network security uses multiple layers. The firewall controls external access; SELinux controls internal service behavior. Both must allow traffic for connections to succeed.

Layer 1: Firewall (firewalld)
Controls which external connections reach the system

↓ If allowed ↓

Layer 2: SELinux Port Binding
Controls which services can listen on which ports

↓ If allowed ↓

Layer 3: Service Configuration
The actual application listening and responding

Troubleshooting order: When connections fail, check: (1) Is the service running? (2) Is the firewall allowing traffic? (3) Is SELinux allowing the port binding?

Understanding the layered security model is crucial for both configuration and troubleshooting. Think of it as three gates a connection must pass through. First, the firewall. This is your perimeter - it decides whether external traffic is even allowed to reach your system on a given port. If the firewall blocks port 8080, no amount of service configuration matters. Second, SELinux port binding. Even if the firewall allows traffic on port 8080, SELinux controls whether your web server process is allowed to bind to that port. If SELinux says httpd can only use port 80, it cannot listen on 8080 regardless of firewall settings. Third, the service itself. The application must be running, configured to listen on the port, and functioning correctly. When troubleshooting connection issues, work through these layers systematically. Is the service running? Is the firewall allowing the port? Is SELinux allowing the service to use that port? This methodical approach quickly isolates problems.

Introduction to firewalld

firewalld is RHEL's dynamic firewall manager. It provides a frontend to the kernel's netfilter framework, allowing runtime changes without disrupting existing connections.

# Check firewalld status
[root@server ~]# systemctl status firewalld
● firewalld.service - firewalld - dynamic firewall daemon
     Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled)
     Active: active (running) since Mon 2024-01-20 10:00:00 EST

# firewalld should be enabled and running by default
[root@server ~]# systemctl enable --now firewalld

# Check if firewalld is running
[root@server ~]# firewall-cmd --state
running

Default behavior: firewalld is enabled by default in RHEL. It blocks all incoming connections except those explicitly allowed, while permitting all outgoing connections.

firewalld is the standard firewall management tool in RHEL. It replaced the older iptables service, though it still uses iptables (or nftables in newer versions) under the hood. The key advantages of firewalld are dynamic management - you can add or remove rules without restarting the firewall or dropping existing connections - and the zone-based model that simplifies configuration. By default, firewalld is enabled and running on RHEL systems. It implements a default-deny policy for incoming traffic - anything not explicitly allowed is blocked. Outgoing traffic is allowed by default. Use systemctl to manage the firewalld service like any other systemd service. The firewall-cmd --state command quickly confirms whether the firewall is active. Never disable firewalld on production systems - instead, configure it to allow the traffic you need.

Firewall Zones

Zones define trust levels for network connections. Each zone has a set of rules determining what traffic is allowed. Interfaces and connections are assigned to zones.

Zone	Trust Level	Default Behavior
drop	None	Drop all incoming, no reply sent
block	None	Reject all incoming with ICMP message
public	Low	Default zone - ssh and dhcpv6-client only
external	Low	For routers - masquerading enabled
dmz	Low	For DMZ servers - limited access
work	Medium	For work networks - ssh, dhcpv6-client
home	Medium	For home networks - more services allowed
internal	High	For internal networks - similar to home
trusted	Full	All traffic accepted - use with caution!

Default zone: The public zone is the default. New interfaces are assigned here unless configured otherwise.

Zones are the organizing principle of firewalld. Each zone represents a trust level and has its own set of allowed services and ports. The idea is that different network environments deserve different rules. The drop zone is the most restrictive - it silently drops all incoming traffic without even sending a rejection message. The block zone is similar but sends ICMP rejection messages. The public zone is the default - it assumes untrusted networks like the internet. Only SSH and DHCPv6 client are allowed by default. This is appropriate for servers exposed to the internet. The work, home, and internal zones offer progressively more trust, suitable for networks where you have some confidence in other hosts. The trusted zone allows everything - use it only for completely trusted networks, and even then, think twice. When you assign an interface to a zone, all traffic on that interface follows that zone's rules. You can have different interfaces in different zones - perhaps eth0 in public facing the internet, and eth1 in internal facing your private network.

Managing Zones

# List all available zones
[root@server ~]# firewall-cmd --get-zones
block dmz drop external home internal nm-shared public trusted work

# Show the default zone
[root@server ~]# firewall-cmd --get-default-zone
public

# Show active zones and their interfaces
[root@server ~]# firewall-cmd --get-active-zones
public
  interfaces: eth0 eth1

# Change the default zone
[root@server ~]# firewall-cmd --set-default-zone=internal

# Assign an interface to a different zone
[root@server ~]# firewall-cmd --zone=internal --change-interface=eth1 --permanent
[root@server ~]# firewall-cmd --reload

# Show all settings for a zone
[root@server ~]# firewall-cmd --zone=public --list-all
public (active)
  target: default
  interfaces: eth0
  services: cockpit dhcpv6-client ssh
  ports: 
  ...

Let us look at the commands for managing zones. firewall-cmd --get-zones lists all available zones. firewall-cmd --get-default-zone shows which zone is used for interfaces not explicitly assigned elsewhere. firewall-cmd --get-active-zones shows zones that actually have interfaces assigned and which interfaces they have. This is often the most useful command for understanding your current configuration. To change the default zone, use --set-default-zone. This affects new interfaces but not existing assignments. To move an interface to a different zone, use --change-interface with the --zone option. Add --permanent to make it survive reboots, then reload. The --list-all command for a zone shows everything configured: target (default action), interfaces assigned, allowed services, open ports, and more. This is your go-to command for auditing zone configuration. Use --list-all-zones to see settings for every zone at once.

Runtime vs Permanent

Critical concept! firewalld maintains two configurations: runtime (active now, lost on reload/reboot) and permanent (saved, applied on reload/reboot).

# Runtime change - immediate but temporary
[root@server ~]# firewall-cmd --add-service=http
success
# This is active NOW but lost after reload or reboot

# Permanent change - saved but not active until reload
[root@server ~]# firewall-cmd --add-service=http --permanent
success
# This is saved but NOT active yet

# Apply permanent changes to runtime
[root@server ~]# firewall-cmd --reload

# Best practice: Do both at once
[root@server ~]# firewall-cmd --add-service=http
[root@server ~]# firewall-cmd --add-service=http --permanent

# Or use --runtime-to-permanent after testing
[root@server ~]# firewall-cmd --add-service=http
# Test that it works...
[root@server ~]# firewall-cmd --runtime-to-permanent

This is one of the most important concepts in firewalld - and a common source of confusion. firewalld maintains two separate configurations. Runtime configuration is what is active right now. Changes without --permanent flag affect only runtime. These changes take effect immediately but are lost when firewalld reloads or the system reboots. Permanent configuration is saved to disk. Changes with --permanent flag are saved but do not take effect until you reload firewalld or reboot. This dual configuration is actually a feature. You can test changes in runtime without risking permanent misconfiguration. If you lock yourself out, just reload and your permanent config is restored. Best practices: either run both commands (without and with --permanent), or make runtime changes, test thoroughly, then use --runtime-to-permanent to save your working configuration. Never make only permanent changes without testing - you will not know if they work until the next reload, which might be an inconvenient time to discover problems.

Adding Services

Services are predefined port and protocol combinations. Using services is preferred over raw port numbers - they are self-documenting and can include multiple ports.

# List all available predefined services
[root@server ~]# firewall-cmd --get-services
RH-Satellite-6 amanda-client amanda-k5-client ... http https ... ssh

# Show what a service includes
[root@server ~]# firewall-cmd --info-service=http
http
  ports: 80/tcp
  protocols:
  ...

# Add a service to the default zone
[root@server ~]# firewall-cmd --add-service=http --permanent
[root@server ~]# firewall-cmd --add-service=https --permanent
[root@server ~]# firewall-cmd --reload

# Add service to a specific zone
[root@server ~]# firewall-cmd --zone=internal --add-service=nfs --permanent

# Remove a service
[root@server ~]# firewall-cmd --remove-service=http --permanent

# List services in the current zone
[root@server ~]# firewall-cmd --list-services
cockpit dhcpv6-client http https ssh

Services are the preferred way to allow traffic in firewalld. A service is a named definition that includes port numbers, protocols, and optionally other settings. Using services has advantages over raw port numbers. Services are self-documenting - http is clearer than 80/tcp. Services can include multiple ports - the samba service includes several ports. Service definitions can be updated centrally. firewall-cmd --get-services lists all predefined services - there are many, covering common applications. Use --info-service to see what ports and protocols a service includes. To allow a service, use --add-service. Remember to add --permanent to save the change, then reload. You can specify a zone with --zone; otherwise the default zone is used. The --remove-service command removes a service. --list-services shows what services are currently allowed in a zone. Common services you will use: ssh (enabled by default), http, https, nfs, samba, dns, mysql, postgresql, and many more.

Opening Ports

When no predefined service exists, open ports directly. Specify the port number and protocol (tcp or udp).

# Open a specific port
[root@server ~]# firewall-cmd --add-port=8080/tcp --permanent
[root@server ~]# firewall-cmd --reload

# Open a range of ports
[root@server ~]# firewall-cmd --add-port=5000-5100/tcp --permanent

# Open UDP port
[root@server ~]# firewall-cmd --add-port=53/udp --permanent

# Open port in specific zone
[root@server ~]# firewall-cmd --zone=internal --add-port=3306/tcp --permanent

# List open ports
[root@server ~]# firewall-cmd --list-ports
8080/tcp 5000-5100/tcp

# Remove a port
[root@server ~]# firewall-cmd --remove-port=8080/tcp --permanent

# Verify configuration
[root@server ~]# firewall-cmd --list-all

Best practice: Use services when available. Only use raw port numbers for custom applications without predefined service definitions.

When no predefined service matches your needs, you can open ports directly. The syntax is --add-port=PORT/PROTOCOL. Port can be a single number or a range. Protocol is usually tcp or udp. Common scenarios for port opening include custom applications on non-standard ports, development servers, or services not in the predefined list. You can open port ranges with dash notation - 5000-5100/tcp opens all ports from 5000 to 5100. The --list-ports command shows directly opened ports - it does not show ports opened through services. Use --list-all to see the complete picture. Remember that opening ports directly is less self-documenting than using services. Consider creating a custom service definition for complex applications you deploy repeatedly. Port opening follows the same runtime/permanent rules. Always use --permanent and reload for changes that should survive reboot.

Rich Rules

Rich rules provide fine-grained control - allowing traffic from specific sources, logging, rate limiting, and more complex conditions.

# Allow HTTP only from specific network
[root@server ~]# firewall-cmd --add-rich-rule='rule family="ipv4" source address="192.168.1.0/24" service name="http" accept' --permanent

# Allow SSH from single IP
[root@server ~]# firewall-cmd --add-rich-rule='rule family="ipv4" source address="10.0.0.50" service name="ssh" accept' --permanent

# Block specific IP
[root@server ~]# firewall-cmd --add-rich-rule='rule family="ipv4" source address="192.168.1.100" drop' --permanent

# Allow port with logging
[root@server ~]# firewall-cmd --add-rich-rule='rule family="ipv4" port port="8080" protocol="tcp" log prefix="Custom8080: " accept' --permanent

# List rich rules
[root@server ~]# firewall-cmd --list-rich-rules

# Remove a rich rule (must match exactly)
[root@server ~]# firewall-cmd --remove-rich-rule='rule family="ipv4" source address="192.168.1.100" drop' --permanent

Rich rules extend firewalld beyond simple service and port allowances. They let you specify source addresses, enabling rules like allow HTTP but only from the internal network. The syntax is more complex but very powerful. Common uses include limiting SSH access to specific management IPs, blocking known problematic addresses, allowing services only from trusted subnets, and adding logging to track specific traffic. The rule structure is: rule family specifies IPv4 or IPv6, source address specifies where traffic must come from, then service or port specifies what traffic, and finally the action (accept, drop, reject, or log). Logging with rich rules is useful for debugging or security monitoring. The log prefix helps identify entries in system logs. To remove a rich rule, you must specify it exactly as it was added. Use --list-rich-rules to see current rules. Rich rules are evaluated in order, and the first match wins. Plan your rules carefully to avoid conflicts.

Common Tasks

# Web server setup (HTTP and HTTPS)
[root@server ~]# firewall-cmd --add-service={http,https} --permanent
[root@server ~]# firewall-cmd --reload

# Database server (MySQL) - internal zone only
[root@server ~]# firewall-cmd --zone=internal --add-service=mysql --permanent

# Custom application on port 8443
[root@server ~]# firewall-cmd --add-port=8443/tcp --permanent
[root@server ~]# firewall-cmd --reload

# Check what is allowed
[root@server ~]# firewall-cmd --list-all
public (active)
  target: default
  interfaces: eth0
  services: cockpit dhcpv6-client http https ssh
  ports: 8443/tcp
  ...

# Temporarily test a change (auto-reverts after timeout)
[root@server ~]# firewall-cmd --add-service=ftp --timeout=300
# FTP allowed for 5 minutes, then automatically removed

Pro tip: Use --timeout=SECONDS to test firewall changes. If you lock yourself out, the rule auto-reverts!

Let us look at common firewall configuration patterns. For a web server, add both http and https services. Brace expansion lets you add multiple services in one command. For database servers, consider using a more restricted zone. Put your database interface in the internal zone and add the database service only there - do not expose databases on public interfaces. For custom applications, open the specific port they use. Always verify with --list-all afterward. The --timeout option is incredibly useful for testing. It adds a rule temporarily - after the specified seconds, it is automatically removed. This is a safety net: if you accidentally lock yourself out with a firewall change, just wait for the timeout. Use this for any change you are not 100% confident about. Brace expansion works for both services and ports: --add-service={http,https,ftp} or --add-port={8080,8443}/tcp.

SELinux Port Bindings

SELinux port bindings control which SELinux types (services) can bind to which network ports. Even if the firewall allows traffic, SELinux must permit the service to use that port.

Firewall allows port 8080

→

SELinux: Can httpd bind to 8080?

→

Service starts (or fails)

# List all SELinux port bindings
[root@server ~]# semanage port -l
SELinux Port Type              Proto    Port Number
http_port_t                    tcp      80, 81, 443, 488, 8008, 8009, 8443, 9000
ssh_port_t                     tcp      22
...

# Filter for specific service type
[root@server ~]# semanage port -l | grep http
http_port_t                    tcp      80, 81, 443, 488, 8008, 8009, 8443, 9000
...

SELinux provides another layer of port control, independent of the firewall. Each service running under SELinux has a type (like httpd_t for Apache). SELinux maintains a list of which ports each type can bind to. For example, httpd_t can only bind to ports labeled http_port_t. By default, http_port_t includes standard web ports: 80, 443, 8080, 8443, and a few others. If you configure Apache to listen on port 8080, it works because 8080 is already in http_port_t. But if you want port 12345, SELinux blocks it - httpd is not allowed to use that port. semanage port -l lists all port type assignments. Filter with grep to find specific services. This is your first step when a service fails to start on a non-standard port. If SELinux is in enforcing mode and the port is not assigned to the right type, the service cannot bind to it, regardless of firewall settings.

Adding Port Bindings

# Check if a port is already assigned
[root@server ~]# semanage port -l | grep 8080
http_port_t                    tcp      80, 81, 443, 488, 8008, 8009, 8443, 9000
# 8080 is included in http_port_t - httpd can use it

# Add a new port to an existing type
[root@server ~]# semanage port -a -t http_port_t -p tcp 8888
# Now httpd can bind to port 8888

# Verify the addition
[root@server ~]# semanage port -l | grep 8888
http_port_t                    tcp      8888

# Add port for SSH on non-standard port
[root@server ~]# semanage port -a -t ssh_port_t -p tcp 2222

# Remove a port assignment
[root@server ~]# semanage port -d -t http_port_t -p tcp 8888

# Modify existing assignment (if port already assigned to different type)
[root@server ~]# semanage port -m -t http_port_t -p tcp 8888

Note: semanage requires the policycoreutils-python-utils package. Install if missing: dnf install policycoreutils-python-utils

The semanage port command manages SELinux port bindings. The syntax is semanage port -a (add) -t TYPE -p PROTOCOL PORT. Common port types you will use: http_port_t for web servers, ssh_port_t for SSH, mysqld_port_t for MySQL, postgresql_port_t for PostgreSQL. Before adding, check if the port is already assigned. If a port is assigned to a different type, use -m (modify) instead of -a (add). Adding a port to http_port_t allows any process running as httpd_t to bind there. This includes Apache, Nginx (if configured for httpd_t), and other web servers. SELinux changes take effect immediately - no reload required. To remove an assignment, use -d (delete). Important: you cannot delete default port assignments that came with the policy - only ones you added. The policycoreutils-python-utils package provides semanage. It may not be installed by default in minimal installations, so install it if the command is not found.

Common Port Types

Port Type	Services	Default Ports
http_port_t	Apache, Nginx, web servers	80, 443, 8008, 8009, 8443
ssh_port_t	OpenSSH server	22
mysqld_port_t	MySQL, MariaDB	3306
postgresql_port_t	PostgreSQL	5432
dns_port_t	BIND, DNS servers	53
smtp_port_t	Postfix, mail servers	25, 465, 587
ftp_port_t	vsftpd, FTP servers	21
nfs_port_t	NFS server	2049

# Find the port type for a specific service
[root@server ~]# semanage port -l | grep -i mysql
mysqld_port_t                  tcp      1186, 3306, 63132-63164

# Find what type a specific port uses
[root@server ~]# semanage port -l | grep " 80"
http_port_t                    tcp      80, 81, 443, 488, 8008...

Here are the most common SELinux port types you will work with. http_port_t is for web servers. It already includes many common ports, so you often do not need to add anything unless using unusual ports. ssh_port_t is just port 22 by default. If you change SSH to a non-standard port, you must add it to ssh_port_t or SSH will fail to start. mysqld_port_t is for MySQL and MariaDB. The default 3306 is included. postgresql_port_t is for PostgreSQL on its default port 5432. To find which type to use, grep semanage port -l for your service name. To find what type a port currently has, grep for the port number. If a port is not in any type, adding it to unreserved_port_t allows any service to use it - but this reduces security. It is better to add ports to the specific service type they need.

SELinux Troubleshooting

# Scenario: Apache configured for port 8888 but fails to start
[root@server ~]# systemctl start httpd
Job for httpd.service failed...

# Check SELinux denials in audit log
[root@server ~]# ausearch -m avc -ts recent
type=AVC msg=... denied { name_bind } for ... 
src=8888 ... scontext=system_u:system_r:httpd_t:s0 
tcontext=system_u:object_r:unreserved_port_t:s0 ...

# Use audit2why for explanation
[root@server ~]# ausearch -m avc -ts recent | audit2why
Was caused by:
The boolean nis_enabled was set incorrectly.
...OR...
Missing type enforcement (TE) allow rule.
    You can use audit2allow to generate a loadable module...

# Get specific fix suggestion
[root@server ~]# ausearch -m avc -ts recent | audit2allow
#============= httpd_t ==============
allow httpd_t unreserved_port_t:tcp_socket name_bind;

# Better solution: add port to http_port_t
[root@server ~]# semanage port -a -t http_port_t -p tcp 8888
[root@server ~]# systemctl start httpd   # Now works!

Let us walk through troubleshooting an SELinux port binding issue. Scenario: you configured Apache to listen on port 8888, but it fails to start. First, check SELinux denials with ausearch -m avc. The AVC message shows denied name_bind - the service was denied permission to bind to a port. It shows the source context (httpd_t) and target context (unreserved_port_t) - Apache tried to bind to a port not in http_port_t. audit2why explains why the denial happened and may suggest fixes. audit2allow shows what rule would allow the action. However, creating custom policy modules should be a last resort. The better solution is usually adding the port to the appropriate type with semanage. After adding port 8888 to http_port_t, Apache can bind there and starts successfully. This methodical approach - check denial, understand cause, apply correct fix - works for any SELinux port issue.

Combining Firewall + SELinux

When running a service on a non-standard port, you typically need to configure both the firewall AND SELinux. Missing either will cause connection failures.

# Example: Run Apache on port 8888

# Step 1: Configure Apache to listen on 8888
[root@server ~]# vi /etc/httpd/conf/httpd.conf
# Change: Listen 8888

# Step 2: Add SELinux port binding
[root@server ~]# semanage port -a -t http_port_t -p tcp 8888

# Step 3: Open firewall port
[root@server ~]# firewall-cmd --add-port=8888/tcp --permanent
[root@server ~]# firewall-cmd --reload

# Step 4: Start/restart the service
[root@server ~]# systemctl restart httpd

# Step 5: Verify
[root@server ~]# ss -tlnp | grep 8888
LISTEN  0  128  *:8888  *:*  users:(("httpd",pid=1234,fd=4))

[root@server ~]# curl http://localhost:8888
<html>...</html>

Here is the complete workflow for running a service on a non-standard port. It requires coordinating service configuration, SELinux, and the firewall. Step 1: Configure the service itself. For Apache, edit httpd.conf and change the Listen directive. Step 2: Add SELinux port binding. Apache runs as httpd_t and needs the port in http_port_t. Without this, Apache cannot start. Step 3: Open the firewall. Without this, external connections cannot reach the service. Use --permanent and reload. Step 4: Restart the service to apply configuration changes. Step 5: Verify everything works. Use ss to confirm the service is listening. Use curl to test local access. Then test from a remote system to verify the firewall is open. If any step fails: service not listening means check service config and SELinux. Local curl fails might mean service not started. Remote access fails means check firewall. This systematic approach covers all the layers.

Troubleshooting Flow

1. Is the service running?
systemctl status SERVICE | ss -tlnp | grep PORT

↓ Yes ↓

2. Is SELinux allowing the port binding?
semanage port -l | grep PORT | ausearch -m avc

↓ Yes ↓

3. Is the firewall allowing traffic?
firewall-cmd --list-all | firewall-cmd --list-ports

↓ Yes ↓

4. Check network/routing/client issues
ping | traceroute | client firewall

When network connections to a service fail, follow this systematic troubleshooting flow. Start at the service level: is it running? Use systemctl status to check if the service is active. Use ss -tlnp to verify it is actually listening on the expected port. If not listening, check service configuration and logs. Next, check SELinux: is it allowing the port? Use semanage port -l to see if the port is in the right type. Use ausearch -m avc to check for recent denials. If denied, add the port with semanage port -a. Then check the firewall: is traffic allowed? Use firewall-cmd --list-all to see current configuration. If the port or service is not listed, add it. Finally, if service, SELinux, and firewall are all correct, the problem is elsewhere - network connectivity, routing, or client-side firewall. This methodical approach prevents wasted time. Do not assume it is the firewall and spend hours there when the service is not even running.

Diagnostic Commands

# Check if service is listening
[root@server ~]# ss -tlnp | grep httpd
LISTEN 0 128 *:80 *:* users:(("httpd",pid=1234...))

# Check firewall status
[root@server ~]# firewall-cmd --list-all

# Check SELinux mode
[root@server ~]# getenforce
Enforcing

# Check SELinux port assignments
[root@server ~]# semanage port -l | grep http_port_t

# Check for SELinux denials
[root@server ~]# ausearch -m avc -ts recent

# Test connectivity from local
[root@server ~]# curl http://localhost:80

# Test connectivity from remote (on client)
[user@client ~]$ curl http://server:80
[user@client ~]$ nc -zv server 80
Connection to server 80 port [tcp/http] succeeded!

# Check iptables rules (low-level)
[root@server ~]# iptables -L -n | head -20

Here are the key diagnostic commands for network service troubleshooting. ss -tlnp shows listening TCP sockets with process names. This confirms a service is actually listening where you expect. firewall-cmd --list-all shows complete firewall configuration for the active zone. getenforce shows SELinux mode. If it is Permissive or Disabled, SELinux is not blocking anything. semanage port -l shows port type assignments. ausearch -m avc -ts recent shows recent SELinux denials. This is crucial for diagnosing SELinux blocks. curl tests HTTP connectivity locally. If local curl works but remote fails, it is likely a firewall issue. nc (netcat) with -zv tests raw TCP connectivity without HTTP. This helps distinguish network issues from application issues. iptables -L shows the actual firewall rules firewalld created. Usually you do not need this, but it helps in complex debugging situations. Build a mental checklist: service listening, SELinux allowing, firewall open, network reachable. Check each in order.

Common Scenarios

Scenario	Firewall	SELinux
Web server on port 80/443	`--add-service={http,https}`	Default ports - no change needed
Web server on port 8080	`--add-port=8080/tcp`	Default in http_port_t - no change needed
Web server on port 9999	`--add-port=9999/tcp`	`semanage port -a -t http_port_t -p tcp 9999`
SSH on port 2222	`--add-port=2222/tcp`	`semanage port -a -t ssh_port_t -p tcp 2222`
MySQL internal only	`--zone=internal --add-service=mysql`	Default port - no change needed
MySQL on port 13306	`--add-port=13306/tcp`	`semanage port -a -t mysqld_port_t -p tcp 13306`

Pattern: Standard ports usually need only firewall changes. Non-standard ports need both firewall AND SELinux configuration.

This table summarizes common scenarios and what configuration each needs. Web server on standard ports (80, 443): just add the http and https services to the firewall. SELinux already allows these ports for httpd_t. Web server on port 8080: open the firewall port. SELinux http_port_t already includes 8080, so no SELinux change needed. Web server on unusual port like 9999: need both firewall port opening AND semanage to add 9999 to http_port_t. SSH on non-standard port: common for security through obscurity. Need both firewall and SELinux changes. Remember to also update sshd_config. MySQL restricted to internal network: use zone assignment rather than exposing to public zone. SELinux default port is fine. The general pattern: standard ports usually just need firewall changes because SELinux default port lists are comprehensive. Non-standard ports need both systems configured.

Best Practices

Do

Use services instead of raw ports when possible
Always use --permanent with firewall-cmd
Test changes with --timeout before committing
Use zones to segment network trust levels
Keep SELinux in enforcing mode
Document all port and service changes
Use rich rules for source-based restrictions
Verify with --list-all after changes

Do Not

Disable firewalld on production systems
Set SELinux to permissive/disabled permanently
Open ports without understanding what uses them
Use trusted zone for internet-facing interfaces
Forget --permanent (changes lost on reboot)
Ignore SELinux denials - fix them properly
Skip testing after firewall changes
Make firewall changes via SSH without --timeout

Critical: When making firewall changes via SSH, always use --timeout. If you accidentally block SSH, the rule auto-reverts and you regain access.

Following best practices prevents security gaps and administrative headaches. Use services over raw ports - they are self-documenting and easier to audit. Always use --permanent so changes survive reboot, but also apply to runtime. Test with --timeout, especially for SSH access - a 5-minute timeout prevents permanent lockout. Use zones to segment trust - internal database servers do not need public zone exposure. Keep SELinux enforcing. Permissive mode is for troubleshooting only, never permanent. If SELinux blocks something, fix it properly with semanage rather than disabling SELinux. Document everything - future administrators need to know why port 8888 is open. On the negative side, never disable firewalld. If you think you need to, you actually need to configure it properly. Never open ports blindly. Understand what service needs each port. And critically, when making changes via SSH, always use --timeout. Many administrators have learned this the hard way by locking themselves out of remote servers.

Key Takeaways

Firewall (firewalld): Controls external access. Use firewall-cmd to add services/ports. Always use --permanent.

Zones: Group interfaces by trust level. Default is public. Use appropriate zones for different networks.

SELinux Ports: Controls which services can bind to which ports. Use semanage port -a for non-standard ports.

Both Required: Non-standard ports need both firewall AND SELinux configuration. Check both when troubleshooting.

LAB EXERCISES

Configure Apache on port 8888 (firewall + SELinux)
Move SSH to port 2222 (both configurations required)
Create rich rule allowing HTTP only from 192.168.1.0/24
Troubleshoot a service that fails to start (SELinux denial)
Configure different zones for different interfaces
Use --timeout to safely test firewall changes

Next: Managing Containers with Podman

Let us summarize the essential network security skills. The firewall (firewalld) is your perimeter defense. It controls what traffic can reach your system from outside. Use firewall-cmd to manage it. Remember --permanent for persistent changes, and always reload after. Zones organize your firewall rules by trust level. The public zone is the default and appropriate for internet-facing interfaces. Internal, work, and home zones offer progressively more trust. SELinux port bindings control what services can listen on which ports. This is independent of the firewall. Use semanage port to add non-standard ports to service types. For non-standard ports, you typically need both firewall and SELinux configuration. Missing either causes connection failures. When troubleshooting, check both. Your lab exercises give hands-on practice with these essential skills. The Apache on 8888 exercise requires both systems. The SSH on 2222 exercise is a common real-world scenario. Practice these until they become second nature - they are heavily tested on the RHCSA and constantly used in production.