iptables: RH-Firewall-1-INPUT vs. INPUT, and the wiki

Support for security such as Firewalls and securing linux

iptables: RH-Firewall-1-INPUT vs. INPUT, and the wiki

Postby mdfx » 2012/03/29 19:41:57

Hello,

I feel like I have started to grasp of the basics of iptables through experiment/logging and reading. I got my start at the CentOS iptables wiki. But one thing still puzzles me that I haven't been able to google up a clear answer on:

Why is the chain "RH-Firewall" used in some cases I've read (like the Samba HowTo , but not others?

For example, in the hardening CentOS wiki there is the following code (I've pared it down a bit):
Code: Select all
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT - [0:0]

-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT

-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp --icmp-type echo-reply -j ACCEPT

-A INPUT -i eth0 -s 10.0.0.0/8 -j LOG --log-prefix "IP DROP SPOOF A: "
-A INPUT -i eth0 -s 172.16.0.0/12 -j LOG --log-prefix "IP DROP SPOOF B: "

-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Accept ssh traffic. Restrict this to known ips if possible.
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT

#Log and drop everything else
-A RH-Firewall-1-INPUT -j LOG
-A RH-Firewall-1-INPUT -j DROP
COMMIT


Some specific parts that confuse me about this:
:RH-Firewall-1-INPUT - [0:0] ~ Seems to be defining a chain, but with no default (a "-")?
-A INPUT -j RH-Firewall-1-INPUT ~ Seems to forward INPUT packets to the RH-Firewall chain, but then rules are defined later for -A INPUT?

All of my experimentation and iptables rules have been absent of any RH-Firewall, using just INPUT, FORWARD, and OUTPUT chains. Is there a reason to use it? Where does it come from/Why does it crop up so often?

I'm running CentOS 6.2 and iptables v1.4.7. Thanks for any responses to these basic questions. Linux is fun!
mdfx
 
Posts: 4
Joined: 2012/03/26 19:47:23

Re: iptables: RH-Firewall-1-INPUT vs. INPUT, and the wiki

Postby TrevorH » 2012/03/29 20:16:42

RH changed the chain name between CentOS 5 and 6. In CentOS 5 the default iptables ruleset contains an INPUT chain that just jumps to a second chain that RH called RH-Firewall-1-INPUT and contained their rules. In CentOS 6 they abolished RH-Firewall-1-INPUT and all the rules are in the INPUT chain.

I prefer the CentOS 6 version - it's less complicated and easier to type :-)
User avatar
TrevorH
Forum Moderator
 
Posts: 9077
Joined: 2009/09/24 10:40:56
Location: Brighton, UK

iptables: RH-Firewall-1-INPUT vs. INPUT, and the wiki

Postby jlehtone » 2012/03/29 21:27:19

The reasoning for the akward named chain may partially have been in this:
Code: Select all
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT

1. You have one set (chain) of rules that you reuse in more than one situation.
2. It is clear by chain name, whose ruleset it is (until player adds more).
3. Packages might inject their rules and they had very peculiarly named target chain.

User actions render 2 ineffective, more clever packages live without 3, and FORWARD and
INPUT do not really share same set of rules, so even 1 has limited value.

However, user defined chains are a very good thing. Reuse is good too. When you have many
rules with similar conditions it is better to use their common condition to shovel all potential
packets to separate chain and check the differing conditions there. All the other packets
will then skip those many rules by failing the first test. For example, tcp and udp could have
separate chains with rules of their own.
User avatar
jlehtone
 
Posts: 1431
Joined: 2007/12/11 08:17:33
Location: Finland

Re: iptables: RH-Firewall-1-INPUT vs. INPUT, and the wiki

Postby mdfx » 2012/03/29 22:19:56

TrevorH wrote:
RH changed the chain name between CentOS 5 and 6. In CentOS 5 the default iptables ruleset contains an INPUT chain that just jumps to a second chain that RH called RH-Firewall-1-INPUT and contained their rules. In CentOS 6 they abolished RH-Firewall-1-INPUT and all the rules are in the INPUT chain.

I prefer the CentOS 6 version - it's less complicated and easier to type :-)


This answers much of my confusion on the matter. Thank you.

jlehtone wrote:
The reasoning for the akward named chain may partially have been in this:
Code: Select all
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT

1. You have one set (chain) of rules that you reuse in more than one situation.
2. It is clear by chain name, whose ruleset it is (until player adds more).
3. Packages might inject their rules and they had very peculiarly named target chain.

User actions render 2 ineffective, more clever packages live without 3, and FORWARD and
INPUT do not really share same set of rules, so even 1 has limited value.

However, user defined chains are a very good thing. Reuse is good too. When you have many
rules with similar conditions it is better to use their common condition to shovel all potential
packets to separate chain and check the differing conditions there. All the other packets
will then skip those many rules by failing the first test. For example, tcp and udp could have
separate chains with rules of their own.


This is good food for thought when constructing my rules. I've yet to implement any custom chains.

Thanks :-)
mdfx
 
Posts: 4
Joined: 2012/03/26 19:47:23


Return to CentOS 6 - Security Support

Who is online

Users browsing this forum: No registered users and 1 guest