1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
<TITLE>The Mason HOWTO: Special considerations</TITLE>
<LINK HREF="mason-5.html" REL=next>
<LINK HREF="mason-3.html" REL=previous>
<LINK HREF="mason.html#toc4" REL=contents>
</HEAD>
<BODY>
<A HREF="mason-5.html"><IMG SRC="next.gif" ALT="Next"></A>
<A HREF="mason-3.html"><IMG SRC="prev.gif" ALT="Previous"></A>
<A HREF="mason.html#toc4"><IMG SRC="toc.gif" ALT="Contents"></A>
<HR>
<H2><A NAME="s4">4. Special considerations</A></H2>
<H2><A NAME="ss4.1">4.1 Kernel</A>
</H2>
<P> (Please note that most kernels provide the support necessary; it's
probably safe to check back with this section only if you have problems.)
<P>IP firewalling and firewall packet logging have to be compiled
into the kernel. To see if IP firewalling is compiled into your kernel,
type the command:
<HR>
<PRE>
ls -al /proc/net/ip_fwchains /proc/net/ip_input
</PRE>
<HR>
<P>If ip_fwchains exists, you have ipchains compiled into your
kernel. If ip_input exists, you have ipfwadmin firewalling compiled into
your kernel. If neither file exists, one of the following is true:
<P>
<UL>
<LI>Your kernel is too old. It appears that linux firewalling switched from
the old "ipfw" firewalling in 1.3.66, but some features require 2.0.0.
</LI>
<LI>Your kernel is missing the proc filesystem or it's not mounted
("mount /proc" will probably fix the latter). If your kernel truly doesn't
support the proc filesystem, reboot into the kernel that came with your
distribution, which almost certainly does.
</LI>
<LI>You have the right version of the kernel, but firewalling is not
enabled. You must recompile the kernel and turn on firewalling. See the
HOWTO's at
<A HREF="http://metalab.unc.edu/linux/HOWTO/">http://metalab.unc.edu/linux/HOWTO/</A>
to see how this is done. In
particular, see the masquerading and kernel HOWTO's.
</LI>
<LI>Your 2.4 kernel has iptables, which doesn't have a flag file like
ipfwadm and ipchains.
</LI>
</UL>
<P>When you recompile the kernel, I recommend you have all of the
following enabled: network firewalls, ip firewalling, firewall packet
logging, always defragment, proc filesystem, transparent proxy support, IP
masquerading, and icmp masquerading.
<P>To see if firewall packet logging is enabled in your kernel, type
one of the following commands:
<HR>
<PRE>
/sbin/ipfwadm -a deny -F -S 127.12.2.3/32 -o <Enter>
/sbin/ipchains -A forward -s 127.12.2.3/32 -l <Enter>
/sbin/iptables -A FORWARD -s 127.12.2.3/32 -j LOG<Enter>
</PRE>
<HR>
<P>The "-o" or "-l" at the end tells the kernel to log this particular
packet type (one which should never show up). If your kernel does not
support logging, I _think_ you would get an error. On the other hand,
I've never had a kernel that has firewalling but does not have logging.
The solution is the same - recompile your kernel to include both
firewalling _and_ firewall packet logging.
<P>(If recompiling a kernel is too daunting, try my automated kernel
builder, "buildkernel", which can be found at
<A HREF="http://www.stearns.org/buildkernel/">http://www.stearns.org/buildkernel/</A>).
<P>
<H2><A NAME="ss4.2">4.2 Ipfw, Ipfwadm, Ipchains, and Iptables</A>
</H2>
<P> Current versions of Mason handle ipfwadm, ipchains and iptables.
It will accept log entries created under all three firewall types
automatically. Mason automatically detects which kind of rule to
create, although this can be overridden with environment variables set
in /etc/masonrc. The masonrc file has comments describing these
fields.
<P>Make sure you have the ipfwadm, ipchains or iptables executable
- one of these should be included with your distribution.
<P>Mason has no support for ipfw firewalls (the firewalling used in
kernels prior to 1.3.66). I don't intend to pursue this type of
firewalling, but am not against integrating a patch if someone feels like
adding the support. Does anyone still use this?
<P>
<H2><A NAME="ss4.3">4.3 DNS</A>
</H2>
<P> Mason does not try to look up the hostnames of any machines involved
in DNS requests (unless they're in /etc/hosts). If it did, Mason could
enter a situation where it issues a steady flow of DNS requests to
resolve the machine names and each DNS request requires a new rule,
which in turn requires more DNS requests... ugh.
<P>The easy way to get machine names into your DNS rules is to make
sure all your DNS servers are listed in /etc/hosts . If they're not
listed there, Mason will just leave them as IP's.
<P>
<P>
<H2><A NAME="ss4.4">4.4 Rule order</A>
</H2>
<P> When a packet needs to be processed (at entry, forwarding, or
exit), the firewall scans the existing list of rules to decide whether to
allow, deny or reject the packet. As this scans stops at the first rule
that matches the packet, the order in which your final firewall rules are
executed can make a difference. This document only provides basic
coverage of how to order your rules - sorry. The best place to find out
more about this is in the O'Reilly and associates books.
<P>(If anyone would like to provide additional general guidelines as
to how this is done, I would be glad to place them here with the
appropriate disclaimers).
<P>
<H2><A NAME="ss4.5">4.5 Generalization</A>
</H2>
<P> The packets Mason processes are data transfers between specific
ports on specific machines. For example, here's a response packet from a
specific FTP server (linux.kernel.org) to what is probably a machine on
your LAN:
<HR>
<PRE>
/sbin/ipfwadm -i accept -W ppp0 -I -P tcp -S linux.kernel.org/32 ftp -D \
devel1.goober.net/32 1024:65535 # ftp/tcp
</PRE>
<HR>
<P>The rule above (possibly along with others) would only allow
devel1 to reach only linux.kernel.org, making for a ridiculously large
ruleset if other machines wanted to ftp out to linux.kernel.org or
wanted to reach other ftp servers.
<P>By default, Mason _generalizes_ the source and destination IP
addresses. For example, devel1.goober.net/32 is replaced with
210.134.12.0/24 (the fictitious network address block of which devel1
is a part). Since linux.kernel.org is not a part of any local network
blocks, linux.kernel.org is replaced with 0/0 (which matches any machine
anywhere).
<P>This automatic generalization can be disabled by setting
IPCONV="HOST" in /etc/masonrc.
<P>Mason also does some generalization on the source and destination
ports. Irc, X, realaudio, traceroute, and others use ranges of ports;
Mason knows how to generalize many protocols to the appropriate range.
<P>For the standard tcp and udp services, Mason generalizes the client
port to 1024:65535. The connection that prompted this rule might have been,
for example, port 1745 on devel1. As Mason didn't recognize 1745 as some
special server, it assumed that the next connection might be from, say,
port 1788. By using the entire range of high ports ("1024:65535" in the
above rule), Mason uses a pretty standard approach to packet filtering to
reduce the number of rules.
<P>
<H2><A NAME="ss4.6">4.6 Router or end node</A>
</H2>
<P> This program was originally intended for use on a traditional
firewall - a packet filtering router (linux box that connects 2 or more
networks through one or more interfaces). It works equally well on Linux
boxes with only one interface. These could be workstations on a LAN,
servers outside of your firewall, or even slip or ppp connected
workstations. The number of interfaces and their type and speed are
irrelevant to the firewall creation process.
<P>This would be great for locking down a web or mail server
outside your firewall, for example. Start up Mason and make sure you
make one of every kind of connection you want to that machine. Mason
will create the corresponding rules. Generalize these and add a default
policy of "deny". _Only_ the connection types you specified will be
allowed to that machine. The difficulty of setting up the rules has
been the major impediment to this kind of hardened end node in the past.
Now that Mason is here, there's no reason why every machine on your LAN
can't have packet filtering enabled and active.
<P>Note that on an end node (Linux box with a single NIC connected to
a single IP network) you should never see forwarding rules created - this
makes sense if you think about it.
<P>You could technically create a firewall on a machine with only the
loopback interface, but this would be more for instructional value about
internal tcp connections than for any security goal. On the other hand,
if you wanted to stop shell account users from getting to an internal Web
server, you certainly could; just make sure you put in blocking rules for
all interfaces, not just the loopback interface.
<P>
<H2><A NAME="ss4.7">4.7 Slow machines or fast nics</A>
</H2>
<P> As a shell script, Mason is much less efficient at its work than
a C app would be. On a slow machine, it can take a couple of seconds
from the time the log entry is fed into it until the firewall rule is
implemented. If the system is slow, if it has a lot of packets
traveling through it, or if it simply has a great deal of log file
traffic it can take Mason a long time to catch up. If this is the case,
start slow. Try one connection type at a time and give the system a
chance to settle before you move on.
<P>If Mason _cannot_ catch up, choose the "EL" (End Learning) option in
mason-gui-text. Wait until Mason stops, then restart learning.
<P>
<H2><A NAME="ss4.8">4.8 Active hacking while mason running</A>
</H2>
<P> If at all possible, try to set up these rules in a controlled
environment. Hook up your firewall to machines that simulate the routers
and networks that will be used in its final location. It is not a good
idea to create a firewall in an environment not completely under your
control.
<P>If you must create the firewall rules in a live environment, be
warned: Mason simply creates rules based on what traffic is passing
through it. IT CANNOT DISTINGUISH BETWEEN THE TRAFFIC YOU'RE CREATING TO
TEACH IT AND SOMEONE ACTIVELY TRYING TO HACK THROUGH YOUR FIREWALL. IF
THIS HAPPENS, MASON WILL CREATE RULES THAT _SPECIFICALLY_ _ALLOW_ PEOPLE
TO GET BACK IN LATER. _Please_ read and try to understand the rules
before you put them to use in a production environment.
<P>(I hate all caps too, but the "boldface" button on my keyboard is
jammed :-).
<P>The "hacker" mentioned above does not need to be a computer
criminal in a far-off country looking to crash your machines. This
individual could be someone in accounting that is (without malicious
intent) connecting to an Internet IRC server, when this doesn't fit in the
security policy you're trying to implement. If you don't read and
understand the rules Mason spits out, you may very well leave an explicit
opening for this user's future IRC use.
<P>One more time: Mason _does_ _not_ understand the traffic flowing
through your firewall; it just creates the rules that you can later use to
specifically allow or disallow this traffic. This is why it is a good
idea to delete any rules that look even vaguely suspicious. If it turns
out these rules are needed for normal operation, they will be relearned
when you restart Mason.
<P>
<H2><A NAME="ss4.9">4.9 Masquerading</A>
</H2>
<P> One of the common uses for Linux firewalling is to act not only as
a packet filter but also as a masquerading host, allowing multiple
machines to share a single IP address.
<P>As of Mason 0.13.0, Mason will automatically masquerade traffic from
RFC 1918 (also called "reserved") addresses. Since you probably don't
want to masquerade between internal lans, you need to list all the
interfaces leading _out_ to the real world (_not_ the interfaces that
use these reserved addresses).
<P>
<H2><A NAME="ss4.10">4.10 Offline and non-root creation</A>
</H2>
<P> If you are especially cautious, you might not want Mason actively
creating rules on your production server. Or maybe you think you've
created a good firewall, but keep getting log messages and don't know how
to keep your log files from filling your disk. Or perhaps your CPU can't
keep up. Or maybe you just don't trust Mason's author - no offense taken
:-). In all of the above circumstances, Mason can create the commands
without actually being fed the log messages live. For example, if you
have packet logging entries in /var/log/messages, try this:
<HR>
<PRE>
cat /var/log/messages | grep ' I=' | DOCOMMAND="none" mason <Enter>
</PRE>
<HR>
<P>The output can, of course, be tee'd, redirected to a file, piped
to less, etc. "... | sort | uniq" can be useful too when you're not
converting it live.
<P>Obviously, the source file can be one that has been transferred
from another machine.
<P>There is one caveat to the offline approach. The specific case is
when one has a "deny" or "reject" policy in place for the input logging
rule. Let's say I try to telnet through the firewall. My packet arrives
at the firewall, is stopped and logged (so Mason can successfully create
the correct input rule later). The firewall never has a rule implemented
that allows me to get any further than that, however, so there is never a
log entry created for any of the remaining 5 packet checks.
<P>One way around this might be to use a policy of "accept" on your
logging rules while you're creating /var/log/messages for later
consumption by Mason. I'm not saying this is appropriate for you, but
might be one way to handle this. Be warned; this can create very large
log files as every packet passing through the system can create 6 log
entries!
<P>One final use for this technique is creating the rules when you're
not root. Simply edit /etc/masonrc to set DOCOMMAND="NO" and the script
will still output the appropriate ipfwadm/ipchains commands but won't
try to execute them, allowing non-root users to create the firewall rules.
Note that you still need to be root long enough to turn on some kind of
logging, or /var/log/messages will never contain any entries to convert.
Root privileges are also required to implement the rules once you've
created them.
<P>
<P>
<H2><A NAME="ss4.11">4.11 /etc/services and special ports</A>
</H2>
<P> Mason converts the protocol number and type (i.e. 53, udp) into
the more common name (domain, in this example). It uses the /etc/services
file to do make this conversion. Before you start, make sure all the
protocols you will work with are listed there. If a particular protocol
is not in that file, Mason will have serious problems producing accurate
rules.
<P>Having this entry is especially important if you are working with
services whose ports are >= 1024 (nfs, X, squid, irc, vdolive, etc.). If
a service >= 1024 is not found in /etc/services, it will be automatically
(and incorrectly) generalized to the port range of 1024-65535. If your
favourite service isn't in there, simply edit the file and add it in the
same format as the other entries.
<P>These services whose ports are >=1024 can occasionally show up in
your rules where Mason should have used 1024:65535 instead. Well, you
know how to fix this, right? Just delete the rule, add the service to
/etc/services, and relearn it.
<P>The entries in /etc/services should only be for well-known server
ports. Client ports (which are usually just random ports between 1024 and
65535 anyways) should not be listed in here. The specific example of
something that should be missing is the ssh client port.
<P>If you plan to do the conversion on one machine and actually run
the firewall on another, make sure all of the protocols used are listed in
the /etc/services on both machines.
<P>The authoritative source for these ports is the Internet Assigned
Numbers Authority (IANA). A list of these ports can be found at:
ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers . Mason
includes what seems to be an even more up-to-date reference; see
/var/lib/mason/nmap-services. Many thanks to the authors of nmap.
<P>
<H2><A NAME="ss4.12">4.12 Insert vs. append</A>
</H2>
<P> Ipfwadm has two ways of adding rules: at the beginning of the rule
list using insert ("-i"), or at the end of the list using append ("-a").
The usual way of creating the firewall is to flush the existing rules and
then add each of the rules using append so they will be scanned in the
same order in which they were implemented. For this reason, the rules
that Mason spits out to stdout use "append" so they can easily be put in a
shell script.
<P>Mason needs some way to tell the kernel to not log already logged
packets anymore. The way to do this is to put a matching rule before the
logging rule. Unfortunately, that means one of two things: deleting the
logging rule at the end, implementing the new rule at the end, and
reinstating the logging rule, or simply inserting the new rule at the top
of the list. The first option is tricky to do well. It's also a bad
choice because the user using Mason may not be logging everything, so
mason doesn't know what logging rule to reinstate. That leaves using "-i"
to insert the rule at the very top of the list.
<P>The end effect is that the rules that Mason displays use "-a" to
match how that would be put into a rule file, but the rules that are
actually implemented while Mason is running use "-i" to avoid relogging
those packets again in this Mason run.
<P>The major side effect of this approach is that the rule set in
memory as Mason is running is almost certainly _not_ in the order you'd
want. The final firewall rule set you put in place should flush whatever
is in memory before starting so as to clean out these incorrectly ordered
rules.
<P>As ipchains and iptables support additional user defined chains,
we can throw all the temporary rules in user defined chains (called
inputN, outputN, and forwardN; the "N" stands for Nolog). These chains
get called just before the logging rules.
<P>
<H2><A NAME="ss4.13">4.13 Allow versus deny and reject</A>
</H2>
<P> During the course of a Mason run, it's quite reasonable that the
firewall creator might want to spend some time working with traffic types
that he/she wants to allow, and then switch over to other traffic types
that he/she wants to reject or deny (see man ipfwadm for the subtle
difference between deny and reject). If you change any settings
by choosing "Change Settings" in mason-gui-text, it will automatically
signal a running Mason to re-read its configuration file. You can
do the same if running mason manually by typing "killall -USR1 mason".
<P>Changing the target of a single rule to Accept, Deny, Reject, or
Masquerade can be done right in the menu under that rule without having
to go back to the main menu and changing the global settings.
<P>
<H2><A NAME="ss4.14">4.14 Input, Output, and Forwarding</A>
</H2>
<P> To implement packet filtering, the Linux kernel needs to inspect
each packet at at least one of the following three times: when the packet
enters the system, as it passes through the system on the way to its exit
interface, and as it leaves the system.
<P>At each of those three times, the kernel can decide to allow or
deny/reject the packet. The rules can be different at each stage - it's
perfectly legal to, for example, allow it in, allow it to be forwarded,
but then block it at the last second before it leaves the system.
<P>A simple firewall could be implemented using just, say, input
rules(*). It's when you get complex firewalls that having rules at all
three stages is useful. You might want to allow hosts from eth0 to get to
a pop-3 server on eth1, but not allow hosts from eth2 to get to the same
server. This kind of restriction might be impossible to do without
forwarding rules, especially if eth2 hosts _should_ be allowed to get to a
pop-3 server on eth0.
<P>For simpler firewalls, or if you want less than the imposing
grandeur of a firewall ruleset that goes on for pages and pages, Mason can
accomodate you. If you just want input rules, add the following to
/var/lib/mason/baserules :
<HR>
<PRE>
if [ -f /proc/net/ip_fwchains ]; then
/sbin/ipchains -A forward -j ACCEPT
/sbin/ipchains -A output -j ACCEPT
elif [ -f /proc/net/ip_input ]; then
/sbin/ipfwadm -F -a accept
/sbin/ipfwadm -O -a accept
fi
</PRE>
<HR>
<P>Place any general traffic types you don't care about in baserules.
<P>Please note that I am _not_ advocating the above, but pointing out
that the technique is available for those that feel the reduced
security is appropriate for them.
<P>(*) The exceptions to this are the special rules for redirecting packets
(which must be done as an input rule), and masquerading packets, (which
must be done as a forwarding rule). Even in the cases where you wish to
use these facilities, it's still legal to implement packet filtering using
another rule type.
<P>Please note that the above does not apply to iptables. In
iptables, packets are not inspected multiple times in multiple chains.
<P>
<H2><A NAME="ss4.15">4.15 Remote firewall creation - Telnet/ssh lockout</A>
</H2>
<P> If you're creating this firewall rule set and you're telnetting,
ssh'ing, or rsh'ing (collectively, "telnetting") in to the firewall, be
careful. Some of the first rules to be created will be for the telnet
packet flow you're using. If you are so unfortunate as to start this
process with a policy of deny, guess what packet flow will be stopped
almost immediately? That's right, your telnet session(s). Your machine
will be completely locked down with no way to remotely reach it. (Now
where were my car keys? <grrrr>)
<P>If you want to put the rules allowing your remote access before
starting Mason, great. If not, just make sure that your startup policy is
allow or it's remote reboot time! Logging in on any of the console's
virtual terminals does not require TCP/IP packets, so you can never lock
yourself out completely.
<P>You did read the section above on "simulating the working
environment under controlled conditions", didn't you? Are you still sure
you want to be creating a firewall not directly under your control?
Just a thought...
<P>
<H2><A NAME="ss4.16">4.16 Ack flag</A>
</H2>
<P> Let's look at some standard rules that allows a telnet connection
to a server somewhere (these are only two of the 6 possible rules).
<PRE>
allow LAN_IP's, ports 1024-65535 -> Outside_world_IP's, port 23
allow Outside_world_IP's, port 23 -> LAN_IP's, ports 1024-65535
</PRE>
<P>It looks pretty safe, right? Hmmm....
<P>Let's say that one of your LAN machines runs a squid server. This
sits waiting for connections on port 3128. Additionally, consider the
possibility that the root user on some Outside_world_IP machine writes
some program that starts a connection _from_ port 23. This user starts
this program and connects to your LANs squid server.
<P>All with your firewalls full consent. Ugh.
<P>The way to avoid this problem is to be able to identify the
_direction_ in which the connection is created. We want to allow
connections that start _from_ LAN:1024-65535 _to_ Outside:23, but block
connections that start _from_ Outside:23 _to_ LAN:1024-65535.
<P>The TCP ACK flag comes to the rescue. The first packet in a
connection does _not_ have this flag set. Every packet after the first
_does_ have this flag set. If we require all packets coming from the
server port have their ACK flag set, we can stop the bogus connection
from port 23 back to port 3128.
<P>In short, by requiring all packets from a server port have their
ACK flag set, we block connections that originate from those server ports.
<P>Three notes. Only TCP uses ACK flags, so we can't use this to
control the direction in which icmp or udp conversations are initiated.
Secondly, DNS may be a problem. Tcp domain transfers and large dns
requests can be from port 53 to port 53, depending on what dns software
you're using. FTP-data connections do not have their ACK flag set
because they can be created in either direction. Finally, there may be
issues from ssh low ports if /etc/services has entries up near 1023.
<P>Mason is able to automatically set the ack flag if your
/etc/services lists all of the services you use.
<P>I specifically avoided the "-b" (bidirectional) flag so that I
could use "-k" to control the direction.
<P>Iptables uses the state of the connection as a more dependable
way of handling the above problem. I'd generally encourage you to use
the "-m state --state ESTABLISHED,RELATED" lines in baserules. If you
do, then Mason hands you a single rule for any given type of traffic;
the opening packet. The ESTABLISHED,RELATED lines handle all the other
packets.
<P>
<P>
<H2><A NAME="ss4.17">4.17 Limitations, Ideas and future enhancements</A>
</H2>
<P>
<UL>
<LI>group foreign machines into additional rule? (Document how.)</LI>
<LI>Document the living hell of NFS.</LI>
</UL>
<P>
<HR>
<A HREF="mason-5.html"><IMG SRC="next.gif" ALT="Next"></A>
<A HREF="mason-3.html"><IMG SRC="prev.gif" ALT="Previous"></A>
<A HREF="mason.html#toc4"><IMG SRC="toc.gif" ALT="Contents"></A>
</BODY>
</HTML>
|