Hi Sumeet,
I've got a few questions (and hopefully some answers)...
What is the proxy server in the DMZ expected to achieve ??
The reason that I'm asking this is, it sounds like it's meant to be a
'reverse proxy server' ie, instead of sending requests (for web pages etc)
from the inside out, it's expected to take requests from the outside and
send them in....
If this is the case then for it to function properly it needs to be able to
connect from itself to the internal web server.
I find this whole situation very confusing, as supposing someone has a
request for your webserver, it gets sent to what I'm going to call your
reverse proxy server on the DMZ, that machine isn't going to be allowed to
connect to your internal server, instead the internal server is somehow
going to have to connect to the reverse proxy server take a request from it
and then return content.... (sounds sorta backwards to me)
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...
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.]
