"Fossies" - the Fresh Open Source Software Archive  

Source code changes of the file "blacklisting_support.xml" between
shorewall-docs-xml-5.2.3.6.tar.bz2 and shorewall-docs-xml-5.2.6.tar.bz2

About: Shorewall (The Shoreline Firewall) is an iptables based firewall (documentation; XML)

blacklisting_support.xml  (shorewall-docs-xml-5.2.3.6.tar.bz2):blacklisting_support.xml  (shorewall-docs-xml-5.2.6.tar.bz2)
skipping to change at line 253 skipping to change at line 253
<important> <important>
<para>Once the dynamic blacklisting ipset has been created, <para>Once the dynamic blacklisting ipset has been created,
changing this option setting requires a complete restart of the changing this option setting requires a complete restart of the
firewall; <command>shorewall restart</command> if RESTART=restart, firewall; <command>shorewall restart</command> if RESTART=restart,
otherwise <command>shorewall stop &amp;&amp; shorewall otherwise <command>shorewall stop &amp;&amp; shorewall
start</command></para> start</command></para>
</important> </important>
</listitem> </listitem>
</varlistentry> </varlistentry>
<varlistentry>
<term>log</term>
<listitem>
<para>Added in Shorewall 5.2.5. When specified, successful
'blacklist' and 'allow' commands will log a message to the system
log.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>noupdate</term>
<listitem>
<para>Added in Shorewall 5.2.5. Normally, once an address has been
blacklisted, each time that a packet is received from the packet,
the ipset's entry for the address is updated to reset the timeout to
the value specifyed in the <option>timeout</option> option above.
Setting the <option>noupdate</option> option, inhibits this
resetting of the entry's timeout. This option is ignored when the
<option>timeout</option> option is not specified.</para>
</listitem>
</varlistentry>
</variablelist> </variablelist>
<para>When ipset-based dynamic blacklisting is enabled, the contents of <para>When ipset-based dynamic blacklisting is enabled, the contents of
the blacklist will be preserved over the blacklist will be preserved over
<command>stop</command>/<command>reboot</command>/<command>start</command> <command>stop</command>/<command>reboot</command>/<command>start</command>
sequences if SAVE_IPSETS=Yes, SAVE_IPSETS=ipv4 or if sequences.</para>
<replaceable>setname</replaceable> is included in the list of sets to be
saved in SAVE_IPSETS.</para>
</section> </section>
<section> <section>
<title>BLACKLIST Policy and Action</title> <title>BLACKLIST Policy and Action</title>
<para>Beginning with Shorewall 5.1.1, it is possible to specify BLACKLIST <para>Beginning with Shorewall 5.1.1, it is possible to specify BLACKLIST
in the POLICY column of <ulink in the POLICY column of <ulink
url="manpages/shorewall-policy.html">shorewall-policy</ulink>(5) when url="manpages/shorewall-policy.html">shorewall-policy</ulink>(5) when
ipset-based dynamic blacklisting is being used. When a packet is disposed ipset-based dynamic blacklisting is being used. When a packet is disposed
of via the BLACKLIST policy, the packet's sender is added to the dynamic of via the BLACKLIST policy, the packet's sender is added to the dynamic
blacklist ipset and the packet is dropped.</para> blacklist ipset and the packet is dropped.</para>
<para>Also available beginning with Shorewall 5.1.1 is a BLACKLIST action <para>Also available beginning with Shorewall 5.1.1 is a BLACKLIST action
for use in the rules file, macros and filter table actions. Execute the for use in the rules file, macros and filter table actions. Execute the
<command>shorewall show action BLACKLIST</command> command for <command>shorewall show action BLACKLIST</command> command for
details.</para> details.</para>
</section> </section>
<section id="fail2ban">
<title>BLACKLIST and Fail2ban</title>
<para>The BLACKLIST command can be used as 'blocktype' in
/etc/fail2ban/actions.d/shorewall.conf. Prior to Shorewall 5.2.5, this
works best if there is no <emphasis role="bold">timeout</emphasis>
specified in the DYNAMIC_BLACKLIST setting or if <emphasis
role="bold">timeout=0</emphasis> is given.</para>
<para>Beginning with Shorewall 5.2.5, Shorewall includes new features that
allow fail2ban to work most seamlessly with Shorewall's ipset-based
dynamic blacklisting:</para>
<itemizedlist>
<listitem>
<para>When a <emphasis role="bold">timeout</emphasis> is specified in
the DYNAMIC_BLACKLIST setting, the dynamic-blacklisting ipset is
created with default timeout 0. As entries are added by BLACKLIST
policies or by the <emphasis role="bold">blacklist</emphasis> command,
the created entry is given the specified timeout value.</para>
</listitem>
<listitem>
<para>The <emphasis role="bold">noupdate</emphasis> option has been
added. Specifying this option prevents 'timeout 0' ipset entries from
being changed to finite timeout entries as a result of blacklisted ip
addresses continuing to send packets to the firewall.</para>
</listitem>
<listitem>
<para>The <emphasis role="bold">blacklist!</emphasis> command has been
added. specifying that command as the fail2ban 'blocktype' causes
entries created by fail2ban to persist until fail2ban unbans them
using the Shorewall <emphasis role="bold">allow</emphasis>
comand.</para>
</listitem>
</itemizedlist>
<para>There are a couple of additional things to note:</para>
<itemizedlist>
<listitem>
<para>The documentation in /etc/fail2ban/action.d/shorewall.conf
states that you should set BLACKLIST=All. A better approach when using
BLACKLIST as the 'blocktype' is to specify the <emphasis
role="bold">disconnect</emphasis> option in the setting of
DYNAMIC_BLACKLIST. With BLACKLIST=All, every packet entering the
firewall from the net must be checked against the dynamic-blacklisting
ipset. That is not required when you specify <emphasis
role="bold">disconnect</emphasis>.</para>
</listitem>
<listitem>
<para>The <emphasis role="bold">noupdate</emphasis> option allows
fail2ban full control when a host is 'unbanned'. The cost of using
this option is that after the specified <emphasis
role="bold">timeout</emphasis>, the entry for an attacking host will
be removed from the dynamic-blacklisting ipset, even if the host has
continued the attack while blacklisted. This isn't a great concern, as
the first attempt to access an unauthorized service will result in the
host being re-blacklisted.</para>
</listitem>
</itemizedlist>
</section>
</article> </article>
 End of changes. 3 change blocks. 
3 lines changed or deleted 90 lines changed or added

Home  |  About  |  Features  |  All  |  Newest  |  Dox  |  Diffs  |  RSS Feeds  |  Screenshots  |  Comments  |  Imprint  |  Privacy  |  HTTP(S)