I assume you mean ASP to be Microsoft Application Server Pages under IIS? 
The SOAP approach is probably best since SOAP uses HTTP and can be filtered by a HTTP 
application gateway (although most don't handle webDAV and other SOAP just yet) while 
any other DCOM approach would require opening up RPC (port 135) plus dynamic ports for 
each application. That said, it still has the inherent risk of a client on the DMZ 
connecting to a server on the internal network  asking it to execute routines based on 
data that possibly comes from tainted sources (taint in the Perl sense).
  This has the risk that the first buffer overflow found in your DCOM application 
gives an intruder access to your internal network, albeit one hop away.
   This you have to way the risks of any connection between a DMZ server and internal 
network and your business needs. But it certainly would be clearer on the network side 
to use SOAP, but probably more complicated on the application side.

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of
[EMAIL PROTECTED]
Sent: Monday, April 16, 2001 11:02
To: [EMAIL PROTECTED]
Subject: ASP's insided the trusted network


I have an ASP based application that may need to be deployed in an envrionment
that uses a DMZ.  I need to come up with a reasonably secure approach for
accessing my functional ASP pages (which use COM to talk to business objects) in
this environment.  The original approach proposed here was to leave the
functional ASP's in the DMZ and have them communicate with the trusted network
via SOAP.  This would leave only the SOAP listeners and the supporting business
objects inside the trusted network.  However, SOAP seems like overkill for this
problem.  An alternate approach would be to use plain HTTP to forward the
request from the DMZ to the functional ASP's in the trusted network.  With this
approach and ASP or ISAPI Extension in the DMZ would receive incoming requests
and forward the request along to the functional pages in the trusted network
(perhaps the forwarding component would check to ensure the final destination
was valid; maybe it could put a special HTTP header in to allow for extra
filtering on the firewall).

What are the inherent problems of running ASP's inside the trusted network ? Are
ASP's especially vulnerable to denial of service or to security breaches ?  How
would a good firewall administrator react to this proposal (would SOAP between
the DMZ and trusted network go over any better)?


-
[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.]

Reply via email to