From owner-svn-doc-head@FreeBSD.ORG Wed Feb 19 17:05:25 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 45A40614; Wed, 19 Feb 2014 17:05:24 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BACDF1C98; Wed, 19 Feb 2014 17:05:24 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1JH5O2m068283; Wed, 19 Feb 2014 17:05:24 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1JH5OuR068282; Wed, 19 Feb 2014 17:05:24 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201402191705.s1JH5OuR068282@svn.freebsd.org> From: Dru Lavigne Date: Wed, 19 Feb 2014 17:05:24 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43989 - head/en_US.ISO8859-1/books/handbook/firewalls X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 17:05:25 -0000 Author: dru Date: Wed Feb 19 17:05:24 2014 New Revision: 43989 URL: http://svnweb.freebsd.org/changeset/doc/43989 Log: Editorial pass through spamd section. The last step on using spamd-setup should be expanded at some point. Sponsored by: iXsystems Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Tue Feb 18 22:23:51 2014 (r43988) +++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Wed Feb 19 17:05:24 2014 (r43989) @@ -1176,63 +1176,59 @@ pass inet proto tcp from any to $localne Protecting Against <acronym>SPAM</acronym> Not to be confused with the - spamd daemon which comes - bundled with spamassassin, the - PF companion - spamd was designed to run on a - PF gateway to form part of the outer defense against spam. - spamd hooks into the - PF configuration via a set of + spamd daemon which comes bundled + with spamassassin, + mail/spamd/ can be configured with + PF to provide an outer defense against SPAM. + This spamd hooks into the + PF configuration using a set of redirections. - The main point underlying the - spamd design is the fact that - spammers send a large number of messages, and the - probability that you are the first person receiving a - particular message is incredibly small. In addition, - spam is mainly sent via a few spammer friendly networks - and a large number of hijacked machines. Both the - individual messages and the machines will be reported to - blacklists fairly quickly, and this is the kind of data - spamd can use to our advantage - with blacklists. - - What spamd does to SMTP - connections from addresses in the blacklist is to - present its banner and immediately switch to a mode - where it answers SMTP traffic one byte at the time. This + Spammers tend to send a large number of messages, and + SPAM is mainly sent from a few spammer friendly networks + and a large number of hijacked machines, both of which + are reported to + blacklists fairly quickly. + + When an SMTP + connection from an address in a blacklist is received, + spamd + presents its banner and immediately switches to a mode + where it answers SMTP traffic one byte at a time. This technique, which is intended to waste as much time as - possible on the sending end while costing the receiver - pretty much nothing, is called + possible on the spammer's end, is called tarpitting. The specific - implementation with one byte SMTP replies is often + implementation which uses one byte SMTP replies is often referred to as stuttering. This example demonstrates the basic procedure for setting up spamd with - automatically updated blacklists: + automatically updated blacklists. Refer to the man pages + which are installed with mail/spamd/ for + more information. + Configuring <application>spamd</application> + - Install the mail/spamd/ port. - In particular, be sure to read the package message - and act upon what it says. Specifically, to use + Install the mail/spamd/ package or port. + In order to use spamd's greylisting - features, a file descriptor file system (see fdescfs(5)) - must be mounted at /dev/fd/. - Do this by adding the following line to + features, &man.fdescfs.5; + must be mounted at /dev/fd. + Add the following line to /etc/fstab: fdescfs /dev/fd fdescfs rw 0 0 - Make sure the fdescfs code - is in the kernel, either compiled in or by loading - the module with &man.kldload.8;. + Then, mount the filesystem: + + &prompt.root; mount fdescfs + - Next, edit the ruleset to include + Next, edit the PF ruleset to include: table <spamd> persist table <spamd-white> persist @@ -1241,42 +1237,44 @@ rdr pass on $ext_if inet proto tcp from rdr pass on $ext_if inet proto tcp from !<spamd-white> to \ { $ext_if, $localnet } port smtp -> 127.0.0.1 port 8025 - The two tables <spamd> and - <spamd-white> are essential. SMTP traffic - from the addresses in the first table plus the ones - which are not in the other table are redirected to a + The two tables <spamd> and + <spamd-white> are essential. SMTP traffic + from an address listed in <spamd> but not in + <spamd-white> is redirected to the spamd daemon listening at port 8025. - The next step is to set up - spamd's own configuration - in /usr/local/etc/spamd.conf - supplemented by rc.conf + The next step is to configure + spamd + in /usr/local/etc/spamd.conf and to + add some rc.conf parameters. - The supplied sample file offers quite a bit of - explanation, and the man page offers additional - information, but we will recap the essentials - here. + The installation of mail/spamd/ + includes a sample configuration file + (/usr/local/etc/spamd.conf.sample) and a + man page for spamd.conf. Refer to + these for additional configuration options beyond those + shown in this example. - One of the first lines without a - # comment sign at the start + One of the first lines in the configuration file that does not begin with a + # comment sign contains the block which defines the all list, which specifies the - lists actually used: + lists to use: all:\ :traplist:whitelist: - Here, all the desired black lists are added, - separated by colons (:). To use - whitelists to subtract addresses from the blacklist, - add the name of the whitelist immediately after the - name of each blacklist, i.e., + This entry adds the desired blacklists, + separated by colons (:). To use a + whitelist to subtract addresses from a blacklist, + add the name of the whitelist immediately after the + name of that blacklist. For example: :blacklist:whitelist:. - Next up is a blacklist definition: + This is followed by the specified blacklist's definition: traplist:\ :black:\ @@ -1284,56 +1282,49 @@ rdr pass on $ext_if inet proto tcp from :method=http:\ :file=www.openbsd.org/spamd/traplist.gz - Following the name, the first data field - specifies the list type, in this case - black. The + where the first line is the name of the blacklist and the second line + specifies the list type. The msg field contains the message to - display to blacklisted senders during the SMTP + display to blacklisted senders during the SMTP dialogue. The method field - specifies how spamd-setup fetches the list data, - here http. The other options are - fetching via ftp, from a - file in a mounted file system or + specifies how spamd-setup fetches the list data; + supported methods are http, + ftp, from a + file in a mounted file system, and via exec of an external program. - Finally the file field specifies - the name of the file spamd expects to receive. + Finally, the file field specifies + the name of the file spamd expects to receive. - The definition of a whitelist follows much the - same pattern: + The definition of the specified whitelist is + similar, but omits the msg field since a + message is not needed: whitelist:\ :white:\ :method=file:\ :file=/var/mail/whitelist.txt - but omits the message parameters since a - message is not needed. - Choose Data Sources with Care Using all the blacklists in the sample - spamd.conf will end up - blacklisting large blocks of the Internet, - including several Asian nations. Administrators - need to edit the file to end up with an optimal - configuration. The administrator is the judge of - which data sources to use, and using lists other - than the ones suggested in the sample file is - possible. + spamd.conf 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. - Put the lines for spamd and any startup - parameters desired in /etc/rc.conf, - for example: - - spamd_flags="-v" # for normal use: "" and see spamd-setup(8) - - When done with editing the setup, reload the - ruleset, start spamd with the - options desired using the - /usr/local/etc/rc.d/obspamd - script, and complete the configuration using + Next, add this entry to /etc/rc.conf. + Additional flags are described in the man page specified + by the comment: + + spamd_flags="-v" # use "" and see spamd-setup(8) for flags + + When finished, reload the + ruleset, start spamd by typing + service start obspamd, + and complete the configuration using spamd-setup. Finally, create a &man.cron.8; job which calls spamd-setup to update the tables @@ -1342,7 +1333,7 @@ rdr pass on $ext_if inet proto tcp from On a typical gateway in front of a mail server, - hosts will start getting trapped within a few seconds to + hosts will soon start getting trapped within a few seconds to several minutes.