> -----Original Message-----
> From: Breach, Geoff [mailto:[EMAIL PROTECTED]]
> Sent: Friday, 12 November 1999 3:20 PM
> To: Firewalls (E-mail)
> Subject: RE: Three NIC Firewall
>
> > My thought was to turn off ip forwarding on the web server
> > and put in a second NIC that would appear on the private
> > network.
>
> No. Please don't. All to many people do this, and all too
> many people believe it's ok. It's ugly, scary, and a Bad
> Thing (tm). Why bother to build a firewall if you're going
> to add a perfectly good back door?
>
> [...]
>
> You could work your problem this way: On your firewall,
> build a VPN tunnel between your DMZ NIC and your Internal
> NIC, set filtering to allow only the two machines to
> talk through it, and set routes on the machines to make
> sure they know how to find each other.
Sorry, but I don't see how these two solutions are different. In fact, isn't
it _worse_? If any other box in the DMZ can be compromised, they can change
the MAC / Ethernet address to match the box that is allowed through the
teeny-VPN, neh? At least with the backdoor NIC approach then you need to
completely compromise that specific box.
On one hand, we're looking at a backdoor NIC in the IIS server to talk to
the database. In the VPN scenario, we're looking at a backdoor tunnel
through the firewall to the internal database. Big deal.
I don't think I like either solution. However, I think that there IS an
argument for the backdoor NIC. If you trust the server that the backdoor NIC
is leading to, this method _can_ be as secure as a firewall solution. At
least you get to review only one service when you do the risk assessment.
Basically, if you trust the service that is listening to the backdoor NIC,
then this design can be made secure. In some cases, I'd rather do this than
run a bunch of crazy DCOM juju through my firewall!
The long and the short of it is that if a DMZ box is allowed to talk to an
inside service, AND the DMZ box is compromised, then IF the inside service
is vulnerable - you're toast. It doesn't matter how you slice the access
methods.
> I still don't like passing the db connection through the
> firewall at all. Databases are sensitive things, and
> companies have a habit of storing lots and lots of money
> in databases (valuable data). A badly configured db
> server is often all to keen to hand over that data to
> anyone who asks for it.
Yup. From here on, I'm with you. 8)
> My preferred solution would be to have two db servers.
> One on your DMZ for real-time access from the web server.
> This one should contain the bare minimum amount of data
> required to provide the online service.
>
> A second, real database server holding all your private
> info sits on the private protected network. Updates
> between the two databases (where possible) happen via
> a 'disconnected' and not real-time method. Maybe ftp a
> set of updates through every hour/day/whatever, or
> sneakernet, or something like that.
^^^^^^^^^^
Or the Whale Communications (R) Air Gap (TM) technology! Woohoo!
(notethatidonotworkforwhaleorendorsetheirproductsthisishumouronly)
Sadly, in many cases the database that is connected to the web _is_ all the
valuable data. D'oh.
>
> If you require live updates and/or requests between
> (1) the web server and the internal db, or (2) the
> internal and external db servers, pay close attention
> to rights, limits and security.
>
> Make sure the DMZ box[es] have very limited access
> to read and write the internal database. Consider
> quarantining writes from the external machines, with
> some form of checking before they're absorbed into the
> main data.
And if you're just reading this now and thinking "Ooh! Taint checking! What
a cool idea!" then go report to your management / shareholders for a
spanking.
> An ugly compromise. The firewall behaved perfectly - it
> checked the requests at application level, and found them
> to be legal HTTP from legal sources (public internet).
This is one of the reasons why I've lost faith in HTTP application layer
gateways. I'm so tempted just to say "Screw it. I can't police it, so I may
as well make it nice and fast."
This whole database backed websites issue is what has made me agree with all
the pundits who are suggesting that the next generation of firewalls needs
to employ pervasive technology. Picking demarcation points is no longer good
enough to provide fine-grained access control.
Basically, we can't afford to have application servers with soft, chewy
centres any more. If the service you're putting up for external access can't
handle the application level heat, then you really need to get it out of the
kitchen.
>
> Geoff
> --
> CREDIT | FIRST Geoff Breach, [EMAIL PROTECTED], +61293944040
> SUISSE | BOSTON Global Network Services - Asia Pacific Engineering
> Opinions expressed herein are mine, not my
> employer's
Cheers,
--
Ben Nagy
Network Consultant, CPM&S Group of Companies
PGP Key ID: 0x1A86E304 Mobile: +61 414 411 520
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
