Mit den SSL Labs von Qualys besteht die Möglichkeit ein Rating zur SSL Verschlüsselung seiner externen Zugriffe erstellen zu lassen. In diesem Artikel möchte ich diese Thematik im Zusammenhang mit NetScaler (Gateway) aufgreifen.

War bis und mit Firmware 10.1 das Standard-Rating eine F, so ist es seit Firmware 10.5 eine C:

Diese Rating Angaben geben uns einen Hinweis wie sicher die Verschlüsselung des NetScaler Gateways ist. Während F ein schlechtes Ergebnis darstellt ist C schon besser. Wir wollen uns die Ratings genauer betrachten und die Konfiguration optimieren um auf ein Rating von A bzw. A+ zu kommen.

Wenn man die erste Analyse genauer betrachtet, so findet man auch die Ursachen beschrieben:
– aktiviertes SSL3 sorgt für eine Abstufung zu B
– TLS 1.2 ist nicht aktiv, dies sorgt für eine Abstufung zu C
– aktivierte RC4 Cipher sorgen für eine Abstufung zu B
– PFS ist nicht aktiviert

Als erstes müssen wir eine virtuelle Appliance (VPX) auf den Firmware Stand von mindestens 10.5 Build 57.7 da vorher TLS 1.1 und TLS 1.2 nur auf der Hardware (MPX/SDX) unterstützt sind.
Nach dem Upgrade müssen im vServer in den SSL Parametern SSL3 deaktiviert sowie TLS 1.2 aktiviert werden.

set ssl vserver nsgw-vsrv-gateway.domain.pit -ssl3 DISABLED -tls12 ENABLED

Nach diesem Schritt wird unser Rating bereits auf ein B angehoben sein. Als weiteren Schritt kümmern wir uns um die Cipher sowie das Perfect Forward Secrecy (PFS).

Der erste Schritt hierbei ist die Erstellung einer neuen Cipher Gruppe:

add ssl cipher CIPHER-PIT
bind ssl cipher CIPHER-PIT -cipherName TLS1-ECDHE-RSA-AES256-SHA -cipherPriority 1
bind ssl cipher CIPHER-PIT -cipherName TLS1-DHE-RSA-AES-256-CBC-SHA -cipherPriority 2
bind ssl cipher CIPHER-PIT -cipherName TLS1-AES-256-CBC-SHA -cipherPriority 3

Für das PFS wird weiter einen Diffie-Hellmann Schlüssel, welcher man via CLI erstellt, da das GUI in ein Timeout läuft:

create ssl dhparam dh-key-2048.key 2048 -gen 2

Wenn die Gruppe und der Schlüssel erstellt sind müssen wir diese nun noch im virtuellen Server konfigurieren:

bind ssl vserver nsgw-vsrv-gateway.domain.pit -cipherName CIPHER-PIT
set ssl vserver nsgw-vsrv-gateway.domain.pit -dh ENABLED -dhFile "/nsconfig/ssl/dh-key-2048.key" -dhCount 1000 -eRSA DISABLED

Nach dieser Einstellung ist unser Rating nun auf einem A:

Im Beispiel ist die Einstellung für das A+ bereits gesetzt aber ich möchte noch darauf eingehen. Vorher ist zu erwähnen, dass das Rating nicht höher wird solange das Intermediate Zertifikat nur SHA1 ist. Um die Wertung zu erhöhen muss einerseits das Intermediate Zertifikat eine höhere Signatur aufweisen sowie der HTTP Strict Transport Security Header gesetzt werden. Dies geschieht bei NetScaler mittels Rewrite Policy:

add rewrite action rw_act_InsertSTSHeader insert_http_header strict-transport-security "\"max-age=63072000; includeSubdomains; preload\"" -comment "strict-transport-security Header"
add rewrite policy rw_pol_InsertSTSHeader HTTP.RES.IS_VALID rw_act_InsertSTSHeader
bind vpn vserver nsgw-vsrv-gateway.domain.pit -policy rw_pol_InsertSTSHeader -priority 300 -gotoPriorityExpression END -type RESPONSE

Anschliessend ist die Bewertung auf einer A+:

Update vom 15.07.16

Wie es scheint, wurden die Prüfroutinen angepasst und unser NetScaler ist „nur“ noch mit einem A- bewertet. Im Report sieht man, dass die seit 10.5 ausgeschaltetet SSL Renegotiation als ‚Workaround‘ betitelt wird. Wenn wir diesen nun einfach komplett einschalten würden, wäre die Bewertung ein F (so war es nämlich vor 10.5). Wir müssen die SSL Konfiguration nun dahingehend ändern, dass nur unsichere SSL Renegotiations gesperrt werden:

set ssl parameter -delySSLReneg NONSECURE

BONUS:

Und wenn wir schon dabei sind, ist es evtl. sinnvoll einem Hacker die Webserver-Informationen nicht gleich auf dem Silbertablett zu präsentieren:

Um diesen Eintrag zu verschleiern verstecken wir diesen ebenfalls mittels zwei Rewrite Policies:

add rewrite action rw_act_DeleteServerHeader delete_http_header Server
add rewrite action rw_act_InsertServerHeader insert_http_header Server "\"unknown environment\""
add rewrite policy rw_pol_DeleteServerHeader HTTP.RES.IS_VALID rw_act_DeleteServerHeader
add rewrite policy rw_pol_InsertServerHeader HTTP.RES.IS_VALID rw_act_InsertServerHeader

bind vpn vserver nsgw-vsrv-gateway.domain.pit -policy rw_pol_DeleteServerHeader -priority 100 -gotoPriorityExpression NEXT -type RESPONSE
bind vpn vserver nsgw-vsrv-gateway.domain.pit -policy rw_pol_InsertServerHeader -priority 200 -gotoPriorityExpression NEXT -type RESPONSE

Das Ergebnis kombiniert mit dem STS Header von vorhin kann dann so aussehen:

Und nun viel Spass beim Nachbauen ;-)

Skript: NS-OptimizeSSL

Hallo zusammen

Eine der Neuerungen mit NetScaler 11 war die Einführung des RDP Proxy. Ich habe mich im Rahmen einer Kursvorbereitung ein wenig mit dem Feature auseinander setzen dürfen/müssen. Nunja was soll ich sagen… es ist eigentlich gar keine Hexerei.

Vorraussetzungen: NetScaler Enterprise (RDP Proxy ist Bestandteil vom Unified Gateway) sowie NetScaler Gateway Universal Licenses

Wie ist funktioniert der RDP Proxy nun? Die komplette Grafik sieht nun so aus:

Die Skizze ist mit einer Unified Gateway Installation gezeichnet, wobei der NetScaler Gateway (NSGW) vServer ohne IP (0.0.0.0) hinter einem Content Switching (CS) vServer mit der entsprechenden VIP (z.B. 192.168.200.10) steht. In einer klassischen Konfiguration kann man den CS vServer weg denken und die VIP ist auf dem NSGW vServer konfiguriert.

Klassische CS Konfiguration:
– CS vServer hört auf die VIP
– Anfragen auf den Hostname webapps.domain.pit werden auf den Loadbalancing (LB) vServer der Webapplikationen geleitet
– Anfragen auf den Hostname rdp.domain.pit werden auf den NSGW vServer geleitet

Anfrage der Webapplikationen verlaufen ohne spezielle Konfigurationen direkt auf die Webserver der Applikationen.

Mittels RDP Server Profilen (z.B. rdp_server_pro) werden die Listener-Einstellungen wie FQDN unseres Gateway, Port, etc. konfiguriert.
Dieses „RDP Server Profile“ muss an den NSGW vServer gebunden werden, damit dieser neu auch auf Anfragen auf den konfigurierten Port reagiert.
Der Zugriff von extern muss nun nebst dem bekannten 443 Port auch den Port für die RDP Verbindung (Standard: 3389) gewährleistet sein.
Zugriffe werden nun auf dem NSGW vServer mit der entsprechenden VIP terminiert.

Update 04.05.16: nach neusten Erkenntnissen kann auch der Port 443 für die RDP Verbindung genutzt werden. Dabei muss jedoch Stand heute eine weitere IP verwendet werden. Gemäss Aussage von Citrix soll „Port Sharing“ in einer der nächsten Versionen funktionieren.

Update 08.07.16: Mit der neuen Version 11.1 funktioniert nun das „Port Sharing“ und man benötigt für einen RDP Proxy nur noch eine IP und kann alle Zugriffe via Port 443 konfigurieren (analog ICA Proxy).

Im „RDP Client Profile“ sind sämtliche für den Client relevanten Einstellungen hinterlegt wie z.B. die FQDN unseres Gateway, welche Mappings wir erlauben, etc.
Dieses Profile muss an eine Session Policy gebunden sein, welche wiederum entweder direkt dem NSGW vServer oder einer Gruppe/einem Benutzer zugeordnet ist.

Der RDP Client greift bei einem Aufruf der Verbindung direkt auf den NSGW vServer zu, dieser terminiert die Frontend RDP Verbindung und baut eine entsprechende RDP Verbindung zum gewünschten Backend Computer auf. Et voilà, so funktionierts… vereinfacht gesagt ;-)

Wie wird dies nun konfiguriert? Hier die Schritt-für-Schritt Anleitung in Form von CLI Kommandos (im GUI entsprechend abbilden):

Das RDP Proxy Feature muss separat aktiviert werden, falls nicht im Basis-Setup bereits geschehen:

enable feature RDPProxy

Nun müssen das RDP Client und Server Profile erstellt werden wobei der SharedKey bei beiden identisch sein müssen. Der Parameter -rdpFileName definiert nur, wie die Datei heisst, welche zum Client übermittelt werden soll:

add rdp clientprofile rdp_client_pro -rdpFileName pit.rdp -rdpHost rdp.domain.pit -psk Password1
add rdp serverprofile rdp_server_pro -rdpIP 192.168.200.10 -psk Password1

Nun muss das RDP Server Profile dem definierten NSGW vServer angebunden werden:

set vpn vserver nsgw-vsrv-rdp.domain.pit -rdpServerProfileName rdp_server_pro

Als nächstes benötigen wir entsprechende Session Policies in welchen wir den Zugriff erlauben, Clientless auf ALLOW setzen und das entsprechende RDP Client Profile zuweisen. Falls bereits Policies vorhanden sein sollten, können diese ggf. einfach angepasst werden:

add vpn sessionAction rdp_prof -defaultAuthorizationAction ALLOW -clientlessVpnMode ON -rdpClientProfileName rdp_client_pro
add vpn sessionPolicy rdp_pol ns_true rdp_prof

Diese Policies werden nun dem NSGW vServer angebunden:

bind vpn vserver nsgw-vsrv-rdp.domain.pit -policy rdp_pol -priority 100

Nach erfolgreicher Anmeldung wählt man den Clientless Access, sofern man nicht automatisch dahin geleitet wurde:

Mit der Eingabe https://FQDN-des-Gateways/rdpproxy/Ziel (z.B. https://rdp.domain.pit/rdpproxy/192.168.100.10) kann man sich nun eine RDP Verbindung via RDP Proxy aufbauen.
Bequemer für den Benutzer ist es, wenn man die Verbindungen als Bookmark erfasst und dem vServer bzw. den Gruppen zuweist:

add vpn url rdp_pitserver1 "PIT Server1" "rdp://192.168.100.11" -clientlessAccess ON
add vpn url rdp_pitserver2 "PIT Server2" "rdp://192.168.100.12" -clientlessAccess ON
add vpn url rdp_pitserver3 "PIT Server3" "rdp://192.168.100.13" -clientlessAccess ON
bind vpn vserver nsgw-vsrv-rdp.domain.pit -urlName rdp_pitserver1
bind vpn vserver nsgw-vsrv-rdp.domain.pit -urlName rdp_pitserver2
bind vpn vserver nsgw-vsrv-rdp.domain.pit -urlName rdp_pitserver3

So sieht ein Benutzer nach erfolgreicher Anmeldung direkt seine Server auf welche er sich mittels RDP verbinden kann:

Damit eine Verbindung erfolgreich aufgebaut werden kann, muss sich der angemeldete Benutzer überhaupt auch ohne Proxy via RDP anmelden können.
Der RDP Proxy macht ein Single-Sign-On und es erfolgt keine Benutzer/Passwort Abfrage mehr.

Nun wünsch ich euch viel Spass beim Nachbauen ;-)

Skript: NS-RDPProxy

Im Artikel „NetScaler Content-Switching für HTTP zu HTTPS Umleitung für mehrere Domains“ habe ich eine Variante der HTTP zu HTTPS Umleitung mittels Content Switching (CS) beschrieben. Mein Kollege Claudio Mascaro hat das Ganze nun ein wenig eleganter mittels einer Responder Policy gelöst :-)

Dafür benötigt man als ersten einen HTTP Loadbalancing (LB) vServer, welcher permanent „ON“ ist und welcher die gleiche IP wie der HTTPS CS vServer aufweist (z.B. 192.168.200.10):

add server PITDUMMY 192.168.199.199
add service svc-HTTPtoHTTPS PITDUMMY HTTP 80 -healthMonitor NO
bind service svc-HTTPtoHTTPS -monitorName tcp -monState DISABLED
add lb vserver lb-vsrv-http.domain.pit HTTP 192.168.200.10 80
bind lb vserver lb-vsrv-http.domain.pit svc-HTTPtoHTTPS

Um den Service permanent „ON“ zu schalten wurde das Monitoring mit den Parametern deaktiviert:
– -healthMonitor NO
– bind service HTTPtoHTTPS -monitorName tcp -monStateDISABLED

Nun benötigt man noch eine Responder Policy welche die Anfrage von HTTP zu HTTPS umleitet:

add responder action rs_act_httptohttps redirect "\"https://\" + HTTP.REQ.HOSTNAME.HTTP_URL_SAFE + HTTP.REQ.URL.PATH_AND_QUERY.HTTP_URL_SAFE" -responseStatusCode 302
add responder policy rs_pol_httptohttps "!CLIENT.SSL.IS_SSL" rs_act_httptohttps

Zu guter Letzt muss diese Policy nun noch dem vorher erstellten LB vServer zugewiesen werden:

bind lb vserver lb-vsrv-http.domain.pit -policyName rs_pol_httptohttps -priority 100 -gotoPriorityExpression END -type REQUEST

Ab jetzt wird jede HTTP Anfrage an die IP 192.168.200.10 nach HTTPS umgeleitet. Somit ist der Weg frei um beim HTTPS CS vServer jederzeit neue Policies hinzuzufügen, ohne sich noch Gedanken über eine Umleitung machen zu müssen.

Ein spezieller Dank geht hier an unseren Master CCI Claudio Mascaro, welcher dies auf unserem System entsprechend eleganter als meine Lösung eingerichtet hat :-)

Skript: NS-HTTP2HTTPS-Responder

Hallo zusammen

In einer neuen Unified Gateway Umgebung hatte ich die Situation, dass über die gleiche IP mehrere Hostnamen angesprochen werden.
Für HTTPS wird beim Wizard automatisch schon ein Content Switching (CS) eingerichtet, welches mit weiteren Policies und Ziel vServer erweitert werden können.

Eine automatische Umleitung von HTTP nach HTTPS wird jedoch nicht eingerichtet. Zu Zeiten als jeder NetScaler Gateway (NSGW) vServer eine eigene IP hatte, richtete man einfach einen Loadbalancing (LB) vServer mit einer Redirection URL ein und fertig. Was nun aber im oben genannten Fall?

