Results 1 to 2 of 2
When I built my adaptive FW I blended together several different tools and tutorials. I have not been working with IPtables directly, instead I've been using CLI tools that manipulate ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
- 08-21-2014 #1
IPtables basic questions
The main one is fwsnort, which takes snort rules and translates them in to IPTables rules. Then there are several other tools that do things like ban any connection that attempts to violate one of those rules.
Fwsnort is a good tool for what it does. But I've been digging and it doesn't build what I would consider to be a "complete" FW. So I've started to get in to the basics of working with IPTables directly in order to add some rules to beef up my FW.
I'm still learning the basics and have to copy and paste rules rather than write my own.
I'm trying to add a stateful packet inspection rule that only allows all established and related connetions.
I found one in a tutorial and added it to the FW through
Now there are some auto generated accept rules at the top of rules.v4 that are generated by iptables-save and when I use iptables-save to insert my stateful packet inspection rule iptables-save places that rule below all of the auto generated accept rules. (Then all of the fwsnort translated rules come below that.)
Which leaves me with a few quetions:
1) Where in the system is iptables-save getting the info to generate the accept rules at the top of the list?
2) Why is it placing my added rule below them?
3) Doesn't having all the accept rules first negate the point of the SPI rule, and all the others for that matter, as the traffic has already been accepted?
4) How do I force iptables-save to place my SPI rule first in the list? (And do I want to? Would that break things? Am I looking at it wrong? Is it currently set up the way it shoud be?)
5) Why does manually editing /etc/iptables/rules.v4 not change the order of the rules? When I manually place the SPI rule at the top in /etc/iptables/rules.v4 and then runCode:
sudo iptables --list-rules
6) Am I looking at this the wrong way?
This is the top portion of my /etc/iptables/rules.v4:
# Generated by iptables-save v1.4.21 on Tue Aug 19 20:33:18 2014 *filter :INPUT ACCEPT [560:68301] :FORWARD ACCEPT [137:68100] :OUTPUT ACCEPT [381:55424] :fail2ban-ssh - [0:0] iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT -A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh -A fail2ban-ssh -j RETURN COMMIT # Completed on Tue Aug 19 20:33:18 2014 # Generated by iptables-save v1.4.21 on Tue Aug 19 20:33:18 2014 *mangle :PREROUTING ACCEPT [766:146890] :INPUT ACCEPT [629:78790] :FORWARD ACCEPT [137:68100] :OUTPUT ACCEPT [450:60467] :POSTROUTING ACCEPT [587:128567] COMMIT Completed on Tue Aug 19 20:33:18 2014 # Generated by iptables-save v1.4.21 on Tue Aug 19 20:33:18 2014 *nat :PREROUTING ACCEPT [16:1214] :INPUT ACCEPT [11:914] :OUTPUT ACCEPT [76:5297] :POSTROUTING ACCEPT [20:1228] -A POSTROUTING -o eth0 -j MASQUERADE COMMIT # Completed on Tue Aug 19 20:33:18 2014
But, doesn't having this at the top:
:INPUT ACCEPT [560:68301] :FORWARD ACCEPT [137:68100] :OUTPUT ACCEPT [381:55424]Code:
-P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT -N fail2ban-ssh -A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A fail2ban-ssh -j RETURN
Doesn't that mean I'm accepting and forwarding everything and then it's too late to apply any of those spiffy rules b/c the traffic has already passed?
- 08-28-2014 #2
- Join Date
- May 2008
- Russia, Far East, Komsomolsk-on-Amur
In addition to the regular rules that you can add to the iptables chains, the iptables has special policy rules.
Policy sets the default target for nor user-defined chains. By default they set 'ACCEPT' target.
The policy target applied after processing all rules in the chain if no matches were found.
Look to 'man iptables' for more info.