In case you don't already know, FWTK stands for the FireW
all Tool Kit. It is used as a base to create a secure firewall
system. If you need good documentation, please read the source code. If
you are not familiar with C or do not feel comfortable with performing the
configuration and security verification yourself, then I would suggest that
you purchase a commercial firewall from a vendor (such as TIS, Checkpoint,
Raptor, etc.).

A machine needs other tools to secure it, including, but hardly
limited to, tools to check files (tripwire), audit tools (tiger/cops), secure
access methods (kerberos/ssh), something to watch logs and machine states
(swatch/watcher some to mind) and filtering and routing tools such as screend/ipfilterd/ipacl.

Again, I would recommend that you do not proceed to build a production
FWTK firewall unless you are familiar with UNIX security.

#########################
TIS, under a broader ARPA contract, developed the FWTK, and made it freely
available under license on October 1, 1993. TIS has retained the commercial
rights to the FWTK. The FWTK was, and is, freely available in source code
form (as was TIS's custom) for the research community. The FWTK has been
retrieved by over 50,000 individuals on 6 continents. (We will issue a press
release when we land Antarctica or a space station. If anyone *is* using
this in space or in Antarctica, please let us know.)

Brian Reid and a couple of folks at DEC had a corporate gateway,
called gatekeeper.dec.com. Paul Vixie took over operating it and was providing
services to a growing list of folks inside the company - they'd telnet in
and FTP out, or whatever. I worked in one of DEC's sales support units, for
Fred Avolio, and we had an Internet connection (9600 baud!!) via an aging
MicroVAXII and Fred told me to clean it up some and "make it look like what
Paul has in gatekeeper" I think I have Fred's original napkin drawing
in my archives someplace. I keep meaning to look for it so I can frame it
for him. :) Gatekeeper in those days was what we'd now call a gateway host
and there was a screening router built on another MicroVAX running an early
Mogul screend. So I built something like that. But I didn't want to give
people accounts on it, so one Xmas break I wrote an FTP proxy in a fit of
hacking. And it worked pretty well. So instead of giving out accounts like
Paul did, I started giving people access via proxies. That worked real well.
Then one of our sales guys, in a fit of enthusiasm, sold "a firewall like
decuac" to a REALLY huge customer and I wound up cloning the system onto
a couple of DECstations and that was, I believe, the first commercial Internet
firewall. Then I had to write the documentation for the bloody thing, and
so it needed a name, so we stole "SEAL" which the guys in Palo Alto had
been talking about for a firewall product but what the heck, we'd already
sold something. :) The next best bet for the name, was "PIG" for "Packaged
Internet Gateway" but that, as it were, didn't fly. From that one customer,
once the documentation had been written, sales took over and we got a little
busy with firewalls from then on. :)

Fred went to TIS and Marcus was looking to leave DEC and [was
going to go to a big place that recently IPO'd and would have made him a
millionaire but he didn't go there] he interviewed at TIS and got a job
there instead. :) And fate had it that about a month afterwards, ARPA called
up and asked "do you guys know anything about these firewalls things?" and
it turned out that the White House was going online and so proposals happened
and then funding happened and so we were officially researching Internet
firewalls and part of that effort included setting up whitehouse.gov and
part of that effort included writing tools for whitehouse.gov which evolved
into a chance to sit down and rethink firewalls and maybe write a better
one...

I [Marcus Ranum] wrote all the code for the bloody thing, and
all of the documentation, up until almost a year later when we hired Peter
Churchyard who brought us the http proxy and Wei Xu who wrote the X proxy.
While they were doing that, I kitted the whole thing up on an Intel box
and that was the GauntletV1.0. Pete and Wei and Char and Dave subsequently
took over the hard work of actually making things work, and I became a useless
suit at that point, yakking on the phone all day and generally being a pain
in the neck. :) Though I no longer work at TIS, I am still a pain in the
neck. :)

Our purposes for releasing the FWTK were:
- to demonstrate, via the software, documentation, and methods used,
how a company with (at the time) 11 years' experience in formal security
methods, and individuals with firewall experience, developed firewall software
- to create a common base of very good firewall software for others to build
on (so people did not have to continue to "roll their own" from scratch)
- to "raise the bar" of firewall software being used.

###########################
The FWTK is a bit of a marketing ploy? I'll leave that alone. The
poster must be young, inexperienced, or new here.

Yes, the FWTK is fabulous if you are willing to do a lot of extra
work yourself. 50,000 downloads later, we still see about 5,000 a month.
It seems to be successfull enough on its own. No, TIS doesn't add enough
features to it to make you decide not to buy a commercial firewall from
us or anyone else. We're crazy but we're not stupid. (Well, okay so
maybe sometimes... :-))

What's a "crystal box?" Since those words were first uttered
by our first customer, and since we got his permission to use it, I'll expand
on it:

"Crystal Box Design. A Crystal Box approach is the opposite of
"black box." With a crystal box approach, the source code and algorithms
that implement security are examinable. In the case of the Gauntlet Internet
Firewall, the code is examinable by any Gauntlet customer. The core functionality
of the FWTK is examinable by anyone with FTP access to the Internet. We
do not depend on the secrecy of our algorithms, methods, or source code for
security. A Crystal Box design means the Gauntlet Internet Firewall, has
benefited from experts in the firewall field who have examined it, used
it, and commented on it."

The Gauntlet Internet Firewall and the TIS Internet Firewall Toolkit
do not share the same code base for anything, typically, and haven't since
version 1.0. (There may be a proxy or two that is identical in cases where
TIS decided to just give the code away to the FWTK users. No user-supplied
code is used without permission and attribution.)

Gauntlet source code is available. We've just unbundled it from
some of the kits. Why? Fewer than 10% of our customers used it. It
is still available. All we ask is a license agreement be signed to protect
our intellectual rights. Why else? UNIX systems are starting to ship
without C Compilers. Solaris is an example.

If you've asked for source and been waiting for months and not
received it and you are a TIS customer, drop me e-mail please. No it's not
the proper channel, but mistakes do get made.

Fred
##########################

1.4: The documentation isn't
included with the toolkit. Where do I get it?

You can find the full FWTK documentation (including user's guides, man
pages, etc.) is in the same place where you downloaded the toolkit. Just
follow the instructions in the README or in the above question.

The filename is "fwtk-doc-only.tar.Z".

1.5: Where can I find the documentation
in something other than PostScript format?

When configuring Netscape Mail you need to append the port to use to the
end of the host name. In Netscape (v3.01 described here) select Options
-> Mail and News Preferences. On the Preferences panel select the Servers
tab.

Change the Outgoing Mail (SMTP) Server to reflect the fully qualified
host.domain name of your firewall followed by a colon and port number to
connect to.

Example: proxy.yourdomain.com:2010

Do the same for the Incoming Mail (POP3) Server, but use a different
port.

Example: proxy.yourdomain.com:2009

You will need entries in the /etc/services file to support
the ports you choose above as follows:

You will need entries in the /usr/local/etc/netperm-table file
to tell FWTK what you want to do when requests come in on these ports. your.net.address.*
refers to the address range you wish to authorize to this service. host.domain.com
refers to the fully qualified host/domain name of the POP server to contact.
port 110 is standard listening port for POP server and port 25 is standard
listening port for SMTP:

In other words provide a limited DNS for Internet consumption but use your
internal DNS to resolve hostnames for services on the Firewall. This
gives the firewall full access to information about your internal network
while still keeping internal host data off of the Internet.

Set up external DNS on the FWTK machine.
This DNS server is the one that the InterNIC points to for your DNS.
Create full DNS records for the host(s) you have directly connected to the
Internet.
Do not give out information on your internal network here! SOA - source of
authority
NS - name server records
A - Address record(s)
MX - Mail exchanger record(s) - Make certain you use actual A records for
this host no CNAMEs
HINFO - Host Info records

Set up DNS on an internal server.
This DNS server is used by only your machines, fill it with every piece of
information you require. Again create full DNS records for all hosts including
BOTH interfaces of the Firewall. Don't forget to give your external interface
a name otherwise you will run into trouble with sendmail if the Firewall
needs this information. I typically enter this in /etc/hosts also.
Hostnames may be any valid hostname including duplicates of hostnames you
used on the outside. This is where you can play games with hostnames.
For instance you can call both of your Web servers, internal and external,
www.yourdomain.com Hosts on the Internet will talk to your external
Web server and your internal network will talk to your Intranet server.
This can be very helpful if you have people internally and externally that
need services such as e-mail, web, nntp, etc. there is no need to make client
changes based on where they are. The client requests the same hostname
and DNS points them at the correct server.
In named.boot:
You do not need a root server "cache" for internal servers, but some servers,
Solaris, have trouble without it.
Add a forwarders line to the end of the file with the IP address of your
Firewall's internal interface. This will resolve hostnames for external domains.

