Editorial pass through ICMP section.
Sponsored by: iXsystems
This commit is contained in:
Dru Lavigne
parent
d927ced901
commit
e45dac121c
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=43983
1 changed files with 68 additions and 154 deletions
|
|
@ -882,152 +882,79 @@ rdr-anchor "ftp-proxy/*"</programlisting>
|
||||||
<sect3 xml:id="pftut-icmp">
|
<sect3 xml:id="pftut-icmp">
|
||||||
<title>Managing <acronym>ICMP</acronym></title>
|
<title>Managing <acronym>ICMP</acronym></title>
|
||||||
|
|
||||||
<para>Making network troubleshooting friendly is a potentially
|
<para>Many of the tools used for debugging or
|
||||||
large subject. At most times, the debugging or
|
troubleshooting a <acronym>TCP/IP</acronym> network rely on the
|
||||||
troubleshooting friendliness of a <acronym>TCP/IP</acronym>
|
Internet Control Message Protocol (<acronym>ICMP</acronym>), which
|
||||||
network depends on treatment of the Internet protocol which
|
was designed specifically with debugging in mind.</para>
|
||||||
was designed specifically with debugging in mind, the
|
|
||||||
<emphasis>Internet Control Message Protocol</emphasis>, or
|
|
||||||
<acronym>ICMP</acronym> as it is usually abbreviated.</para>
|
|
||||||
|
|
||||||
<para><acronym>ICMP</acronym> is the protocol for sending and
|
<para>The <acronym>ICMP</acronym> protocol sends and
|
||||||
receiving <emphasis>control messages</emphasis> between
|
receives <emphasis>control messages</emphasis> between
|
||||||
hosts and gateways, mainly to provide feedback to a sender
|
hosts and gateways, mainly to provide feedback to a sender
|
||||||
about any unusual or difficult conditions enroute to the
|
about any unusual or difficult conditions enroute to the
|
||||||
target host.</para>
|
target host.
|
||||||
|
|
||||||
<para>There is a lot of <acronym>ICMP</acronym> traffic which
|
|
||||||
usually just happens in the background while users are
|
|
||||||
surfing the web, reading mail or transferring files.
|
|
||||||
Routers use <acronym>ICMP</acronym> to negotiate packet
|
Routers use <acronym>ICMP</acronym> to negotiate packet
|
||||||
sizes and other transmission parameters in a process often
|
sizes and other transmission parameters in a process often
|
||||||
referred to as <emphasis>path <acronym>MTU</acronym>
|
referred to as <emphasis>path <acronym>MTU</acronym>
|
||||||
discovery</emphasis>.</para>
|
discovery</emphasis>.</para>
|
||||||
|
|
||||||
<para>Some admins refer to <acronym>ICMP</acronym> as either
|
<para>From a firewall perspective, some <acronym>ICMP</acronym>
|
||||||
<quote>just evil</quote>, or, if their understanding runs a
|
control messages are vulnerable to known attack vectors.
|
||||||
little deeper, <quote>a necessary evil</quote>. The reason
|
Also, letting all diagnostic traffic pass unconditionally
|
||||||
for this attitude is purely historical. The reason can be
|
makes debugging easier, but it also makes it
|
||||||
found a few years back when it was discovered that several
|
easier for others to extract information about
|
||||||
operating systems contained code in their networking stack
|
the network. For these reasons, the following rule may not be
|
||||||
which could make a machine running one of the affected
|
optimal:</para>
|
||||||
systems crash and fall over, or in some cases just do really
|
|
||||||
strange things, with a sufficiently large
|
|
||||||
<acronym>ICMP</acronym> request.</para>
|
|
||||||
|
|
||||||
<para>One of the companies which was hit hard was Microsoft,
|
|
||||||
and you can find rather a lot of material on the
|
|
||||||
<quote>ping of death</quote> 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.</para>
|
|
||||||
|
|
||||||
<para>One of the early workarounds was to simply block either
|
|
||||||
all <acronym>ICMP</acronym> traffic or at least
|
|
||||||
<acronym>ICMP</acronym> 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.</para>
|
|
||||||
|
|
||||||
<para>The obvious question then becomes, if
|
|
||||||
<acronym>ICMP</acronym> is such a good and useful thing,
|
|
||||||
should we not let it all through, all the time? The
|
|
||||||
answer is <quote>It depends</quote>.</para>
|
|
||||||
|
|
||||||
<para>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</para>
|
|
||||||
|
|
||||||
<programlisting>pass inet proto icmp from any to any</programlisting>
|
<programlisting>pass inet proto icmp from any to any</programlisting>
|
||||||
|
|
||||||
<para>might not be optimal if the internal workings of the
|
<para>One solution is to let all
|
||||||
local network should be cloaked in a bit of mystery. In
|
<acronym>ICMP</acronym> traffic from the local network through
|
||||||
all fairness it should also be said that some
|
while stopping all probes from outside the network:</para>
|
||||||
<acronym>ICMP</acronym> traffic might be found quite
|
|
||||||
harmlessly riding piggyback on
|
|
||||||
<literal>keep state</literal> rules.</para>
|
|
||||||
|
|
||||||
<para>The easiest solution could very well be to let all
|
|
||||||
<acronym>ICMP</acronym> traffic from the local net through
|
|
||||||
and stop probes from elsewhere at the gateway:</para>
|
|
||||||
|
|
||||||
<programlisting>pass inet proto icmp from $localnet to any keep state
|
<programlisting>pass inet proto icmp from $localnet to any keep state
|
||||||
pass inet proto icmp from any to $ext_if keep state</programlisting>
|
pass inet proto icmp from any to $ext_if keep state</programlisting>
|
||||||
|
|
||||||
<para>Stopping probes at the gateway might be an attractive
|
<para>Additional
|
||||||
option anyway, but let us have a look at a few other
|
options are available which demonstrate some of
|
||||||
options which will show some of
|
<application>PF</application>'s flexibility. For example,
|
||||||
<application>PF</application>'s flexibility.</para>
|
rather than allowing all <acronym>ICMP</acronym> messages,
|
||||||
|
one can specify the messages used by &man.ping.8; and
|
||||||
<sect4 xml:id="pftut-letpingthru">
|
&man.traceroute.8;. Start by defining a macro for
|
||||||
<title>Letting <command>ping</command> Through</title>
|
that type of message:</para>
|
||||||
|
|
||||||
<para>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
|
|
||||||
<command>ping</command> which scared people into
|
|
||||||
filtering or blocking <acronym>ICMP</acronym> 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 <acronym>ICMP</acronym>, and in order to keep our
|
|
||||||
ruleset tidy, we start by defining another macro:</para>
|
|
||||||
|
|
||||||
<programlisting>icmp_types = "echoreq"</programlisting>
|
<programlisting>icmp_types = "echoreq"</programlisting>
|
||||||
|
|
||||||
<para>and a rule which uses the definition,</para>
|
<para>and a rule which uses the macro:</para>
|
||||||
|
|
||||||
<programlisting>pass inet proto icmp all icmp-type $icmp_types keep state</programlisting>
|
<programlisting>pass inet proto icmp all icmp-type $icmp_types keep state</programlisting>
|
||||||
|
|
||||||
<para>More or other types of <acronym>ICMP</acronym> packets
|
<para>If other types of <acronym>ICMP</acronym> packets
|
||||||
may need to go through, and <literal>icmp_types</literal>
|
are needed, expand <literal>icmp_types</literal>
|
||||||
can be expanded to a list of those packet types that are
|
to a list of those packet types. Type
|
||||||
allowed.</para>
|
<command>more /usr/src/contrib/pf/pfctl/pfctl_parser.c</command>
|
||||||
</sect4>
|
to see the list of <acronym>ICMP</acronym> message
|
||||||
|
types supported by <application>PF</application>. Refer to
|
||||||
|
<link
|
||||||
|
xlink:href="http://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml">http://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml</link>
|
||||||
|
for an explanation of each message type.</para>
|
||||||
|
|
||||||
<sect4 xml:id="pftut-helptraceroute">
|
<para>Since Unix <command>traceroute</command> uses <acronym>UDP</acronym>
|
||||||
<title>Helping &man.traceroute.8;</title>
|
by default, another rule is needed to allow Unix
|
||||||
|
<command>traceroute</command>:</para>
|
||||||
<para>&man.traceroute.8; is another command which is quite
|
|
||||||
useful when users claim that the Internet is not working.
|
|
||||||
By default, Unix <command>traceroute</command> uses UDP
|
|
||||||
connections according to a set formula based on
|
|
||||||
destination. The rule below works with
|
|
||||||
<command>traceroute</command> on all Unixes I have had
|
|
||||||
access to, including GNU/Linux:</para>
|
|
||||||
|
|
||||||
<programlisting># allow out the default range for traceroute(8):
|
<programlisting># 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</programlisting>
|
pass out on $ext_if inet proto udp from any to any port 33433 >< 33626 keep state</programlisting>
|
||||||
|
|
||||||
<para>Experience so far indicates that
|
<para>Since <command>TRACERT.EXE</command> on Microsoft Windows systems
|
||||||
<command>traceroute</command> implementations on other
|
uses <acronym>ICMP</acronym> echo request messages,
|
||||||
operating systems work roughly the same. Except, of
|
only the
|
||||||
course, on Microsoft Windows. On that platform,
|
first rule is needed to allow network traces from those systems. Unix <command>traceroute</command>
|
||||||
<command>TRACERT.EXE</command> uses ICMP ECHO for this
|
|
||||||
purpose. So to let Windows traceroutes through, only the
|
|
||||||
first rule is needed. Unix <command>traceroute</command>
|
|
||||||
can be instructed to use other protocols as well, and will
|
can be instructed to use other protocols as well, and will
|
||||||
behave remarkably like its Microsoft counterpart if
|
use <acronym>ICMP</acronym> echo request messages if
|
||||||
<option>-I</option> is used. Check the &man.traceroute.8;
|
<option>-I</option> is used. Check the &man.traceroute.8;
|
||||||
man page (or its source code, for that matter) for all the
|
man page for
|
||||||
details.</para>
|
details.</para>
|
||||||
|
|
||||||
<para>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 <link
|
|
||||||
xlink:href="http://marc.theaimsgroup.com/">http://marc.theaimsgroup.com/</link>),
|
|
||||||
to be a very valuable resource whenever you need OpenBSD
|
|
||||||
or <application>PF</application> related
|
|
||||||
information.</para>
|
|
||||||
</sect4>
|
|
||||||
|
|
||||||
<sect4 xml:id="pftut-pathmtudisc">
|
<sect4 xml:id="pftut-pathmtudisc">
|
||||||
<title>Path <acronym>MTU</acronym> Discovery</title>
|
<title>Path <acronym>MTU</acronym> Discovery</title>
|
||||||
|
|
||||||
|
|
@ -1035,60 +962,47 @@ pass out on $ext_if inet proto udp from any to any port 33433 >< 33626 kee
|
||||||
independent, and one consequence of device independence is
|
independent, and one consequence of device independence is
|
||||||
that the optimal packet size for a given connection cannot
|
that the optimal packet size for a given connection cannot
|
||||||
always be predicted reliably. The main constraint on
|
always be predicted reliably. The main constraint on
|
||||||
packet size is called the
|
packet size is the
|
||||||
<firstterm>Maximum Transmission Unit</firstterm>, or
|
<firstterm>Maximum Transmission Unit</firstterm>
|
||||||
<acronym>MTU</acronym>, which sets the upper limit on the
|
(<acronym>MTU</acronym>) which sets the upper limit on the
|
||||||
packet size for an interface. &man.ifconfig.8; shows the
|
packet size for an interface. Type <command>ifconfig</command> to view the
|
||||||
<acronym>MTU</acronym> for the network interfaces.</para>
|
<acronym>MTU</acronym>s for a system's network interfaces.</para>
|
||||||
|
|
||||||
<para>Modern TCP/IP implementations expect to be able to
|
<para><acronym>TCP/IP</acronym> uses a process known as path
|
||||||
determine the right packet size for a connection through a
|
<acronym>MTU</acronym> discovery to
|
||||||
process which, simply put, involves sending packets of
|
determine the right packet size for a connection. This
|
||||||
|
process sends packets of
|
||||||
varying sizes with the <quote>Do not fragment</quote> flag
|
varying sizes with the <quote>Do not fragment</quote> flag
|
||||||
set, expecting an <acronym>ICMP</acronym> return packet
|
set, expecting an <acronym>ICMP</acronym> return packet
|
||||||
indicating <quote>type 3, code 4</quote> when the upper
|
of <quote>type 3, code 4</quote> when the upper
|
||||||
limit has been reached. Now do not dive for the RFCs
|
limit has been reached. Type 3 means <quote>destination
|
||||||
right away. Type 3 means <quote>destination
|
unreachable</quote>, and code 4 is short for
|
||||||
unreachable</quote>, while code 4 is short for
|
|
||||||
<quote>fragmentation needed, but the do-not-fragment flag
|
<quote>fragmentation needed, but the do-not-fragment flag
|
||||||
is set</quote>. So if connections to networks which may
|
is set</quote>. To allow path MTU discovery in order
|
||||||
have other <acronym>MTU</acronym>s than the local network
|
to support connections to other <acronym>MTU</acronym>s, add
|
||||||
seem sub-optimal, and there is no need to be that
|
the
|
||||||
specific, the list of <acronym>ICMP</acronym> types can be
|
<literal>destination unreachable</literal> type to the
|
||||||
changed slightly to let the
|
<literal>icmp_types</literal> macro:</para>
|
||||||
<quote>destination unreachable</quote> packets through,
|
|
||||||
too:</para>
|
|
||||||
|
|
||||||
<programlisting>icmp_types = "{ echoreq, unreach }"</programlisting>
|
<programlisting>icmp_types = "{ echoreq, unreach }"</programlisting>
|
||||||
|
|
||||||
<para>As we can see, this means we do not need to change
|
<para>Since
|
||||||
the pass rule itself:</para>
|
the pass rule already uses that macro, it does not need to
|
||||||
|
be modified in order to support the new
|
||||||
|
<acronym>ICMP</acronym> type:</para>
|
||||||
|
|
||||||
<programlisting>pass inet proto icmp all icmp-type $icmp_types keep state</programlisting>
|
<programlisting>pass inet proto icmp all icmp-type $icmp_types keep state</programlisting>
|
||||||
|
|
||||||
<para><application>PF</application> allows filtering on all
|
<para><application>PF</application> allows filtering on all
|
||||||
variations of <acronym>ICMP</acronym> types and codes.
|
variations of <acronym>ICMP</acronym> types and codes.
|
||||||
For those who want to delve into what to pass (or not) of
|
The list of possible
|
||||||
<acronym>ICMP</acronym> traffic, the list of possible
|
types and codes are documented in &man.icmp.4; and
|
||||||
types and codes are documented in the &man.icmp.4; and
|
&man.icmp6.4;.</para>
|
||||||
&man.icmp6.4; man pages. The background information is
|
|
||||||
available in the <acronym>RFC</acronym>s
|
|
||||||
<footnote><para>The main internet <acronym>RFC</acronym>s
|
|
||||||
describing <acronym>ICMP</acronym> 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
|
|
||||||
<link xlink:href="http://www.ietf.org">ietf.org</link>
|
|
||||||
and
|
|
||||||
<link xlink:href="http://www.faqs.org">faqs.org</link>
|
|
||||||
web sites.</para></footnote>.</para>
|
|
||||||
</sect4>
|
</sect4>
|
||||||
</sect3>
|
</sect3>
|
||||||
|
|
||||||
<sect3 xml:id="pftut-tables">
|
<sect3 xml:id="pftut-tables">
|
||||||
<title>Tables Make Life Easier</title>
|
<title>Using Tables</title>
|
||||||
|
|
||||||
<para>By this time it may appear that this gets awfully static
|
<para>By this time it may appear that this gets awfully static
|
||||||
and rigid. There will after all be some kinds of data which
|
and rigid. There will after all be some kinds of data which
|
||||||
|
|
|
||||||
Loading…
Reference in a new issue