Bestehend nach dem Wizard und ein paar Anpassungen:
– CS vServer cs-vsrv-https.domain.pit mit der IP 192.168.200.10 konfiguriert für HTTPS
– NSGW vServer nsgw-vsrv-citrix.domain.pit mit der IP 0.0.0.0
– LB vServer lb-vsrv-data.domain.pit mit der IP 0.0.0.0
– LB vServer lb-vsrv-mail.domain.pit mit der IP 0.0.0.0
– drei DNS Einträge citrix.domain.pit, data.domain.pit und mail.domain.pit auf eine spezifische öffentliche IP

In unserer Umgebung haben wir dies mit einem weiteren Content Switching vServer mit HTTP und den dazu gehörenden LB vServern eingerichtet:

add cs vserver cs-vsrv-http.domain.pit HTTP 192.168.200.10 80
add cs policy cs-pol-http-citrix -rule "HTTP.REQ.HOSTNAME.STARTSWITH(\"citrix\")"
add cs policy cs-pol-http-data -rule "HTTP.REQ.HOSTNAME.STARTSWITH(\"data\")"
add cs policy cs-pol-http-mail -rule "HTTP.REQ.HOSTNAME.STARTSWITH(\"mail\")"
add lb vserver http_redirect-citrix.domain.pit HTTP 0.0.0.0 0 -redirectURL "https://citrix.domain.pit"
add lb vserver http_redirect-data.domain.pit HTTP 0.0.0.0 0 -redirectURL "https://data.domain.pit"
add lb vserver http_redirect-mail.domain.pit HTTP 0.0.0.0 0 -redirectURL "https://mail.domain.pit"
bind cs vserver cs-vsrv-http.domain.pit -policyName cs-pol-http-data -targetLBVserver http_redirect-data.domain.pit -priority 100
bind cs vserver cs-vsrv-http.domain.pit -policyName cs-pol-http-mail -targetLBVserver http_redirect-mail.domain.pit -priority 200
bind cs vserver cs-vsrv-http.domain.pit -policyName cs-pol-http-citrix -targetLBVserver http_redirect-citrix.domain.pit -priority 300

Nun prüft zuerst die Policy vom CS nach der Subdomain und leitet an den entsprechenden HTTP vServer weiter. Dieser wiederum hat eine Umleitung auf die korrekte HTTPS Adresse hinterlegt.

Am Rande bemerkt: so sieht im Grundsatz auch die CS Konfiguration des Unified Gateways aus. Dieser basiert auf HTTPS, benötigt zusätzlich noch ein SSL Zertifikat und der NSGW vServer muss eingerichtet werden. Darauf verzichte ich jedoch in diesem Blogeintrag. ;-)

Skript: NS-HTTP2HTTPS-CS

Hallo NetScaler Freunde

Im letzten Artikel „XML Dienste & Citrix Director gemeinsam hinter NetScaler“ berichtete ich über die Möglichkeit XML und Director über den gleichen Loadbalancing (LB) vServer zu konfigurieren. Was nun aber, wenn auch noch Storefront auf dem gleichen Server installiert ist?

Vom Prinzip her verwenden wir wieder den LB vServer wie im letzten Artikel beschrieben.

Im DNS Server fügt man nun einen weiteren Host Eintrag hinzu:
storefront.domain.pit = 192.168.100.30

Nun benötigen wir eine weitere Responder Policy, welche
– den Hostname überprüft (startet der Hostename mit storefront…?)
– prüft, ob die URL den Wert „StoreWeb“ noch nicht enthält – unabhängig der GROSSklein Schreibung
– nach /Citrix/StoreWeb umleitet, sofern oben genannte Bedingungen zutreffen:

add responder action Resp_Act_to_SF-StoreWeb redirect "\"/Citrix/StoreWeb\"" -responseStatusCode 302

add responder policy Resp_Pol_to_SF-StoreWeb "HTTP.REQ.HOSTNAME.STARTSWITH(\"storefront\") && HTTP.REQ.URL.SET_TEXT_MODE(IGNORECASE).CONTAINS(\"StoreWeb\").NOT" Resp_Act_to_SF-StoreWeb

bind lb vserver lb-vsrv-PIT-XD-HTTPS -policyName Resp_Pol_to_SF-StoreWeb -priority 100 -gotoPriorityExpression END -type REQUEST

Mit dieser weiteren Responder Policy ist nun auch dieses Ziel erreicht.

Skript: NS-RespStorefront

Hey NetScaler Fans

Ich habe in meiner Umgebung folgendes Szenario:
– zwei XenDesktop Controller auf welchen auch Director installiert ist
– einen Loadbalancing (LB) vServer auf dem NetScaler, welcher beide Server ansteuert

Ziel war es:
– den SSL LB vServer für XML-Anfragen zwischen Storefront und Controller zu verwenden mit Hostname = xmlxd7.domain.pit
– den gleichen SSL LB vServer für den Zugriff auf die Director Site zu verwenden mit Hostname = director.domain.pit
… bis hierher noch kein Problem, aber
– beim Zugriff auf den Hostname director.domain.pit soll der NetScaler im Bedarfsfall auf die URL /Director umleiten, aber KEINESFALLS wenn eine XML Anfrage den LB vServer erreicht

Soweit so gut, das Loadbalancing einrichten ist soweit ja mal keine Hexerei:

add server pit-xd01 192.168.100.31
add server pit-xd02 192.168.100.32

add service svc-https-pit-xd-01 pit-xd01 SSL 443
add service svc-https-pit-xd-02 pit-xd01 SSL 443

add lb vserver lb-vsrv-PIT-XD-HTTPS SSL 192.168.100.30 443 -persistenceType SOURCEIP -timeout 1440

bind lb vserver lb-vsrv-PIT-XD-HTTPS svc-https-pit-01
bind lb vserver lb-vsrv-PIT-XD-HTTPS svc-https-pit-02

add ssl certKey lb-server-cert -cert lb-server.cert -key lb-server.key
add ssl certKey PIT-CA -cert PIT-CA.cer
link ssl certKey lb-server-cert PIT-CA 
bind ssl vserver lb-vsrv-PIT-XD-HTTPS -certkeyName lb-server-cert

Im DNS müssen nun zwei Host-Einträge für den neuen vServer erstellt werden:
xmlxd7.domain.pit = 192.168.100.30
director.domain.pit = 192.168.100.30

Jetzt folgt der kniffligere Teil – die Umleitung für die Director URL.
Dies ist mit einer Responder Policy zu lösen, welche
– den Hostname überprüft (startet der Hostename mit director…?)
– prüft, ob die URL den Wert „director“ noch nicht enthält – unabhängig der GROSSklein Schreibung
– nach /director umleitet, sofern oben genannte Bedingungen zutreffen:

add responder action Resp_Act_to_Director redirect "\"/Director\"" -responseStatusCode 302

add responder policy Resp_Pol_to_Director "HTTP.REQ.HOSTNAME.STARTSWITH(\"director\") && HTTP.REQ.URL.SET_TEXT_MODE(IGNORECASE).CONTAINS(\"director\").NOT" Resp_Act_to_Director

bind lb vserver lb-vsrv-PIT-XD-HTTPS -policyName Resp_Pol_to_Director -priority 100 -gotoPriorityExpression END -type REQUEST

Mit dieser Responder Policy ist nun auch dieses Ziel erreicht.

Und als Abschluss noch dies…
Der aufmerksame Leser hat festgestellt, das der LB vServer für XML und Director auf Port 443 (HTTPS) reagiert. Bei der Eingabe geht dies jedoch des öftern mal vergessen. Dafür kann man einen weiteren LB vServer mit einer Umleitung einrichten:

add lb vserver http_redirect-director.domain.pit HTTP 192.168.100.30 80 -redirectURL "https://director.software-online.ch"

Viel Erfolg beim Nachbauen :-)

Skript: NS-XMLandDirector