Linux Iptables firewall

[IKnowNot]

1st, ,I'm glad to see yanksfan got it working.

This is incorrect. The number and location of rules in your file is unrelated to their situation in the actual rule chain.

ruleset:
iptables -A INPUT -p tcp -i eth1 -j DROP
iptables -A OUTPUT -p tcp -i eth1 --dport 25 -j ACCEPT
iptables -A INPUT -p tcp -i eth1 --dport 25 -j ACCEPT
iptables -A OUTPUT -p tcp -i eth1 -j DROP
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

What would happen to ANY packet coming in on eth1 ?
Would any packet be ESTABLISHED ?


I probably should not have made such a general statement and thus prompt such a response. ( usually only have to watch myself when that closely when talking to lawyers. ) But it was not incorrect. I assumed the original poster had at least some knowledge of Netfilter.
And the location IS important, but important per chain.

My thoughts here were that NO ruleset would contain just what was listed. Before the stateful rules mentioned above, or the other rules, it is a VERY good idea to drop malformed packets, packets leaving to the net side with private IP addresses, packets coming in from the net side with private IP addresses, packets coming from the LAN outside the LAN IP range, etc.
And yes, I do yield, you could put the port ACCEPT rule after the stateful ESTABLISHED rule as they would be working on different packets and the ESTABLISHED packets would only be ESTABLISHED after the connection was established after the original packet was accepted by the port rule. ( ??? )
But why? Why confuse the issue? It is best to keep the rulsets as straight forward and logical as possible, isn't it?

[chsh]

Originally posted here by IKnowNot
[...]I probably should not have made such a general statement and thus prompt such a response. ( usually only have to watch myself when that closely when talking to lawyers. ) But it was not incorrect.

Yes, actually it is incorrect.
ruleset:
iptables -A INPUT -j DROP # Drop all incoming.
iptables -I INPUT 1 -p TCP --dport 80 -j ACCEPT # Accept TCP/80 (HTTP)
According to you, file order matters, however here hits will still come in to port 80. Using append-only may make sense to some people, however in medium- and semi-large- rulesets it can be more efficient to use non-linear (in a file sense) rulesets. Usually insert is best used when using custom chains, or when using specific-use NF modules, but I've used it quite often in scripts to perform drop-all at the beginning and then adding whatever needs to be accepted -- in fact, the ruleset on the box I'm on is done in such a manner.

[yanksfan]

I guess none of you use webmin (www.webmin.com), but that's what I used to configure iptables. A big security downside of webmin is that the entire program is run by root, but since I only allow my computer from the LAN to access it (and only I use it), I think that its pretty safe. Let me know what you think about webmin.

[IKnowNot]

No, I’ve never used webmin, so I can’t comment on it. I’m just overly paranoid and don’t like any service I don’t need running. And sorry to have hijacked this thread, was not my intent.

And the location IS important, but important per chain..

Yes, you can insert, but you are then inserting into the chain at a specific location.
The chain is then modified, and STILL goes top-down, from one rule to another.

As far as the file goes, if I’m building a table for a workstation I can just take the rulesets and list them, print them, then the computer does the work listing them in the top-down order for me, the way the rulsets will be followed; I can be sloppy. But if I’m building or diagnosing a stand-alone firewall or a firewall for a server I may not have print services running. No GUI, limited shells, etc. Now with large rulesets trying to track down a problem or open a new have-to-have service for some meathead can very quickly become a nightmare trying to follow all those inserts and deletes. Again, why? Why not take a little more time to do it in a logical step-down order the way the kernel will read them?

If you are trying to diagnose a running ruleset the insert and delete make perfect sense. Or you if are scrambling to shut something down during an attack. Yes, I use append mostly and use insert and delete very sparingly on a final version.

Where I may use it in a final ruleset is at the end of my rules, something like
# -----now that tables are finished remove absolute stops and pray ------ #
iptables -D INPUT -i ! lo -j DROP
iptables -D OUTPUT -o ! lo -j DROP
iptables -D FORWARD -i ! lo -j DROP

and I want these at the very end, not somewhere in the middle which would defeat the purpose.
Just because you can do something does not mean you should.

[chsh]

Originally posted here by IKnowNot
Just because you can do something does not mean you should.

It also doesn't mean you shouldn't. There are very valid reasons for logically separating things in a file and using very many inserts that can make loads of sense. For a workstation this may not be the case, however don't dismiss it as being an invalid approach because you have never encountered a situation where it is the most logical method of designing rulesets. My point was your statement that:

Yes! Just remember, Netfilter ( and IPTables ) works in a top-down method. Those rules would be AFTER the rules which allowed the original connections.

In the context of file layout isn't actually correct. It is important to not give a newbie unclear information, and I merely posted to clarify something.

[IKnowNot]

Yes, I do understand and agree. But I enjoyed the exchange. It gave me a necessary break and maybe someone else could get something out of it.

Some people call me Anal Retentive but red wine and oatmeal are helping clear that up!