Glenn Hunt wrote: > 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. I didn't really get into it, but the DB server should have some firewall rules(not a full blown layer 2 hardware solution(like iptables or ipchains on linux)) in place to only allow connections on ports 1521 and 22(for example) for Oracle and SSH *FROM* the other machine on the internal network. Assuming you somehow get through the primary firewall in front of the webserver, you then have to crack the webserver before you can even begin to attempt to crack the DB. > Having two database machines (one inside and one outside the firewall) > seems needlessly complex. If you are worried about web access +1 > 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. Expense is an understatement :) You pretty much triple the amount of hardware and have to deal with other issues that come with load balancing. Not to mention having to maintain it all > 2. Use a hardware-based firewall. By not using a traditional "OS-based" > firewall, the chances of failure are greatly reduced. ? I've always had an issue with people saying that dedicated(hardware-based) firewalls are superior to OS based firewalls. When you get down to it, even dedicated firewalls are OS based(PIX is IOS, NetRaptor is Unix, etc..). The reason dedicated firewalls are less failure prone is because they come pre-configed and stripped of unessacary hardware. Running a firewall of good server hardware and stripping off the crap(do you really need USB enabled on your firewall? etc..) has achieved *years* of uptime for me at a price usually half of dedicated solutions.. but thats just me :) > 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. oy. an easier solution would just to run a warm backup firewall. > 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. My point is that Joe Cracker would have to a.) get through firewall rules b.) get through the webserver before c.) he ever found out even what network the DB server is on. And if Joe can get through one firewall, it doesn't matter how many more you have behind that because he'll probably get through those too.. .djc.