NetScaler AppFW – Grundkonfiguration

Während heute Morgen unser vollständig ausgebuchter TechTalk zum Thema „Hyper-V: Alternative zu VMware?“ stattfand, laufen bereits die Anmeldungen für das nächste Mal: am 12.05.2015 spreche ich über die NetScaler Web Application Firewall: „Hinstellen, anschalten, sicher sein?“

Es gibt belegte Brötchen und Getränke zum Frühstück, Talk und Demo. Die Plätze sind begrenzt, daher am besten gleich anmelden.

NetScaler 10.5 build 56.12 eliminates Java

Really. End-to-End. Finally. What was promised, expected and not completely fulfilled with 10.5 initially might now be true with the latest build.

56.12 appeared as if nothing special had happened on March 31st. Just today I luckily updated a customer with easy change management and we went straight to the latest build. Behold my wide eyes – visualizers, diagnostics and even the AppFW profiles do NOT trigger the Java applet anymore! I did not do a full walkthrough yet, but I don’t know of any relevant modules of Configuration Utility that might be missing so far.

What a great day! 😀

How to respond with the desired status code

As you probably know, NetScaler can respond to a client request with a website stored directly on the appliance. Since 10.5 you can even use the new GUI to import the sources from any website reachable from your  NetScaler appliance. This is a great feature to give a meaningful response to your users. But let’s check the details, because the devil is in the details.

First of all you’ll need to add some tools to your browser to see all the details. I usually use my Firefox with the add-ons „Live HTTP Headers“ and „HttpRequester“. For this test I will use the „HttpRequester“ to show you the difference.

I’m using a really simple html page to deliver as an error page to my test user. The page was imported through the import html wizard.

 

You can use the page from a responder policy to deliver the page to your user. The content will be delivered to your client. That means there will be a status code 200 that means everything is alright. But we are trying to deliver a different message. Because we have a situation that is not alright!

So how to get the right status delivered? Just build the response on your own. 🙂

Let’s compare the different results:

 

That’s a really annoying way to setup the response, but if you need the right response code, you actually have to deal with it. But I’ll try to address this in the next meeting with Citrix NetScaler product management.

Updating NetScaler Gateway using custom theme

Since version 10.1 NetScaler (Gateway) uses a new mechanism for deploying and maintaining custom design themes for login pages. This works quite a bit better than the old way with manual boot scripts to copy customized files. But it still is prone to issues especially after updating the NetScaler firmware.

Before updating firmware, make sure to set the theme back to „Default“. This will not impact your users, because you do this on the SECONDARY node in your HA pair, which is not taking connections at that time. After the update, set the theme to „Custom“ again and re-implement customization, force HA failover and repeat on the other node.

What might happen, if you change this procedure? A couple of chances to mess things up:

  • No login possible through or malfunction of admin UI. The Configuration Utility is part of the ns_gui folder being deployed through the custom theme mechanism. If theme stays at „Custom“, the updated files will not be part of the customized ns_gui folder and thus the admin UI will be old and possibly incompatible with the new firmware.
  • No login possible through or malfunction of NetScaler Gateway and AAA-TM. If the files for login, tmlogin et al. are not updated, they might be missing changes needed for correct function with new firmware. Furthermore, the client components (Gateway Plugin, EPA Plugin) will not be updated and especially establishing an SSL-VPN will fail subsequently;
  • Update-downgrade-loop of Gateway Plugin: Even if you noticed that the client components need an update and you manually uploaded the new AGEE_setup.exe to your NetScaler Gateway (after you have manually updated the admin_ui folder in your ns_gui_custom folder to be able to login again…) and your clients have successfully updated, they will still fail to establish SSL-VPN connections. First they were told they need to update Gateway Plugin to a new version, which they thought they downloaded from the NetScaler Gateway, but they got the same old version. Now they have the new version installed, but upon connection they will be told they need to downgrade to an older version. After which they would be told to update again. This is due to another file not being updated, which compares the client’s version to its own information – which still has the old firmware version.

There might be even more issues, but at least these have been seen in the wild already. So make sure to simply go back to default and redo the customization. A script for creating the archive out of the newly customized files might be helpful. Yes, the archive. Make sure to recreate it after every customization, because it will be extracted and its contents will be used upon every NetScaler boot.

Update: Thanks to Stuart Carroll (@stuart_carroll) for the comment on using Rewrite feature to modify default themes to reduce risks even more. Whenever possible (complexity of customization is limited, of course), this is the best way to go. See our (German, sorry) post on using Rewrite for customizing Clientless Access view to get an idea on that.

Citrix ShareFile – Neue Zone: Access Restricted!

Citrix hat vor wenigen Tagen bekanntgegeben, dass die FollowMeData-Lösung ShareFile um eine weitere Storage Zone erweitert worden ist: Die „Restricted StorageZone“. Was ist der Unterschied zwischen einer Restricted StorageZone und einer Standard StorageZone?

