SSL Renegotiation

Vor kurzem wurden Tools veröffentlich, welche mit Hilfe von clientseitiger SSL Renegotiation versuchen, Webserver so stark unter Last zu setzen, dass diese nicht mehr auf Anfragen reagieren können und somit die Seiten für den Zeitraum des Angriffs nicht zur Verfügung stehen (Denial of Service). Abhilfe können hier Loadbalancer wie der Citrix NetScaler schaffen, welcher auf eine effiziente Verarbeitung von SSL-Verschlüsselungen ausgelegt und als Hardware Appliance sogar mit SSL-Beschleuniger-Chips (Cavium) ausgestattet ist.

Darüber hinaus besteht bei vielen Webservern die Möglichkeit die clientseitige SSL Renegotiation zu deaktivieren. Standardmäßig ist dies z.B. bei neueren Versionen des Apache Webservers der Fall.

Steht zwischen Client und Webserver ein Loadbalancer, entsteht die Rechenlast im Normalfall nicht auf dem Backend sondern auf den davor geschalteten Loadbalancern. Um zu verhindern, dass es nun zu einer erhöhten Last auf den NetScalern kommt, besteht hier ebenfalls die Möglichkeit die clientseitige SSL Renegotiation zu deaktvieren:

Die Konfiguration erfolgt in der GUI über die Haupseite SSL -> „Change advanced SSL settings“ -> „Deny SSL Renegotiation“.

IP-Adressen des NetScalers

Der NetScaler hat verschiedene Arten von IP-Adressen für unterschiedliche Aufgaben. Die erste Adresse ist die NSIP (NetScaler IP), die als Management IP immer statisch existieren muss. In einem High Availability Paar aus zwei NetScalern ist die NSIP die einzige fixe IP, die jedes einzelne System individuell besitzt. Über diese Adresse wird der NetScaler administriert und von ihr gehen administrative Verbindungen wie DNS Requests, NTP Zeitsynchronisation, Authentifizierungsanfragen und die HA Synchronisation aus.

Bei der Erstinstallation muss weiterhin mindestens eine MIP (Mapped IP) oder eine SNIP (Subnet IP) konfiguriert werden, die als Ausgangspunkt der Kommunikation zu den Backend Servern verwendet wird. Per Default verwendet der NetScaler eine SNIP, sofern verfügbar, oder fällt sonst auf die MIP zurück („Default SNIP“). Es sollte in jedem IP-Netz, in das der NetScaler direkt kommunizieren kann oder soll, eine SNIP angelegt werden, die für diese Verbindungen genutzt werden kann. Der Weg in andere Netze wird über die Routingtabelle gefunden.

Der Dritte Typ von IP-Adressen sind die VIPs (Virtual IPs), die den Clients als Gegenstelle zur Verfügung stehen. Eine VIP wird typischerweise durch das Anlegen eines Virtual Servers erzeugt, der unter dieser IP ansprechbar ist.

Clients verbinden sich also zu VIPs, wo der NetScaler die Verbindung terminiert. Dann baut er eine eigene Verbindung zu dem Backend Service auf, ausgehend von der entsprechenden SNIP (Default: USNIP Modus) oder MIP, über die er die Client-Anfrage weiterleitet. Sollen die Server stattdessen die Client IP selbst als Quelle der Verbindung sehen, muss der USIP Modus (Use Source IP) aktiviert werden, was sowohl global als auch pro Virtual Server möglich ist.

Bei Verwendung des USIP Modus ist zu bedenken, dass die Antwortpakete der Server direkt an die Client IP adressiert werden, was unter Umständen den NetScaler umgeht, wenn Client und Server sich im selben Subnetz befinden oder der Server eine andere Route in das Client Netz hat als über den NetScaler (asymmetrisches Routing).

Administrative Verbindungen auf SNIP verlagern

