Kevin Old wrote:
> 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 at pbl.ca> Pollard Banknote Limited
Systems Administrator 1499 Buffalo Place
Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7