Im Unterschied zu den cloudbasierten Citrix-managed StorageZones und den vom Kunden verwalteten On-Premise-StorageZones sind Dateien, die in einer „Restricted StorageZone“ abgelegt werden, nur für domänenauthentifizierte Benutzer innerhalb des Unternehmens abrufbar. Citrix hat keinerlei Einfluss auf diese Zone und kann keine User außerhalb der Domäne berechtigen, auf abgelegte Dateien zuzugreifen. Die Datei- und Ordnernamen sind mit dem kundeneigenen AES256-Key verschlüsselt und Metadaten werden verschlüsselt in die ShareFile-Cloud übertragen. Die Verschlüsselung wird natürlich auch hier auf dem On-Premise-StorageZone Controller im kundeneigenen Unternehmensnetzwerk vorgenommen.

Um Zugriff auf die Daten innerhalb dieser StorageZone zu erhalten, ist eine Domänenauthentifizierung notwendig. Datei- und Ordnernamen bleiben nur innerhalb der Domäne bekannt und können von keinem anderen Account, ob extern oder Citrix-intern, abgerufen werden, sobald sich die Daten in einer solchen StorageZone befinden. Zudem müssen die User beim Zugriff nebst der ShareFile-Cloud-Authentifizierung ihre Identität über den StorageZone Controller überprüfen lassen.

Die reglementierte StorageZone muss nicht über ein Portforwarding o.Ä. dem Internet präsentiert werden. Falls die StorageZone nur mit einer internen IP konfiguriert wird, muss der User für den Zugriff über das Firmennetzwerk oder einen gesicherten VPN-Tunnel – zum Beispiel ein XenMobile Micro-VPN – verbunden sein, um auf Daten zugreifen zu können, Dateien zu teilen oder zu synchronisieren.

Und das Beste daran: Authentifizierten Benutzern geht der FollowMeData-Vorteil durch diese Lösung nicht verloren, sodass sie weiterhin auch mobil auf die Daten zugreifen und über mehrere Geräte synchronisieren können. Dateien aus der Restricted StorageZone können eben nicht mit Anwendern außerhalb des Unternehmens geteilt werden.

Quelle: http://goo.gl/qUGJVp

Update Shellshock & Poodle

Hi everybody,

just a short note to get the latest news for the Shellshock & Poodle vulnerability. I’m sure most of you had already done the steps Citrix recommends. But for the others here are the steps you need to do.

Shellshock:

For NetScaler, Shellshock is only a problem on your private interfaces like SNIP, NSIP. Your VIP is safe. To get your private interfaces secure as well, just upgrade to 10.5-52.11 or 10.1-129.11 or 9.3-67.5 it depends where you come from. But I’m sure all of you are using 10.x instead of 9.3 meanwhile as the latter one is End-of-Maintenance by the end of next week.

AppFirewall got a new signature since the end of September called web-shell-shock to protect services behind NetScaler.

Poodle:

And again Citrix NetScaler gives you the chance to raise the security for every other web service you’re publishing. Just disable SSLv3 on your NetScaler SSL vServer objects and all your published web services are save. For your other NetScaler objects like NSIP / SNIP you need to go to the CLI but even those steps are explained in detail in CTX200238.

 

 

 

Citrix Technology Exchange 2014: Die besten Sessions

Morgen und übermorgen findet in München-Unterschleißheim die Citrix Technology Exchange statt – ausgebucht schon seit einigen Tagen, obwohl wir hier noch gar keine Werbung gemacht haben…

Über 1.000 Besucher freuen sich auf intensive Sessions mit vor allem technischen Inhalten. Aber auch Feedback und Erfahrungsaustausch unter anderem mit Vertretern von Citrix Consulting Services und Product Management stehen auf der Agenda. Besonders ans Herz legen möchte ich natürlich meine Session am Mittwoch nach dem Mittagessen im Raum Alpsee: „O’WASP is! – Advanced Application Security mit NetScaler“ – wer mir hinterher die korrekte Anzahl von Star Wars Zitaten sagen kann, kann etwas gewinnen. 🙂

NetScaler ShellShock

During the last days we all had the chance to start a personal panic for what kind of systems would all be affected by the newest ShellShock Security Issue.  But lets face the facts. There is a chance to survive. 😉

Citrix is actually working under pressure to fix every possible ShellShock security issue. From Citrix NetScaler point of view there are only possible security issues for NSIP and management enabled SNIP objects. But we all know that your NSIP and SNIP IPs are only home in secure networks anyway.

We are waiting for a fix to close that last possible door, while an App Firewall Signature Update is already available blocking ShellShock attacks for any service published by Citrix NetScaler!

Stay tuned!

 

Outlook Anywhere for Mac OS

I’m almost the only guy with a Mac OS workstation in our company. On that behalf nearly every strange behavior and every service ticket with Mac OS comes on my desk.

Today I had a really interesting case. The main actors where Office 2011 for Mac and an enhanced NetScaler Exchange publishing. The Outlook for Mac refused to connect to Outlook Anywhere (formerly known as Outlook RPC-over-https).

We didn’t have a clue what could be the problem until we noticed, that Outlook for Mac won’t use the „/rpc“ path. Instead it uses the „/ews“.

From here on we only used the well known steps to provide 401 authentication instead of 302 redirect on NetScaler AAA and set up the basic authentication for the Exchange / IIS Site. With that everything works fine…