Yes, I have a chain called "OC", and no, I don't have anything in my input chain that calls the "OC" chain. I wasn't aware that I needed to call the "OC" chain from my input chain.
Can you provide syntax of how I might do this?
Uh, oh. May I suggest to read documentation first, and get some understanding on how Netfilter works before attempting to configure your firewall? Like before you get burned. You can't just create a chain, and expect that packets will automagically go through it. It's not the way Netfilter works.
To get you started, Netfilter has three built-in tables, each of which have some number of built-in chains (you can add your custom chains to these tables if you have complex setup, or you can simply use only built-in ones if you have simple setup). Note that chains are grouped into tables. So INPUT chain of filter table, and INPUT chain of mangle table are two different chains, each with its own set of rules, and called at two completely different stages of packet processing.
Each of three tables has its purpuse. Altough you can do some things in any one of them, you should really limit yourself to the appropriate table:
filter - general packet filtering, place where you accept or drop nat - place where you implement NAT mangle - playground for doing nasty things to packets
You'd usually set default policy of chains in fitler table to DROP, and policy of chains in nat and mangle tables to ACCEPT. That is, if you are using three tables the way they are intended to be used.
If you do not specify '-t' option to iptables command, than command operates on filter table.
To see how and when packets enter built-in chain, check out this two links (the flow chart is handy to have it printed and in front of you if doint anything remotely complex):
http://www.aptalaska.net/~jclive/ http://www.faqs.org/docs/iptables/traversingoftables.html
Each rule in each chain will see modifications to the packet made by previous chains and rules. Have that in mind if your firewall rules are going to modify packets (for example if you have NAT).
Packets will go by default only through built-in chains. If you define custom chains, you must explicitly "jump" into them from one of built-in chains. For example, say you create SSH_IN chain to control who can connect to local SSH server:
iptables -N SSH_IN iptables -A SSH_IN -s 1.2.3.4 -j ACCEPT iptables -A SSH_IN -j DROP
iptables -A INPUT -p tcp --dport 22 --sport 1024: -j SSH_IN
Note that above is not working example, do not cut&paste into your firewall config, there are some holes and assumptions inthere.
What above example shows is a good practice of explicitly saying what should happen to packet when it gets to the end of custom chain. Default policy can be set only to built-in chains, and is *not* inherited when you jump into custom chain. While iptables documentation specifies what happens to packet if it "falls-off" the end of custom chain, my advice is to always have catch-all DROP, ACCEPT, or RETURN at the end of all of your custom chains. It burned me once when I remembered wrong what happens to packet when it falls-off end of custom chain.
One common misconception (from skipping the "read documentation" step) that people have is how and when packets enter INPUT, OUTPUT, and FORWARD chains of filter table.
Only packets generated on firewall will go to OUTPUT chain. Only packets to be delivered to firewall will go to INPUT chain. Only packets that are to be forwarded will go to FORWARD chain.
From the above, packet can go only to *one* chain of filter table. So, to allow access to the service on the firewall, and to allow access to services behind the firewall, you must have rules for it in both INPUT (to allow access to service running on firewall) and FORWARD chains (to allow access to service running on a host behind the firewall).
The above is just a tip of an iceberg. Just a few very basic things from top of my head. You should really go through all of Netfilter documentation.
A word of advice at the end, have a default policy be to DROP everything. Than only allow things you want to allow. Even if you end up allowing large netblocks in, it is still much safer than allowing all of the Internet (and blocking one or two IPs).
-- Aleksandar Milivojevic <amilivojevic@xxxxxx> Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7
