On Wed, 15 Nov 2006, Mick wrote:
iptables -P INPUT DROP
iptables -A INPUT -i ! ${UPLINK} -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
I would like to define more than one iface in UPLINK, e.g. eth0, wlan0, ppp0.
It sounds like you want to write a rule that says,
"If the packet arrives on any of the interfaces eth0, wlan0, or ppp0,
then do ${something} with it."
I have never found a good way to do this, but I have found several bad
ways of doing this. :)
Here is one of the easiest of the bad ways:
Make separate rules which effectively test for each of the interfaces
you're interested in. If the rules match, then make the packets jump to
a new chain for further testing.
Let's use eth0, wlan0, and ppp0 as an example. Assume that you've got
these interfaces bound on a Gentoo system acting as a firewall and NAT
device. You trust eth0 and wlan0, as these are the interfaces from
which you connect to the system. You don't trust ppp0, as its IP
address is publicly routable.
You wish to be able to SSH into the Gentoo system from hosts on the eth0
and wlan0 interfaces, but not from packets arriving on the ppp0
interface.
You can't write a rule like the following:
iptables -A INPUT -i eth0,wlan0 -p tcp --dport ssh -j ACCEPT
So instead you write rules like this:
iptables -N in-from-trusted
iptables -A INPUT -i eth0 -j in-from-trusted
iptables -A INPUT -i wlan0 -j in-from-trusted
iptables -A in-from-trusted -p tcp --dport ssh -j ACCEPT
Consider how this works. Assume that one of your trusted hosts on the
eth0 segment sends a new SSH packet to the Gentoo system.
The SSH packet hits the "INPUT" chain, where it matches the first rule
because it arrives on the eth0 interface. The packet them jumps (-j) to
the chain in-from-trusted. The packet matches the first rule in this
chain because its destination tcp port is 22, and so the packet is
accepted.
The same rules apply for an incoming ssh packet arriving on the wlan0
interface.
If an ssh packet comes in on the ppp0 interface, it won't match any of
the rules from the INPUT chain listed above, and-- assuming that there
are no further rules in the INPUT chain-- its fate will be that of the
policy of the INPUT chain: DROP.
Finally, consider a packet arriving on the wlan0 interface whose
destination tcp port is, say, http . This packet will match the rule
"-A INPUT -i wlan0" and it will jump to the in-from-trusted chain. It
won't match the rule in in-from-trusted "-p tcp --dport ssh", and so it
won't be accepted here.
This method works well enough in this example, but gets unwieldly
quickly if taken to its logical extreme. I once maintained a set of
iptables rules that was written entirely in this method. It was nothing
but a series of "tests" chained together with jumps and returns. Even
though I wrote it, it was nearly impossible for me to follow and debug
it: tracing a packet required consulting five or six chains, and
inserting new rules was a chore because it was always necessary to avoid
inserting a rule in such a way to short-circuit an existing "test".
I warned you this was a bad way. :)
It's entirely possible that I'm misunderstanding the design of
netfilter, but it seems to me that the solution to complicated rulesets
is to permit boolean logic in rules like so:
iptables -A INPUT \
\(-i eth0 -or -i wlan0) -and \(-p tcp --dport ssh\) \
-j ACCEPT
Joe
--
gentoo-user@gentoo.org mailing list
