From owner-svn-doc-all@FreeBSD.ORG Wed Feb 19 18:32:16 2014 Return-Path: Delivered-To: svn-doc-all@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 251EBFD5; Wed, 19 Feb 2014 18:32:16 +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 0FB0B1574; Wed, 19 Feb 2014 18:32:16 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1JIWFwe003757; Wed, 19 Feb 2014 18:32:15 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1JIWFhX003756; Wed, 19 Feb 2014 18:32:15 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201402191832.s1JIWFhX003756@svn.freebsd.org> From: Dru Lavigne Date: Wed, 19 Feb 2014 18:32:15 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43993 - 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 18:32:16 -0000 Author: dru Date: Wed Feb 19 18:32:15 2014 New Revision: 43993 URL: http://svnweb.freebsd.org/changeset/doc/43993 Log: Finish editorial pass through PF chapter. 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 17:51:00 2014 (r43992) +++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Wed Feb 19 18:32:15 2014 (r43993) @@ -433,6 +433,13 @@ device pfsync privileges. It can be installed from the Ports Collection. + + 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;. @@ -1400,94 +1407,80 @@ rdr pass on $ext_if inet proto tcp from and antispoof can be used to make the ruleset behave sanely. - block-policy is an option which + 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 will give to hosts which - try to create connections which are subsequently - blocked. The option has two possible values, - drop, which drops blocked packets - with no feedback, and return, which - returns with status codes such as - Connection refused or - similar. - - The correct strategy for block policies has been the - subject of rather a lot of discussion. We choose to - play nicely and instruct our firewall to issue - returns: + 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 versions up to - OpenBSD 4.5 inclusive, scrub is a - keyword which enables network packet normalization, - causing fragmented packets to be assembled and removing - ambiguity. Enabling scrub provides a + 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 supplementing options are available, but we - choose the simplest form which is suitable for most - configurations. + number of options are available, but the + simplest form is suitable for most + configurations: scrub in all - Some services, such as NFS, require some specific - fragment handling options. This is extensively - documented in the PF user - guide and man pages provide all the information you - could need. - - One fairly common example is this, + Some services, such as NFS, require specific + fragment handling options. Refer to + http://www.openbsd.gr/faq/pf/scrub.html + for more information. + + 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 - meaning, we reassemble fragments, clear the - do not fragment bit and set the maximum - segment size to 1440 bytes. Other variations are - possible, and you should be able to cater to various - specific needs by consulting the man pages and some - experimentation. - - antispoof is a common special - case of filtering and blocking. This mechanism protects - against activity from spoofed or forged IP addresses, + 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. - We specify that we want to weed out spoofed traffic - coming in from the rest of the world and any spoofed - packets which, however unlikely, were to originate in - our own 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 $int_if - Handling Non-Routable Addresses from - Elsewhere + Handling Non-Routable Addresses Even with a properly configured gateway to handle - network address translation for your own network, you - may find yourself in the unenviable position of having + network address translation, one may have to compensate for other people's - misconfigurations. + 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. - One depressingly common class of misconfigurations - is the kind which lets traffic with non-routable - addresses out to the Internet. Traffic from - non-routeable addresses have also played a part in - several DOS attack techniques, so it may be worth - considering explicitly blocking traffic from - non-routeable addresses from entering your - network. - - One possible solution is the one outlined below, - which for good measure also blocks any attempt to - initiate contact to non-routable addresses through the - gateway's 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 + interface. martians = "{ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, \ 10.0.0.0/8, 169.254.0.0/16, 192.0.2.0/24, \ @@ -1495,43 +1488,6 @@ antispoof for $int_if block drop in quick on $ext_if from $martians to any block drop out quick on $ext_if from any to $martians - - Here, the martians macro denotes - the RFC 1918 addresses and a few other ranges which are - mandated by various RFCs not to be in circulation on the - open Internet. Traffic to and from such addresses is - quietly dropped on the gateway's external - interface. - - The specific details of how to implement this kind - of protection will vary, among other things according to - your specific network configuration. Your network - design could for example dictate that you include or - exclude other address ranges than these. - - This completes our simple NATing firewall for a - small local network. A more thorough tutorial is - available at http://home.nuug.no/~peter/pf/, - where you will also find slides from related - presentations. - - - - Viewing Traffic - - Over time, a number of tools have been developed which - interact with PF in various - ways. - - Can Erkin Acar's pftop - makes it possible to keep an eye on what passes into and - out of the network. pftop is - available through the ports system as - sysutils/pftop. The name is a strong - hint at what it does - pftop - shows a running snapshot of traffic in a format which is - strongly inspired by &man.top.1;.