- Reword some text.
- Use firewall package instead of firewall software application. - Do not say non-stateful firewall's are "legacy" since they still make sense in some cases. - Move paragraph about /etc/rc.firewall to the ipfw section and don't say it's outdates, just simple. [1] Inspired by: den [1]
This commit is contained in:
parent
e3b704a49c
commit
bac2a185c2
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=24202
1 changed files with 26 additions and 43 deletions
|
@ -141,59 +141,35 @@
|
|||
</sect1>
|
||||
|
||||
<sect1 id="firewalls-apps">
|
||||
<title>Firewall Software Applications</title>
|
||||
<title>Firewall Packages</title>
|
||||
|
||||
<para>&os; has three different firewall software products built
|
||||
into the base system. They are IPFILTER (also known as IPF),
|
||||
IPFIREWALL (also known as IPFW) and PF (OpenBSD's PacketFilter).
|
||||
IPFIREWALL has the built in DUMMYNET traffic shaper facilities
|
||||
for controlling bandwidth usage. IPFILTER does not have a built
|
||||
in traffic shaper facility for controlling bandwidth usage, but
|
||||
the ALTQ port application can be used to accomplish the same
|
||||
function. The DUMMYNET feature and <acronym>ALTQ</acronym> is
|
||||
generally useful only to large ISPs or commercial users. IPF,
|
||||
IPFW and PF use rules to control the access of packets to and
|
||||
<para>&os; has three different firewall packages built
|
||||
into the base system. They are: <emphasis>IPFILTER</emphasis>
|
||||
(also known as <acronym>IPF</acronym>),
|
||||
<emphasis>IPFIREWALL</emphasis> (also known as <acronym>IPFW</acronym>),
|
||||
and <emphasis>OpenBSD's PacketFilter</emphasis> (also known as
|
||||
<acronym>PF</acronym>). &os; also has two built in packages for
|
||||
traffic shaping (basically controlling bandwidth usage):
|
||||
&man.altq.4; and &man.dummynet.4;. Dummynet has traditionally been
|
||||
closely tied with <acronym>IPFW</acronym>, and
|
||||
<acronym>ALTQ</acronym> with
|
||||
<acronym>IPF</acronym>/<acronym>PF</acronym>. IPF,
|
||||
IPFW, and PF all use rules to control the access of packets to and
|
||||
from your system, although they go about it different ways and
|
||||
have different rule syntaxes.</para>
|
||||
|
||||
<!-- XXX: Is rc.firewall really outdated and complicated?
|
||||
AND: should we modify/remove /etc/rc.firewall or rewrite
|
||||
this: -->
|
||||
|
||||
<para>The IPFW sample rule set (found in
|
||||
<filename>/etc/rc.firewall</filename>) delivered in the basic
|
||||
install is outdated, complicated and does not use stateful rules
|
||||
on the interface facing the public Internet. It exclusively uses
|
||||
legacy stateless rules which only have the ability to open or
|
||||
close the service ports. The IPFW example stateful rules sets
|
||||
presented here supercede the
|
||||
<filename>/etc/rc.firewall</filename> file distributed with the
|
||||
system.</para>
|
||||
|
||||
<para>Stateful rules have technically advanced interrogation
|
||||
abilities capable of defending against the flood of different
|
||||
methods currently employed by attackers.</para>
|
||||
|
||||
<para>All of these firewall software solutions IPF, IPFW and PF
|
||||
still maintain their legacy heritage of their original rule
|
||||
processing order and reliance on non-stateful rules. These
|
||||
outdated concepts are not covered here, only the new, modern
|
||||
stateful rule construct and rule processing order is
|
||||
presented.</para>
|
||||
|
||||
<para>You should read about both of them and make your own decision
|
||||
on which one best fits your needs.</para>
|
||||
<para>The reason that &os; has multiple build in firewall packages
|
||||
is that different people have different requirements and
|
||||
preferences. No single firewall package is the best.</para>
|
||||
|
||||
<para>The author prefers IPFILTER because its stateful rules are
|
||||
much less complicated to use in a <acronym>NAT</acronym>
|
||||
environment and it has a built in ftp proxy that simplifies the
|
||||
rules to allow secure outbound FTP usage. It is also more
|
||||
appropriate to the knowledge level of the inexperienced firewall
|
||||
user.</para>
|
||||
rules to allow secure outbound FTP usage.</para>
|
||||
|
||||
<para>Since all firewalls are based on interrogating the values of
|
||||
<para>Since all firewalls are based on inspecting the values of
|
||||
selected packet control fields, the creator of the firewall
|
||||
rules must have an understanding of how
|
||||
rulesets must have an understanding of how
|
||||
<acronym>TCP</acronym>/IP works, what the different values in
|
||||
the packet control fields are and how these values are used in a
|
||||
normal session conversation. For a good explanation go to:
|
||||
|
@ -2104,6 +2080,13 @@ pass in quick on rl0 proto tcp from any to any port = 20 flags S keep state</pro
|
|||
coding technique to achieve what is referred to as Simple
|
||||
Stateful logic.</para>
|
||||
|
||||
<para>The IPFW sample rule set (found in
|
||||
<filename>/etc/rc.firewall</filename>) in the standard &os;
|
||||
install is rather simple and it is not expected that it used
|
||||
directly without modifications. The example does not use
|
||||
stateful filtering, which is beneficial in most setups, so it
|
||||
will not be used as base for this section.</para>
|
||||
|
||||
<para>The IPFW stateless rule syntax is empowered with technically
|
||||
sophisticated selection capabilities which far surpasses the
|
||||
knowledge level of the customary firewall installer. IPFW is
|
||||
|
|
Loading…
Reference in a new issue