Da der NetScaler im Normalfall Verbindungen zu Servern sowohl von seiner NSIP (administrativ) als auch einer oder mehrerer SNIPs/MIPs aufbaut, tauchen in ggf. erforderlichen Firewall Policies unterschiedliche Quelladressen für ein und dasselbe System auf. Um das zu vereinfachen, kann der Administrator dafür sorgen, dass auch administrative Verbindungen wie etwa DNS und LDAP (Authentifizierung) von einer SNIP ausgehen. Dazu werden für alle betroffenen Dienste Load Balancing VServer auf dem NetScaler angelegt, die die eigentlich zu adressierenden Server als load balanced Services ansprechen. Diese Backend Kommunikation geht dann von der entsprechenden SNIP aus, von der auch die sonstigen Verbindungen in das entsprechende Netz initiiert werden.

IP-Adressen im HA Modus

In einem HA Paar ist es sinnvoll, den administrativen Zugriff auf einer SNIP oder MIP zu aktivieren. Da alle Adressen abgesehen von der NSIP im HA Paar „floating“, d.h. immer auf dem primären NetScaler aktiv sind, erreicht man darüber immer das System, auf dem die Konfiguration geändert werden kann.

Sind die an einem HA Setup beteiligten Systeme in unterschiedlichen Subnetzen untergebracht, muss der INC Modus (Independent Networking Configuration) aktiviert werden. Mit INC ist es möglich (und erforderlich), dass die NetScaler eines HA Paares nicht nur unterschiedliche NSIPs, sondern auch individuelle MIPs und SNIPs besitzen. Die VIPs können identisch sein, jedoch unterscheiden sich die IP-Adressen für die Backend Kommunikation entsprechend der unterschiedlichen Subnetze.

NetScaler Integrationsvarianten

Der Citrix NetScaler steht als Service Delivery Controller der neusten Generation zwischen Clients und Servern. Er bietet in Form von Virtual Servern (VServern) Services für Clients an, die er in Richtung der Server intelligent verteilt und dazwischen inhaltlich eingreifen kann.

Für die Einbindung des NetScalers in die eigene Infrastruktur stehen unterschiedliche Herangehensweisen zur Verfügung. Angefangen bei der physikalischen Anbindung an die umgebenden Netze bis zur logischen Integration auf  Ebene IP-Adressen und Routing.

Soll der NetScaler etwa als Reverse Proxy für öffentlich bereitgestellte Services dienen, wird er in einer Demilitarisierten Zone (DMZ) platziert, in der ihn sowohl in Richtung Internet (public) als auch Servernetz (private) eine oder mehrere Firewalls umgeben. Da es sich um einen aus Netzwerksicht sicherheitskritischen Bereich handelt, wird es in der Regel abgelehnt, dass der NetScaler selbst an mehrere Netze mit unterschiedlichen Sicherheitsniveaus angeschlossen wird. Daher findet hier der „One-Arm Mode“ Einsatz, in dem der NetScaler nur an ein Segment angeschlossen ist und daher typischerweise auch nur IP-Adressen aus einem einzigen Subnetz besitzt. Natürlich können davon unabhängig mehrere physikalische Interfaces genutzt werden (Link Aggregation, Channels…).

Diese Integration kann auch in Umgebungen eingesetzt werden, in denen sich Clients und Server intern in unterschiedlichen oder sogar im selben Netz befinden. Im ersten Fall (Clients und Server in unterschiedlichen Netzen) ist allerdings die Integration „Inline“ meist besser geeignet. Dabei stellt der NetScaler den einzigen Weg für die Clients dar, die Server zu erreichen, d.h. er verbindet die Netzsegmente entweder durch die Virtual Server, die er bereitstellt, oder auch komplett als Layer 3 Router. Diese „Two-Arm“ Topologie ist wünschenswert und wird daher oft herbeigeführt, auch wenn sich zunächst Clients und Server im selben Netz befinden.

Der Vorteil des Inline Mode ist, dass eine Umgehung des NetScalers und der dort implementierten Optimierungs- und vor allem Schutzmaßnahmen verhindert wird. Durch den „Transparent Mode“ kann das sogar erreicht werden, ohne eine Segmentierung auf IP-Ebene zu erzwingen. Auch dabei wird der NetScaler physikalisch als einziger Weg zwischen der Client- und der Server-Infrastruktur implementiert. Durch die Aktivierung des „Layer 2 Mode“ agiert der NetScaler als Bridge und Clients können die Server direkt adressieren. Der Netzwerkverkehr aber läuft dennoch durch den NetScaler, wo weiterhin alle Eingriffe in den Traffic möglich sind.

HTTP Access Logging auf dem NetScaler

Der NetScaler stellt HTTP Access Logs nicht in Form von Logdateien sondern über einen Ringpuffer zur Verfügung. Dieser Ringpuffer kann in der Standardeinstellung maximal 16 MB groß werden und überschreibt die ältesten Einträge sobald er die maximale Größe erreicht hat. Zum Auslesen des Ringpuffers kann der Citrix Web Logging Client verwendet werden, welcher für verschiedene Systeme zur Verfügung steht und über das Citrix Portal heruntergeladen werden kann.

„HTTP Access Logging auf dem NetScaler“ weiterlesen

Citrix Receiver für das BlackBerry Playbook

Mit Spannung wurde das erste Enterprise-Tablet von Research in Motion erwartet.

Doch damit ein Enterprise-Tablet seinem Ruf gerecht werden kann, bedarf es natürlich auch Anwendungen, die die tägliche Arbeit unterstützen bzw. überhaupt erst ermöglichen. Man könnte fast behaupten, dass der Erfolg eines Device davon abhängt, wie gut oder schlecht das Angebot an Apps ist, welche für das entsprechende Endgerät zur Verfügung stehen.

Ist nicht der unglaubliche Erfolg von iPad, iPhone und Co. auch in hohem Maß der Vielzahl an fantastischen Anwendungen zu verdanken? Gerade hier steckt RIM mit der AppWorld noch in den Kinderschuhen und hinkt deutlich hinter Android und Apple hinterher. Fast vier Monate nach dem Erscheinen des Tablets auf dem deutschen Markt, gehen nun endlich auch die ersten namhaften Hersteller von Enterprise Anwendungen ins Rennen.

Der Arbeitsbereich des Citrix Receiver für das BlackBerry Playbook

Ein erster Schritt zu einem erwachsenen Enterprisegerät wird mit der Verfügbarkeit des Citrix Receivers für das Playbook über die BlackBerry AppWorld gemacht. Zur Zeit steht der Receiver in einer Pre-Release-Version zur Verfügung, die auf den ersten Blick einen recht soliden und aufgeräumten Eindruck macht. Nach Eingabe der Verbindungsdaten wird der Anwender mit einer Lister der für ihn publizierten Anwendungen belohnt. Diese können dann nach Belieben auf den Arbeitsbereich gezogen und von dort aus gestartet werden.

Nach dem ersten Start einer Anwendung erhielten wir allerdings eine „Application Launch Failed“-Meldung. Diese ließ sich mit einer Anpassung der „webinterface.conf“ im Verzeichnis “inetpub”\wwwroot\Citrix\PNAgent\conf auf dem XenApp-Server beheben. Hierbei muss folgender Bereich der Konfigurationsdatei erweitert definiert werden:

ClientAddressMap=*,SG,192.168.30.0/255.255.255.0,Normal

Wobei natürlich die Netzadresse und die Netzmaske des eignen internen Netzes verwendet werden sollte. Von dieser Erweiterung sollten nur Verbindungen betroffen sein, die über den PNAgent erfolgen (Service Site). Das Webinterface sollte davon unberührt bleiben.

Wechsel zwischen einzelnen Anwendungen

Arbeitet man nun mit mehreren Applikationen gleichzeitig und möchte zwischen diesen hin und her schalten, so kann man dieses z.B. durch eine Fingerbewegung vom oberen Rand des Playbooks in die Bildschirmmitte erreichen. In diesem Fall erhält man eine Übersicht, in der dann zwischen den gestarteten Anwendungen gewechselt werden kann.

In dieser ersten freigegebenen Version werden Verbindungen über ein Citrix Access Gateway noch nicht unterstützt, so dass damit auch Sicherheitsfeatures wie z.B. eine zwei-Faktoren Authentifizierung erst einmal wegfallen. Dieses Manko wird laut Citrix aber in der endgültigen ersten Version beseitigt sein. Man darf also gespannt hoffen.

 

NetScaler String Maps

