1 |
On Wed, 15 Nov 2006, Mick wrote: |
2 |
|
3 |
> iptables -P INPUT DROP |
4 |
> iptables -A INPUT -i ! ${UPLINK} -j ACCEPT |
5 |
> iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT |
6 |
> |
7 |
> I would like to define more than one iface in UPLINK, e.g. eth0, wlan0, ppp0. |
8 |
|
9 |
It sounds like you want to write a rule that says, |
10 |
|
11 |
"If the packet arrives on any of the interfaces eth0, wlan0, or ppp0, |
12 |
then do ${something} with it." |
13 |
|
14 |
I have never found a good way to do this, but I have found several bad |
15 |
ways of doing this. :) |
16 |
|
17 |
Here is one of the easiest of the bad ways: |
18 |
|
19 |
Make separate rules which effectively test for each of the interfaces |
20 |
you're interested in. If the rules match, then make the packets jump to |
21 |
a new chain for further testing. |
22 |
|
23 |
Let's use eth0, wlan0, and ppp0 as an example. Assume that you've got |
24 |
these interfaces bound on a Gentoo system acting as a firewall and NAT |
25 |
device. You trust eth0 and wlan0, as these are the interfaces from |
26 |
which you connect to the system. You don't trust ppp0, as its IP |
27 |
address is publicly routable. |
28 |
|
29 |
You wish to be able to SSH into the Gentoo system from hosts on the eth0 |
30 |
and wlan0 interfaces, but not from packets arriving on the ppp0 |
31 |
interface. |
32 |
|
33 |
You can't write a rule like the following: |
34 |
|
35 |
iptables -A INPUT -i eth0,wlan0 -p tcp --dport ssh -j ACCEPT |
36 |
|
37 |
So instead you write rules like this: |
38 |
|
39 |
iptables -N in-from-trusted |
40 |
|
41 |
iptables -A INPUT -i eth0 -j in-from-trusted |
42 |
iptables -A INPUT -i wlan0 -j in-from-trusted |
43 |
|
44 |
iptables -A in-from-trusted -p tcp --dport ssh -j ACCEPT |
45 |
|
46 |
Consider how this works. Assume that one of your trusted hosts on the |
47 |
eth0 segment sends a new SSH packet to the Gentoo system. |
48 |
|
49 |
The SSH packet hits the "INPUT" chain, where it matches the first rule |
50 |
because it arrives on the eth0 interface. The packet them jumps (-j) to |
51 |
the chain in-from-trusted. The packet matches the first rule in this |
52 |
chain because its destination tcp port is 22, and so the packet is |
53 |
accepted. |
54 |
|
55 |
The same rules apply for an incoming ssh packet arriving on the wlan0 |
56 |
interface. |
57 |
|
58 |
If an ssh packet comes in on the ppp0 interface, it won't match any of |
59 |
the rules from the INPUT chain listed above, and-- assuming that there |
60 |
are no further rules in the INPUT chain-- its fate will be that of the |
61 |
policy of the INPUT chain: DROP. |
62 |
|
63 |
Finally, consider a packet arriving on the wlan0 interface whose |
64 |
destination tcp port is, say, http . This packet will match the rule |
65 |
"-A INPUT -i wlan0" and it will jump to the in-from-trusted chain. It |
66 |
won't match the rule in in-from-trusted "-p tcp --dport ssh", and so it |
67 |
won't be accepted here. |
68 |
|
69 |
This method works well enough in this example, but gets unwieldly |
70 |
quickly if taken to its logical extreme. I once maintained a set of |
71 |
iptables rules that was written entirely in this method. It was nothing |
72 |
but a series of "tests" chained together with jumps and returns. Even |
73 |
though I wrote it, it was nearly impossible for me to follow and debug |
74 |
it: tracing a packet required consulting five or six chains, and |
75 |
inserting new rules was a chore because it was always necessary to avoid |
76 |
inserting a rule in such a way to short-circuit an existing "test". |
77 |
|
78 |
I warned you this was a bad way. :) |
79 |
|
80 |
It's entirely possible that I'm misunderstanding the design of |
81 |
netfilter, but it seems to me that the solution to complicated rulesets |
82 |
is to permit boolean logic in rules like so: |
83 |
|
84 |
iptables -A INPUT \ |
85 |
\(-i eth0 -or -i wlan0) -and \(-p tcp --dport ssh\) \ |
86 |
-j ACCEPT |
87 |
|
88 |
Joe |
89 |
-- |
90 |
gentoo-user@g.o mailing list |