Tuesday, 25 June 2013

Junos Space and Security Director - Part 1

Space, the final frontier!

Junos Space is largely the replacement for Juniper's previous management platform (NSM).  In this post, I'll run through configuring a small lab environment and give an overview of the features built in to Space.

Part of the reason that I've been investigating Space is that I've been engaged to recommend a solution for a network that requires remote management of 30 or so Juniper SRX devices.  As such, I'll also touch on the Security Director side of Space.

Getting Space

Space is fairly easy to obtain assuming you already have an account on Juniper's website.  For those of you who don't, I'm assuming that a free account will also give you access to the image but if not, please don't ask me!

At the time of writing, Release 13.1 only contains the image for Security Director.  We'll come back to this in a future post so for now change Release to 12.3 and grab the virtual appliance image.

The virtual appliance is designed to run in ESX but as I don't have that available to me at the moment I'll use VMWare Player instead.

You will likely be notified that the ova does not comply with the OVF specification and/or virtual hardware compliance checks.  I suspect this is due to the use of Player over full ESX.  Select Retry.

Select Retry if you get this error.
I'm also doing this on a laptop with less RAM than Space expects at first import so I'll also reduce the amount of RAM allocated to the virtual machine.  Space will complain about this initially but besides reduced performance everything appears to operate correctly.

Reducing the RAM to 3GB

Adding an Additional Disk

The next step is one that is widely missed.  By default, the VM only has an 8GB disk.  Unfortunately, installing some applications (such as Security Director) requires that 10 times the application be available for installation.  Security Director weighs in at ~500mb so we'll need to add an additional disk.

I would recommend adding at least 40GB if you can based on Juniper Support documents.

Select Add

Select Hard Disk
Create a new virtual disk
SCSI is preferred
Enter 40GB.  As this is a lab machine, don't worry about allocating all of the space now.
Choose a filename for your new disk image

Logging in for the first time

Great, now you've got a virtual machine running Space.

Login using the default credentials and let's take it for a spin.

Username: admin
Password: abc123

Yes, please!

I've made a deliberate decision to reduce the RAM and accept the risks so let's charge on!

The next bit covers configuring IP addresses for the primary interface, nameservers and the like.

An important thing to note is that you will need at least two IP addresses.  One is used for communication with devices, etc. and the second is used exclusively for the web GUI.  Both IP addresses must be in the same subnet but can not be the same.

You will also be prompted to enter a maintenance password.  This is used when Space has entered maintenance mode.  This can occur after an unexpected reboot, during software upgrades or other unexpected conditions.  It's important to keep this handy.

All configured and ready to go
Apply the settings and Space will start it's initial configuration routine.

About that disk drive..

Finally, we've got to expand the volume group.

We've already added the virtual disk so go ahead and choose option 5.

And we're done!

In part two I'll cover logging in to Space and importing a device.  Finally, we'll also take a look at Security Director and see how it compares to NSM.

Saturday, 16 February 2013

It's the little things

(Yes, this post was really old BUT I deleted it without paying attention)

The little things...

I hardly ever use this thing which is kind of depressing.

I've been working on setting up a home lab using VMware Workstation/vSphere5 lately.

In simple terms, it has:

  • Bastion.  Used for managing the entire environment in isolation using SSH tunnels.
  • FreeNAS.  Presents a storage target to vSphere so I can vmotion things around.
  • Cacti.  Graphing various things while I experiment with templating.
  • Nagios.  Monitoring various things.  Mainly focusing on network monitoring to experiment with thresholds and failure conditions.
  • Syslog.  Collecting data and working on ways to analyse and store it.  We can't all afford Splunk ;)
  • Services. DHCP, Bind, etc.
  • F5 LTMs.  Local load balancing.  Currently a big focus for my employer so it's a big focus for me!
  • F5 GTMs.  Global site load balancing.  As above!
  • F5 ARXs.  iSCSI presentation.
  • A whole heap of temp VMs that I build as I get to things in my studies or I think the technology is pretty cool.  At the moment this includes an 8 host CouchDB cluster just because I can, I'm not even putting data in it :D

