RE: Securing www server w/Oracle back end.

["Ben Nagy" <ben () iagu net>]

> -----Original Message-----
> From: firewall-wizards-admin () honor icsalabs com 
> [mailto:firewall-wizards-admin () honor icsalabs com] On Behalf 
> Of George J. Jahchan, Eng.
> Sent: Wednesday, 9 April 2003 10:30 AM
> To: Firewall Wizards List
>
> I think I have found the solution, it is from a French 
> company called NetSecure and the product is NetSecure Web.

Bordel. Sauve-toi! Maintenent c'est les francais avec cette espece de
soi-disant "solution".[1]

> My understanding of the scenario is as follows:
>
> WWW server gets moved to the private zone close to the db 
> server and a NetSecure internal agent gets installed on it or 
> preferably on another server (requirements are minimal).
>
> An external NetSecure agent gets installed on a stand-alone 
> server in DMZ.
>
> No holes have to be punched through the firewall from DMZ to 
> private zone.

That seems unlikely. How do these two agents talk? Either they go through
the firewall or they bypass it using a serial connection / crossover cable,
USB, magic elves etc. Either is equivalent, in my book.

> The internal agent polls the external agent for queued 
> requests every second (this is the default and can be 
> changed). The internal agent performs http protocol 
> inspection (customizable) and forwards "sanitized" requests 
> to the real web server which sends its response back through 
> the internal agent to the external agent and from there to the client.
>
> SSL decryption could occur in an HSM card installed in the 
> server hosting the internal NetSecure agent. NetSecure 
> internal agent would inspect the content of http requests 
> after they have been decrypted in HSM.

This requires that the internal agent MitM the SSL connection. This can be
problematic with certificate signing etc. Having said that, the same applies
to the secure reverse proxy fans. This is not an unsolvable issue, I admit.

> Theoretically the setup behaves like an air gap between the 
> client and the web server and is transparent to both. On 
> paper, this looks like a viable solution.

Sorry, but this is exactly the kind of spaghetti I was talking about earlier
in the thread. I can see no security delta here. There is basically no
difference between this and a secured reverse proxy solution. The only thing
I can see that's useful is the "sanitisation" of HTTP requests, which can be
done with a number of other in-place products that integrate with the
webserver, depending on platform.

I think it's the phrase "air gap" that has me riled up, in fact....

Theory - you run this solution. Someone sends a request that uses valid
HTTP, and roots your webserver. All further communication to the trojan now
running on the server runs over HTTP POST. The ONLY thing stopping this
happening is the quality of the HTTP sanitisation - it will go through this
"air gap" like curry through a drunk, since the HTTP traffic still makes it
back and forth somehow, whether via simple TCP or whether carried lovingly
on the backs of trained rhesus monkeys.

> Look forward to readers comments.

No thumbs up from me. YMMV.

ben

[1] Je deconne. J'aime bien les francais, d'ac?

_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards