IT Infrastructure | Virtualization | Application Delivery | Networking | Storage


Leave a comment

Securing Citrix Netscaler… The basics!

While there is an abundance of best practices and white papers on how to secure your Netscaler, I come across many implementations that are worryingly insecure. Whenever I highlight this with the IT Manager, engineering or the security team they are naturally keen to plug these holes asap.

After some digging I normally find it’s due to lack of understanding in the product, a disjoint in the handover from the integrator (if installed by a 3rd party), or the project budget was running out and corners were cut. Maybe it went in as a POC and somehow slipped into production as it was ‘working’. It’s particularly prevalent in businesses where there is an absence of a dedicated network / security team and the senior ‘all rounder’ techs manage the routing, switching and firewalls but aren’t too sure of the mystical box called Netscaler that someone installed at some point.

Regardless of the reasons, it must be a least, somewhat secured!

Netscaler is an awesome but complex product, unlike it’s main competitor, the F5 which is modular, the Netscaler is an all in one, unified system, you just need to license the appliance for the features you need. That also explains why the answers vary when you ask, “What is a Netscaler?”

“It’s a secure access gateway”, “it’s a load balancer”, “it’s an application accelerator”, “it’s an SSL offloader”… Well, it’s all of those things and a whole lot more…

Here are 10 tips I’ve thrown together that will minimize the attack surface and provide some security for your Netscaler implementation. I recommended further securing the Netscaler as per Citrix best practice but these steps will at least get it somewhat secured in around an hour.

1.Change the default login! Yes, user: nsroot password: nsroot is left in place way too often.

2. If running a physical appliance (MPX), ensure it’s physically secured in a comms room with limited access to the front panel & console port.

3. Configure role-based access security control (RBAC) for the admins and engineers that require access to the device with named accounts for each.

4. Configure a low system session timeout for the GUI and CLI. This can be done at user / group level but before going that granular, it can be set globally:

  • GUI: Navigate to System > Settings, click Set global system parameters, and set the ANY Client Idle Time-out (secs) parameter.
  • CLI: At the command prompt, enter the following command:
    set system parameter -timeout <secs>

5. Use HTTPS for GUI management access, disable the HTTP access to the GUI management interface. To do so, run the following command:

  • > set ns ip <NSIP> -gui SECUREONLY

6. Create a 2048-bit RSA private and public key pair and use the keys for HTTPS and SSH to access NetScaler IP address, instead of using the factory provisioned 512-bit RSA private and public key pair.

7. Patch it! Ensure the latest security patches and known stable firmware are applied.

8. Ensure it’s secured by a firewall and that it’s management IP is not accessible from the internet.

9. Configure logging to an external host, there’s a nice walk through here:

10. Use Access Control Lists (ACLs) so that the Netscaler CLI and GUI is only accessible from controlled management VLANs / network segments.

I must stress, you can go much further in securing the Netscaler but the above points are fairly easy to implement and will provide a nice baseline. It should bring some value to those sitting with a wide open, unsecure appliance, and believe me, there’s plenty of them!

Feedback and ideas are welcomed, as always! thanks

 


Leave a comment

GNS3 “Not enough space on flash to store vlan database”

GNS3 is a great application for practice, training and simulating network designs/changes when you don’t have the luxury of a proper lab or dev environment. I came up against an issue today on a lab I had built for test purposes. I had already done the basic configuration for a bunch of routers, switches and hosts, the issue appeared when I tried to add some VLANs at the core and distribute them using VTP (VLAN Trunking Protocol)

Now, I personally would not use VTP in a production environment but that’s purely my preference, I know plenty of network engineers who run it on their networks without issue. I’ve just heard way too many horror stories but let’s shelf that for now…

If you’re new to GNS3 it can be a little clunky to get going with it so hopefully this helps some others that come across this problem.

