I have setup and used several variations of Linux based firewalls in a
production environment. It mostly comes down to the normal firewall
question. What is your security policy? what are you trying to protect?
What do you need to allow? Who do you trust?
In most cases I have found that the answers to these questions are very
simple. The company needs to protect their internal network from all
outside access. They need to serve web pages to the Internet. They
need to exchange mail from an internal server with the Internet. They
need internal machines to be able to access http and ftp on the
Internet.
The tools I use for most of these simple configurations are a very
stripped, or bare bones Linux install, Apache (as both a web server and
a proxy), qmail, and a DNS server.
Take a stripped Linux installation with two network cards and at least
32 MB RAM (if it's more than 12 MB, you haven't stripped the Linux
install). Build a very tight kernel, no modules, no module support; no
support for NFS or anything that you do not need (remember that you will
have to do the build on another machine because you don't have any
compilers on your stripped down firewall). Setup qmail and set it to
pass mail between your internal SMTP server and the Internet. Make sure
to only allow relaying of mail from your internal mail server. Next
build two version of Apache (make sure to grab the latest stable version
(1.2.5 has a lot of security fixes, not too mention all of the bug fixes
and buffer overflows that they have fixed in the last 3 months). Make
the first build and exclude almost everything; do you really need cgi
support? server side includes? user directory mapping? Name this binary
httpd and set it aside. Now go back and enable the proxy server part of
Apache. Build and name this proxyd.
The point of this exercise is to eliminate as much complexity as
possible form the Apache code. You are making a machine as bare bones
as possible to eliminate as many potential holes as you can.
For the configuration:
Setup and configure httpd to only bind to your outside address. This is
your webserver that the world sees.
Setup and configure proxyd to bind to only your internal address. For
simplicity you probably want this to look at the same document source as
httpd. Make sure both httpd and proxyd are running at as low a
privilege as possible. How you accomplish this depends on your paranoia
level. I already have the nobody account sufficiently locked out of the
system, so I tend to use this ID. You may want separate ID's for proxyd
and httpd. Hell maybe you want to run thttpd as your external web
server. It works.
Double check your qmail. It uses DNS to decide where to route. Make
sure that qmail is looking at an internal DNS server that tells it to
send mail for inside to an appropriate internal server.
This is where your DNS server comes in. Because of the factors of qmail
and proxyd you want the firewall to look at your internal DNS. Your
internal DNS has your wins-DNS linking (in DHCP environments) and allows
you to do good logging of who is using the Internet. Your internal
server needs be able to resolve Internet addresses now. Have it look
towards the DNS server on the firewall for anything it doesn't know.
Do not put anything in your external DNS (on your firewall) that the
world cannot already see, or you do not want them to know.
Complexity: It's a bad thing.
When you are done you will have built a very simple, bare bones
firewall. It is fairly easy to proof and test because you are dealing
with very few things that you are trusting, namely:
The Linux network stack: It hasn't been around as long as Berkeley's,
but a lot of people have worked on breaking it, and a lot of other
people trust it. There are alternatives to inetd (needed for qmail)
including tcpserver, written by the same very security paranoid person
that wrote qmail.
qmail: Very capable, very secure. Qmail was written with two goals in
mind: Maximum reliable security and speed. Security was the most
important criteria used when Dan Bernstein wrote Qmail.
Apache: A tremendous amount of resources have been poured into Apache's
security lately. Apache dominates the http server market with half of
the world's server running on Apache - market share does not equal
security though!
named: I don't have as much faith in named, I wish I didn't need to run
it. There have been many efforts to improve it's security, and Paul
Vixie is not a security laggard.
Things to remember!
Your Mileage May Vary! This is an outline for a generic system that I
have used in the past. This is not the whole system, but it is the meat
of the system. You probably have different needs than my customers do
so you will need to alter things.
No warranty expressed or implied. Firewalls are not toasters. You
cannot implement an effective or secure firewall with out understanding
the protocols and systems that you are trying to protect.
Nothing is Bulletproof. Even Marcus Ranam's Ultimate firewall
(wirecutters) is not safe against the untrained technician who sees a
broken network cable and replaces it.
TANSTAFL. You do the math...
Have fun,
Chris
>-----Original Message-----
>From: Scott Robert Lenz [SMTP:scott @
neologics .
com]
>Sent: Friday, February 06, 1998 10:01 AM
>To: Firewalls Mailing list
>Subject: FW: LINUX FIREWALLS
>
>Do any of you out there believe in a LINUX firewall implementation as a
>viable resource? My network is currently NT based, but I don't wish to
>devote EVERYTHING to Microsquash.
>
>What I am looking for is some good resources I can review for detailed
>plans about setting up and installing a LINUX firewall option.
>
>Also, does the LINUX option allow for any subnet routing? I, unfortunately,
>am stuck with using MSMPR to do the routing between subnets (actually, 2
>separate, legal Class C Licenses).
>
>Whatever any of you can provide in my quest for a better option than
>MSPROXY would be greatly appreciated.
>
>PS: I think we are all professional, and mature enough, not to have to
>blatantly flame everyone whom asks a simple question. Remember, there was a
>time that YOU were just a new to the technology as THEM.
>
>
>Scott Lenz
>NeoLogics Software & Services, LLC
>Evergreen, CO
>(303)670-8681
>
|
|
