View Security server questions

[boom]

Hi,

Could anyone please clarify the following questions in regard of the View Security server?

1. Does the Security server authenticates HTTPS connections from Internet clients before they hit internal broker servers?

After reading the documentation I had an impression that the HTTPS connections from clients are not authenticated by the Security server. Unauthenticated clients are allowed to "touch" the internal servers by using Security servers as a proxy. Is this correct? This is looks like a big risk for me.

2. Is the trafic (AJP13, JMS) between the Security server and broker servers SSL-encrypted?

3. Is there a way to disallow HTTPS connections from Internet to the Broker management console that is located on the same HTTPS that clients use for VDI connections?

Thank you

[markbenson]

Hi "boom",

Good questions.

1. HTTPS Connections from Internet Clients are terminated at the Security Server. AJP13 is used to pass authentication and other client control traffic from the Security Server to the Connection Server after validation. This is for authentication, authorization and obtaining configuration data etc. Security Servers therefore do not need to be joined to an AD domain and AD traffic does not need to go between the DMZ and the green zone (where AD is). The role of the Security Server is to ensure that only traffic on behalf of authenticated users (PCoIP etc) can be sent to the virtual desktops in the green zone. It is normal for a Security Server to be located in a DMZ between the green zone and the Internet. The Security Server is acting as a proxy. No HTTPS goes between Security Server and Connection Server. That is all AJP13 and JMS.  No protocols go straight from the Internet to the Connection Server(s). It is common for Internet access in View to add additional authentication steps such as RSA SecurID, RADIUS or X.509 Smart Card certificates etc. so that a pre authentication step is performed before AD is ever contacted.

2.  AJP13 (containing the control traffic from View Clients) goes between Security Server and Connection Server using an IPsec secured channel and so is all encrypted. This IPsec channel is automatically set up as part of the Security Server pairing performed at installation time. Sensitive data in JMS messages is also encrypted.

3. The recommended firewall settings for a DMZ only permit AJP13 and JMS to go to a Connection Server (not HTTPS). This prevents Internet access to View Administrator from the Internet. You also cannot connect to View Administrator on the Connection Server via a Security Server. You can only access it internally.

Hope these answers help.

Mark

[boom]

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.

It looks like it gets just wrapped into AJP13 and sent to the internal connection server.

The risk I am concerned about is that the unauthenticated HTTP (wrapped) request reaches the internal server.

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.

Is there a way to mitigate these risks and prevent unathenticated users hitting the internal servers?

May be client SSL certificates?

Thank you

[markbenson]

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.