As shown in figure 1, I tried to add a VLAN (VLAN 10) named ‘devops’. On applying this I got an error to say it was not possible in client mode… Easy, I’ll change it to server mode. On running ‘vtp server’ I was presented with 2 errors, ‘Not enough space on the flash to store the VLAN database’ and then ‘No device available’

gns3-issue

I should mention at this point, ‘vlan database’ is a deprecated command, VLANs should be configured from privileged exec mode in the global config when using real Cisco kit but GNS3 requires ‘vlan database’.

Now, we need to shutdown the affected virtual switch(s) and choose ‘configure’ from the right click options as shown in figure 2:

gns3-issue2

I have found that basic configuration items like hostname, banner, interface setup and vty lines etc, are saved (as expected) to the non volatile RAM but any configuration in ‘vlan database’ mode is written to, and referenced in flash.

The default setting for IOS images in GNS3 for the PCMCIA disks is ‘0 MiB’ meaning nothing can be written to storage thus causing the issue at hand.

Set this to at least 1 MiB as shown in figure 3:

gns3-issue3

Side note: Many seasoned IT Pro’s have often questioned the difference between MB and MiB, if you are asking the same question, it’s answered nicely here:

https://www.storelocatorplus.com/the-difference-between-mib-and-mb

Now that we have some disk space to write our ‘vlan database’ configuration to, we need to power the switch on and run ‘erase flash’ from privileged exec mode to initialize it as shown in figure 4:

gns3-issue4

You can now go ahead and add you VLAN configuration using ‘vlan database’ and it should successfully apply without error.

As I mentioned earlier, GNS3 is a great tool but it can be a little tricky getting started with it, especially if you are new to networking. There is plenty of decent online resources that will help you along, their forum is also a good support resource:

https://www.gns3.com/community

I also recommend the GNS3 training course by Keith Barker over at CBT Nuggets:

https://www.cbtnuggets.com/it-training/gns3-definitive-guide

Leave a comment if you have anything to ask or add, I’ll be happy to respond…

 


Leave a comment

SD-WAN with Citrix Cloudbridge

SDN is a technology that I’m interested in but I’ve yet to get my hands dirty, being a ‘Citrix Guy’, I’ve been looking at their SD-WAN solution using Cloudbridge. I wasn’t fortunate enough to make this years Citrix summit in Las Vegas but I enjoyed this demo of it in action, albeit a ‘wee’ bit cheesy…  check it out here:

 


Leave a comment

VMware vCenter IP Change – 503 Service Unavailable

One of my clients had endless issues with a problematic vCenter server running on Windows Server 2008R2. I recommended the vCenter appliance (vCenter 6 Update 1) and subsequently got asked to do the work… all went to plan, but I got a call a few weeks later to say it stopped working following a relativity straight forward migration to different network segment.

The client actioned an export / import of the vCenter OVA and updated the IP address with one from the new subnet. When trying to access the vCenter via the web to manage their environment they got the following error:

vcenter-error

I jumped on to take a look and after some digging, I found that host file on the appliance is not updated with the new IP address following the change. To fix this, connect to the appliance using ssh and drop into the shell. If you have issues connecting, make sure ssh and bash are enabled, you can do this by browsing to:

https://your_vcenter_fqdn:5480

vmware1

  • Connect to the appliance using your ssh client of choice
  • Drop into the shell by typing ‘shell’
  • Now, edit the ‘hosts’ file in ‘etc’ using VI
  • Command – ‘vi /etc/hosts’

Rusty with VI? Let me google that for you:

https://www.cs.colostate.edu/helpdocs/vi.html

Once the IP is updated, give the appliance a reboot.

If you are still having issues connecting, give all vCenter services a restart,

  • Connect to the appliance using your ssh client of choice
  • Drop into the shell by typing ‘shell’
  • Change directory to bin ‘cd/bin’
  • Stop all services ‘service-control –stop –all’
  • Start all services ‘service-control –start –all’

Now, you should be cooking with gas…