Ok, I'm going to add my bandwidth-chewing 2cents worth. I liked
Colin Campbell's post and we do something similar with our
installation.
The product we use is NetDynamics from Spider Technologies which
is a Java based application server environment for database
access. Put simply the diagram is thus:
Outside
|
FW - Web Server (with application stub)
|
Internal Net
|
|-- Farm of application servers
|
Oracle or other database servers
The only 'hole' between the DMZ and the internal net is a
single port for the ND application stub to talk to the
application server farm controller. This way we don't have
to worry about the bouncing SQL*Net ports in a multi-threaded
Oracle listener environment. It also keeps our application
runtimes (java) on the inside.
The concerns include somebody possibly being able to
compromise the web server and then send commands down the
open pipe. I'm pretty confident in my NT box's setup but only
if I could get the blasted localSystem account to behave...
That's another reason for moving the application servers to the
internal network. They're mighty hard to get to.
I do not know how ND would handle a stream of
garbage. Neither do I know if one is able to craft a
URL to somehow tamper with the backend servers as the URL get's
passed thru the communication channel and acted upon.
I am not a very enthusiastic supporter of NetDynamics, the
product is FULL of bugs and not very good in handling
runaway processes. The memory footprint of the java apps
are HUGE, too. I've gotten off topic enough....
|
|
