Building Internet Firewalls (First Edition) - Errata
Second Edition Errata available from O'Reilly & Associates web site
Last updated 14 July 2000 by Brent Chapman.
This document describes errors in various printings of First Edition of the book Building Internet Firewalls, by D. Brent Chapman and Elizabeth D. Zwicky (First Edition, 1995, published by O'Reilly & Associates).
Errors in the Second Edition (O'Reilly & Associates, June 2000) are described elsewhere.
Each time O'Reilly & Associates prints a new run of the book, they correct any minor errors that have been identified since the previous printing.
Each entry lists the page number of the error, describes the error, and which printing it first appeared in (if it wasn't there in the First Edition printing). The document is organized by printing, and lists the corrections made in each printing. At the end, we also list the errors that have not yet been corrected in any printing.
You should determine which printing you have, then read the sections of this document that describe errors fixed in printings after the one you have, as well as errors that have not yet been fixed in any printing.
To determine which printing of the book you have, look at the copyright page, between the title page and the table of contents. In the bottom right corner of the copyright page, below the recycling information and to the right of the ISBN number, all but the First Edition printing have a printing date.
The First Edition printing does not have a printing date in the bottom right corner of the copyright page. You can verify that you have a First Edition printing by looking at the "Printing History" section near the middle of the copyright page; it should list only "September 1995: First Edition" (later revisions have more entries in the "Printing History" section).
There have been several printings of the book, including (but not limited to):
If you find any errors in the book, please report them to Firewalls-Book@GreatCircle.COM .
In the second table, the destination address for Packet 4 should be 172.16.1.1.
At the top of the page, the description of Packet 4 should read "Packet 4 is from a random machine at the university to one of your nonproject machines; you want it to be denied; it is, by rule C."
In Figure C-13, the first 2 bits of a Class B address should be "1" and "0" (not "0" and "1" as shown).
Page x (Table of Contents)
Page numbers for chapters 11, 12, and 13 are off by 2. The actual page numbers are 2 greater than what's shown in the table of contents.
Page xi (Table of Contents)
Page number for "Internet Routing Architecture" in Appendix C is incorrect; should be 491.
Page xv (Table of Figures)
Page numbers for figures in Chapter 13 are incorrect; actual page numbers are 2 greater than what is shown in the table of figures.
Page xxiii (Preface)
In the footnote, the correct title of Craig Hunt's excellent book is TCP/IP Network Administration. Oops... We really do like the book a whole lot, and we really do use it all the time, and we have no idea why nobody (neither of the authors, nor any of the fine folks at O'Reilly & Associates) caught this error. Our sincere apologies to Craig Hunt.
Page xxv (Preface)
In the second paragraph of the Acknowledgments, we again got the title of Craig Hunt's book wrong; the correct title is TCP/IP Network Administration. Honestly, we've all got dog-eared (i.e., well-used) copies close at hand, and use it all the time; I have no idea why we didn't glance up and notice that we'd gotten the title wrong...
There was a minor graphics problem with Figure 4-4; the shading between the cloud and the "Firewall" was misaligned.
Near the end of the 4th line of the 2nd paragraph, "dual-homed" was misspelled.
In the footnote, the actual publication date of the second edition of Practical UNIX Security will be some time in 1996.
In the second line of the first paragraph of the "Logging Actions" section, the word "denied" was misspelled.
In the table at the top of the page, the "Protocol" column header was misspelled.
In the caption for Figure 6-10, the closing parenthesis was omitted.
At the end of the 3rd line in the 1st paragraph of the "Other TIS FWTK Proxies" section, there was a space missing between "http-gw" and "with".
In the first line of the "Multimedia Internet Mail Extensions (MIME)" section, the word "electronic" was misspelled.
In the first bullet item near the top of the page, the phrase "packets with the ACK . set" should read "packets with the ACK bit set".
In Figure 10-3, in the very last text block, the last sentence should read `If server says "no," tells...'
The last paragraph before the "Planning for Disconnecting or Shutting Down Machines" section should read
In a small organization, you will pick your fallback candidates by name. In a large one, you will usually specify fallbacks by job title. If job title is your criterion, it's important to base your decision on the characteristics of the job, not of the person currently in it. Don't write into your plan that the janitor should decide, on the theory that the current janitor also is the most sensible and technical of those who aren't system administrators. The next janitor might be an airhead with a mop.
Page 441 (Part IV intro)
In the last paragraph, the correct title of Appendix C is "TCP/IP Fundamentals".
In the section on RFC1244 by Holbrook & Reynolds, the formatting is a little broken. The paragraph that begins "Note that the Internet RFCs ..." should be part of this entry, instead of appearing to be a separate entry.
Also, in that same entry, the FTP and HTTP URLs have been run together; the first pair should be:
and the second pair should be:
The last sentence in the section on Craig Hunt's book (the first entry on the page) should read "... is adapted from the first two chapters of this book."
Page 513 (Index)
RFC1597 and RFC1627 are on page 90.
Page 520 (Colophon)
The first sentence of the last paragraph should read "The inside layout was designed by Nancy Priest, Edie Freedman, and Jennifer Niederst."
Figure 6-3 shows an IP header, not a TCP header. For a picture of a TCP header, see Figure C-8 on page 479.
In the 11th entry of the table ("Data channel creation for outgoing FTP request, passive mode"), the "Dest. Addr" column should say "Ext", not "Int".
In the "Proxying Characteristics of Telnet" section, the sentence that says "The TIS FWTK Telnet proxy server will not allow you to reach servers other than Telnet (on port 23) ..." should be deleted; it is incorrect.
In the 7th entry of the table ("Outgoing query via TCP, client to server"), the "ACK set" column should say "b" instead of "a".
In the sixth line of the second full paragraph (which begins "For all of these reasons ..."), the word "pre-infected" is misspelled.
In the next-to-last paragraph, the italicized words at the end of the next-to-last sentence should read "/bin/cat /etc/finger_info"; that is, there should be a space after "cat".
In the next-to-last paragraph (which begins "If you have a dual-homed host ..."), the second sentence (which begins "In order to act as an IP router ...") should be replaced with:
In order to act as an IP router, a dual-homed host needs to accept packets that are addressed to other machines' IP addresses, and send them on appropriately.
In the second and third tables, the column label that says "Rule" should say "Packet".
In the second table, the column label that says "Rule" should say "Packet".
The third sentence of the next to last paragraph should read "... the Igateway package from Sun (written by Jim Thompson) ...".
In the last line on the page, the sentence should read "... and the port the connection came in on ...".
In the 9th entry of the table ("Data channel creation for outgoing FTP request, normal mode"), the "Dest. Addr." column should say "Int", not "int".
The last sentence of the first paragraph of the "Internet Relay Chat (IRC)" section should refer to Figure 8-12, not Figure 8-10.
The third paragraph should start "There is also a WWW-browsable archive for Firewalls ..."
Page 453 - superceded by newer information below
Marcus Ranum's current email address is <email@example.com>. The current origin of the Firewalls FAQ is:
RFC1918 has superceded and obsoleted RFC1627.
In the first full paragraph, which begins "Users can now ...", the following should be added to the end of the paragraph:
Note that if your site creates a top-level index of your FTP area (such as a file containing the output of "ls -lR ~ftp"), you need to make sure that the hidden directories don't appear in the index; the easiest way to do that is to run the indexing command as the "ftp" user, so that it has the same permissions that someone using anonymous FTP would have.
The first paragraph should read:
TFTP is a UDP-based protocol. Servers listen on port 69 for the initial client-to-server packet, to establish the TFTP session, then use a port above 1023 for all further packets during that session. Clients use ports above 1023.
The table should look like this (changes and additions are noted in bold text):
|Direction||Source Addr||Dest Addr||Protocol||Source Port||Dest Port||Notes|
|In||Ext||Int||UDP||>1023||69||Incoming TFTP request (first packet from client)|
|Out||Int||Ext||UDP||>1023||>1023||Response to incoming request|
|In||Ext||Int||UDP||>1023||>1023||Subsequent packets from client|
|Out||Int||Ext||UDP||>1023||69||Outgoing TFTP request (first packet from client)|
|In||Ext||Int||UDP||>1023||>1023||Response to outgoing request|
|Out||Int||Ext||UDP||>1023||>1023||Subsequent packets from client|
All references in the text to "ports below 1023" should be changed to "ports below 1024". All references to "<1023" in the Source Port or Destination Port columns of the tables should be changed to "<1024".
The second sentence of the section on rexec should be changed to:
It's rarely used because it has few standard clients; the only utility commonly shipped with UNIX systems that we're aware of that uses rexec is the inst software installation tool that's part of the Silicon Graphics IRIX operating system, for remote software installations.
In Figure 8-11, the lower right box in the diagram should be labelled "Answering Client", not "Answering Server".
In the first paragraph, the sentence that ends in the fifth line should read "... nameservers for the net domain.". The next sentence should read "It then asks one of those net nameservers which machines ..."
In the next-to-last paragraph, the statement that "machines running IBM's AIX operating system always use TCP" is no longer true; IBM changed this behavior some time ago.
In Figure 8-13, near the top center and top right corner of the diagram, the two instances of '" "' should read '"."', since "." generally signifies the root of the DNS tree.
Also in Figure 8-13, the bottom-most machine should be labelled "DNS Client" not "DNS Server".
In the first line of the first set of sample DNS data, there should be a space between "tiger.somebody.net." and "root.tiger.somebody.net.".
The information-hiding DNS configuration ("split brain DNS") described in the book does not work if you use subdomains within DNS (i.e. you are "somebody.net" and have subdomains such as "engineering.somebody.net", "sales.somebody.net", etc.).
... In the configuration you recommend, you point the bastion host's resolver at an internal name server, which is authoritative for some portion of the internal name space. The internal name server is also configured to use a name server running on the bastion host as a forwarder. The problem arises when the internal name server isn't authoritative for the entire internal name space.
Say, for example, your internal domain is foo.com and your bastion host's resolver emits a query for host.sub.foo.com. The internal name server receives the query but uses the configured forwarder rather than following the delegation to sub.foo.com. And, of course, the bastion host's name server has only minimal information about foo.com, probably not including delegation to sub.foo.com, and certainly not including delegation to the internal sub.foo.com name servers. Hence it returns NXDOMAIN.
I go over a few configurations in the new edition of DNS and BIND that (I feel) address this. None is perfect, but here's the one I use most commonly:
- Configure the bastion host's resolver to use the local name server.
- Configure the bastion host's name server as a secondary for the real foo.com, and protect foo.com with secure_zones.
- (Optionally) Protect the bastion host with border router-based access lists.
- Set up an external name server for the shadow foo.com, and have your ISP(s) configure their name server(s) as secondary. Have the NIC delegate to these.
Now you have a name server on the bastion host that is "wall-eyed": that is, it can see into the Internet's name space and into your internal name space, which is what it needs. It'll follow delegation from foo.com, since it isn't using forwarders to override the normal resolution process.
The one major weakness I can see in this configuration is that there is still the possibility of someone pointing a resolver directly at the bastion host's name server and looking up data in a subdomain of foo.com, since secure_zones doesn't apply to delegated subdomains. You can either add secure_zones to everything -- possibly cumbersome -- or just live with the possibility. Of course, using a border router or bastion host capable of doing state-based UDP filtering would help.
All references in the text to "ports below 1023" should be changed to "ports below 1024". All references to "<1023" in the Source Port or Destination Port columns of the table should be changed to "<1024".
The parenthetical comment in the last sentence on the page should be changed to "(e.g., some clients always use TCP, even though most DNS clients use UDP by default)".
The first sentence should read "All of these things can happen to TCP packets, too, but they will be corrected before the data is passed to the application."
In the sample Cisco access control lists at the top of the page, the two lines that say "interface serial 0" should be changed to say "interface serial 1" so that they match the explanation of the sample.
The last line of the last paragraph (before the footnote) should read "... this subnet can only reach your project subnet.".
In the fifth line of the second paragraph, the word "disregard" is misspelled.
The last line should read "... converted to use SOCKS) ...".
In the first sentence of the first paragraph, move the parenthetical reference to "(ftp-gw)" to the end of the sentence; ftp-gw is a modified user procedure proxy server.
The sentence that begins on the third line should read "Often there are other acceptable ways ...".
The next-to-last line on the page should read "... which those users think will do neat things ...".
Under the discussion of rule DNS-2, add the sentence "Note that rule DNS-2 (which allows server-to-server communication) is redundant if rule DNS-3 (which allows client-to-server communication) is present."
The last line of the second paragraph should read "There is one good reason for this: ..."
In the bulleted item that begins "Directories that contain ...", the second sentence should read:
For example, on UNIX machines, directories should contain two entries with names made out of periods ("." and "..", indicating "this directory" and "parent directory"), but there should not be more than two such entries (for instance, "..." or "..<space>").
Marcus Ranum's email address has changed again, to <firstname.lastname@example.org>. The current origin of the Firewalls FAQ is
In the sample /etc/services file, about one third of the way down the list of services, "Telnet" should not be capitalized; it should be "telnet".
None that we know of.
If you find any errors in the book, please report them to Firewalls-Book@GreatCircle.COM .
Great Circle Associates, Inc.
2608 Buena Vista Ave.
Alameda, CA 94501 USA
Please report problems to Webmaster@GreatCircle.COM
Copyright © 2013 Great Circle Associates, Inc.
USA Toll Free: 877 GRT CRCL
(877 478 2725)
International: +1 415 861 3588
Fax: +1 415 552 2982