Alex,
What is the proxy server in the DMZ expected to achieve ??
The proxy server in the DMZ is in effect a 'reverse proxy server' with the
limitation that it can't initiate new connections to the internal server,it
can only reply to pre-opened connections.
How does the internal server know to connect to the reverse proxy server, ie
how does it know when the reverse proxy server has a request for it. You
mentioned having a pool of connections already open.... I have no knowledge
of any 'common' proxy server / reverse proxy server / web server that will
do this...
The internal server will have to pre-open a certain number of connections to
the proxy server and leave them open. The proxy server will send the
requests through these pre-open connections.
I can't make the proxy server the real server, as the real server has to
make some database connections and the database is also inside the firewall.
Therefore the proxy server can only stream the request on a pre-opened
connection to the internal server and wait for a response.
I don't know if anybody has solved such a problem before, but suggestions
are really appreciated.
Thanks,
Sumeet
One way that I can think of doing this would be to have a set of perl
scripts.... one on the / an internal server (doesn't have to be on the web
server itself, in fact it would probably be better running on a stand-alone
box totally locked down for everything other than the ports that you choose
to run the perl script on), and one on the DMZ server. The DMZ server should
be listening on 80 for requests from the outside world, and the perl script
on the internal server should have a connection (or a few connections,
depending on the kinda load that you're expecting) to the server in the DMZ.
The server in the DMZ can then send a request it recv's to the connection
that is already open between it and the internal server. The internal server
then opens a connection with the web server on port 80 and can send the
request to it, and the reply back the other way.
I think that that solution is a totally ridiculous one and is a lot more
complicated than it needs to be, as with anything, the more complication the
more risk associated with it. The risk can be programming flaws, or lack of
understanding be the admins leading to incorrect configuration etc, all of
which reduces the security of the system.
If I were in that situation, I would stick a web server on the DMZ, and set
up content replication initiated on the internal server going to the server
on the DMZ. This way any editing etc can be done by the internal staff on
the web server on the internal network and the changes will be replicated to
the server on the DMZ.
To me that would be the solution with the least risk associated with it. If
the server on the DMZ is compromised, so what... all that can be done is
they can stuff up one copy of the web site... not the real copy (which
resides on the internal network). The content replication should be setup so
that it works one way (ie from the inside out), so that any compromise will
be limited to the server on the DMZ and isn't propogated to the internal
server.
I hope that that makes some sense, and possibly provides a solution to what
you are trying to achieve.
Cheers,
Alex Hague
>Thanks for your reply mouss and ben.
>
>>here I'll second ben and confess that I don't understand the meaning of
>your original message.
>>what exactly do you want to achieve?
>>do you want people in the public network to access resources in your
>internal server?
>I would like to clarify this further. The intent is to allow users on the
>internet to access the internal server in the most
>secure manner.The security people believe by having such a configuration
>the proxy and the internal server and the firewall not allowing incoming
>connections), they can put the internal server on the net with maximum
>security (though with maximum trouble to me, the developer :).
>I will have to implement a pool of open connections on the Proxy server
>,which would have originated from the internal server, and then have to do
>a
>lot of custom code to do this. That's the reason, I was asking if some
>other
>product has implemented such a solution or if somebody else can suggest
>another configuration which would achieve the same security.
>Thanks for your input,
>Sumeet
>
>-----Original Message-----
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED]]On Behalf Of mouss
>Sent: Monday, August 21, 2000 11:42 AM
>To: Sumeet Vij; Ben Nagy; [EMAIL PROTECTED]
>Subject: RE: How do I do a reverse Invoke
>
>
>At 10:36 21/08/00 -0400, Sumeet Vij wrote:
>>Ben,
>> What I meant was the proxy server in the DMZ can't open a
>>connection to the
>>real server inside the firewall. It can only write on a connection that
>>was
>>pre-opened by the server inside the firewall.
>> The security people seem to think that by not allowing new
>>connections to
>>come in through the Proxy server, the real server inside the firewall
>would
>>be safe even if the proxy server is compromised. I am not sure how
>>convincing the argument is. Please let me know if their assumption is
>sound.
>
>
>their assumption is sound and reasonable. unless you find a secure way or
>you
>"accept" the risk, you'd better reject "incoming" connections.
>Also, you don't want to have the same level of severity on both hosts, and
>if you
>allow the dmz host to get to the internl host, then you should be as severe
>on the
>DMZ as you are for internal hosts, but then you don't need a DMZ!
>
>>Again, if you know of some products/implementations of this, please let me
>
>here I'll second ben and confess that I don't understand the meaning of
>your original message.
>what exactly do you want to achieve?
>do you want people in the public network to access resources in your
>internal server?
>if so, then copy the files you want to make available on the DMZ server.
>
>cheers,
>mouss
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