Wieder mal ein Beispiel aus dem echten Leben: Bestehende Reverse Proxies für eine öffentliche Website sollen abgelöst werden. Im Einsatz ist der Apache HTTP-Server mit mod_proxy, mod_rewrite und vhost-Konfigs im Bereich von über 100kb.

Diese 100kb bestehen fast ausschließlich aus RewriteRules, Redirects und ProxyPass Regeln. Sinn und Zweck ist hier, dass einerseits nur Pfade und URLs erreichbar sind, die explizit den Proxy passieren dürfen (ProxyPass Regeln als Positivliste), und andererseits regelmäßig von der Marketingabteilung in Umlauf gebrachte Kurz-URLs zu den vollständigen Pfaden plus Parametern aufgelöst werden, die die Webserver/-services dann auch gebrauchen und ausliefern können.

Eine an sich leichte Übung mit Content Switching Virtual Servern, Load Balancing Virtual Servern, Responder Policies (Redirects) und Rewrite Policies. Zusätzlich könnte man noch ein Pattern Set als Positivliste schon im Content Switching VS einsetzen. Noch mal kurz drüber nachgedacht – das will doch aber keiner pflegen! Die bestehende Konfig ist über Jahre gewachsen, die Listen sind elend lang und hätten bei dieser Überführung riesige Listen von Policies zur Folge.

Die Lösung und enorme Erleichterung kam mit dem NetScaler Release 9.3: String Maps.

Der Kunde bekommt: je Einsatzzweck (Redirect / Rewrite) eine String Map, in der jeweils die erwartete URL/Pfad (Schlüssel) und die daraus resultierende URL/Pfad für den Redirect respektive die Umschreibung (Wert) aufgenommen werden. Dann gibt es einen Content Switching VS, an den die Responder Policy (ja, nur genau eine!) gebunden wird. Diese Policy prüft (Expression), ob die aufgerufene URL/Pfad in der Redirect String Map enthalten ist. Falls ja, wird eine Responder Action vom Typ Redirect aufgerufen, in der wiederum das Ziel des Redirects aus der String Map gelesen wird.

Per Content Switching Policies werden die restlichen Requests auf die entsprechenden Load Balancing VS verteilt. Requests, die für keinen der LBVS passend sind (die Kriterien kann man nun doch wieder mit Pattern Sets oder einzelnen String Maps abbilden, wie es eben passt), landen in einem Catch-All LBVS oder einem direkten Redirect zu einer Startseite. An die LBVS wird dann jeweils genau eine Rewrite Policy gebunden, die wiederum per String Map das Rewriting der Kurz-URLs u.ä. vornimmt. In diesem Fall so aufgeteilt und nicht auch schon im CSVS, damit die einzelnen Maps kleiner sind – aber da das Vergleichen mit einer String Map um Größenordnungen schneller ist als das Durchackern hunderter Policies, könnte man das auch noch stärker zentralisieren.

Die Pflege dieses Setups beschränkt sich künftig auf das Ergänzen/Anpassen der String Map Einträge. Kein Gefummel an Policies, wunderbare Übersicht.

Workshifting mit XenApp und Lync

Heute mal ein kurzer Schnappschuss aus der Praxis, der zeigt, dass „Workshifting“ und das Versprechen mit dem Arbeiten jederzeit, von jedem Ort, mit jedem Endgerät, nicht nur bei den Herstellern funktioniert.

Heute arbeite ich über eine UMTS-Verbindung von ANYPLACE aus. Morgens den Citrix Receiver angeklickt, LogOn mit Benutzername, Passwort und per Blackberry generiertem OTP. In der XenApp Session (hinter einem Access Gateway Enterprise natürlich) läuft der Lync Client, in dem ich mit drei Klicks die Anrufumleitung auf meinen Blackberry aktiviere (gestern war ich noch im Office). Wer nicht auf meine Statusnachricht achtet, merkt nicht, dass ich gar nicht im Haus bin.

Einen externen Anrufer verpasse ich anzunehmen, so dass er bei unserem Servicedesk landet. Die Telefone dort hängen zwar noch an der parallel laufenden VoIP Anlage, aber auch die ist transparent über das Media Gateway verbunden. So stellt der Kollege den Anruf ganz normal auf meine interne Durchwahl durch und übergibt den externen Anrufer von der VoIP TK über Lync an meinen Blackberry, ohne sich darüber Gedanken machen zu müssen.

