From owner-svn-doc-head@FreeBSD.ORG Tue Feb 18 19:25:17 2014 Return-Path: Delivered-To: svn-doc-head@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 4167246C; Tue, 18 Feb 2014 19:25:17 +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 0E61919FE; Tue, 18 Feb 2014 19:25:17 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1IJPGCl007339; Tue, 18 Feb 2014 19:25:16 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1IJPGfQ007338; Tue, 18 Feb 2014 19:25:16 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201402181925.s1IJPGfQ007338@svn.freebsd.org> From: Dru Lavigne Date: Tue, 18 Feb 2014 19:25:16 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43983 - 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: Tue, 18 Feb 2014 19:25:17 -0000 Author: dru Date: Tue Feb 18 19:25:16 2014 New Revision: 43983 URL: http://svnweb.freebsd.org/changeset/doc/43983 Log: Editorial pass through ICMP section. 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 18:25:51 2014 (r43982) +++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Tue Feb 18 19:25:16 2014 (r43983) @@ -882,152 +882,79 @@ rdr-anchor "ftp-proxy/*" Managing <acronym>ICMP</acronym> - Making network troubleshooting friendly is a potentially - large subject. At most times, the debugging or - troubleshooting friendliness of a TCP/IP - network depends on treatment of the Internet protocol which - was designed specifically with debugging in mind, the - Internet Control Message Protocol, or - ICMP as it is usually abbreviated. + Many of the tools used for debugging or + troubleshooting a TCP/IP network rely on the + Internet Control Message Protocol (ICMP), which + was designed specifically with debugging in mind. - ICMP is the protocol for sending and - receiving control messages between + The ICMP protocol sends and + receives control messages between hosts and gateways, mainly to provide feedback to a sender about any unusual or difficult conditions enroute to the - target host. - - There is a lot of ICMP traffic which - usually just happens in the background while users are - surfing the web, reading mail or transferring files. + target host. Routers use ICMP to negotiate packet sizes and other transmission parameters in a process often referred to as path MTU discovery. - Some admins refer to ICMP as either - just evil, or, if their understanding runs a - little deeper, a necessary evil. The reason - for this attitude is purely historical. The reason can be - found a few years back when it was discovered that several - operating systems contained code in their networking stack - which could make a machine running one of the affected - systems crash and fall over, or in some cases just do really - strange things, with a sufficiently large - ICMP request. - - One of the companies which was hit hard was Microsoft, - and you can find rather a lot of material on the - ping of death bug by using your favorite - search engine. This all happened in the second half of the - 1990s, and all modern operating systems, at least the ones - we can read, have thoroughly sanitized their network code - since then. At least that is what we are led to - believe. - - One of the early workarounds was to simply block either - all ICMP traffic or at least - ICMP ECHO, which is what ping uses. Now - these rulesets have been around for roughly fifteen years, - and the people who put them there are still scared. - - The obvious question then becomes, if - ICMP is such a good and useful thing, - should we not let it all through, all the time? The - answer is It depends. - - Letting diagnostic traffic pass unconditionally of - course makes debugging easier, but also makes it - relatively easy for others to extract information about - your network. That means that a rule like + From a firewall perspective, some ICMP + control messages are vulnerable to known attack vectors. + Also, letting all diagnostic traffic pass unconditionally + makes debugging easier, but it also makes it + easier for others to extract information about + the network. For these reasons, the following rule may not be + optimal: pass inet proto icmp from any to any - might not be optimal if the internal workings of the - local network should be cloaked in a bit of mystery. In - all fairness it should also be said that some - ICMP traffic might be found quite - harmlessly riding piggyback on - keep state rules. - - The easiest solution could very well be to let all - ICMP traffic from the local net through - and stop probes from elsewhere at the gateway: + One solution is to let all + ICMP traffic from the local network through + while stopping all probes from outside the network: pass inet proto icmp from $localnet to any keep state pass inet proto icmp from any to $ext_if keep state - Stopping probes at the gateway might be an attractive - option anyway, but let us have a look at a few other - options which will show some of - PF's flexibility. - - - Letting <command>ping</command> Through - - The ruleset we have developed so far has one clear - disadvantage: common troubleshooting commands such as - &man.ping.8; and &man.traceroute.8; will not work. That - may not matter too much to end users, and since it was - ping which scared people into - filtering or blocking ICMP traffic in - the first place, there are apparently some people who feel - we are better off without it. If you are in my perceived - target audience, you will be rather fond of having those - troubleshooting tools avalable. With a couple of small - additions to the ruleset, they will be. &man.ping.8; - uses ICMP, and in order to keep our - ruleset tidy, we start by defining another macro: + Additional + options are available which demonstrate some of + PF's flexibility. For example, + rather than allowing all ICMP messages, + one can specify the messages used by &man.ping.8; and + &man.traceroute.8;. Start by defining a macro for + that type of message: icmp_types = "echoreq" - and a rule which uses the definition, + and a rule which uses the macro: pass inet proto icmp all icmp-type $icmp_types keep state - More or other types of ICMP packets - may need to go through, and icmp_types - can be expanded to a list of those packet types that are - allowed. - - - - Helping &man.traceroute.8; - - &man.traceroute.8; is another command which is quite - useful when users claim that the Internet is not working. - By default, Unix traceroute uses UDP - connections according to a set formula based on - destination. The rule below works with - traceroute on all Unixes I have had - access to, including GNU/Linux: + If other types of ICMP packets + are needed, expand icmp_types + to a list of those packet types. Type + more /usr/src/contrib/pf/pfctl/pfctl_parser.c + to see the list of ICMP message + types supported by PF. Refer to + http://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml + for an explanation of each message type. + + Since Unix traceroute uses UDP + by default, another rule is needed to allow Unix + traceroute: # allow out the default range for traceroute(8): -# "base+nhops*nqueries-1" (33434+64*3-1) pass out on $ext_if inet proto udp from any to any port 33433 >< 33626 keep state - Experience so far indicates that - traceroute implementations on other - operating systems work roughly the same. Except, of - course, on Microsoft Windows. On that platform, - TRACERT.EXE uses ICMP ECHO for this - purpose. So to let Windows traceroutes through, only the - first rule is needed. Unix traceroute + Since TRACERT.EXE on Microsoft Windows systems + uses ICMP echo request messages, + only the + first rule is needed to allow network traces from those systems. Unix traceroute can be instructed to use other protocols as well, and will - behave remarkably like its Microsoft counterpart if + use ICMP echo request messages if is used. Check the &man.traceroute.8; - man page (or its source code, for that matter) for all the + man page for details. - Under any circumstances, this solution was lifted - from an openbsd-misc post. I have found that list, and - the searchable list archives (accessible among other - places from http://marc.theaimsgroup.com/), - to be a very valuable resource whenever you need OpenBSD - or PF related - information. - - Path <acronym>MTU</acronym> Discovery @@ -1035,60 +962,47 @@ pass out on $ext_if inet proto udp from independent, and one consequence of device independence is that the optimal packet size for a given connection cannot always be predicted reliably. The main constraint on - packet size is called the - Maximum Transmission Unit, or - MTU, which sets the upper limit on the - packet size for an interface. &man.ifconfig.8; shows the - MTU for the network interfaces. - - Modern TCP/IP implementations expect to be able to - determine the right packet size for a connection through a - process which, simply put, involves sending packets of + packet size is the + Maximum Transmission Unit + (MTU) which sets the upper limit on the + packet size for an interface. Type ifconfig to view the + MTUs for a system's network interfaces. + + TCP/IP uses a process known as path + MTU discovery to + determine the right packet size for a connection. This + process sends packets of varying sizes with the Do not fragment flag set, expecting an ICMP return packet - indicating type 3, code 4 when the upper - limit has been reached. Now do not dive for the RFCs - right away. Type 3 means destination - unreachable, while code 4 is short for + of type 3, code 4 when the upper + limit has been reached. Type 3 means destination + unreachable, and code 4 is short for fragmentation needed, but the do-not-fragment flag - is set. So if connections to networks which may - have other MTUs than the local network - seem sub-optimal, and there is no need to be that - specific, the list of ICMP types can be - changed slightly to let the - destination unreachable packets through, - too: + is set. To allow path MTU discovery in order + to support connections to other MTUs, add + the + destination unreachable type to the + icmp_types macro: icmp_types = "{ echoreq, unreach }" - As we can see, this means we do not need to change - the pass rule itself: + Since + the pass rule already uses that macro, it does not need to + be modified in order to support the new + ICMP type: pass inet proto icmp all icmp-type $icmp_types keep state PF allows filtering on all variations of ICMP types and codes. - For those who want to delve into what to pass (or not) of - ICMP traffic, the list of possible - types and codes are documented in the &man.icmp.4; and - &man.icmp6.4; man pages. The background information is - available in the RFCs - The main internet RFCs - describing ICMP and - some related techhiques are RFC792, RFC950, RFC1191, - RFC1256, RFC2521, rfc2765, while necessary updates for - ICMP for IPv6 are found in RFC1885, RFC2463, RFC2466. - These documents are available in a number of places on - the net, such as the - ietf.org - and - faqs.org - web sites.. + The list of possible + types and codes are documented in &man.icmp.4; and + &man.icmp6.4;. - Tables Make Life Easier + Using Tables By this time it may appear that this gets awfully static and rigid. There will after all be some kinds of data which