forked from extern/shorewall_code
Punctuation Consistancy layer-2 vs. layer 2
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@5252 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
parent
8fc7dfe2d7
commit
b24efabfe7
@ -45,7 +45,7 @@
|
||||
/etc/shorewall/accounting. By default, the accounting rules are placed in a
|
||||
chain called <quote>accounting</quote> and can thus be displayed using
|
||||
<quote>shorewall[-lite] show accounting</quote>. All traffic passing into,
|
||||
out of or through the firewall traverses the accounting chain including
|
||||
out of, or through the firewall traverses the accounting chain including
|
||||
traffic that will later be rejected by interface options such as
|
||||
<quote>tcpflags</quote> and <quote>maclist</quote>. If your kernel doesn't
|
||||
support the connection tracking match extension (Kernel 2.4.21) then some
|
||||
@ -78,7 +78,7 @@
|
||||
Chain names must start with a letter, must be composed of letters
|
||||
and digits, and may contain underscores (<quote>_</quote>) and
|
||||
periods (<quote>.</quote>). Beginning with Shorewall version 1.4.8,
|
||||
chain names man also contain embedded dashes (<quote>-</quote>) and
|
||||
chain names may also contain embedded dashes (<quote>-</quote>) and
|
||||
are not required to start with a letter.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
@ -92,7 +92,7 @@
|
||||
|
||||
<listitem>
|
||||
<para><emphasis role="bold">SOURCE</emphasis> - Packet Source. The name
|
||||
of an interface, an address (host or net) or an interface name followed
|
||||
of an interface, an address (host or net), or an interface name followed
|
||||
by <quote>:</quote> and a host or net address.</para>
|
||||
</listitem>
|
||||
|
||||
@ -164,8 +164,8 @@
|
||||
outbound ones.</para>
|
||||
|
||||
<para>Accounting rules are not stateful -- each rule only handles traffic in
|
||||
one direction. For example, if eth0 is your internet interface and you have
|
||||
a web server in your DMZ connected to eth1 then to count HTTP traffic in
|
||||
one direction. For example, if eth0 is your internet interface, and you have
|
||||
a web server in your DMZ connected to eth1, then to count HTTP traffic in
|
||||
both directions requires two rules:</para>
|
||||
|
||||
<programlisting> #ACTION CHAIN SOURCE DESTINATION PROTOCOL DEST SOURCE
|
||||
|
@ -47,7 +47,7 @@
|
||||
series of one or more iptables rules. The symbolic name may appear in the
|
||||
ACTION column of an <filename><ulink
|
||||
url="Documentation.htm#Rules">/etc/shorewall/rules</ulink></filename> file
|
||||
entry in which case, the traffic matching that rules file entry will be
|
||||
entry, in which case the traffic matching that rules file entry will be
|
||||
passed to the series of iptables rules named by the action.</para>
|
||||
|
||||
<para>Actions can be thought of as templates. When an action is invoked in
|
||||
@ -290,7 +290,7 @@ Reject:REJECT #Default Action for REJECT policy</programlisting>
|
||||
|
||||
<listitem>
|
||||
<para>PROTO - Protocol - Must be <quote>tcp</quote>,
|
||||
<quote>udp</quote>, <quote>icmp</quote>, a number, or
|
||||
<quote>udp</quote>, <quote>icmp</quote>, a protocol number, or
|
||||
<quote>all</quote>.</para>
|
||||
</listitem>
|
||||
|
||||
@ -303,7 +303,7 @@ Reject:REJECT #Default Action for REJECT policy</programlisting>
|
||||
<para>A port range is expressed as <<emphasis>low
|
||||
port</emphasis>>:<<emphasis>high port</emphasis>>.</para>
|
||||
|
||||
<para>This column is ignored if PROTOCOL = all but must be entered if
|
||||
<para>This column is ignored if PROTO = "all", but must be entered if
|
||||
any of the following fields are supplied. In that case, it is
|
||||
suggested that this field contain <quote>-</quote>.</para>
|
||||
|
||||
@ -331,7 +331,7 @@ Reject:REJECT #Default Action for REJECT policy</programlisting>
|
||||
names, port numbers or port ranges.</para>
|
||||
|
||||
<para>If you don't want to restrict client ports but need to specify
|
||||
an ADDRESS in the next column, then place "-" in this column.</para>
|
||||
any of the following fields, then place "-" in this column.</para>
|
||||
|
||||
<para>If your kernel contains multi-port match support, then only a
|
||||
single Netfilter rule will be generated if in this list and in the
|
||||
@ -403,7 +403,7 @@ Reject:REJECT #Default Action for REJECT policy</programlisting>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>Omitted column entries should be entered using a dash ("-:).</para>
|
||||
<para>Omitted column entries should be entered using a dash ("-").</para>
|
||||
|
||||
<para>Example:</para>
|
||||
|
||||
@ -422,7 +422,7 @@ LogAndAccept loc $FW tcp 22</programlisting>
|
||||
<section>
|
||||
<title>Actions and Logging</title>
|
||||
|
||||
<para>Specifying a log level in a rule that specifies a user- or
|
||||
<para>Specifying a log level in a rule that specifies a user-defined or
|
||||
Shorewall-defined action will cause each rule in the action to be logged
|
||||
with the specified level (and tag).</para>
|
||||
|
||||
@ -457,7 +457,7 @@ bar:info</programlisting>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>If you follow the log level with "!" then logging will be at
|
||||
<para>If you follow the log level with "!" then logging will be set at
|
||||
that level for all rules recursively invoked by the action.</para>
|
||||
|
||||
<para>Example:</para>
|
||||
|
@ -57,7 +57,7 @@
|
||||
<firstterm>routers</firstterm>. In the context of the Open System
|
||||
Interconnect (OSI) reference model, a router operates at layer 3,
|
||||
Shorewall may also be deployed on a GNU Linux System that acts as a
|
||||
<firstterm>bridge</firstterm>. Bridges are layer-2 devices in the OSI
|
||||
<firstterm>bridge</firstterm>. Bridges are layer 2 devices in the OSI
|
||||
model (think of a bridge as an ethernet switch).</para>
|
||||
|
||||
<para>Some differences between routers and bridges are:</para>
|
||||
@ -65,7 +65,7 @@
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>Routers determine packet destination based on the destination IP
|
||||
address while bridges route traffic based on the destination MAC
|
||||
address, while bridges route traffic based on the destination MAC
|
||||
address in the ethernet frame.</para>
|
||||
</listitem>
|
||||
|
||||
@ -120,8 +120,8 @@
|
||||
|
||||
<para>The following diagram shows a typical application of a
|
||||
bridge/firewall. There is already an existing router in place whose
|
||||
internal interface supports a network and you want to insert a firewall
|
||||
between the router and the systems in the local network. In the example
|
||||
internal interface supports a network, and you want to insert a firewall
|
||||
between the router, and the systems in the local network. In the example
|
||||
shown, the network uses RFC 1918 addresses but that is not a requirement;
|
||||
the bridge would work exactly the same if public IP addresses were used
|
||||
(remember that the bridge doesn't deal with IP addresses).</para>
|
||||
@ -135,7 +135,7 @@
|
||||
<listitem>
|
||||
<para>The Shorewall system (the Bridge/Firewall) has only a single IP
|
||||
address even though it has two ethernet interfaces! The IP address is
|
||||
configured on the bridge itself rather than on either of the network
|
||||
configured on the bridge itself, rather than on either of the network
|
||||
cards.</para>
|
||||
</listitem>
|
||||
|
||||
@ -184,7 +184,7 @@
|
||||
url="http://bridge.sf.net">http://bridge.sf.net</ulink>.</para>
|
||||
|
||||
<para>Unfortunately, many Linux distributions don't have good bridge
|
||||
configuration tools and the network configuration GUIs don't detect the
|
||||
configuration tools, and the network configuration GUIs don't detect the
|
||||
presence of bridge devices. Here is an excerpt from a Debian
|
||||
<filename>/etc/network/interfaces</filename> file for a two-port bridge
|
||||
with a static IP address:</para>
|
||||
@ -332,8 +332,8 @@ exit 0</programlisting></para>
|
||||
|
||||
<para>Axel Westerhold has contributed this example of configuring a bridge
|
||||
with a static IP address on a Fedora System (Core 1 and Core 2 Test 1).
|
||||
Note that these files also configure the bridge itself so there is no need
|
||||
for a separate bridge config script.</para>
|
||||
Note that these files also configure the bridge itself, so there is no
|
||||
need for a separate bridge config script.</para>
|
||||
|
||||
<blockquote>
|
||||
<para><filename>/etc/sysconfig/network-scripts/ifcfg-br0:</filename></para>
|
||||
@ -495,8 +495,8 @@ rc-update add bridge boot
|
||||
|
||||
<para>In the scenario pictured above (where the hosts 192.168.1.10 and
|
||||
192.168.1.11 are on the 'net' side of the bridge), there would probably be
|
||||
two zones defined -- one for the internet and one for the local LAN so in
|
||||
<filename>/etc/shorewall/zones</filename>:</para>
|
||||
two zones defined -- one for the internet, and one for the local LAN; so
|
||||
in <filename>/etc/shorewall/zones</filename>:</para>
|
||||
|
||||
<programlisting>#ZONE TYPE OPTIONS
|
||||
fw firewall
|
||||
@ -516,7 +516,7 @@ net all DROP info
|
||||
all all REJECT info
|
||||
#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE</programlisting>
|
||||
|
||||
<para>Only the bridge device itself is configured with an IP address so
|
||||
<para>Only the bridge device itself is configured with an IP address, so
|
||||
only that device is defined to Shorewall in
|
||||
<filename>/etc/shorewall/interfaces</filename>:</para>
|
||||
|
||||
|
@ -68,7 +68,7 @@
|
||||
appropriate for blacklisting 1,000s of different addresses. Static
|
||||
Blacklisting can handle large blacklists but only if you use
|
||||
ipsets</emphasis>. Without ipsets, the blacklists will take forever to
|
||||
load and will have a very negative effect on firewall
|
||||
load, and will have a very negative effect on firewall
|
||||
performance.</para>
|
||||
</important>
|
||||
</section>
|
||||
@ -136,7 +136,7 @@
|
||||
|
||||
<para>In this example, there is a portmap ipset
|
||||
<emphasis>Blacklistports</emphasis> that blacklists all traffic with
|
||||
destination ports included in the ipsec. There are also
|
||||
destination ports included in the ipset. There are also
|
||||
<emphasis>Blacklistnets</emphasis> (type <emphasis>nethash</emphasis>) and
|
||||
<emphasis>Blacklist</emphasis> (type <emphasis>iphash</emphasis>) ipsets
|
||||
that allow blacklisting networks and individual IP addresses. Note that
|
||||
|
@ -52,7 +52,7 @@
|
||||
<firstterm>routers</firstterm>. In the context of the Open System
|
||||
Interconnect (OSI) reference model, a router operates at layer 3,
|
||||
Shorewall may also be deployed on a GNU Linux System that acts as a
|
||||
<firstterm>bridge</firstterm>. Bridges are layer-2 devices in the OSI
|
||||
<firstterm>bridge</firstterm>. Bridges are layer 2 devices in the OSI
|
||||
model (think of a bridge as an ethernet switch).</para>
|
||||
|
||||
<para>Some differences between routers and bridges are:</para>
|
||||
@ -60,7 +60,7 @@
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>Routers determine packet destination based on the destination IP
|
||||
address while bridges route traffic based on the destination MAC
|
||||
address, while bridges route traffic based on the destination MAC
|
||||
address in the ethernet frame.</para>
|
||||
</listitem>
|
||||
|
||||
@ -143,8 +143,8 @@
|
||||
|
||||
<para>The following diagram shows a typical application of a
|
||||
bridge/firewall. There is already an existing router in place whose
|
||||
internal interface supports a network and you want to insert a firewall
|
||||
between the router and the systems in the local network. In the example
|
||||
internal interface supports a network, and you want to insert a firewall
|
||||
between the router, and the systems in the local network. In the example
|
||||
shown, the network uses RFC 1918 addresses but that is not a requirement;
|
||||
the bridge would work exactly the same if public IP addresses were used
|
||||
(remember that the bridge doesn't deal with IP addresses).</para>
|
||||
@ -158,7 +158,7 @@
|
||||
<listitem>
|
||||
<para>The Shorewall system (the Bridge/Firewall) has only a single IP
|
||||
address even though it has two ethernet interfaces! The IP address is
|
||||
configured on the bridge itself rather than on either of the network
|
||||
configured on the bridge itself, rather than on either of the network
|
||||
cards.</para>
|
||||
</listitem>
|
||||
|
||||
@ -207,7 +207,7 @@
|
||||
url="http://bridge.sf.net">http://bridge.sf.net</ulink>.</para>
|
||||
|
||||
<para>Unfortunately, many Linux distributions don't have good bridge
|
||||
configuration tools and the network configuration GUIs don't detect the
|
||||
configuration tools, and the network configuration GUIs don't detect the
|
||||
presence of bridge devices. Here is an excerpt from a Debian
|
||||
<filename>/etc/network/interfaces</filename> file for a two-port bridge
|
||||
with a static IP address:</para>
|
||||
@ -356,8 +356,8 @@ exit 0</programlisting></para>
|
||||
|
||||
<para>Axel Westerhold has contributed this example of configuring a bridge
|
||||
with a static IP address on a Fedora System (Core 1 and Core 2 Test 1).
|
||||
Note that these files also configure the bridge itself so there is no need
|
||||
for a separate bridge config script.</para>
|
||||
Note that these files also configure the bridge itself, so there is no
|
||||
need for a separate bridge config script.</para>
|
||||
|
||||
<blockquote>
|
||||
<para><filename>/etc/sysconfig/network-scripts/ifcfg-br0:</filename></para>
|
||||
@ -536,7 +536,7 @@ net all DROP info
|
||||
all all REJECT info
|
||||
#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE</programlisting>
|
||||
|
||||
<para>Only the bridge device itself is configured with an IP address so
|
||||
<para>Only the bridge device itself is configured with an IP address, so
|
||||
only that device is defined to Shorewall in
|
||||
<filename>/etc/shorewall/interfaces</filename>:</para>
|
||||
|
||||
@ -571,8 +571,8 @@ br0 192.168.1.0/24 routeback
|
||||
<title>Combination Router/Bridge</title>
|
||||
|
||||
<para>A system running Shorewall doesn't have to be exclusively a bridge
|
||||
or a router -- it can act as both. Here's an example:<graphic
|
||||
fileref="images/bridge2.png" /></para>
|
||||
or a router -- it can act as both, which is also know as a brouter. Here's
|
||||
an example:<graphic fileref="images/bridge2.png" /></para>
|
||||
|
||||
<para>This is basically the same setup as shown in the <ulink
|
||||
url="shorewall_setup_guide.htm">Shorewall Setup Guide</ulink> with the
|
||||
|
Loading…
Reference in New Issue
Block a user