Red Hat Bugzilla – Bug 976598
Updating iptables config is inconsistent.
Last modified: 2014-01-05 19:04:58 EST
Section Number and Name:
Describe the issue:
Currently, the following update methods are used:
--On the command line, with 'iptables -A INPUT' (goes on end of chain)
--On the command line, with 'iptables -I INPUT' (uses a number to determine where to place)
--Updating the /etc/sysconfig/iptables configuration file
Suggestions for improvement:
Use the update-the-file approach so that it is obvious where the rule needs to be, and so that sysadmins can easily integrate the rule into their iptables script.
The other alternative is a tool called lokkit but would have to check if it is always available (need it to be in the @base package group in RHEL).
(In reply to Summer Long from comment #0)
> Section Number and Name:
> Firewall sections
> Describe the issue:
> Currently, the following update methods are used:
> --On the command line, with 'iptables -A INPUT' (goes on end of chain)
> --On the command line, with 'iptables -I INPUT' (uses a number to determine
> where to place)
I had forgotten but further testing has confirmed, the default RHEL firewall includes a REJECT all rule at the end of the INPUT chain. As a result both of these methods of updating the firewall result in the new rule being inserted *after* the rule that REJECTs the traffic (hence having no impact). That is unless of course you happen to know the exact number to provide with -I (unlikely).
I think that's why I had gone with the update the file approach in the first place (on top of the reasons in the description).
Taking this one for now. Will update the BZ status once my RH account gets reactivated. --ddomingo
I revised the iptables instructions in the following topics to make them consistent with all the others; they are all of the "update config file" variety now:
Configuring the Object Storage Service Storage Nodes
By the way, the iptables rule in that last topic also opens port 873, not sure why. Left it as is for now.