Recently in Security Category

PIX/ASA Emulation using GNS

| No Comments | No TrackBacks

Many folks are likely practicing for certifications and have trouble being able to get thier hands ahold of real equipment to praactice on.  GNS3 is a great tool for basic emulation of routers, switches (with some tricks) and firewalls!

Most folks want to emulate an ASA, which I am not currently aware of any product thaat will do this, but for the moment, the PIX code is virtually identical!  The primry differences what most people will notice (from an emulation perspective anyway) is that the interfaces have slight differences (Ethernet0-5 vs. Ethernet0/0-3 & Management0/0) and the SSM modules are not present and the IPS and Content inspection commands for the service policies won't exist.

But what aabout licensing?  This is where the real trouble happens, your emulated PIX by default won't have an activation key or serial number.  Ooops!  This means no VPN, not even DES!  No failover either!  Therefore you can't test any config that requires these features.  What you need to do is to locate a valid PIX somewhere.  In my case, I have a PIX 515E at work in our lab. 

I pulled a show ver from that PIX and made note of the Serial Number and Activation Key.  Once I had these, I go into GNS3 and right click on my PIX (from the network topology window) and select configure.  Obviously you need to select your PIX code file here, but you can also paste in the activation key.  You will get an error if you just paste it in though.  You must change the spaces in the activation key into commas ",".  The serial number field requires the information to be entered in hex.  So open your handy calculator and enter the decimal serial number from the real unit or from the show ver and convert it to hex.  You can then past this number into the field in GNS3 with a "0x" in front of it.  Depending on the code you choose, the activation key may or may not work at this point.  If it doesn't simply enter config mode on your virtual PIX and enter the activation-key command.  after a save and reboot the PIX should accept the key and work with the same license as the real one.

Just as an important note: This is NOT intended as a way to bypass Cisco's licensing.  You should not even think about using a GNS3/PEMU emulated firewall for production security purposes.  If you have a production need, eBay a PIX or better yet, buy a shiney new ASA 5505.  Only use this information in a lab.  Also, don't even think about asking me for activation keys or serial numbers. 

1.5 Factor Authentication?

| No Comments | No TrackBacks

So, with all the recent concern over PCI and similar security requirements, lots of people are considering multi-factor authentication technologies whenever the cost/convenience tradeoff makes sense.  VPN and other remote access technologies are places where this kind of technology makes good sense.  About a year ago I was asked to help implement a two factor authentication scheme for VPN using a Cisco ASA firewall.  There was a sincere desire to avoid having to pay for RSA tokens or smart cards, so we decided to use the technology that the customer had available, certificates.  In theory, one could use a certificate as something you have and then provide a username and password during x-auth as something you know

To implement this, I changes the ISAKMP profile to use RSA-SIG authentication instead of pre-shared keys.  I set up the remote access VPN as normal, including X-AUTH.  When the VPN client connected, we discovered that everything we did actually worked!  Since making something work the first time is not typically my specialty, I knew something must have been wrong.  A bit of thinking and testing later, the other shoe finally dropped!  We connected to the VPN using USER1's certificate, but tried USER2's username and password.  Much to my dismay, it worked. 

While this does technically pass the definition of two factor authentication, at least as far as the auditors are concerned, I wouldn't call it a good long term plan.  TAC to the rescue!  My confidence was shattered when I was informed that this was a new feature according to the design engineers and wouldn't be available until spring-ish 2008.  Fast forward about a year and guess where I am?  In the past few months I happened to notice a command that I thought enabled the X-AUTH username to certificate CN check.  Apparently I was wrong, as it doesn't work.  Well to be exact, the command I am referencing, username-from-certificate, works when paired with another command, pre-fill-username.  Unfortunately, but not surprisingly, the latter command only applies to WebVPN/SSLVPN!

I am planning on opening a TAC case in the morning on this as well as calling my local SE, in the mean time I am going to assume this is another sign of the death of IPSec (the other sign being no 64-bit OS support).

UPDATE: It turns out that this feature was requested and supplied in version 8.0(3) 1.  Unfortunately only for AnyConnect.  There are no plans to support the IPSec client with certificate CN validation.  Ouch, another nail in the coffin for the good old IPSec VPN client.  I guess I better spend some time snuggling up next to the WebVPN/SSL VPN command reference guides!

About this Archive

This page is an archive of recent entries in the Security category.

Routing is the previous category.

Switching is the next category.

Find recent content on the main index or look in the archives to find all content.