Eventually, I'll add a few Windows hosts but my own interest is fairly low so it's not a priority at the moment.

As I'm a network guy, I've been inclined to over-engineer the whole lot so I've also set up a few of networks:

  • Storage.  Presenting storage to the ARX VMs.
  • Prod.  Generic VM network.
  • Load Balancing.  Presenting SCSI targets from the ARX VMs and doing layer 4 to 7 load balancing with the GTM/LTMs.

 A bridged network is also available to the Bastion to make life easy!

At the moment, I'm experimenting with using a Synology DS1512+ loaded with 8TB (10TB really but some is used for redundancy) for storage.  This is in addition to the 2TB disk presented by FreeNAS.

The end goal with the ARX is to combine both the Synology targets with the FreeNAS targets and make a pretty cool system where end systems won't care where it's stored, only that it is stored   How terribly cloudy!

In other news, Debian is still terrible.  mpt-status has been loaded automatically for at least the last two years, by default, because VMware emulate a particular SCSI controller.  I really hate building new VMs and having to manually disable/stop the mpt-statusd service.  I know, I can use Chef, Puppet, etc but talk about effort.  I'll eventually get to them but really, this should be something chosen during the installer (i.e.  do you want to use raid? LVM is stll an option, why isn't raid?).

Things like this really push me towards CentOS/Scientific Linux.

I think I'm going to start using this blog to document the cool tips and tricks I come across when I'm messing with this stuff.   I absolutely hate running in to the situation below so I'd rather document the solution and save someone the headache.

Source: http://xkcd.com/979/

Friday, 13 January 2012

SSH Tunnel Woes

At my workplace we often need to work from home or other places where a secure connection to our internal network is not available. One of the key concerns for this kind of work is the security of our internal networks and our customer's hosts. In order to mitigate this risk we have implemented two remote access solutions - SSL VPN and SSH tunnels.

Recently, I was unable to login to the SSL VPN on my Macbook Air which lead to a fairly annoying lack of connectivity to our internal networks in the middle of a change window. We have a backup solution for situations like this but I also couldn't get this to work and I still can't work out why.

The alternate solution is a fairly standard SSH tunnel. Local ports are redirected and forwarded by the remote server to the host that you eventually want to connect to. For a Windows host this usually means forwarding a local port to port 3389 to allow RDP to connect.

The command that I use is this:

ssh -N -f -L xxxx:my-desktop:3389 username@ssh-server

The flags cause the ssh client to stay in the foreground until just before command execution (-f) and then background the ssh client (-N). This allows me to complete our two factor authentication and then continue working without ssh in the foreground. xxxx is the local port that I need to connect to in order to forward my connection to port 3389 on my-desktop.

After this I use a small script to find the connection in the process list and kill it without having to look up the process ID.

Unfortunately, this has recently stopped working and I'm not sure when it occurred as I usually use the SSL VPN.

The SSH session connects, authentication completes and my port successfully forwards to my desktop. The OSX RDP client attempts to connect to the desktop but ultimately fails.

Curious as to why this was I decided to investigate a bit further.

I know the OSX RDP client works because I was eventually able to get the SSL VPN connection up and working. I've also used it on the LAN several times to connect to my PC.

To prove that the port forwarding was working I shut down the RDP process on my Windows PC, started a netcat session listening on TCP 3389 (nc -l 3389) and used telnet to connect to the local tunnel port on my Macbook. The TCP session was established and I could enter data from both ends and have it appear on the other end.

Wireshark captures taken during this time don't indicate any issues. I tried again with the OSX RDP client while taking a packet capture and once again didn't turn up anything untoward.

At this point I was getting fairly frustrated with the problem because it didn't make any sense. I decided to present my SSH tunnel towards a Windows 7 VM running in VMware Fusion and try to connect from there. On the VM, I connected to the port on the host machine and was able to connect absolutely fine with the Windows RDP client.

This is where my ideas for troubleshooting stop as I can't think of any other theories. If anyone has any ideas or more details on what could be going on that would be great. I have a workaround (using the Windows VM) but ideally I don't want to fire up a full VM just to connect when the SSL VPN is not available.