Hi "boom",
boom wrote:
Thank you for the response Mark
So if I undestand your answer properly, the HTTPS connection is not authenticated on the Security server in DMZ.
That's correct. There is no need for the Security Server to connect to authentication servers such as Active Directory. It is always the Connection Server that performs the authentication. Security Server does not allow connections to the desktops in the green zone until authentication is successful.
boom wrote:
The risk I am concerned about is that the unauthenticated HTTP (wrapped) request reaches the internal server.
No. No (wrapped) HTTP reaches the internal Connection Server. It is only the specific authentication requests (XML requests in AJP13 in IPsec) that can go to the Connection Server. HTTP(S) traffic is blocked.
boom wrote:
This looks risky if happens something like this: http://www.cvedetails.com/cve/CVE-2012-5978/
An unauthenticated user would be able to get files from an internal server instead of being isolated in DMZ.
View does not allow users to access files on internal servers.
boom wrote:
Is there a way to mitigate these risks and prevent unathenticated users hitting the internal servers?
May be client SSL certificates?
Always check release notes and make sure you update the software version to apply latest patches and security updates. e.g. for View today, use version 5.1.3 or 5.2.
In addition to Active Directory authentication, View also supports two-factor authentication such as RSA SecurID and other mechanisms through the RADIUS protocol. View also supports Certificate authentication using X.509 certificates from Smart Cards. Certificate authentication is initially checked at the point of SSL termination (usually the View Security Server).
You can also use a second level DMZ so that Security Servers are in an outer DMZ, Connection Servers are in an inner DMZ and Desktops are in the green zone.
boom wrote:
Thank you
No problem.
Mark.