Ein anderer Kollege möchte mal mit mir gemeinsam einen Sachverhalt begutachten und ruft mich dazu an. Zwar kann ich nicht kurz vorbeikommen, aber er gibt seinen Desktop per Lync frei, so dass wir gemeinsam sehen, agieren und darüber sprechen können – ganz so als säßen wir gemeinsam vor dem Schirm.

Sollte ich später doch noch in einem Office auftauchen, setze ich mich dort an einen Arbeitsplatz, melde mich an und verbinde meine XenApp Session, die ich in der Zwischenzeit vielleicht auch aus dem Zug noch mal aufgerufen habe, um auf dem Tablet an einem Text weiter zu schreiben, und arbeite genau an der Stelle weiter, wo ich vorher aufgehört habe.

Abgesehen vom letzten Teil habe ich das heute schon alles so praktiziert. Da ich nicht mit dem Zug unterwegs bin, entfällt dieser Teil wohl auch, aber es kommt vor. Und das ist schon cool. 🙂

CVE-2011-3192: Apache Zero Day Exploit in the wild – Gegenmaßnahme

Ein 0-Day Exploit für aktuelle Apache Installationen ist im Umlauf – remote Denial of Service:

Full Disclosure
Advisory der Entwickler

Auf Basis der Empfehlung aus dem Advisory können sich diejenigen das Anfassen aller Apache Konfigurationen in der Webserver Farm sparen, die einen NetScaler davor stehen haben – Standard Edition ist ausreichend:

add rewrite policy rw-pol-CVE-2011-3192-bad-range-RESET „http.REQ.HEADER(\“range\“).EXISTS && http.REQ.HEADER(\“range\“).REGEX_MATCH(re#!(^bytes=[^,]+(,[^,]+){0,4}$|^$)#)“ RESET

Global binden und Ruhe. Ohne Garantie, noch ungetestet. Es sind auch sanftere Reaktionen denkbar, etwa das Ersetzen des Headers.

Transparentes Caching mit Netscaler als Content Switch

Nehmen wir an, wir hätten es mit folgenden Anforderungen zu tun: Ein Telekommunikationsanbieter will eine Infrastruktur für transparentes Caching von Inhalten implementieren, die das Datenvolumen in Schach hält und die Zugriffszeiten beschleunigt, die seine Kunden über ihre Mobilfunkgeräte anfordern. Die zu bedienende Bandbreite wird mit 8GBit/s veranschlagt, Luft nach oben sollte natürlich auch noch sein.

Es wird eine Cache Farm mit ca. 50 Cache Servern bereitgestellt, die in Gruppen jeweils für eine definierte Menge/Liste von Domains oder URLs zuständig sein sollen. URLs jenseits der Gesamtliste sollen nicht durch die Caches laufen, sondern direkt abgeholt werden (Whitelist-Verfahren). Außerdem soll ein Verbindungslimit pro Cache Server gesetzt werden, so dass ein Cache, der z.B. 1.000 bestehende Verbindungen bedient, keine weiteren Anfragen mehr bekommt. Sobald alle Caches einer Gruppe gesättigt sind, sollen die zugehörigen Requests ohne Caching durchlaufen. Gefragt ist nun eine Komponente, die als Content Switch vor den Caches agiert und die Requests entsprechend umleitet oder direkt weitergibt – aber immer ohne etwas an den Paketen ab Layer 3 aufwärts zu ändern, d.h. es darf keine Adressumschreibung stattfinden.

Lösung: Citrix Netscaler MPX 11500. Die MPX 11500 hat genau 8GBit/s als Maximaldurchsatz, ist aber per Lizenzupgrade auf bis zu 30Gbit/s (MPX 18500) skalierbar.

Das Netscaler Pärchen wird als L3 Router in den Traffic eingebunden, d.h. jeglicher Verkehr läuft durch die Netscaler. So ist das vollkommen transparente Eingreifen recht einfach zu realisieren. Stichworte sind: MAC-based Forwarding, L2Conn und USIP, Transparent Cache Services mit einem Max Client Limit, sowie Content Switching Policies zur Verteilung der Requests.