Re: Here is my plan for firewall implementation

["Marcus J. Ranum" <mjr () nfr net>]

>   My plan is to build a Pentium 133 with 32 MB RAM with 540 MB Hard Drive
> running Linux Slackware using kernel 2.0.30 and TIS Firewall Toolkit 2.0.
> I plan to use the SMTP, HTTP, TELNET, and FTP proxies from the FWTK and set
> up a fake DNS on this machine.

So far, so good...
You might want to consider using the filtering layer in
Linux to screen the firewall host itself (and you might want
to allow some kinds of traffic to screen through the firewall,
eventually so keep that option open). Screening's a great
tool for protecting firewall platforms against attack. I used
to build firewalls by carefully configuring all the software
on the machine so that extra deamons were shut down,
etc, etc. That's still worth doing, but it's a whole LOT easier
and probably as (or more) effective to add a layer of
in-kernel screening to prevent outsiders from being able
to talk to things you don't want them to.

This is a great trick for securing web sites, too. You can
screen so that only port tcp/80 can come in, and then allow
udp/53 only to a firewall or some other machine with a
nameserver.

>   I will build another Linux computer to act as the internal DNS that will
> forward all queries it cannot answer to the firewall and then forward
> answers back to the systems that asked.  It will also be my network
> monitoring station and the station the I xfer all update to my external web
> and ftp servers.

That sounds good. You're going to syslog all your logs to that
internal machine? You might want to set up an 'artifical ignorance'
log scanner on it. I can post an explanation of how to build one,
if you want.

>   My default policy will be to deny all unless otherwise permitted.  I am
> trying to protect the information as we deal with government contracts but
> still need access to the internet to look up data and exchange information
> with other contractors.

Exchanging data safely is a TOUGH problem. These days I am
leaning heavily towards telling people NOT to use FTP, but to
use web instead. That way you can layer it under SSL if there's
sensitive information going around. The only big drawback is
that, at present, nobody has a decent utility for uploading
files using POST.

Now *THAT* is an idea!!! Someone should write a program that
is *compatible* with FTP's command interface, but which uses
HTTP instead. Then we could lose that bidirectional callback
nonsense. Any takers? :)

mjr.
-----
Marcus J. Ranum, CEO, Network Flight Recorder, Inc.
<A HREF=http://www.clark.net/pub/mjr>Personal</A>
<A HREF=http://www.nfr.net>Work</A>
<A HREF=http://www.clark.net/pub/mjr/websec>New Book!!</A>