1 |
On Wed, 15 Nov 2006, Mick wrote: |
2 |
> On Wednesday 15 November 2006 21:25, Flophouse Joe wrote: |
3 |
>> On Wed, 15 Nov 2006, Mick wrote: |
4 |
|
5 |
> UPLINK="eth0 wlan0 ppp0" |
6 |
> for x in ${INTERFACES} |
7 |
> do |
8 |
> iptables -A INPUT -i ! ${x} -j ACCEPT |
9 |
> . . . more rules . . . |
10 |
> iptables -A INPUT -p tcp -i ${x} -j DROP |
11 |
> fi |
12 |
> ===================================================== |
13 |
> type of think. Not sure if the syntax is correct, but the idea is that we |
14 |
> define multiple interfaces, but only write the rules once with the |
15 |
> variable 'x' where the interface is meant to go. |
16 |
|
17 |
I'm not 100% certain that I understand the goal, so please let me know |
18 |
if I've gotten it wrong. It sounds like you want to apply identical |
19 |
firewall rules to each of three interfaces. It's possible that there |
20 |
are other interfaces, and if traffic arrives on those interfaces, then |
21 |
it should not be matched by the rules in the for loop. |
22 |
|
23 |
If this is the case, then yes, the for loop you've suggested should be |
24 |
perfectly fine. The rules you specify in that loop will only be applied |
25 |
to traffic which arrives on the interfaces that you loop through. |
26 |
|
27 |
If you're anything like me, you'll find the rules created in this manner |
28 |
slightly difficult to read from the output of "iptables -vnL", but you'd |
29 |
have the same problem using the test-then-jump method I mentioned in my |
30 |
previous post. As near as I can tell, this is a limitation of iptables |
31 |
(or netfilter) itself, in that (to the best of my knowledge) it isn't |
32 |
possible to specify a rule that matches multiple interfaces whose names |
33 |
don't begin the same way. |
34 |
|
35 |
>> It's entirely possible that I'm misunderstanding the design of |
36 |
>> netfilter, but it seems to me that the solution to complicated rulesets |
37 |
>> is to permit boolean logic in rules like so: |
38 |
>> |
39 |
>> iptables -A INPUT \ |
40 |
>> \(-i eth0 -or -i wlan0) -and \(-p tcp --dport ssh\) \ |
41 |
>> -j ACCEPT |
42 |
> |
43 |
> Is there a legit way of specifying such rules? |
44 |
|
45 |
Not that I'm aware of, but I'd very much like to be proven wrong. Does |
46 |
anyone else on the list know of a way to specify boolean conditions in |
47 |
iptables rules as illustrated above? |
48 |
|
49 |
For what it's worth, I have found a way to get something that |
50 |
approximates the ability to use ORs in iptables rules, but it borders on |
51 |
the criminially insane. I describe it below: |
52 |
|
53 |
I have a Gentoo system in my house which acts as a firewall and NAT |
54 |
gateway. It has three network interfaces: |
55 |
|
56 |
eth0 connects to the public internet, |
57 |
eth1 connects to a non-routable network segment, |
58 |
eth2 connects to a non-routable wireless access point left wide open. |
59 |
|
60 |
I wish for some hosts-- and only some hosts-- to be able to connect to the |
61 |
wireless access point and have their traffic masqueraded out to the |
62 |
public internet. |
63 |
|
64 |
Since I'm dealing with a very small number of hosts, and since these |
65 |
hosts are directly connected to the Gentoo system's ethernet segment, |
66 |
I've decided to filter traffic from the wireless access point based on |
67 |
the source MAC address of the ethernet frames coming from the wireless |
68 |
access point. |
69 |
|
70 |
Let's say that I trused the hosts with MAC address 00:11:22:33:44:55 and |
71 |
with MAC address 00:22:44:66:88:AA, and I wished for these hosts to have |
72 |
their traffic forwarded out to the internet without any restrictions |
73 |
whatsoever. |
74 |
|
75 |
This would be simple enough: |
76 |
|
77 |
iptables -A FORWARD -i eth2 -o eth0 \ |
78 |
-m mac --source-mac 00:11:22:33:44:55 -j ACCEPT |
79 |
|
80 |
iptables -A FORWARD -i eth2 -o eth0 \ |
81 |
-m mac --source-mac 00:22:44:66:88:AA -j ACCEPT |
82 |
|
83 |
But in reality, the rules are a bit more complicated. I disallow |
84 |
outgoing access to SMTP and BitTorrent, for example. I also disallow |
85 |
outgoing traffic to certain UDP ports. |
86 |
|
87 |
These rules add up quickly. It's possible to collapse some of these rules |
88 |
using -m multiport , but I still end up with a few rules for each of the |
89 |
hosts that are being forwarded from the wireless interface to the public. |
90 |
And since I can't test for multiple MAC addresses in one rule, I need |
91 |
separate rules for each host. |
92 |
|
93 |
I've got about six hosts connecting to the wireless access point, and |
94 |
I've got three rules for each host. Because I can't "OR" rules |
95 |
together, I've got 6 x 3 = 18 rules to juggle. |
96 |
|
97 |
This isn't too big of a deal if I wrap it up in a for loop, but it's |
98 |
still unsightly to look at in the output of "iptables -vnL" |
99 |
|
100 |
I've used the connmark match and the CONNMARK target to get the same |
101 |
effect. |
102 |
|
103 |
In table mangle chain PREROUTING, I have rules that look like this: |
104 |
|
105 |
iptables -t mangle -A PREROUTING \ |
106 |
-m mac --mac-source 00:11:22:33:44:55 \ |
107 |
-j CONNMARK --set-mark 0x1/0x1 |
108 |
|
109 |
iptables -t mangle -A PREROUTING \ |
110 |
-m mac --mac-source 00:22:44:66:88:AA \ |
111 |
-j CONNMARK --set-mark 0x1/0x1 |
112 |
|
113 |
iptables -t mangle -A PREROUTING \ |
114 |
-m mac --mac-source 33:66:99:CC:FF:00 \ |
115 |
-j CONNMARK --set-mark 0x1/0x1 |
116 |
|
117 |
And now I can collapse the rules in table filter, chain FORWARD like so: |
118 |
|
119 |
iptables -A FORWARD -p tcp -m multiport ! --dports 25,6881 \ |
120 |
-i eth2 -o eth0 -m connmark 0x1/0x1 -j ACCEPT |
121 |
|
122 |
iptables -A FORWARD -p udp -m multiport ! --dports 123,456 \ |
123 |
-i eth2 -o eth0 -m connmark 0x1/0x1 -j ACCEPT |
124 |
|
125 |
The "connmark 0x1/0x1" business sets a bit associated with the connection; think of |
126 |
it as setting a variable and then checking for it later. |
127 |
|
128 |
The above two rules are effectively saying the following: |
129 |
|
130 |
iptables -A FORWARD -p tcp -m multiport ! --dports 25,6881 \ |
131 |
-i eth2 -o eth0 \ |
132 |
-m mac --mac-source mac-1,mac-2,mac3 \ |
133 |
-j ACCEPT |
134 |
|
135 |
iptables -A FORWARD -p tcp -m multiport ! --dports 123,456 \ |
136 |
-i eth2 -o eth0 \ |
137 |
-m mac --mac-source mac-1,mac-2,mac-3 \ |
138 |
-j ACCEPT |
139 |
|
140 |
As you can see, this method is pretty complicated, too. It's not really |
141 |
any substitute for "real" boolean logic (as described near the top of |
142 |
this post). If anyone knows of a way to do this, I'd like to know |
143 |
about it. |
144 |
|
145 |
Joe |
146 |
-- |
147 |
gentoo-user@g.o mailing list |