White space fix only. Translators can ignore.
Sponsored by: iXsystems
This commit is contained in:
Dru Lavigne
parent
917364f5d4
commit
a4bb242dc7
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=43994
1 changed files with 177 additions and 171 deletions
|
|
@ -435,11 +435,11 @@ device pfsync</programlisting>
|
|||
</tip>
|
||||
|
||||
<para>To keep an eye on the traffic that passes through the
|
||||
<application>PF</application> firewall, consider installing the
|
||||
<package>sysutils/pftop</package> package or port. Once installed,
|
||||
<application>pftop</application> can be run to view
|
||||
a running snapshot of traffic in a format which is
|
||||
similar to &man.top.1;.</para>
|
||||
<application>PF</application> firewall, consider installing
|
||||
the <package>sysutils/pftop</package> package or port. Once
|
||||
installed, <application>pftop</application> can be run to
|
||||
view a running snapshot of traffic in a format which is
|
||||
similar to &man.top.1;.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
|
|
@ -1186,27 +1186,29 @@ pass inet proto tcp from any to $localnet port $tcp_services \
|
|||
<application>spamd</application> daemon which comes bundled
|
||||
with <application>spamassassin</application>,
|
||||
<package>mail/spamd/</package> can be configured with
|
||||
<application>PF</application> to provide an outer defense against <acronym>SPAM</acronym>.
|
||||
This <application>spamd</application> hooks into the
|
||||
<application>PF</application> to provide an outer defense
|
||||
against <acronym>SPAM</acronym>. This
|
||||
<application>spamd</application> hooks into the
|
||||
<application>PF</application> configuration using a set of
|
||||
redirections.</para>
|
||||
|
||||
<para>Spammers tend to send a large number of messages, and
|
||||
<acronym>SPAM</acronym> is mainly sent from a few spammer friendly networks
|
||||
and a large number of hijacked machines, both of which
|
||||
are reported to
|
||||
<para>Spammers tend to send a large number of messages, and
|
||||
<acronym>SPAM</acronym> is mainly sent from a few spammer
|
||||
friendly networks and a large number of hijacked machines,
|
||||
both of which are reported to
|
||||
<firstterm>blacklists</firstterm> fairly quickly.</para>
|
||||
|
||||
<para>When an <acronym>SMTP</acronym>
|
||||
connection from an address in a blacklist is received,
|
||||
<application>spamd</application>
|
||||
presents its banner and immediately switches to a mode
|
||||
where it answers <acronym>SMTP</acronym> traffic one byte at a time. This
|
||||
<para>When an <acronym>SMTP</acronym> connection from an
|
||||
address in a blacklist is received,
|
||||
<application>spamd</application> presents its banner and
|
||||
immediately switches to a mode where it answers
|
||||
<acronym>SMTP</acronym> traffic one byte at a time. This
|
||||
technique, which is intended to waste as much time as
|
||||
possible on the spammer's end, is called
|
||||
<firstterm>tarpitting</firstterm>. The specific
|
||||
implementation which uses one byte <acronym>SMTP</acronym> replies is often
|
||||
referred to as <firstterm>stuttering</firstterm>.</para>
|
||||
implementation which uses one byte <acronym>SMTP</acronym>
|
||||
replies is often referred to as
|
||||
<firstterm>stuttering</firstterm>.</para>
|
||||
|
||||
<para>This example demonstrates the basic procedure for
|
||||
setting up <application>spamd</application> with
|
||||
|
|
@ -1218,12 +1220,12 @@ pass inet proto tcp from any to $localnet port $tcp_services \
|
|||
<title>Configuring <application>spamd</application></title>
|
||||
|
||||
<step>
|
||||
<para>Install the <package>mail/spamd/</package> package or port.
|
||||
In order to use
|
||||
<para>Install the <package>mail/spamd/</package> package
|
||||
or port. In order to use
|
||||
<application>spamd</application>'s greylisting
|
||||
features, &man.fdescfs.5;
|
||||
must be mounted at <filename class="directory">/dev/fd</filename>.
|
||||
Add the following line to
|
||||
features, &man.fdescfs.5; must be mounted at <filename
|
||||
class="directory">/dev/fd</filename>. Add the
|
||||
following line to
|
||||
<filename>/etc/fstab</filename>:</para>
|
||||
|
||||
<programlisting> fdescfs /dev/fd fdescfs rw 0 0</programlisting>
|
||||
|
|
@ -1231,11 +1233,11 @@ pass inet proto tcp from any to $localnet port $tcp_services \
|
|||
<para>Then, mount the filesystem:</para>
|
||||
|
||||
<programlisting>&prompt.root; mount fdescfs</programlisting>
|
||||
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>Next, edit the <application>PF</application> ruleset to include:</para>
|
||||
<para>Next, edit the <application>PF</application> ruleset
|
||||
to include:</para>
|
||||
|
||||
<programlisting>table <spamd> persist
|
||||
table <spamd-white> persist
|
||||
|
|
@ -1245,43 +1247,45 @@ rdr pass on $ext_if inet proto tcp from !<spamd-white> to \
|
|||
{ $ext_if, $localnet } port smtp -> 127.0.0.1 port 8025</programlisting>
|
||||
|
||||
<para>The two tables <literal><spamd></literal> and
|
||||
<literal><spamd-white></literal> are essential. <acronym>SMTP</acronym> traffic
|
||||
from an address listed in<literal> <spamd></literal> but not in
|
||||
<literal><spamd-white></literal> is redirected to the <application>spamd</application>
|
||||
daemon listening at port 8025.</para>
|
||||
<literal><spamd-white></literal> are essential.
|
||||
<acronym>SMTP</acronym> traffic from an address listed
|
||||
in<literal> <spamd></literal> but not in
|
||||
<literal><spamd-white></literal> is redirected to
|
||||
the <application>spamd</application> daemon listening at
|
||||
port 8025.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>The next step is to configure
|
||||
<application>spamd</application>
|
||||
in <filename>/usr/local/etc/spamd.conf</filename> and to
|
||||
add some <filename>rc.conf</filename>
|
||||
parameters.</para>
|
||||
<application>spamd</application> in
|
||||
<filename>/usr/local/etc/spamd.conf</filename> and to
|
||||
add some <filename>rc.conf</filename> parameters.</para>
|
||||
|
||||
<para>The installation of <package>mail/spamd/</package>
|
||||
includes a sample configuration file
|
||||
(<filename>/usr/local/etc/spamd.conf.sample</filename>) and a
|
||||
man page for <filename>spamd.conf</filename>. Refer to
|
||||
these for additional configuration options beyond those
|
||||
shown in this example.</para>
|
||||
(<filename>/usr/local/etc/spamd.conf.sample</filename>)
|
||||
and a man page for <filename>spamd.conf</filename>.
|
||||
Refer to these for additional configuration options
|
||||
beyond those shown in this example.</para>
|
||||
|
||||
<para>One of the first lines in the configuration file that does not begin with a
|
||||
<literal>#</literal> comment sign
|
||||
contains the block which defines the
|
||||
<literal>all</literal> list, which specifies the
|
||||
lists to use:</para>
|
||||
<para>One of the first lines in the configuration file
|
||||
that does not begin with a <literal>#</literal> comment
|
||||
sign contains the block which defines the
|
||||
<literal>all</literal> list, which specifies the lists
|
||||
to use:</para>
|
||||
|
||||
<programlisting>all:\
|
||||
:traplist:whitelist:</programlisting>
|
||||
|
||||
<para>This entry adds the desired blacklists,
|
||||
separated by colons (<literal>:</literal>). To use a
|
||||
whitelist to subtract addresses from a blacklist,
|
||||
add the name of the whitelist <emphasis>immediately</emphasis> after the
|
||||
<para>This entry adds the desired blacklists, separated by
|
||||
colons (<literal>:</literal>). To use a whitelist to
|
||||
subtract addresses from a blacklist, add the name of the
|
||||
whitelist <emphasis>immediately</emphasis> after the
|
||||
name of that blacklist. For example:
|
||||
<literal>:blacklist:whitelist:</literal>.</para>
|
||||
|
||||
<para>This is followed by the specified blacklist's definition:</para>
|
||||
<para>This is followed by the specified blacklist's
|
||||
definition:</para>
|
||||
|
||||
<programlisting>traplist:\
|
||||
:black:\
|
||||
|
|
@ -1289,22 +1293,24 @@ rdr pass on $ext_if inet proto tcp from !<spamd-white> to \
|
|||
:method=http:\
|
||||
:file=www.openbsd.org/spamd/traplist.gz</programlisting>
|
||||
|
||||
<para>where the first line is the name of the blacklist and the second line
|
||||
specifies the list type. The
|
||||
<para>where the first line is the name of the blacklist
|
||||
and the second line specifies the list type. The
|
||||
<literal>msg</literal> field contains the message to
|
||||
display to blacklisted senders during the <acronym>SMTP</acronym>
|
||||
dialogue. The <literal>method</literal> field
|
||||
specifies how <application>spamd-setup</application> fetches the list data;
|
||||
supported methods are <literal>http</literal>,
|
||||
display to blacklisted senders during the
|
||||
<acronym>SMTP</acronym> dialogue. The
|
||||
<literal>method</literal> field specifies how
|
||||
<application>spamd-setup</application> fetches the list
|
||||
data; supported methods are <literal>http</literal>,
|
||||
<literal>ftp</literal>, from a
|
||||
<literal>file</literal> in a mounted file system, and
|
||||
via <literal>exec</literal> of an external program.
|
||||
Finally, the <literal>file</literal> field specifies
|
||||
the name of the file <application>spamd</application> expects to receive.</para>
|
||||
the name of the file <application>spamd</application>
|
||||
expects to receive.</para>
|
||||
|
||||
<para>The definition of the specified whitelist is
|
||||
similar, but omits the <literal>msg</literal> field since a
|
||||
message is not needed:</para>
|
||||
similar, but omits the <literal>msg</literal> field
|
||||
since a message is not needed:</para>
|
||||
|
||||
<programlisting>whitelist:\
|
||||
:white:\
|
||||
|
|
@ -1315,88 +1321,89 @@ rdr pass on $ext_if inet proto tcp from !<spamd-white> to \
|
|||
<title>Choose Data Sources with Care</title>
|
||||
|
||||
<para>Using all the blacklists in the sample
|
||||
<filename>spamd.conf</filename> will
|
||||
blacklist large blocks of the Internet. Administrators
|
||||
need to edit the file to create an optimal
|
||||
configuration which uses applicable
|
||||
data sources and, when necessary, uses custom lists.</para>
|
||||
<filename>spamd.conf</filename> will blacklist large
|
||||
blocks of the Internet. Administrators need to edit
|
||||
the file to create an optimal configuration which uses
|
||||
applicable data sources and, when necessary, uses
|
||||
custom lists.</para>
|
||||
</tip>
|
||||
|
||||
<para>Next, add this entry to <filename>/etc/rc.conf</filename>.
|
||||
Additional flags are described in the man page specified
|
||||
by the comment:</para>
|
||||
<para>Next, add this entry to
|
||||
<filename>/etc/rc.conf</filename>. Additional flags are
|
||||
described in the man page specified by the
|
||||
comment:</para>
|
||||
|
||||
<programlisting>spamd_flags="-v" # use "" and see spamd-setup(8) for flags</programlisting>
|
||||
|
||||
<para>When finished, reload the
|
||||
ruleset, start <application>spamd</application> by typing
|
||||
<command>service start obspamd</command>,
|
||||
and complete the configuration using
|
||||
<command>spamd-setup</command>. Finally, create a
|
||||
&man.cron.8; job which calls
|
||||
<command>spamd-setup</command> to update the tables
|
||||
at reasonable intervals.</para>
|
||||
<para>When finished, reload the ruleset, start
|
||||
<application>spamd</application> by typing
|
||||
<command>service start obspamd</command>, and complete
|
||||
the configuration using <command>spamd-setup</command>.
|
||||
Finally, create a &man.cron.8; job which calls
|
||||
<command>spamd-setup</command> to update the tables at
|
||||
reasonable intervals.</para>
|
||||
</step>
|
||||
</procedure>
|
||||
|
||||
<para>On a typical gateway in front of a mail server,
|
||||
hosts will soon start getting trapped within a few seconds to
|
||||
<para>On a typical gateway in front of a mail server, hosts
|
||||
will soon start getting trapped within a few seconds to
|
||||
several minutes.</para>
|
||||
|
||||
<para><application>PF</application> also supports
|
||||
<firstterm>greylisting</firstterm>, which temporarily
|
||||
rejects messages from unknown hosts with
|
||||
<replaceable>45n</replaceable> codes. Messages
|
||||
from greylisted hosts which try again within a reasonable time
|
||||
are let through. Traffic from
|
||||
senders which are set up to behave within the limits set
|
||||
by RFC 1123
|
||||
and RFC 2821 are immediately let
|
||||
through.</para>
|
||||
<para><application>PF</application> also supports
|
||||
<firstterm>greylisting</firstterm>, which temporarily
|
||||
rejects messages from unknown hosts with
|
||||
<replaceable>45n</replaceable> codes. Messages from
|
||||
greylisted hosts which try again within a reasonable time
|
||||
are let through. Traffic from senders which are set up to
|
||||
behave within the limits set by RFC 1123 and RFC 2821 are
|
||||
immediately let through.</para>
|
||||
|
||||
<para>More information about greylisting as a technique
|
||||
can be found at the <link
|
||||
xlink:href="http://www.greylisting.org/">greylisting.org</link>
|
||||
web site. The most amazing thing about greylisting, apart
|
||||
from its simplicity, is that it still works. Spammers
|
||||
and malware writers have been very slow to adapt in order
|
||||
to bypass this technique.</para>
|
||||
<para>More information about greylisting as a technique can be
|
||||
found at the <link
|
||||
xlink:href="http://www.greylisting.org/">greylisting.org</link>
|
||||
web site. The most amazing thing about greylisting, apart
|
||||
from its simplicity, is that it still works. Spammers and
|
||||
malware writers have been very slow to adapt in order to
|
||||
bypass this technique.</para>
|
||||
|
||||
<para>The basic procedure for configuring greylisting is as
|
||||
follows:</para>
|
||||
<para>The basic procedure for configuring greylisting is as
|
||||
follows:</para>
|
||||
|
||||
<procedure>
|
||||
<title>Configuring Greylisting</title>
|
||||
<step>
|
||||
<para>Make sure that &man.fdescfs.5; is
|
||||
mounted as described in Step 1 of the previous Procedure.</para>
|
||||
</step>
|
||||
<procedure>
|
||||
<title>Configuring Greylisting</title>
|
||||
|
||||
<step>
|
||||
<para>To run <application>spamd</application> in
|
||||
greylisting mode, add this line to <filename>/etc/rc.conf</filename>:</para>
|
||||
<step>
|
||||
<para>Make sure that &man.fdescfs.5; is mounted as
|
||||
described in Step 1 of the previous Procedure.</para>
|
||||
</step>
|
||||
|
||||
<programlisting>spamd_grey="YES" # use spamd greylisting if YES</programlisting>
|
||||
<step>
|
||||
<para>To run <application>spamd</application> in
|
||||
greylisting mode, add this line to
|
||||
<filename>/etc/rc.conf</filename>:</para>
|
||||
|
||||
<para>Refer to the <application>spamd</application> man page
|
||||
for descriptions of additional related parameters.</para>
|
||||
</step>
|
||||
<programlisting>spamd_grey="YES" # use spamd greylisting if YES</programlisting>
|
||||
|
||||
<step>
|
||||
<para>To complete the greylisting setup:</para>
|
||||
<para>Refer to the <application>spamd</application> man
|
||||
page for descriptions of additional related
|
||||
parameters.</para>
|
||||
</step>
|
||||
|
||||
<programlisting>&prompt.root; <command>service restart obspamd</command>
|
||||
<step>
|
||||
<para>To complete the greylisting setup:</para>
|
||||
|
||||
<programlisting>&prompt.root; <command>service restart obspamd</command>
|
||||
&prompt.root; <command>service start spamlogd</command></programlisting>
|
||||
</step>
|
||||
</procedure>
|
||||
</step>
|
||||
</procedure>
|
||||
|
||||
<para>Behind the scenes, the <application>spamdb</application> database
|
||||
tool and the <application>spamlogd</application>
|
||||
whitelist updater perform essential
|
||||
functions for the greylisting feature. <application>spamdb</application> is the
|
||||
administrator's main interface to managing the black,
|
||||
grey, and white lists via the contents of the
|
||||
<filename>/var/db/spamdb</filename> database.</para>
|
||||
<para>Behind the scenes, the <application>spamdb</application>
|
||||
database tool and the <application>spamlogd</application>
|
||||
whitelist updater perform essential functions for the
|
||||
greylisting feature. <application>spamdb</application> is
|
||||
the administrator's main interface to managing the black,
|
||||
grey, and white lists via the contents of the
|
||||
<filename>/var/db/spamdb</filename> database.</para>
|
||||
</sect3>
|
||||
|
||||
<sect3 xml:id="pftut-hygiene">
|
||||
|
|
@ -1407,58 +1414,58 @@ rdr pass on $ext_if inet proto tcp from !<spamd-white> to \
|
|||
and <literal>antispoof</literal> can be used to make the
|
||||
ruleset behave sanely.</para>
|
||||
|
||||
<para>The <literal>block-policy</literal> is an option which
|
||||
can be set in the <literal>options</literal> part of the
|
||||
ruleset, which precedes the redirection and filtering
|
||||
rules. This option determines which feedback, if any,
|
||||
<application>PF</application> sends to hosts that are
|
||||
blocked by a rule. The option has two possible values:
|
||||
<literal>drop</literal> drops blocked packets
|
||||
with no feedback, and <literal>return</literal>
|
||||
returns a status code such as
|
||||
<computeroutput>Connection refused</computeroutput>.</para>
|
||||
<para>The <literal>block-policy</literal> is an option which
|
||||
can be set in the <literal>options</literal> part of the
|
||||
ruleset, which precedes the redirection and filtering rules.
|
||||
This option determines which feedback, if any,
|
||||
<application>PF</application> sends to hosts that are
|
||||
blocked by a rule. The option has two possible values:
|
||||
<literal>drop</literal> drops blocked packets with no
|
||||
feedback, and <literal>return</literal> returns a status
|
||||
code such as
|
||||
<computeroutput>Connection refused</computeroutput>.</para>
|
||||
|
||||
<para>If not set, the default policy is <literal>drop</literal>. To change the <literal>block-policy</literal>, specify
|
||||
the desired value:</para>
|
||||
<para>If not set, the default policy is
|
||||
<literal>drop</literal>. To change the
|
||||
<literal>block-policy</literal>, specify the desired
|
||||
value:</para>
|
||||
|
||||
<programlisting>set block-policy return</programlisting>
|
||||
<programlisting>set block-policy return</programlisting>
|
||||
|
||||
<para>In <application>PF</application>, <literal>scrub</literal> is a
|
||||
keyword which enables network packet normalization. This
|
||||
process reassembles
|
||||
fragmented packets and drops TCP packets that have invalid
|
||||
flag combinations. Enabling <literal>scrub</literal> provides a
|
||||
measure of protection against certain kinds of attacks
|
||||
based on incorrect handling of packet fragments. A
|
||||
number of options are available, but the
|
||||
simplest form is suitable for most
|
||||
configurations:</para>
|
||||
<para>In <application>PF</application>,
|
||||
<literal>scrub</literal> is a keyword which enables network
|
||||
packet normalization. This process reassembles fragmented
|
||||
packets and drops TCP packets that have invalid flag
|
||||
combinations. Enabling <literal>scrub</literal> provides a
|
||||
measure of protection against certain kinds of attacks
|
||||
based on incorrect handling of packet fragments. A number
|
||||
of options are available, but the simplest form is suitable
|
||||
for most configurations:</para>
|
||||
|
||||
<programlisting>scrub in all</programlisting>
|
||||
<programlisting>scrub in all</programlisting>
|
||||
|
||||
<para>Some services, such as <acronym>NFS</acronym>, require specific
|
||||
fragment handling options. Refer to
|
||||
<link
|
||||
<para>Some services, such as <acronym>NFS</acronym>, require
|
||||
specific fragment handling options. Refer to <link
|
||||
xlink:href="http://www.openbsd.gr/faq/pf/scrub.html">http://www.openbsd.gr/faq/pf/scrub.html</link>
|
||||
for more information.</para>
|
||||
for more information.</para>
|
||||
|
||||
<para>This example reassembles fragments, clears the
|
||||
<quote>do not fragment</quote> bit, and sets the maximum
|
||||
segment size to 1440 bytes:</para>
|
||||
<para>This example reassembles fragments, clears the
|
||||
<quote>do not fragment</quote> bit, and sets the maximum
|
||||
segment size to 1440 bytes:</para>
|
||||
|
||||
<programlisting>scrub in all fragment reassemble no-df max-mss 1440</programlisting>
|
||||
<programlisting>scrub in all fragment reassemble no-df max-mss 1440</programlisting>
|
||||
|
||||
<para>The <literal>antispoof</literal> mechanism protects
|
||||
against activity from spoofed or forged <acronym>IP</acronym> addresses,
|
||||
mainly by blocking packets appearing on interfaces and
|
||||
in directions which are logically not possible.</para>
|
||||
<para>The <literal>antispoof</literal> mechanism protects
|
||||
against activity from spoofed or forged
|
||||
<acronym>IP</acronym> addresses, mainly by blocking packets
|
||||
appearing on interfaces and in directions which are
|
||||
logically not possible.</para>
|
||||
|
||||
<para>These rules weed out spoofed traffic
|
||||
coming in from the rest of the world as well as any spoofed
|
||||
packets which originate in the local
|
||||
network:</para>
|
||||
<para>These rules weed out spoofed traffic coming in from the
|
||||
rest of the world as well as any spoofed packets which
|
||||
originate in the local network:</para>
|
||||
|
||||
<programlisting>antispoof for $ext_if
|
||||
<programlisting>antispoof for $ext_if
|
||||
antispoof for $int_if</programlisting>
|
||||
</sect3>
|
||||
|
||||
|
|
@ -1466,20 +1473,19 @@ antispoof for $int_if</programlisting>
|
|||
<title>Handling Non-Routable Addresses</title>
|
||||
|
||||
<para>Even with a properly configured gateway to handle
|
||||
network address translation, one may have
|
||||
to compensate for other people's
|
||||
misconfigurations. A common misconfiguration is to
|
||||
let traffic with non-routable
|
||||
addresses out to the Internet. Since traffic from
|
||||
non-routeable addresses can play a part in
|
||||
several <acronym>DoS</acronym> attack techniques,
|
||||
consider explicitly blocking traffic from
|
||||
non-routeable addresses from entering the
|
||||
network through the external interface.</para>
|
||||
network address translation, one may have to compensate for
|
||||
other people's misconfigurations. A common misconfiguration
|
||||
is to let traffic with non-routable addresses out to the
|
||||
Internet. Since traffic from non-routeable addresses can
|
||||
play a part in several <acronym>DoS</acronym> attack
|
||||
techniques, consider explicitly blocking traffic from
|
||||
non-routeable addresses from entering the network through
|
||||
the external interface.</para>
|
||||
|
||||
<para>In this example, a macro containing non-routable
|
||||
addresses is defined, then used in blocking rules. Traffic to and from these addresses is
|
||||
quietly dropped on the gateway's external
|
||||
addresses is defined, then used in blocking rules. Traffic
|
||||
to and from these addresses is quietly dropped on the
|
||||
gateway's external
|
||||
interface.</para>
|
||||
|
||||
<programlisting>martians = "{ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, \
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue