FWTK Home

FWTK DOCUMENTATION

1.1: Introduction

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.

1.2: History

For you curious folks, here is some combined FWTK history posted to the list by Frederick Avolio and Marcus J. Ranum.

#########################
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.

We think all would agree that we achieved our goals.

1.3: FWTK vs. Gauntlet

The difference between the two was best stated by Frederick Avolio

###########################
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... :-))

There is a side-by-side comparison in the Gauntlet FAQ at:
http://www.nai.com/products/security/prodserv/gauntlet/firewalls/faq.asp

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?

You can view the following docs which have been converted to PDF. You will need at least Adobe Acrobat Reader version 3.0, which can be downloaded at http://www.adobe.com/prodindex/acrobat/readstep.html ,

Document name and location Description

Admin Guide:
admin_guide.pdf Technical discussion of configuration and administration of the toolkit

Manual (man) pages:
manpages.pdf All man pages in one document

FWTK Overview:
overview.pdf High-level general overview of firewall security using the toolkit

Presentation:
presentation.pdf Slide show presentation of the reasons to use a firewall

User's Guide:
user_guide.pdf Brief handout to get users familiar with the toolkit

FWTK Tutorials

2.2: POP mail tutorial

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:

pop-gw 2009/tcp # Firewalled POP3 Service
mail-gw 2010/tcp # Firewalled SMTP Service

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:

plug-gw:port 2009 your.net.address.* -plug-to host.domain.com -port 110
plug-gw:port 2010 your.net.address.* -plug-to host.domain.com -port 25

Lastly, the following lines need to be in your /etc/inetd.conf file:

pop-gw stream tcp nowait root /usr/local/etc/plug-gw plug-gw 2009
mail-gw stream tcp nowait root /usr/local/etc/plug-gw plug-gw 2010

Todd Tavasci <ltt1268@netscape.net >

Tutorials

3.1: Split-DNS tutorials

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

- Bill Earle <Bill.Earle@Dynabrade.COM >

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.

>From the named.boot file of our INTERNAL DNS:
cache           .                                   named.cache
primary         oicinc.com               named.oicinc.com
primary         172.16.100.in-addr.arpa named.oicinc.rev
forwarders      172.16.100.100

The named.cache file of our INTERNAL DNS: ;
; Initial cache data for root domain servers. ;
; list of servers...
. 99999999 IN NS portal.oicinc.com.
portal.oicinc.com. 99999999 IN A 172.16.100.100

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.

- Paul Beltrani <beltrani@portal.oic.htdc.org >

3.2: Sendmail configuration

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:

LOCAL_NET_CONFIG
R$* < @ $* . $m. > $* $# smtp $@ $2 $: $1 < @ $2 . $m > $3
R$* < @ $m. > $* $# smtp $@ mailhost $: $1 < @ $m. > $2

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.

FEATURE(mailertable, hash /etc/mail/mailertable)

The "mailertable" is just a list of domains and delivery rules. eg

my.domain smtp:mailhost.internal.my.domain
.my.domain smtp:mailhost.internal.my.domain

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.

Colin Campbell <sgcccdc@citec.qld.gov.au >

FEATURE(nouucp)dnl
FEATURE(nodns)dnl
FEATURE(always_add_domain)dnl
FEATURE(nocanonify)dnl
MASQUERADE_AS(firesign.com)dnl
MAILER(local)dnl
MAILER(smtp)dnl

The inportant ones were the MASQUERADE_AS and the noncanonify. Also, make sure that the Cw has all of the possible hostnames in it That might get you going without DNS.

Eric Geyer <ericg@firesign.com >

3.3: Help with applying patches

A patch file is NOT a C source code file.

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.

EXAMPLE:
John and I both have files "list.c" in directory "src".

I fix mine. I make a 'diff' file and send it to John:

$ diff -u list.c list.c.new > list.patch
$ mailx -s list.patch john < list.patch

     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

FTP it to the Unix box in ASCII mode
run the "dos2unix" command on the Unix server
strip the CR/LF pair by typing: tr -d "\r"

Joseph S. D. Yao <jsdy@cospo.osis.gov >

3.4: Quick guide on how to replace ftpd with ftp-gw

** WHAT IS THE SIMPLEST WAY TO RUN FTP-GW?

1. Get a Unix box with two ethernet interfaces. Connect one to INSIDE network, one to OUTSIDE network. Don't let any users on this machine except root -- it's JUST for proxying
FTP).

2. Plug it together like this:

3. Alternatively, use a single ethernet box and connect it like this:

But you'll have to be *much* more careful when you construct your access lists on the router.

4. Disable normal FTP daemon (remove from /etc/inetd.conf)

5. Put ftp-gw in /usr/local/libexec
Make it safe to your taste with chown, chmod.
No idea?
chown bin.bin /usr/local/libexec/ftp-gw
chmod 555 /usr/local/libexec/ftp-gw

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):

2. In WS_FTP session properties you select

        FIREWALL TAB
        Host Name: myproxy.mycompany.com      YES Use Firewall
        User ID:   (blank)
        Password: (blank)
        Port:      (blank)
        Firewall Type: USER with no logon

(Again, put the hostname of your ftp-gw machine in the host name. Must be the INSIDE name or IP address.)

3. You might want to use passive as well:

        ADVANCED TAB
        Leave settings at defaults except:
        YES Passive transfers

** HOW DO I USE WINDOWS 95 COMMAND-LINE FTP WITH FTP-GW?

1. You can't use passive mode as far as I know.

2. You must run ftp-gw on default port 21

3. You can't do mkdir, rmdir. Instead do
quote mkd DIRNAME
or quote rmd DIRNAME

This was tested with ftp.exe which ships with Windows 95 Version 4.00.950 B, which is
C:\WINDOWS\FTP.EXE and has size 37520 bytes.

Jonathan Laventhol <jonathan.laventhol@imagination.co.uk >