forked from extern/shorewall_code
file "releasenotes.xml" is not used anymore so I removed it.
if a problem, feel free to revert this change. git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@2536 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
parent
26aa63f5e4
commit
09b9211dac
@ -70,7 +70,7 @@
|
|||||||
<para>Standard Macros. These actions are released as part of
|
<para>Standard Macros. These actions are released as part of
|
||||||
Shorewall. They are listed in the file
|
Shorewall. They are listed in the file
|
||||||
<filename>/usr/share/shorewall/actions.std</filename> and are defined
|
<filename>/usr/share/shorewall/actions.std</filename> and are defined
|
||||||
in the corresponding action.* files in <filename
|
in the corresponding macros.* files in <filename
|
||||||
class="directory">/usr/share/shorewall</filename>. Each
|
class="directory">/usr/share/shorewall</filename>. Each
|
||||||
<filename>macros.*</filename> file has a comment at the beginning of
|
<filename>macros.*</filename> file has a comment at the beginning of
|
||||||
the file that describes what the action does. As an example, here is
|
the file that describes what the action does. As an example, here is
|
||||||
@ -99,9 +99,9 @@ PARAM - - tcp 135,139,445
|
|||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>User-defined Macros. These actions are created by end-users.
|
<para>User-defined Macros. These macros are created by end-users. They
|
||||||
They are listed in the file /etc/shorewall/actions and are defined in
|
are listed in the file /etc/shorewall/actions and are defined in
|
||||||
action.* files in /etc/shorewall/actions or in another directory
|
macros.* files in /etc/shorewall/actions or in another directory
|
||||||
listed in your CONFIG_PATH (defined in <ulink
|
listed in your CONFIG_PATH (defined in <ulink
|
||||||
url="Documentation.htm#Conf">/etc/shorewall/shorewall.conf</ulink>).</para>
|
url="Documentation.htm#Conf">/etc/shorewall/shorewall.conf</ulink>).</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
@ -157,7 +157,7 @@ Reject:REJECT #Common Action for REJECT policy</programlisting>
|
|||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section>
|
<section>
|
||||||
<title>Defining your own Actions</title>
|
<title>Defining your own Macros</title>
|
||||||
|
|
||||||
<para>To define a new action:</para>
|
<para>To define a new action:</para>
|
||||||
|
|
||||||
|
@ -1,122 +0,0 @@
|
|||||||
<?xml version="1.0" encoding="UTF-8"?>
|
|
||||||
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
|
||||||
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
|
|
||||||
<article>
|
|
||||||
<!--$Id$-->
|
|
||||||
|
|
||||||
<title>Shorewall 1.4.9</title>
|
|
||||||
|
|
||||||
<section>
|
|
||||||
<title>Problems Corrected</title>
|
|
||||||
|
|
||||||
<para>These are the problems corrected since Shorewall 1.4.8</para>
|
|
||||||
|
|
||||||
<orderedlist>
|
|
||||||
<listitem>
|
|
||||||
<para>There has been a low continuing level of confusion over the
|
|
||||||
terms <quote>Source NAT</quote> (SNAT) and <quote>Static NAT</quote>.
|
|
||||||
To avoid future confusion, all instances of <quote>Static NAT</quote>
|
|
||||||
have been replaced with <quote>One-to-one NAT</quote> in the
|
|
||||||
documentation and configuration files.</para>
|
|
||||||
</listitem>
|
|
||||||
|
|
||||||
<listitem>
|
|
||||||
<para>The description of NEWNOTSYN in shorewall.conf has been reworded
|
|
||||||
for clarity.</para>
|
|
||||||
</listitem>
|
|
||||||
|
|
||||||
<listitem>
|
|
||||||
<para>Wild-card rules (those involving <quote>all</quote> as SOURCE or
|
|
||||||
DEST) will no longer produce an error if they attempt to add a rule
|
|
||||||
that would override a NONE policy. The logic for expanding these
|
|
||||||
wild-card rules now simply skips those (SOURCE,DEST) pairs that have a
|
|
||||||
NONE policy.</para>
|
|
||||||
</listitem>
|
|
||||||
</orderedlist>
|
|
||||||
</section>
|
|
||||||
|
|
||||||
<section>
|
|
||||||
<title>Migration Considerations</title>
|
|
||||||
|
|
||||||
<para>None.</para>
|
|
||||||
</section>
|
|
||||||
|
|
||||||
<section>
|
|
||||||
<title>New Features</title>
|
|
||||||
|
|
||||||
<para>These are the new features added since Shorewall 1.4.8</para>
|
|
||||||
|
|
||||||
<orderedlist>
|
|
||||||
<listitem>
|
|
||||||
<para>To cut down on the number of <quote>Why are these ports closed
|
|
||||||
rather than stealthed?</quote> questions, the SMB-related rules in
|
|
||||||
/etc/shorewall/common.def have been changed from <quote>reject</quote>
|
|
||||||
to <quote>DROP</quote>.</para>
|
|
||||||
</listitem>
|
|
||||||
|
|
||||||
<listitem>
|
|
||||||
<para>For easier identification, packets logged under the
|
|
||||||
<quote>norfc1918</quote> interface option are now logged out of chains
|
|
||||||
named <quote>rfc1918</quote>. Previously, such packets were logged
|
|
||||||
under chains named <quote>logdrop</quote>.</para>
|
|
||||||
</listitem>
|
|
||||||
|
|
||||||
<listitem>
|
|
||||||
<para>Distributors and developers seem to be regularly inventing new
|
|
||||||
naming conventions for kernel modules. To avoid the need to change
|
|
||||||
Shorewall code for each new convention, the MODULE_SUFFIX option has
|
|
||||||
been added to shorewall.conf. MODULE_SUFFIX may be set to the suffix
|
|
||||||
for module names in your particular distribution. If MODULE_SUFFIX is
|
|
||||||
not set in shorewall.conf, Shorewall will use the list <quote>o gz ko
|
|
||||||
o.gz</quote>. To see what suffix is used by your distribution:</para>
|
|
||||||
|
|
||||||
<programlisting>ls /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter</programlisting>
|
|
||||||
|
|
||||||
<para>All of the files listed should have the same suffix (extension).
|
|
||||||
Set MODULE_SUFFIX to that suffix. Examples:</para>
|
|
||||||
|
|
||||||
<orderedlist>
|
|
||||||
<listitem>
|
|
||||||
<para>If all files end in <quote>.kzo</quote> then set
|
|
||||||
MODULE_SUFFIX="kzo"</para>
|
|
||||||
</listitem>
|
|
||||||
|
|
||||||
<listitem>
|
|
||||||
<para>If all files end in <quote>.kz.o</quote> then set
|
|
||||||
MODULE_SUFFIX="kz.o"</para>
|
|
||||||
</listitem>
|
|
||||||
</orderedlist>
|
|
||||||
</listitem>
|
|
||||||
|
|
||||||
<listitem>
|
|
||||||
<para>Support for user defined rule ACTIONS has been implemented
|
|
||||||
through two new files: <itemizedlist><listitem><para>/etc/shorewall/actions
|
|
||||||
- used to list the user-defined ACTIONS.</para></listitem><listitem><para>/etc/shorewall/action.template
|
|
||||||
- For each user defined <action>:</para><orderedlist><listitem><para>copy
|
|
||||||
this file to /etc/shorewall/action.<action></para></listitem><listitem><para>Add
|
|
||||||
the appropriate rules in that file for the <action>.</para></listitem></orderedlist></listitem></itemizedlist>Once
|
|
||||||
an <action> has been defined, it may be used like any of the
|
|
||||||
builtin ACTIONS (ACCEPT, DROP, etc.) in /etc/shorewall/rules.</para>
|
|
||||||
|
|
||||||
<para>Example: You want an action that logs a packet at the
|
|
||||||
<quote>info</quote> level and accepts the connection.</para>
|
|
||||||
|
|
||||||
<para>In /etc/shorewall/actions, you would add:</para>
|
|
||||||
|
|
||||||
<simplelist>
|
|
||||||
<member>LogAndAccept</member>
|
|
||||||
</simplelist>
|
|
||||||
|
|
||||||
<para>You would then copy /etc/shorewall/action.template to
|
|
||||||
/etc/shorewall/action.LogAndAccept and in that file, you would add the
|
|
||||||
two rules:</para>
|
|
||||||
|
|
||||||
<simplelist>
|
|
||||||
<member>LOG:info</member>
|
|
||||||
|
|
||||||
<member>ACCEPT</member>
|
|
||||||
</simplelist>
|
|
||||||
</listitem>
|
|
||||||
</orderedlist>
|
|
||||||
</section>
|
|
||||||
</article>
|
|
Loading…
Reference in New Issue
Block a user