From owner-svn-doc-all@FreeBSD.ORG Wed Feb 19 19:21:14 2014 Return-Path: Delivered-To: svn-doc-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 226D9EBE; Wed, 19 Feb 2014 19:21:14 +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 0CD0A19A7; Wed, 19 Feb 2014 19:21:14 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1JJLDAL024577; Wed, 19 Feb 2014 19:21:13 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1JJLDS7024576; Wed, 19 Feb 2014 19:21:13 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201402191921.s1JJLDS7024576@svn.freebsd.org> From: Dru Lavigne Date: Wed, 19 Feb 2014 19:21:13 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43994 - 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-all@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 19:21:14 -0000 Author: dru Date: Wed Feb 19 19:21:13 2014 New Revision: 43994 URL: http://svnweb.freebsd.org/changeset/doc/43994 Log: White space fix only. Translators can ignore. 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 Wed Feb 19 18:32:15 2014 (r43993) +++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Wed Feb 19 19:21:13 2014 (r43994) @@ -435,11 +435,11 @@ device pfsync To keep an eye on the traffic that passes through the - PF firewall, consider installing the - sysutils/pftop package or port. Once installed, - pftop can be run to view - a running snapshot of traffic in a format which is - similar to &man.top.1;. + PF firewall, consider installing + the sysutils/pftop package or port. Once + installed, pftop can be run to + view a running snapshot of traffic in a format which is + similar to &man.top.1;. @@ -1186,27 +1186,29 @@ pass inet proto tcp from any to $localne 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 to provide an outer defense + against SPAM. This + spamd hooks into the PF configuration using a set of redirections. - 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 + 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 + 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 spammer's end, is called tarpitting. The specific - implementation which uses one byte SMTP replies is often - referred to as stuttering. + implementation which uses one byte SMTP + replies is often referred to as + stuttering. This example demonstrates the basic procedure for setting up spamd with @@ -1218,12 +1220,12 @@ pass inet proto tcp from any to $localne Configuring <application>spamd</application> - Install the mail/spamd/ package or port. - In order to use + Install the mail/spamd/ package + or port. In order to use spamd's greylisting - features, &man.fdescfs.5; - must be mounted at /dev/fd. - Add 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 @@ -1231,11 +1233,11 @@ pass inet proto tcp from any to $localne Then, mount the filesystem: &prompt.root; mount fdescfs - - Next, edit the PF ruleset to include: + Next, edit the PF ruleset + to include: table <spamd> persist table <spamd-white> persist @@ -1245,43 +1247,45 @@ rdr pass on $ext_if inet proto tcp from { $ext_if, $localnet } port smtp -> 127.0.0.1 port 8025 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. + <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 configure - spamd - in /usr/local/etc/spamd.conf and to - add some rc.conf - parameters. + spamd in + /usr/local/etc/spamd.conf and to + add some rc.conf parameters. 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 in the configuration file that does not begin with a - # comment sign - contains the block which defines the - all list, which specifies the - lists to use: + (/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 in the configuration file + that does not begin with a # comment + sign contains the block which defines the + all list, which specifies the lists + to use: all:\ :traplist:whitelist: - 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 + 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:. - This is followed by the specified blacklist's definition: + This is followed by the specified blacklist's + definition: traplist:\ :black:\ @@ -1289,22 +1293,24 @@ rdr pass on $ext_if inet proto tcp from :method=http:\ :file=www.openbsd.org/spamd/traplist.gz - where the first line is the name of the blacklist and the second line - specifies the list type. 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 - dialogue. The method field - specifies how spamd-setup fetches the list data; - supported methods are http, + display to blacklisted senders during the + SMTP dialogue. The + method field 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. + the name of the file spamd + expects to receive. The definition of the specified whitelist is - similar, but omits the msg field since a - message is not needed: + similar, but omits the msg field + since a message is not needed: whitelist:\ :white:\ @@ -1315,88 +1321,89 @@ rdr pass on $ext_if inet proto tcp from Choose Data Sources with Care Using all the blacklists in the sample - 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. + 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. - Next, add this entry to /etc/rc.conf. - Additional flags are described in the man page specified - by the comment: + 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 - at reasonable intervals. + 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 at + reasonable intervals. - On a typical gateway in front of a mail server, - hosts will soon start getting trapped within a few seconds to + On a typical gateway in front of a mail server, hosts + will soon start getting trapped within a few seconds to several minutes. - PF also supports - greylisting, which temporarily - rejects messages from unknown hosts with - 45n 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. - - More information about greylisting as a technique - can be found at the greylisting.org - 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. - - The basic procedure for configuring greylisting is as - follows: - - - Configuring Greylisting - - Make sure that &man.fdescfs.5; is - mounted as described in Step 1 of the previous Procedure. - - - - To run spamd in - greylisting mode, add this line to /etc/rc.conf: - - spamd_grey="YES" # use spamd greylisting if YES - - Refer to the spamd man page - for descriptions of additional related parameters. - + PF also supports + greylisting, which temporarily + rejects messages from unknown hosts with + 45n 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. + + More information about greylisting as a technique can be + found at the greylisting.org + 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. + + The basic procedure for configuring greylisting is as + follows: + + + Configuring Greylisting + + + Make sure that &man.fdescfs.5; is mounted as + described in Step 1 of the previous Procedure. + + + + To run spamd in + greylisting mode, add this line to + /etc/rc.conf: - - To complete the greylisting setup: + spamd_grey="YES" # use spamd greylisting if YES - &prompt.root; service restart obspamd + Refer to the spamd man + page for descriptions of additional related + parameters. + + + + To complete the greylisting setup: + + &prompt.root; service restart obspamd &prompt.root; service start spamlogd - - + + - Behind the scenes, the spamdb database - tool and the spamlogd - whitelist updater perform essential - functions for the greylisting feature. spamdb is the - administrator's main interface to managing the black, - grey, and white lists via the contents of the - /var/db/spamdb database. + Behind the scenes, the spamdb + database tool and the spamlogd + whitelist updater perform essential functions for the + greylisting feature. spamdb is + the administrator's main interface to managing the black, + grey, and white lists via the contents of the + /var/db/spamdb database. @@ -1407,58 +1414,58 @@ rdr pass on $ext_if inet proto tcp from and antispoof can be used to make the ruleset behave sanely. - The block-policy is an option which - can be set in the options part of the - ruleset, which precedes the redirection and filtering - rules. This option determines which feedback, if any, - PF sends to hosts that are - blocked by a rule. The option has two possible values: - drop drops blocked packets - with no feedback, and return - returns a status code such as - Connection refused. - - If not set, the default policy is drop. To change the block-policy, specify - the desired value: - - set block-policy return - - In PF, scrub is a - keyword which enables network packet normalization. This - process reassembles - fragmented packets and drops TCP packets that have invalid - flag combinations. Enabling scrub 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: - - scrub in all - - Some services, such as NFS, require specific - fragment handling options. Refer to - The block-policy is an option which + can be set in the options part of the + ruleset, which precedes the redirection and filtering rules. + This option determines which feedback, if any, + PF sends to hosts that are + blocked by a rule. The option has two possible values: + drop drops blocked packets with no + feedback, and return returns a status + code such as + Connection refused. + + If not set, the default policy is + drop. To change the + block-policy, specify the desired + value: + + set block-policy return + + In PF, + scrub is a keyword which enables network + packet normalization. This process reassembles fragmented + packets and drops TCP packets that have invalid flag + combinations. Enabling scrub 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: + + scrub in all + + Some services, such as NFS, require + specific fragment handling options. Refer to http://www.openbsd.gr/faq/pf/scrub.html - for more information. + for more information. - This example reassembles fragments, clears the - do not fragment bit, and sets the maximum - segment size to 1440 bytes: + This example reassembles fragments, clears the + do not fragment bit, and sets the maximum + segment size to 1440 bytes: - scrub in all fragment reassemble no-df max-mss 1440 + scrub in all fragment reassemble no-df max-mss 1440 - The antispoof mechanism protects - against activity from spoofed or forged IP addresses, - mainly by blocking packets appearing on interfaces and - in directions which are logically not possible. + The antispoof mechanism protects + against activity from spoofed or forged + IP addresses, mainly by blocking packets + appearing on interfaces and in directions which are + logically not possible. - 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: + 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: - antispoof for $ext_if + antispoof for $ext_if antispoof for $int_if @@ -1466,20 +1473,19 @@ antispoof for $int_if Handling Non-Routable Addresses 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 DoS attack techniques, - consider explicitly blocking traffic from - non-routeable addresses from entering the - network through the external interface. + 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 DoS attack + techniques, consider explicitly blocking traffic from + non-routeable addresses from entering the network through + the external interface. 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. martians = "{ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, \