Are ipchains related to "firewall rules" in Red Hat Linux?
Yes, ipchains is related to firewall rules in Red Hat Linux. It is a firewall packet filtering utility that was used in older versions of Red Hat Linux (before version 7.0). It is still available in Red Hat Linux, but it is deprecated and is no longer the preferred way to manage firewall rules.
The preferred way to manage firewall rules in Red Hat Linux is to use the firewalld command. Firewalld is a more modern firewall management tool that provides a wider range of features and is easier to use.
If you are using an older version of Red Hat Linux, you can still use ipchains to manage firewall rules. However, if you are using Red Hat Linux 7.0 or later, you should use firewalld instead.
Here is a table that summarizes the differences between ipchains and firewalld:
||Older versions of Red Hat Linux
||Red Hat Linux 7.0 and later
||Basic firewall packet filtering
||Advanced firewall management
| Ease of use
||Easier to use
The `firewalld` command-line utility is an integral part of firewall management in Red Hat Linux and related distributions. Developed to supersede iptables in certain scenarios, `firewalld` provides a dynamic and more straightforward interface for configuring and maintaining firewall rules. It operates based on a concept of "zones" and "services," which allows for easier management and a more intuitive rule definition compared to traditional iptables commands. Below are key functionalities and examples that illustrate how `firewalld` is employed to manage firewall rules.
Installation and Service Management
Before you can utilize `firewalld`, ensure that it is installed on your system. Use the package manager to install it:
sudo yum install firewalld
To start, enable, or stop the `firewalld` service:
sudo systemctl start firewalld
sudo systemctl enable firewalld
sudo systemctl stop firewalld
Firewall zones are one of the cornerstone concepts in `firewalld`. Zones define the level of trust for network connections or interfaces. To list all available zones:
To get the default zone, use:
To set the default zone to, for example, "public," execute:
Adding and Removing Services
Services are predefined sets of rules that correspond to common network services such as HTTP, SSH, etc. To list all available services:
To add a service (e.g., `http`) to a zone (e.g., `public`):
firewall-cmd --zone=public --add-service=http
To remove a service from a zone:
firewall-cmd --zone=public --remove-service=http
To add a port (e.g., `8080/tcp`) to a zone:
firewall-cmd --zone=public --add-port=8080/tcp
To remove a port from a zone:
firewall-cmd --zone=public --remove-port=8080/tcp
The above changes are not persistent across reboots unless explicitly saved. To make the current runtime configuration persistent:
Advanced Rules and Direct Interface
For advanced users who require more granular control, `firewalld` also provides a direct interface to specify custom iptables rules:
firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 0 -p tcp --dport 8080 -j ACCEPT
This command adds a custom rule to allow TCP traffic on port 8080, leveraging iptables syntax within the `firewalld` framework.
In summary, `firewalld` offers a robust, dynamic, and user-friendly approach to firewall management in Red Hat Linux systems. Through its zoning concept and service-based rule definitions, it provides an intuitive method for both basic and advanced firewall configurations. Its integration with systemd allows for seamless service management, and its extensibility via direct rules ensures that even the most complex firewall requirements can be met.
Changing ipchains Firewall Rules
Now let us try adding a rule. As an example, let us imagine we want to block ICMP packets to disallow "pinging" of our Linux box.
You may do that to avoid various Denial of Service attacks that could be launched against your system. Block ICMP with a command like the following:
# ipchains -A input -p icmp -j DENY
This specifies that we are adding a rule to the input chain. It will match any ICMP packet and will drop it rather than allowing it through. Now if you are using the ping command against your Linux box, you should receive no response. Type the ipchains -L command again, and you will see something like this:
Chain input (policy ACCEPT):
target prot opt source destination ports
DENY icmp ------ anywhere anywhere any -> any
Chain forward (policy ACCEPT):
Chain output (policy ACCEPT):
You can see your new rule listed. This rule will block all ICMP packets entering your system, regardless of which computer sent those packets. If your Linux system is acting as a router, it will also block ICMP packets that are being forwarded from the Internet to your network, or vice versa. People on the Internet will be unable to ping anything on your network. Likewise, you will be unable to ping anything on the Internet. Perhaps that is not what you want. Let us assume then that you wish to block pinging of systems on your network by people on the Internet, but allow pinging of the router and allow the router to ping hosts on the Internet. First, we should flush the contents of the input chains using the -F parameter; then we can add our new rule.
# ipchains -F input
# ipchains -A forward -p icmp -j DENY
Now we can ping the Linux system and the Linux system can ping other boxes, but ping requests will not be passed through the Linux system. If you wish, use the ipchains -L command to verify that the rule has now been added to the forward chain rather than the input chain. You may also wish to block the telnet protocol when coming from the Internet. For this example, let us assume that our Linux router is connected to the Internet via a dialup connection called ppp0 and is connected to our internal LAN via an Ethernet connection called eth0. In that case, you could block telnet with a command like the following:
# ipchains -A input -i ppp0 -p tcp --dport 23 -j DENY
This rule basically says that any TCP packet with a destination port of 23 (the telnet port as specified in
/etc/services) that is arriving on the ppp0 interface should be dropped. This does not prevent you from
telneting to your Linux box from your internal network, but it does block telnet access from the Internet.
Red Hat Linux Certification