All machines should point to the internal DNS server for host
name resolution, including the Firewall.
resolv.conf on your Firewall should have the "nameserver" entry with
the IP address of your internal DNS server. This way your Firewall
knows about your internal network and can also resolve information on the
external network, via the forwarder, a.k.a. your firewall.

This should get give you the basic concept of split DNS.
There are many references on the net for DNS configuration, a good place
to start is at the BIND home page: http://www.isc.org/bind.html

The INTERNAL DNS (the one only our internal users can see) is
set up as the primary DNS for our network. It includes info for all
machines behind the firewall. All internal machines point to it for ALL
queries. It forwards all queries it can't handle to the only other server
it knows about, the EXTERNAL DNS running on the firewall.

The EXTERNAL DNS (the one the Internet sees) is the primary DNS
as far as InterNIC is concerned. This server should have a cache file to
leads to the root level servers. Note: This server only contains info
I want the world to know about. e.g. MX records and the addr of our external
web and FTP servers.

For running split DNS: External sites see the external MX and
send to smap on the bastion. With the bastion's resolver pointing to an
internal DNS, sendmail uses that first then gets forwarded to the bastion's
named. Thus:

External mail inbound gets accepted by smap according to the external
MX records. Sendmail then uses the internal MX records to deliver the mail.
Too easy.

Outbound mail gets accepted by smap on the bastion. Sendmail looks
in the internal DNS and gets no answer (directly) and the DNS query is forwarded
to the bastion's DNS which returns the correct external A/MX record for
mail delivery.

Works like a charm.

If you don't want to use split DNS, you'll need a .cf to force
local mail to the internal mailhost. You could do this a number of ways

1) use LOCAL_NET_CONFIG and specify rules to deliver to a specific
host. Something like the following should suffice:

The first line accepts mail for any machine in the domain and
delivers to that machine. The second delivers mail adressed to the domain
and sends it to the mailhost. Of course you could do the same in the first
case - instead of sending to the host send to the mailhost and let it decide
how to deliver.

2) use the "mailertable" feature. We use this on an internal machine
which is doing a similar job to the bastion.

These rules accept ALL mail for either the domain or any host/subdomain
and use the "smtp" mailer to send to the internal mailhost. Of course you
need to build "makemap" so you can create the hash table.

A patch file is the 'diff' output between two files: in this case,
probably two C source code files or support files.

The 'patch' program does, essentially, a reverse 'diff'.
You must start with the SAME source file as the older one that the person
who made the patch started with. You will end up with the SAME new
source file that the person ended up with.

John gets the file, and saves it by the
same name [stripping
mail headers and the like]. He uses the 'patch'
program to
update his copy of "list.c":

$ cd src
$ patch < ../list.patch

John and I now have the same version
of list.c.

NOTES:
(1) The patch file is 'diff' output, and cannot
be compiled.
(2) The 'patch' program must be run in the directory
where the file or files being updated are located.
(3) You must, Must, MUST start with the same version(s)
of the same file(s); otherwise, the 'patch' will either refuse to work at
all, or if it does run, it has a good chance of giving you garbled output.
(4) If you downloaded the patch file from a web
site, you may want to make sure that it is properly formatted as a Unix
text file. To change its formatting, either

6. Put this line in /usr/local/etc/netperm-table
ftp-gw: permit-hosts 192.168.*.*

(Obviously you change the numbers to your own internal addresses.
You can have this as your entire netperm-table).

7. Put this in /usr/local/etc/rc.d/ftp-gw.sh (or other auto-startup
place. You can just put the second line in /etc/rc.local, for example).
#!/bin/sh
[ -x /usr/local/libexec/ftp-gw
] && /usr/local/libexec/ftp-gw -daemon ftp && echo -n '
ftp-gw'

8. Test it with command-line FTP.

9. (It's just my opinion, but I can heartily recommend use
of RFC 1597 Private Internet numbers. Very good from a security
point of view and much easier to manage because you have so much space.
I know lots of people disagree: I'm just reporting that we've got ours working
this way very well. Don't do it, however, if you your company is likely
to merge with another
company!]

** HOW DO I CONFIGURE WS_FTP TO USE FTP-GW?

This was tested with Version 4.50 of 17.07.1997

1. Assuming you have ftp-gw set up in simplest way as shown
above (no internal authentication):