[thelist] Firewalls vs. Web Databases

[Glenn Hunt]

An interesting solution, but there are dangers in this setup. Assuming
that the DB is normally behind the firewall, you have just completely
bypassed your firewall. You leave a hole open. You would be better to
have everything firewalled. That way you only open the incoming ports
necessary (usually just 80, possible 443), and everything else is
blocked. It means that a hacker has to compromise two machines to get
anywhere - first the firewall, and then an inside machine.

Having two database machines (one inside and one outside the firewall)
seems needlessly complex. If you are worried about web access
disappearing because the firewall goes down, then the logical thing is
to minimize the chance of the firewall "going down". There are three
options, probably in order of preference:

1. Load balancing hardware - Certainly the best solution, but also the
most expensive. Would be used to divide traffic between two firewalls.

2. Use a hardware-based firewall. By not using a traditional "OS-based"
firewall, the chances of failure are greatly reduced.

3. Use two firewalls and round-robin DNS. The biggest issue with this
that the DNS would have to be updated if a firewall went down.

If none of the above are possibilities, then at least use a *NIX-based
firewall (personally I use FreeBSD) - they are very stable and virtually
hack-proof.

The best for security is definitely everything behind the firewall, or
at least the firewall being the only connection between the 'net and
your private network.

Glenn Hunt
ghunt at hds.ca

-----Original Message-----
From: thelist-admin at lists.evolt.org
[mailto:thelist-admin at lists.evolt.org] On Behalf Of Daniel J. Cody
Sent: Thursday, September 20, 2001 12:41 PM
To: thelist at lists.evolt.org
Subject: Re: [thelist] Firewalls vs. Web Databases


A variation of this is something I tend to do..

Config your webserver so that it will work inside or outside the 
firewall and install an additional network card in it.

Configure that second NIC to be on a private network(10.10.10.0 for 
example), then configure your database to sit on that private network as

well. Plug the second NIC on your webserver and your DB into a 
hub/switch, and configure them to talk to eachother over that *private* 
link.(further security could be added by only allowing the DB to talk to

the IP address of the second NIC on the webserver)

With this method, the DB doesn't care whether or not its in front of or 
behind a firewall, and since the webserver and the DB talk over a 
private link, the webserver doesn't care either. The DB can always be 
reached on that private network whether or not there's a firewall in 
front of the public IP address of the webserver and the webserver more 
or less acts as a firewall between the DB and the internet.

You'll also see an improvment in speed between the DB and the webserver 
since they're on a dedicated link with eachother. :)

Again, just my preference.. If anything is unclear or you have 
questions, feel free to shout :)

.djc.


J. Blanchard wrote:


> Or third, we could establish a data server outside of the firewall 
> with the web server, replicate needed items from inside the firewall 
> for the database, and create a subnet between the servers.




---------------------------------------
For unsubscribe and other options, including
the Tip Harvester and archive of TheList go to: http://lists.evolt.org
Workers of the Web, evolt !