[rhn-users] iptables question

[Gary Wilson Jr]

> Add the DROP rule first, then the two exception ALLOW rules. Newly added 
> rules take precedence over older ones. /sbin/iptables -L -v will 
> demonstrate this. BTW: your DROP rule needs -p tcp on it.
> 
> # /sbin/iptables -A INPUT -p tcp --dport ssh -j DROP
> # /sbin/iptables -A INPUT -s 1.1.1.1 -p tcp --dport ssh -j ACCEPT
> # /sbin/iptables -A INPUT -s 2.2.2.2 -p tcp --dport ssh -j ACCEPT
> 
> Correction: The rules should be INSERT, not APPEND. That is, /sbin/iptables -I INPUT.... 

Yes, if you are adding them in this order, you do need to use -I instead 
of -A.  However, I would highly recommend using the -A method and 
placing the DROP rule last.  This is because a rule chain is traversed 
from top to bottom.  When using -A, your rules are written out in the 
order they will be traversed in the chain.  If using the -I method, your 
rules are written out in the opposite order they would get traversed. 
While this might not be too hard to fathom with only 3 rules, it will 
most definitely lead to confusion when more rules are added or someone 
else is trying to understand your rule set.

That said, I would recommend something like:

/sbin/iptables -A INPUT -s 1.1.1.1 -p tcp --dport ssh -j ACCEPT
/sbin/iptables -A INPUT -s 2.2.2.2 -p tcp --dport ssh -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport ssh -j DROP

If you want to use the state module, you might have an INPUT chain 
looking something like this:

.
. (maybe rules accepting all loopback traffic here)
.
/sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
.
. (maybe rules dropping spoofed or blacklisted traffic here)
.
/sbin/iptables -A INPUT -m state --state NEW \
	-p tcp --dport ssh --source 1.1.1.1 -j ACCEPT
/sbin/iptables -A INPUT -m state --state NEW \
	-p tcp --dport ssh --source 2.2.2.2 -j ACCEPT
.
. (maybe more ACCEPT rules here)
.
/sbin/iptables -A INPUT -m limit --limit 3/minute --limit-burst 3 \
	-j LOG --log-prefix "incoming DROPPED packet"
/sbin/iptables -A INPUT -j DROP


The state module was created to speed up a packet's traversal through 
the rule set.  You put the ESTABLISHED,RELATED rule near the top of your 
INPUT chain and now that rule becomes a "shortcut" for established and 
related connections because those packets will now get matched very 
early in the chain.  The state module is also optimized and much faster 
than if you were matching all your allowable traffic with separate 
non-state-module rules.  And of course the longer your INPUT chain, the 
greater the benefit.