Firewall behind Router

Monty J. Harder lists at kc.rr.com
Sun Jan 6 03:18:01 CST 2002


"Brian Densmore" <DensmoreB at ctbsonline.com> wrote:

> >  Your scheme violates The Prime Directive of Firewalls:  Accept no
> > connections from outside the firewall.  The proper way to do
> > this is to put
> > the servers in the DMZ, so that connections can be opened to

> Well, I have to disagree a little here [even if though it is against the
> prime directives]. Of course it depends on how you define a DMZ. We have

  As the former President said:  "It all depends on what your definition of
"is" is."

> a Router on our outside connection, it does some firewalling. Behind
> that is a switch, behind that is a firewall. The firewall directs
> traffic to the various web and mail servers and the LAN. Even the WAN
> goes through the outside router (over a dedicated line). I have my own
> web/mail server outside the firewall. Now you could call the
> Router/switch combo the DMZ, or you could call our configuration a
> double firewall. There is no ftp server, although we are looking at

  I'd call anything outside the "inner" firewall the DMZ wrt that firewall.
You're using the "outer" firewall as an additional line of defense, and
there's nothing wrong with that - it's a great idea, in fact.  If you wear a
belt =and= suspenders, you're a lot less likely to get caught with your
pants down.  But make no mistake about the fact that it's the inner firewall
that is the most important.  The fact that the outer firewall permits
connections from the outside means you have to treat the servers in the DMZ
like potential Ebola carriers and quarantine them scrupulously.  Maybe even
have a Sentinel inside the (inner) firewall running a cron job to do
Tripwire-ish things and respond to a detected intrusion by clamping down in
some pre-arranged way, and paging the sysadmin to let him know The Shit Has
Hit The Fan.

  The reason for the Prime Directive is that the process that opens the
socket from inside the (inner) firewall is presumably in control of what's
being done with the data that come in.  While it is still =possible= for a
creative cracker to figure out an exploit, it has to be a very clever one
indeed to get that process to execute some command or code that "lowers the
drawbridge" across the moat to allow further mischief.  OTOH, we are much
less certain about what process running in the DMZ is asking for a socket
into the LAN.  By not allowing a compromised machine in the DMZ the chance
to open any sockets, we're keeping the risk to a minimum.  You still have to
watch for Trojans inside opening things up, but you're going to have to
watch for those anyway (and even at that, having the router looking for
attempts to open a socket on port 31337, for instance, and blocking same,
isn't an awful idea either).

> I feel that the mail server and web server are better behind the
> firewall. I also feel they should be dedicated and all ports closed on

  If you mean behind the outer firewall, you get no argument from me.

> firewalls, so be it. For a commercial enterprise the added security is
> well worth the investment. A single intrusion event will easily cost
> more than that second firewall.

  The second firewall can be an old machine that isn't fast enough to run
the latest bloatware, running a stripped-down Linux kernel custom tuned to
the purpose, with no extraneous services turned on. Or even installed. (I
volunteered to man the LUG booth at ITEC so that everyone else could hear
Bruce Schnier's address, so I'm relying on their second-hand description,
but) Counterpane's security boxen do not even have a shell on them.  All
administration is done by adjusting site-specific configuration files on a
floppy, which is promptly write-protected.  The machine boots from a CD, and
has ample RAM drives to enable maximum speed.

  For all I know the kernel's been tweaked to make it impossible to mount
some of the RAM drives r/w after they've been initialized from the r/o
media.  I don't know if that's a stock option for RAM drives, but it ought
to be - a single command that says "Read this file/partition/whatever into
RAM somewhere, and lock it so that it's r/o, and don't ever let me tell you
to change it to r/w, no matter how much I beg.  And if someone claims to be
me, and even =asks= you to remount a Permanently Read Only filesystem as
r/w, I want you to let me know about it, and transfer their connection to
the Tar Pit nearest you!"




More information about the Kclug mailing list