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.
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:
We think all would agree that we achieved our goals.
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:
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.
The filename is "fwtk-doc-only.tar.Z".
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.
Do the same for the Incoming Mail (POP3) Server, but use a different port.
You will need entries in the /etc/services file to support the ports you choose above as follows:
pop-gw 2009/tcp # Firewalled POP3
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
plug-gw:port 2009 your.net.address.* -plug-to host.domain.com
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
Todd Tavasci <email@example.com >
Set up external DNS on the FWTK machine.
Set up DNS on an internal server.
All machines should point to the internal DNS server for host
name resolution, including the 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:
The named.cache file of our INTERNAL DNS: ;
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 <firstname.lastname@example.org
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.
FEATURE(mailertable, hash /etc/mail/mailertable)
The "mailertable" is just a list of domains and delivery rules. eg
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 <email@example.com
I was able to get it working using this set of features in the .mc file:
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 <firstname.lastname@example.org
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.
I fix mine. I make a 'diff' file and send it to John:
-u list.c list.c.new > list.patch
John gets the file, and saves it by the
same name [stripping
$ cd src
John and I now have the same version of list.c.
** 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
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
6. Put this line in /usr/local/etc/netperm-table
(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).
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
** 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
(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:
** 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
This was tested with ftp.exe which ships with Windows 95 Version
4.00.950 B, which is
Jonathan Laventhol <email@example.com >