|
Lines 128-134
Link Here
|
| 128 |
modules (according to the previously choosen installation method), you |
128 |
modules (according to the previously choosen installation method), you |
| 129 |
have to make some changes to the <filename>/etc/rc.conf</filename> |
129 |
have to make some changes to the <filename>/etc/rc.conf</filename> |
| 130 |
configuration file. The default rule of the firewall is to reject all IP |
130 |
configuration file. The default rule of the firewall is to reject all IP |
| 131 |
packets. Initially we'll set up an 'open' firewall, in order to verify |
131 |
packets. Initially we'll set up an <option>open</option> firewall, in order to verify |
| 132 |
its operation without any issue related to packet filtering (in case you |
132 |
its operation without any issue related to packet filtering (in case you |
| 133 |
are going to execute this procedure remotely, such configuration will |
133 |
are going to execute this procedure remotely, such configuration will |
| 134 |
avoid you to remain isolated from the network). Put these lines in |
134 |
avoid you to remain isolated from the network). Put these lines in |
|
Lines 141-147
Link Here
|
| 141 |
|
141 |
|
| 142 |
<para>The first row will enable the firewall (and will load the module |
142 |
<para>The first row will enable the firewall (and will load the module |
| 143 |
<filename>ipfw.ko</filename> if it is not compiled in the kernel), the |
143 |
<filename>ipfw.ko</filename> if it is not compiled in the kernel), the |
| 144 |
second one to set up it in 'open' mode (as explained in |
144 |
second one to set up it in <option>open</option> mode (as explained in |
| 145 |
<filename>/etc/rc.firewall</filename>), the third one to not show rules |
145 |
<filename>/etc/rc.firewall</filename>), the third one to not show rules |
| 146 |
loading and the fourth one to enable logging support.</para> |
146 |
loading and the fourth one to enable logging support.</para> |
| 147 |
|
147 |
|
|
Lines 178-184
Link Here
|
| 178 |
|
178 |
|
| 179 |
<para>Now it's time to reboot the system and use it as before: there will |
179 |
<para>Now it's time to reboot the system and use it as before: there will |
| 180 |
be some new messages about the bridge and the firewall, but the bridge |
180 |
be some new messages about the bridge and the firewall, but the bridge |
| 181 |
will not be activated and the firewall, being in 'open' mode, will not |
181 |
will not be activated and the firewall, being in <option>open</option> mode, will not |
| 182 |
avoid any operations.</para> |
182 |
avoid any operations.</para> |
| 183 |
|
183 |
|
| 184 |
<para>If there are any problems, you should sort them out now |
184 |
<para>If there are any problems, you should sort them out now |
|
Lines 220-230
Link Here
|
| 220 |
are being received by the local machine. In general, incoming packets |
220 |
are being received by the local machine. In general, incoming packets |
| 221 |
are run through the firewall only once, not twice as is normally the |
221 |
are run through the firewall only once, not twice as is normally the |
| 222 |
case; in fact they are filtered only upon receipt, so rules that use |
222 |
case; in fact they are filtered only upon receipt, so rules that use |
| 223 |
'out' or 'xmit' will never match. Personally, I use 'in via' which is an |
223 |
<option>out</option> or <option>xmit</option> will never match. Personally, I use <option>in via</option> which is an |
| 224 |
older syntax, but one that has a sense when you read it. Another |
224 |
older syntax, but one that has a sense when you read it. Another |
| 225 |
limitation is that you are restricted to use only 'pass' or 'drop' |
225 |
limitation is that you are restricted to use only <option>pass</option> or <option>drop</option> |
| 226 |
commands for packets filtered by a bridge. Sophisticated things like |
226 |
commands for packets filtered by a bridge. Sophisticated things like |
| 227 |
'divert', 'forward' or 'reject' are not available. Such options can |
227 |
<option>divert</option>, <option>forward</option> or <option>reject</option> are not available. Such options can |
| 228 |
still be used, but only on traffic to or from the bridge machine itself |
228 |
still be used, but only on traffic to or from the bridge machine itself |
| 229 |
(if it has an IP address).</para> |
229 |
(if it has an IP address).</para> |
| 230 |
|
230 |
|
|
Lines 234-240
Link Here
|
| 234 |
exact same set of IP addresses and port numbers (but with source and |
234 |
exact same set of IP addresses and port numbers (but with source and |
| 235 |
destination reversed, of course). For firewalls that have no |
235 |
destination reversed, of course). For firewalls that have no |
| 236 |
statekeeping, there is almost no way to deal with this sort of traffic |
236 |
statekeeping, there is almost no way to deal with this sort of traffic |
| 237 |
as a single session. But with a firewall that can "remember" an outgoing |
237 |
as a single session. But with a firewall that can <quote>remember</quote> an outgoing |
| 238 |
<acronym>UDP</acronym> packet and, for the next few minutes, allow a |
238 |
<acronym>UDP</acronym> packet and, for the next few minutes, allow a |
| 239 |
response, handling <acronym>UDP</acronym> services is trivial. The |
239 |
response, handling <acronym>UDP</acronym> services is trivial. The |
| 240 |
following example shows how to do it. It's possible to do the same thing |
240 |
following example shows how to do it. It's possible to do the same thing |
|
Lines 248-254
Link Here
|
| 248 |
have to care for them anymore. Custom rules should be put in a separate |
248 |
have to care for them anymore. Custom rules should be put in a separate |
| 249 |
file (say <filename>/etc/rc.firewall.local</filename>) and loaded at |
249 |
file (say <filename>/etc/rc.firewall.local</filename>) and loaded at |
| 250 |
system startup, by modifying the row of |
250 |
system startup, by modifying the row of |
| 251 |
<filename>/etc/rc.conf</filename> where we defined the 'open' |
251 |
<filename>/etc/rc.conf</filename> where we defined the <option>open</option> |
| 252 |
firewall:</para> |
252 |
firewall:</para> |
| 253 |
|
253 |
|
| 254 |
<programlisting>firewall_type="/etc/rc.firewall.local"</programlisting> |
254 |
<programlisting>firewall_type="/etc/rc.firewall.local"</programlisting> |
|
Lines 338-351
Link Here
|
| 338 |
server, if you have them. Obviously the whole rule set should be |
338 |
server, if you have them. Obviously the whole rule set should be |
| 339 |
flavored to personal taste, this is only a specific example (rule format |
339 |
flavored to personal taste, this is only a specific example (rule format |
| 340 |
is described accurately in the &man.ipfw.8; man page). Note that in |
340 |
is described accurately in the &man.ipfw.8; man page). Note that in |
| 341 |
order for 'relay' and 'ns' to work, name service lookups must work |
341 |
order for <quote>relay</quote> and <quote>ns</quote> to work, name service lookups must work |
| 342 |
<emphasis>before</emphasis> the bridge is enabled. This is an example of |
342 |
<emphasis>before</emphasis> the bridge is enabled. This is an example of |
| 343 |
making sure that you set the IP on the correct network card. |
343 |
making sure that you set the IP on the correct network card. |
| 344 |
Alternatively it is possible to specify the IP address instead of the |
344 |
Alternatively it is possible to specify the IP address instead of the |
| 345 |
host name (required if the machine is IP-less).</para> |
345 |
host name (required if the machine is IP-less).</para> |
| 346 |
|
346 |
|
| 347 |
<para>People that are used to setting up firewalls are probably also used |
347 |
<para>People that are used to setting up firewalls are probably also used |
| 348 |
to either having a 'reset' or a 'forward' rule for ident packets |
348 |
to either having a <option>reset</option> or a <option>forward</option> rule for ident packets |
| 349 |
(<acronym>TCP</acronym> port 113). Unfortunately, this is not an |
349 |
(<acronym>TCP</acronym> port 113). Unfortunately, this is not an |
| 350 |
applicable option with the bridge, so the best thing is to simply pass |
350 |
applicable option with the bridge, so the best thing is to simply pass |
| 351 |
them to their destination. As long as that destination machine is not |
351 |
them to their destination. As long as that destination machine is not |
|
Lines 360-368
Link Here
|
| 360 |
of traffic will take different paths through the kernel and into the |
360 |
of traffic will take different paths through the kernel and into the |
| 361 |
packet filter. The inside net will go through the bridge, while the |
361 |
packet filter. The inside net will go through the bridge, while the |
| 362 |
local machine will use the normal IP stack to speak. Thus the two rules |
362 |
local machine will use the normal IP stack to speak. Thus the two rules |
| 363 |
to handle the different cases. The 'in via |
363 |
to handle the different cases. The <option>in via |
| 364 |
<devicename>fxp0</devicename>' rules work for both paths. In general, if |
364 |
<devicename>fxp0</devicename></option> rules work for both paths. In general, if |
| 365 |
you use 'in via' rules throughout the filter, you will need to make an |
365 |
you use <option>in via</option> rules throughout the filter, you will need to make an |
| 366 |
exception for locally generated packets, because they did not come in |
366 |
exception for locally generated packets, because they did not come in |
| 367 |
via any of our interfaces.</para> |
367 |
via any of our interfaces.</para> |
| 368 |
</sect1> |
368 |
</sect1> |