Citrix ADC SSL Bewertung optimieren – Stand November 2022

Dieser Artikel baut auf folgenden Beiträgen auf:
NetScaler SSL Bewertung optimieren
Citrix ADC SSL Bewertung optimieren – Stand Februar 2020
welche diverse Basisschritte beschreiben. Dieser Artikel beschreibt lediglich die Erstellung einer neuen Cipher Gruppe mit aktuellen Cipher Suites

Eine neue Cipher Gruppe kann entweder im ADC direkt oder via ADM verteilt werden mit folgenden Befehlen:

add ssl cipher PIT-SECURE-20220601
bind ssl cipher PIT-SECURE-20220601 -cipherName TLS1.3-AES256-GCM-SHA384 -cipherPriority 1
bind ssl cipher PIT-SECURE-20220601 -cipherName TLS1.3-AES128-GCM-SHA256 -cipherPriority 2
bind ssl cipher PIT-SECURE-20220601 -cipherName TLS1.2-ECDHE-RSA-AES256-GCM-SHA384 -cipherPriority 3
bind ssl cipher PIT-SECURE-20220601 -cipherName TLS1.2-ECDHE-RSA-AES128-GCM-SHA256 -cipherPriority 4
bind ssl cipher PIT-SECURE-20220601 -cipherName TLS1.2-DHE-RSA-AES256-GCM-SHA384 -cipherPriority 5
bind ssl cipher PIT-SECURE-20220601 -cipherName TLS1.2-DHE-RSA-AES128-GCM-SHA256 -cipherPriority 6

Im Anschluss müssen die Ciphers auf den vServern ersetzt werden wie exemplarisch mit einem Citrix Gateway aufgezeigt:

unbind ssl vserver nsgw-vsrv-gateway.domain.pit -cipherName CIPHER-PIT-AEAD
bind ssl vserver nsgw-vsrv-gateway.domain.pit -cipherName PIT-SECURE-20220601

Zu guter Letzt folgt wie immer das Testing und die Dokumentation.

Viel Spass beim Nachbau :-)




Citrix ADC SSL Bewertung optimieren – Stand Februar 2020

Im ursprünglichen Artikel bin ich auf die Basis-Schritte eingegangen, wie man bei Qualys die SSL Bewertung auf einen guten Stand bringen kann.

Da die Test-Routinen jeweils an die neusten Erkenntnisse angepasst werden, waren meine Bewertungen auf ein B gesunken, was für mich nicht hinnehmbar war. Hier möchte ich euch die Schritte beschreiben, wie ich wieder auf eine A+ Bewertung gekommen bin.



Der erste Schritt ist relativ einfach. Durch die aktivierten TLS 1.0 und TLS 1.1 wurde die Bewertung automatisch auf ein B heruntergestuft. Dazu kann man diese im virtuellen Server einfach in den SSL Parametern deaktivieren. Im gleichen Atemzug habe ich auch bereits TLS 1.3 aktiviert.

set ssl vserver nsgw-vsrv-gateway.domain.pit -tls1 DISABLED -tls11 DISABLED -tls13 ENABLED

Der nächste Schritt beinhaltet die Anpassung der Cipher Suites. Bei Qualys findet man einen direkten Link mit der Auflistung passender Algorithmen. Nebst dem bestehenden TLS 1.2 habe ich auch gleich diese für TLS 1.3 hinzugefügt.
Man kann einerseits die bestehende Gruppe anpassen oder wie ich eine neue Gruppe erstellen:

add ssl cipher CIPHER-PIT-AEAD
bind ssl cipher CIPHER-PIT-AEAD -cipherName TLS1.2-ECDHE-ECDSA-AES128-GCM-SHA256 -cipherPriority 1
bind ssl cipher CIPHER-PIT-AEAD -cipherName TLS1.2-ECDHE-ECDSA-AES256-GCM-SHA384 -cipherPriority 2
bind ssl cipher CIPHER-PIT-AEAD -cipherName TLS1.2-ECDHE-ECDSA-AES128-SHA256 -cipherPriority 3
bind ssl cipher CIPHER-PIT-AEAD -cipherName TLS1.2-ECDHE-ECDSA-AES256-SHA384 -cipherPriority 4
bind ssl cipher CIPHER-PIT-AEAD -cipherName TLS1.3-AES256-GCM-SHA384 -cipherPriority 5
bind ssl cipher CIPHER-PIT-AEAD -cipherName TLS1.3-AES128-GCM-SHA256 -cipherPriority 6
bind ssl cipher CIPHER-PIT-AEAD -cipherName TLS1.2-ECDHE-RSA-AES256-GCM-SHA384 -cipherPriority 7
bind ssl cipher CIPHER-PIT-AEAD -cipherName TLS1.2-ECDHE-RSA-AES128-GCM-SHA256 -cipherPriority 8
bind ssl cipher CIPHER-PIT-AEAD -cipherName TLS1.2-DHE-RSA-AES256-GCM-SHA384 -cipherPriority 9
bind ssl cipher CIPHER-PIT-AEAD -cipherName TLS1.2-DHE-RSA-AES128-GCM-SHA256 -cipherPriority 10

Anschliessend muss man nur noch auf dem vServer die alte Cipher Gruppe entfernen und die neue hinzufügen um in der Bewertung ein A+ zu sehen:

unbind ssl vserver nsgw-vsrv-gateway.domain.pit -cipherName CIPHER-PIT
bind ssl vserver nsgw-vsrv-gateway.domain.pit -cipherName CIPHER-PIT-AEAD

Zu guter Letzt müssen sämtliche Applikationen getestet werden, ob auch alle mit den verschärften Algorithmen umgehen können.

Viel Spass beim Nachbau :-)




Ubiquiti Unifi – Rückblick & Cloud Key

In meinem Post über meine Umstellung zu Hause sind nun rund zwei Monate vergangen und ich möchte ein wenig die Erfahrung wiedergeben.

Seit den Setup aller Komponenten lief die Infrastruktur einwandfrei. Im Gegensatz zu früher war nie ein Neustart der Firewall oder dem Access Point notwendig geworden. Kurzum ich bin zufrieden.

Einzig der Controller auf dem Windows-System nervte mich irgendwann, da das Update-Prozedere durch die Installation im Benutzerprofil doch eher mühsam war. Daher habe ich mich dann doch dazu entschieden den Cloud Key zu erwerben. Der Cloud Key ist ein ca. 15x5x2cm grosses Gerät, welches an einen PoE Port am Switch angeschlossen wird. Auf dem Cloud Key wiederum läuft dann dediziert der Unifi Controller. Die Migration vom Windows Unifi Controller hin zum Cloud Key war dann dank dem KB Artikel zur Site Migration eine Sache von rund 15 Minuten.

So ein Post soll ja nicht nur ein Produkt beweihräuchern, sondern auch kritische Punkte aufzeigen.

Das erste war bei mir das WLAN. Die erste SSID war konfiguriert für 2,4 und 5 GHz mit der Option, dass wenn möglich 5GHz forciert werden soll. Leider konnte mein Mobilephone damit nicht sauber umgehen und verblieb auf dem 2,4GHz Band, sobald das 5GHz einmal zu schwach war. Ich habe nicht lange zur Suche investiert sondern habe eine weitere von 4 möglichen SSIDs erstellt und nun gibt es zwei SSIDs für zwei verschiedene Frequenzbänder. So funktioniert es bisher tadellos.

Auffallend ist die Wärmeentwicklung der Geräte. Klar sie sind lüfterlos, dennoch oder genau deswegen werden sie recht heiss – sind dafür leise. Gemäss einem Arbeitskollegen könnte man dies bei den Switches mittels Wandmontage optimieren, was bei mir aktuell nicht der Fall ist. Dem werde ich weiter nachgehen – Vorschläge sind gerne Willkommen. :-)

Last but not least die Status LEDs. Was in Büros kaum auffällt, merkt man zu Hause umso mehr. Die Geräte haben blaue Status LEDs die den Betrieb anzeigen. Tagsüber kaum sichtbar, sind diese in der Nacht doch sehr hell. Ich habe mich hier entschieden, diese zu deaktivieren. Dies kann man entweder pro Gerät entscheiden, oder direkt in den Einstellungen der Site für alle Geräte deaktivieren, wie ich es auch gemacht habe.

Dies war ein kleiner Rückblick der letzten zwei Monate. Schauen wir einmal was die nächsten Monate evtl. noch für Neuerungen bringen.




Ubiquiti Unifi – eine saubere Netzwerkgeschichte

Lange Zeit war es still in diesem Blog. Dies lag oder liegt vor allem daran, dass ich vermehrt an der Endkunden-Front unterwegs bin und somit weniger Zeit finde zum Schreiben.
Vor gut zwei Wochen verabschiedete sich meine gut siebenjährige ZyWALL in den ewigen Elektronenhimmel und es musste Ersatz her. Ich war mit meinem Heimnetz, welches auch ein Testnetzwerk und Wifi umfasst noch nicht wirklich warm geworden. Ein Arbeitskollege musste wegen eines Brandfalles sein komplettes Netzwerk ersetzen und schwärmte dabei von Ubiquiti. Ubiwas?

Die Firma Ubiquiti Networks wurde 2005 mit lediglich einer Vision und einem Kapital von 30’000USD gegründet. 2010 brachte die Firma die Unifi Serie heraus, mit welcher ich mich nun auch befasst habe. Innerhalb dieser Serie gibt es eine Unmenge an Switches, Access Points und sonstigem Netzwerkkram, was es schon zu Hauf auf dem Markt gibt, notabene auch günstiger.
Was macht diese Unifi Geräte nun so besonders? An der Hardware wird es kaum liegen, denn Design ist Geschmackssache und über Geschmäcker lässt sich streiten. Also muss es an der Software liegen. Verbindet man sich dann aber z.B. mit einem Switch stellt man fest, dass dieser nur über eine CLI Oberfläche verfügt. Warum soll man sich das nun also antun?

Der grösste Vorteil an diesen Geräten ist, dass man dazu gratis eine Controller-Software herunterladen kann. Diese ist für Windows, MAC oder Linux erhältlich. Letztere auch als eigenständiges Produkt, dem Cloud-Key. Dieses USB-Device kann man an einen der PoE Switche anschliessen und die Controller Software läuft dann auf diesem autonom.
Ich habe den Controller aktuell auf einem Windows System installiert. Nach der Konfiguration müsste der Controller theoretisch nicht mehr laufen, er bietet jedoch ein paar nette Funktionen an wie z.B. ein Gast-WLAN inkl. Anmeldeportal.

Welche Komponenten habe ich nun aus welchem Grund für mein Heimnetz angeschafft, obwohl nur die Firewall zu ersetzen gewesen wäre?

UniFi® Security Gateway (USG)
Wie es der „Gateway“ im Namen schon sagt, ist dies der Zugang ins Internet. Der USG ist einerseits ein Router mit den üblichen Funktionen Routing, DHCP Server, Firewall etc. bildet jedoch auch ein Kern im Aufbau des Unifi Netzwerkes. Das komplizierteste an der Konfiguration war hier, dass ich nicht das Standard Subnetz 192.168.1.0/24 verwenden wollte. In diesem Fall muss der Controller vorher aufgesetzt werden (war meiner bereits) und die USG über CLI mit einer IP im definierten Subnetz konfiguriert werden. Die Beschreibung ist hier zu finden:
https://help.ubnt.com/hc/en-us/articles/236281367-UniFi-How-to-Adopt-a-USG-into-an-Existing-Network
Dies wäre theoretisch das einzige Gerät, welches ich nach dem Ausfall meiner Firewall benötigt hätte. Das Routing etc. macht der USG auch ohne Probleme, jedoch ist im Bereich Firewall noch Entwicklungspotential. Für den Heimbereich und auch in kleineren Firmen absolut brauchbar. Wer jedoch komplexe Firewallregeln, Policy Based Routing, QoS etc. benötigt sollte vorerst ein anderes Gerät wählen.

UniFi® Switch 8-60W
Ich hätte auch meine bisherigen kleinen Netgear Switche im Einsatz behalten können, jedoch haben mich diese „gemanagten“ Switche in Sachen VLAN entäuscht. Daher habe ich alle für mich relevanten Switche durch das genannte Modell ersetzt. Wegen dem Access Point und dem VoIP Telefon wählte ich ein PoE Modell. Im Büro hätte es auch eines ohne PoE getan, jedoch war der Preisunterschied minimal. Dieser 8-Port-Switch bietet nun 8 verwaltbare Gbit-Ports, wobei vier Ports PoE fähig sind bis zu einer Maximal-Leistung von 60W. Ich habe mir auch den 16-Port Switch angeschaut, jedoch war der teurer wie zwei der kleinen.

UniFi® AP AC PRO
Der Access Point (AP) der PRO Serie sollte meinen kleinen ZyXEL AP ersetzen, welcher wie die ZyWALL schon in die Jahre gekommen ist. Von Ubiquiti gäbe es noch günstigere APs jedoch habe ich mich aus folgenden Gründen für diesen entschieden:
– Dualband (2,4/5GHz) fähig
– VLAN fähig (nicht nur auf dem Papier)
– mehrere unabhängige SSIDs aufschaltbar (max. 4)
– Gäste WLAN fähig
Basierend auf den genannten Punkten sind bei mir nun auch ein produktives WLAN und ein WLAN für Gäste konfiguriert. Zweiteres ist auf einem definierten Gäste-VLAN, welches auch nur den Internet-Zugang zulässt. Als kleines Schmankerl muss ein Benutzer des Gäste-WLANs sich auch mittels separatem Passwort auf einer Portalseite anmelden, wie man es auch aus Hotels kennt.

Anmerkung
Es ist anzumerken, dass jede Geräteklasse für sich angeschafft und betrieben werden kann. Im Verbund jedoch da zeigen sie ihre Stärke. Wenn z.B. ein neues Netzwerk (VLAN) inkl. DHCP Server benötigt wird, wird dieses im Kontroller angelegt, den Switches/Ports und ggf. WLAN zugewiesen und ausgerollt. Anschliessend sind alle Geräte im Verbund fix fertig konfiguriert und es kann gearbeitet werden. Wenn man im Vergleich dazu erst das VLAN erstellen, die einzelnen Switches/Ports konfigurieren muss, dann hat man je nach Netzwerkgrösse ein arbeitsreiches Wochenende vor sich…

Resumee
Nach nun rund zwei Wochen im Betrieb bin ich noch voll zufrieden. Alles in allem eine vollwertige Lösung, die an der einen oder anderen Ecke noch Verbesserungspotential hat:
+ mehrheitlich intuitive Controller-Software (für IT Leute)
+ einfache Konfiguration
+ auf einander abgestimmte Komponenten
+ Preis/Leistung
– sehr rudimentäre Firewall
– Installation der Controller-Software im Benutzerprofil statt System




WordPress Sicherheit erhöhen

WordPress liefert von Haus aus schon eine relativ gute Sicherheit.

Neulich bin ich durch einen Newsletter auf ein Plugin aufmerksam gemacht worden, welches die Sicherheit noch ein wenig erhöht.

Das Plugin All In One WP Security & Firewall bietet diverse Funktionen um den eigenen Blog besser abzusichern. Die Funktionen reichen von einem automatischen DB Backup, über einen Schutz vor Brute Force Attacken, einer Firewall und vieles mehr…

Als nette Funktion sei noch erwähnt, dass die Übersicht vom Plugin uns auch ein Rating der Seite bietet, also ein Indikator, ob man noch mehr Zeit in die Sicherheit investieren sollte, oder ob es soweit passt.

Ich habe das Plugin mittlerweile bei allen von mir verwalteten WordPress Blogs implementiert und der Aufwand beläuft sich auf 15-30 Minuten.




NetScaler SSL Bewertung optimieren

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:

NSRateC

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:

NSRateA

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+:

NSRateAPlus

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:

NSSrvHeadApache

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:

NSSrvHeadUnknown

Und nun viel Spass beim Nachbauen ;-)

Skript: NS-OptimizeSSL




Webinterface mit RADIUS konfigurieren

Hi Folks

Das Webinterface bietet ja die Möglichkeit der Zwei-Faktor Authentifizierung mittels SafeWord, RSA und RADIUS. Wer schon mit RADIUS gearbeitet hat weiss, dass zur Sicherheit ein „Shared-Key“ benötigt wird. Wo nun aber diesen definieren? Die Konsole bietet hierzu keine Möglichkeit…

Für die entsprechende Website müssen in der web.config zwei Parameter geprüft bzw. angepasst werden:

WI-RADIUS-Param
Im RADIUS_SECRET_PATH wird auf eine txt verwiesen, in welcher sich der RADIUS Schlüssel (Shared-Key) befindet.
Zusätzlich muss entweder im RADIUS_NAS_IDENTIFIER eine RADIUS Client-Identifikation (min. 3 Zeichen) oder unter RADIUS_NAS_IP_ADDRES die RADIUS Client-IP hinterlegt werden.
Dies ist die IP, mit welcher sich das Webinterface beim RADIUS Server meldet.

Unter ..\\conf muss die genannte radius_secret.txt angelegt werden. In dieser Textdatei wird der Schlüssel für den RADIUS Server hinterlegt
HINWEIS: aus Security-Sicht müssen die Berechtigungen auf diese Datei restriktiv gehalten werden.

Nun muss im Webinterface in der Authentifizierung der RADIUS aktiviert und konfiguriert werden:

WI-RADIUS-Config
In dem Beispiel ist der SAS Demo-RADIUS konfiguriert

Auf die Serverseitige Dokumentation wurde in diesem Beitrag verzichtet, da es zig Lösungen gibt, welche unterschiedlicher nicht sein könnten ;-)

Citrix Webinterface 5.4