mirror of
https://gitlab.com/shorewall/code.git
synced 2025-02-22 20:51:15 +01:00
Shorewall 2.2.0-RC5
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@1903 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep
parent
0ecbc812ff
commit
ebe6ff9749
@ -1,11 +1,11 @@
|
||||
#
|
||||
# Shorewall 2.2 /usr/share/shorewall/action.AllowTrcrt
|
||||
#
|
||||
# This action accepts Traceroute (for up to 20 hops):
|
||||
# This action accepts Traceroute (for up to 30 hops):
|
||||
#
|
||||
######################################################################################
|
||||
#TARGET SOURCE DEST PROTO DEST SOURCE RATE USER/
|
||||
# PORT PORT(S) LIMIT GROUP
|
||||
ACCEPT - - udp 33434:33454 #UDP Traceroute
|
||||
ACCEPT - - udp 33434:33524 #UDP Traceroute
|
||||
ACCEPT - - icmp 8 #ICMP Traceroute
|
||||
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
|
||||
|
||||
@ -10,6 +10,8 @@
|
||||
# rejNonSyn #Silently Reject Non-syn TCP packets
|
||||
# dropInvalid #Silently Drop packets that are in the INVALID
|
||||
# #conntrack state.
|
||||
# allowInvalid #Accept packets that are in the INVALID
|
||||
# #conntrack state.
|
||||
#
|
||||
# The NonSyn logging builtins log at the level specified by LOGNEWNOTSYN in
|
||||
# shorewall.conf. If that option isn't specified then 'info' is used.
|
||||
|
||||
@ -2270,7 +2270,7 @@ setup_netmap() {
|
||||
setup_ecn() # $1 = file name
|
||||
{
|
||||
local interfaces=""
|
||||
local hosts
|
||||
local hosts=
|
||||
local h
|
||||
|
||||
strip_file ecn $1
|
||||
@ -3404,7 +3404,7 @@ merge_levels() # $1=level at which superior action is called, $2=level at which
|
||||
#
|
||||
process_actions1() {
|
||||
|
||||
ACTIONS="dropBcast allowBcast dropNonSyn dropNotSyn rejNotSyn dropInvalid"
|
||||
ACTIONS="dropBcast allowBcast dropNonSyn dropNotSyn rejNotSyn dropInvalid allowInvalid"
|
||||
USEDACTIONS=
|
||||
|
||||
strip_file actions
|
||||
@ -3619,6 +3619,13 @@ process_actions3() {
|
||||
run_iptables -A $xchain -m state --state INVALID -j DROP
|
||||
fi
|
||||
;;
|
||||
allowInvalid)
|
||||
if [ "$COMMAND" != check ]; then
|
||||
[ -n "$xlevel" ] && \
|
||||
log_rule_limit ${xlevel%\!} $xchain allowInvalid $2 "" "$xtag" -A -m state --state INVALID
|
||||
run_iptables -A $xchain -m state --state INVALID -j ACCEPT
|
||||
fi
|
||||
;;
|
||||
*)
|
||||
#
|
||||
# Not a builtin
|
||||
|
||||
@ -1 +1 @@
|
||||
2.2.0-RC4
|
||||
2.2.0-RC5
|
||||
|
||||
@ -15,13 +15,15 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2003-08-25</pubdate>
|
||||
<pubdate>2005-01-14</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2003</year>
|
||||
|
||||
<year>2004</year>
|
||||
|
||||
<year>2005</year>
|
||||
|
||||
<holder>Thomas M. Eastep</holder>
|
||||
</copyright>
|
||||
|
||||
@ -52,6 +54,11 @@
|
||||
<para><ulink url="bridge.html">Bridge/Firewall</ulink> Support
|
||||
(physdev match support).</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><ulink url="traffic_shaping.htm">CLASSIFY</ulink> Target
|
||||
Support.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</section>
|
||||
|
||||
@ -61,12 +68,11 @@
|
||||
<para>The 2.6 Linux kernel introduces a new implementation of IPSEC which
|
||||
eliminates the <filename class="devicefile">ipsecN</filename> device
|
||||
names. Netfilter/iptables support for this new implementation is
|
||||
incomplete and therefore Shorewall support is limited. See the <ulink
|
||||
url="IPSEC.htm">Shorewall IPSEC documentation</ulink>.</para>
|
||||
|
||||
<para><emphasis role="bold">Update:</emphasis> The Shorewall 2.1 <ulink
|
||||
url="ReleaseModel.html">Development release</ulink> now contains support
|
||||
for IPSEC under the 2.6 Kernel. See the <ulink url="IPSEC-2.6.html">Kernel
|
||||
2.6 IPSEC documentation</ulink> for details.</para>
|
||||
incomplete unless your kernel has been patched. For unpatched kernels, see
|
||||
the <ulink url="IPSEC.htm">Shorewall IPSEC documentation</ulink>
|
||||
(Shorewall support for IPSEC with unpatched 2.6 kernels is very limited).
|
||||
For patched 2.6 kernels (including those supplied with
|
||||
<trademark>SuSE</trademark> 9.2) see the <ulink
|
||||
url="IPSEC-2.6.html">Kernel 2.6 IPSEC documentation</ulink>.</para>
|
||||
</section>
|
||||
</article>
|
||||
@ -15,13 +15,15 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2004-09-17</pubdate>
|
||||
<pubdate>2005-01-14</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2003</year>
|
||||
|
||||
<year>2004</year>
|
||||
|
||||
<year>2005</year>
|
||||
|
||||
<holder>Thomas M. Eastep</holder>
|
||||
</copyright>
|
||||
|
||||
@ -371,13 +373,9 @@ acton:info:test fw net</programlisting>
|
||||
<title>Standard Actions In Shorewall 2.0</title>
|
||||
|
||||
<para>Beginning with Shorewall 2.0.0-Beta1, Shorewall includes a number of
|
||||
defined actions. These defined actions are listed in
|
||||
pre-defined actions. These defined actions are listed in
|
||||
<filename>/usr/share/shorewall/actions.std</filename>.</para>
|
||||
|
||||
<para>The <filename>/usr/share/shorewall/actions.std</filename> file
|
||||
includes the common actions <quote>Drop</quote> for DROP policies and
|
||||
<quote>Reject</quote> for REJECT policies.</para>
|
||||
|
||||
<example>
|
||||
<title>Example of Using a Standard Action</title>
|
||||
|
||||
@ -404,9 +402,61 @@ AllowFTP loc fw</programlisting>
|
||||
<filename>Action.Reject</filename> to <filename
|
||||
class="directory">/etc/shorewall</filename> and modify that copy as
|
||||
desired.</para>
|
||||
|
||||
<note>
|
||||
<para>Some of the standard actions are <firstterm>built-in</firstterm>s.
|
||||
This means that there is no corresponding action.* file and that
|
||||
Shorewall constructs the rules for the actions using direct
|
||||
<command>iptables</command> commands. If you need to modify one of these
|
||||
built-in actions, you will need to use the <link
|
||||
linkend="Extension">Extension Script mechanism</link> described below
|
||||
and you will need to give the action a different name.</para>
|
||||
</note>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<section id="Common">
|
||||
<title>Common Actions</title>
|
||||
|
||||
<para>Also beginning with Shorewall version 2.2.0-Beta1, when an ACCEPT,
|
||||
DROP or REJECT policy is about to be enforced, a <firstterm>common
|
||||
action</firstterm> can first be invoked. In /etc/shorewall/actions.std are
|
||||
found these two entries:</para>
|
||||
|
||||
<programlisting>Drop:DROP #Common Action for DROP policy
|
||||
Reject:REJECT #Common Action for REJECT policy</programlisting>
|
||||
|
||||
<para>These entries designate the action named <firstterm>Drop</firstterm>
|
||||
as the common action for DROP policies and the common action
|
||||
<firstterm>Reject</firstterm> as the common action for REJECT policies.
|
||||
</para>
|
||||
|
||||
<para>The purpose of common actions is:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>To avoid filling your log with useless clutter. For example, one
|
||||
of the things that the Drop action does is to silently drop SMB
|
||||
traffic by invoking the <firstterm>DropSMB</firstterm> action. </para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>To ensure proper behavior. For example, both the Drop and Reject
|
||||
actions invoke the <firstterm>RejectAuth</firstterm> action to REJECT
|
||||
connection requests on TCP port 113. If these requests are simply
|
||||
dropped, connection timeouts can occur when you connect to a server
|
||||
that uses AUTH identification.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>It should be stressed that <emphasis role="bold">the common actions
|
||||
do not cause any traffic to be dropped or rejected that isn't about to be
|
||||
dropped or rejected anyway</emphasis> (remember that these actions are
|
||||
invoked just before the connection request is going to be dropped or
|
||||
rejected by policy anyway). Their main function is to avoid log
|
||||
clutter.</para>
|
||||
</section>
|
||||
|
||||
<section id="Extension">
|
||||
<title> Creating an Action using an Extension Script</title>
|
||||
|
||||
<para>There may be cases where you wish to create a chain with rules that
|
||||
|
||||
Binary file not shown.
Binary file not shown.
File diff suppressed because one or more lines are too long
Binary file not shown.
File diff suppressed because one or more lines are too long
@ -15,7 +15,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2005-01-06</pubdate>
|
||||
<pubdate>2005-01-12</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2001-2005</year>
|
||||
@ -72,7 +72,7 @@
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>I use one-to-one NAT for EastepLaptop (My work system -- Windows
|
||||
<para>I use one-to-one NAT for Eastepnc6000 (My work system -- Windows
|
||||
XP SP1). Internal address 192.168.1.7 and external address
|
||||
206.124.146.180.</para>
|
||||
</listitem>
|
||||
@ -151,13 +151,10 @@
|
||||
/etc/network/interfaces file (see below) adds a host route to
|
||||
206.124.146.177 through eth1 when that interface is brought up.</para>
|
||||
|
||||
<para>Tarry (192.168.1.4) runs a PPTP server for Road Warrior access from
|
||||
my work laptop and Ursa (206.124.146.178/192.168.1.5) is configured with
|
||||
OpenVPN for VPN access from our second home in <ulink
|
||||
<para>Ursa (206.124.146.178/192.168.1.5) is configured with OpenVPN for
|
||||
VPN access from our second home in <ulink
|
||||
url="http://www.omakchamber.com/">Omak, Washington</ulink> or when we are
|
||||
otherwise out of town. I have a new work laptop that is not yet in
|
||||
service; when it is, I will install OpenVPN on it as well and use OpenVPN
|
||||
exclusively for remote access.</para>
|
||||
otherwise out of town.</para>
|
||||
|
||||
<para><graphic align="center" fileref="images/network.png" /></para>
|
||||
</section>
|
||||
|
||||
@ -15,13 +15,15 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2004-02-08</pubdate>
|
||||
<pubdate>2005-01-14</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2002</year>
|
||||
|
||||
<year>2004</year>
|
||||
|
||||
<year>2005</year>
|
||||
|
||||
<holder>Thomas M. Eastep</holder>
|
||||
</copyright>
|
||||
|
||||
@ -31,7 +33,8 @@
|
||||
1.2 or any later version published by the Free Software Foundation; with
|
||||
no Invariant Sections, with no Front-Cover, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled
|
||||
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation License</ulink></quote>.</para>
|
||||
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation
|
||||
License</ulink></quote>.</para>
|
||||
</legalnotice>
|
||||
</articleinfo>
|
||||
|
||||
@ -47,6 +50,15 @@ ACCEPT loc fw udp 137:139
|
||||
ACCEPT loc fw tcp 137,139,445
|
||||
ACCEPT loc fw udp 1024: 137</programlisting></para>
|
||||
|
||||
<para>Users running Shorewall 2.0.0 or later may simpify the above through
|
||||
use of the <firstterm>AllowSMB</firstterm> <ulink
|
||||
url="User_defined_Actions.html">action</ulink>:</para>
|
||||
|
||||
<programlisting>#ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE
|
||||
# PORT(S)
|
||||
AllowSMB fw loc
|
||||
AllowSMB loc fw</programlisting>
|
||||
|
||||
<para>To pass traffic SMB/Samba traffic between zones Z1 and Z2:</para>
|
||||
|
||||
<para><emphasis role="bold">/etc/shorewall/rules:</emphasis><programlisting>#ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE
|
||||
@ -58,8 +70,16 @@ ACCEPT Z2 Z1 udp 137:139
|
||||
ACCEPT Z2 Z1 tcp 137,139,445
|
||||
ACCEPT Z1 Z1 udp 1024: 137</programlisting></para>
|
||||
|
||||
<para>Again, users running 2.0.0 or later may write:</para>
|
||||
|
||||
<programlisting>#ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE
|
||||
# PORT(S)
|
||||
AllowSMB Z1 Z2
|
||||
AllowSMB Z2 Z1</programlisting>
|
||||
|
||||
<para>To make network browsing (<quote>Network Neighborhood</quote>) work
|
||||
properly between Z1 and Z2 requires a Windows Domain Controller and/or a
|
||||
WINS server. I run Samba on my firewall to handle browsing between two zones
|
||||
connected to my firewall. Details are <ulink url="myfiles.htm">here</ulink>.</para>
|
||||
connected to my firewall. Details are <ulink
|
||||
url="myfiles.htm">here</ulink>.</para>
|
||||
</article>
|
||||
@ -15,10 +15,10 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2004-11-24</pubdate>
|
||||
<pubdate>2005-01-14</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2001-2004</year>
|
||||
<year>2001-2005</year>
|
||||
|
||||
<holder>Thomas M. Eastep</holder>
|
||||
</copyright>
|
||||
@ -252,7 +252,8 @@
|
||||
|
||||
<member>- prio</member>
|
||||
</simplelist>Classification always occurs in the POSTROUTING
|
||||
chain.</para>
|
||||
chain. This feature requires Shorewall 2.2.0 and requires that
|
||||
your kernel and iptables include CLASSIFY target support.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user