Das Blinken Lichten

As I have mentioned many times before, my problem with CSD is that it just doesn’t work all of the time.  The fact that it can detect my anti-virus manufacturer but not the type is frustrating.  The fact that even though it detects the manufacturer but can’t use that result in a DAP is even MORE frustrating.  I spent a lot of time searching the internet for a solution and one thing I came across was something called advanced expressions.

Advanced expressions can be defined within a DAP and use LUA functions to evaluate what gets returned to the ASA during host scan.  The function is sort of hidden within the DAP interface.  You need to select the down arrow on the right side of the screen in the ‘Advanced’ area.  Once you press the down arrow your window should look like this…

If you click the ‘Guide’ button you’ll pull up the help on how to define LUA’s and be shown some examples.  Basically the advanced expression allows you to check for an instance of a anti-virus program, or an instance of an anti-spyware program, or that the client has a firewall installed.  You can’t determine what it is, or if it’s up to date, you can just detect if it’s there.  I see this as a sort of compromise for the host scan results not working at all.  Yes, it would be VERY nice if host scan and DAPs worked perfectly, but at least this way you can determine if the client has a anti-virus program installed at all.  I tested the LUA expression for anti-virus by uninstalling and reinstalling my anti-virus software and it worked.

Below are the different LUA expressions for anti-virus, anti-spyware, and client firewall.  To use any of them simply copy and paste them in the logical expressions box within the advanced options of the DAP.
Note: I copied and pasted these from the help.  This is NOT my own work

Anti-Virus
assert(function()
    for k,v in pairs(endpoint.av) do
         if (EVAL(v.exists, "EQ", "true", "string")) then
              return true
         end
    end
    return false
end)()

Anti-Spyware
assert(function()
    for k,v in pairs(endpoint.as) do
         if (EVAL(v.exists, "EQ", "true", "string")) then
              return true
         end
    end
    return false
end)()

Firewall
assert(function()
    for k,v in pairs(endpoint.fw) do
         if (EVAL(v.exists, "EQ", "true", "string")) then
              return true
         end
    end
    return false
end)()

I think LUA expressions are a little more straight forward in some cases.  I’d love to spend more time trying to hack apart the LUA expressions to figure out what all of the variables are.  If anyone has done that I’d love to hear from you. 

This post wraps up my coverage of CSD.  I’m hoping that someone at Cisco reads these posts and sends me an email telling me that there has been a new update and everything magically works now; that would be great, however the reality is that it isn’t perfect.  I imagine other manufacturers’ similar products aren’t perfect either.  Regardless, there are some great pieces within CSD that do work, and work very well.

I’ve decided to merge parts 5 and 6 together since host scan results are used directly with dynamic access policies.  In this post we’ll walk through an example of how to define a basic host scan and use its results to determine access with dynamic access policies.

DAPs (Dynamic Access policies) allow you to evaluate tons of different client settings and apply policy based upon the results.  In regards to CSD, DAPs are evaluated at the time of logon.  As you might recall from part 2 of this series we can ask host scan to look for processes, files, and registry entries during the CSD load process.  The results of those scans are sent to the ASA and then evaluated during the user login process.  A default DAP (DfltAccessPolicy) is defined in the ASA which is enforced if the ASA can’t match the user to another DAP based on other criteria.  Let’s take a look at the DAP screen in the ASDM.

As mentioned above, there is a single DAP defined from the start.  The DAP is enforced if no other DAPs are matched to the client configuration.  Let’s do a quick example of how the default DAP works.

Select the Default DAP and select ‘Edit’ from the right-hand side of the screen.  Editing the default DAP will look slightly different then editing DAPs you create.  This is because you aren’t allowed to change which attributes match the default DAP.  Change the settings of the default DAP to look like the screen below.  Ensure that ‘Terminate’ is selected and enter a meaningful user message.  Then press OK to close the DAP window and then press apply in the ASDM window.

Now let’s try logging into our WebVPN portal to see what happens. 

As you can see we matched the default DAP and received the error message we defined.  Now, let’s define a DAP of our own.   Navigate to CSD – Host Scan in the ASDM.  Under basic host scan select the ‘Add’ button and select ‘File Scan…’ as shown below.
 

In the ‘Add File Scan’ window let’s define a test scan searching for a file that we are sure the DAP will find.  Press ‘OK’ to add the file to basic host scan.  Ensure you press the ‘Apply All’ button at the bottom of the screen as well.

Now let’s go back to the DAP window and define a new DAP.  Press the ‘Add’ button on the right side of the screen.  You should be presented with the ‘Add Dynamic Access Policy’ window as shown below.
 

There are a ton of options we can define but for now let’s just make a DAP that looks for the file we defined in host scan.  To do this, press the ‘Add’ button on the far right of the screen. This should present you with the ‘Add Endpoint Attribute’ window as shown below. 

Endpoint attributes are any settings sent to the ASA about the state of the client.  This includes the files, processes, and registry entries we ask host scan to search for, as well as all of the information it should return by default.  The information it should return by default are items such as anti-virus, anti-spyware, operating system, client firewall, etc…  However as you’ll recall, most of those items don’t return the correct values which means that they won’t work in our DAPs.  That being said, I’m going to stick with evaluating host scan items during this walk through.  I am NOT saying that the other attributes won’t work for you, all I’m saying is that you should test them in your environment before deployment.

So let’s ask the DAP to look for the file we defined in host scan.  Under the ‘Endpoint Attribute Type’ drop down select ‘File’.  Since we only defined one file for host scan to look for it will automatically be selected in the ‘Endpoint ID:’ drop down.  Press ‘OK’ to add the endpoint attribute.

Now we need to tell the ASA what we want to do with clients who match this DAP.  Let’s set this DAP to ‘Terminate’ as well and set the message to something meaningful as I have done below.  Press ’OK’ and then ensure you apply the configuration.

Now, let’s try logging into our WebVPN portal again.  We now get the screen shown below.

A click on the ‘More Info’ link shows us the message we defined in the DAP.

Now, let’s go back into the ASDM and change the DAP from terminate to continue and update the message to reflect this change.  Now, try logging in again.  You should be able to login to the portal and should see something similar to what is shown below. The yellow exclamation box next to the address bar will be flashing.  If you click on the exclamation box you’ll see the message you specified in the DAP. 

I’m not going to go through all of the different policies you can apply to a users sessions with DAPs, they are far too numerous.  Play around with the different settings you can apply within the DAP and see if there are any that you can use.  I’ve found that checking for files, processes, and registry entries can halfway-substitute checking for things like anti-virus or anti-spyware.  In the next post we’ll talk about using advanced expressions within the DAPs to automatically check for anti-virus and anti-spyware.

I’m going to wrap up my overview of DAPs by talking about their configuration and where it is stored. DAPs are something that are best created, modified, and edited through the ASDM.  However there is some code that still appears in the config.  For instance, after I completed this configuration I had the following code in my config file.

dynamic-access-policy-record Test
user-message "Test DAP, Access allowed"
dynamic-access-policy-record DfltAccessPolicy
user-message "This is the default policy, no access allowed."
action terminate

As you can see, the default action would be to continue so its not defined underneath our test DAP.  The rest of the DAP information is stored in a XML file similar to the pre-login policy definitions.  The XML file is called ‘dap.xml’ and it’s located in the root of Disk:0.  A quick look at the XML shows the following.

Our look at DAPs today has been brief but I’m hoping that, by showing you the initial configuration, you’ll play around with the different DAP settings and see what else you can do with them.

Now, let’s talk about something in CSD that works fairly well, pre-login policies.  Pre-login polices are evaluated prior to even showing the user the login prompt for WebVPN.  Much like all the other CSD functionality it needs to be defined within the ASDM. 

Pre-login policy follows what I like to call a ‘flow’.  You begin at the ‘Start’ item and then choose your path based on decisions throughout the flow.  The below screenshot shows a little better example. 

For example, in this flow, CDS checks the OS type. If is Windows XP, 2K, or Vista I am put into the default policy.  If I’m running Windows 9x, Mac, Linux, or CSD is unable to detect then my login is denied and I am shown this screen in my browser.

The benefit of this flow-like system is that I can have any number of policies.  For instance, take a look at this screenshot below. 

I have defined a policy for each OS detection type, which means that I can define CSD settings for each policy.  As I create the policies in the flow, they are also added into the ASDM as shown below. 

As you can see, with each policy I create, I am able to define individual settings within that policy.  Now that we have a basis of understanding, let’s look at each of the checks available for use with pre-login policy.  As shown in the very first image, the default setting doesn’t have any configure pre-login policy checks and dumps the user directly into the default policy. To add a pre-login check, click the plus-sign as highlighted in the image below.  When you click the plus-sign an insert check window will appear at the bottom of the screen as shown in the second image.  You are able to configure checks for registry items, files, certificates, OS, and IP addresses.

To change the outcome of a check click on the bow directly to the right of the plus-sign. When you select the box to the left of the plus-sign the box at the bottom of the screen will change to end selection window. The end of you flow can deny login, point to a policy (login allowed), or start a subsequence.

Subsequences are just new flows.  The image below shows a subsequence, I think it’s fairly self-explanatory. 
Pretty easy isn’t it?  It certainly is.  However like the other parts of CSD there are pieces that I just couldn’t get working, specifically the IP address check and the certificate check. They just didn’t work and I wasn’t able to find any helpful documentation on defining each of the checks either.  The more frustrating point is that there isn’t a log ANYWHERE that tells you on what step of the policy the client failed at.  The best thing I found was in the hostscan.log file located within C:\Documents and Settings\<Username>\Application Data\Cisco\Cisco HostScan\ directory.  And this is all it says…..

 

[Sat Jan 30 14:53:48 2010][hostscan][info][csd_transport_get_data] getting data done
[Sat Jan 30 14:53:48 2010][hostscan][debug][cfg_process_data] parsing config data.
[Sat Jan 30 14:53:48 2010][hostscan][warn][parse_prelogin] prelogin denied!

Neat, I mean that tells me all sorts of things I didn’t know already.  It seems to be a reoccurring theme here that the logging and debug information with CSD just isn’t up to par.  On top of which pre-login policies, once defined in production, aren’t something you can just start playing around with to see which one is getting hung up on a particular client machine.  At any rate, let’s walk through configuring the ones that do work.

Shown below is the entire flow that I configured.  I’ll list the checks I configured below.

 

OS Check – All only newer versions of windows
 

Registry Check – Check the registry for HKLM\SOFTWARE|McAfee
 

File Check – Check for C:\Program Files\McAfee\Managed VirusScan\VScan\McShield.exe

Designing flows for pre-login policies are pretty easy to do, however I would stress that these items should be tested well in advance of actually deploying them in production.  And good luck when it comes to troubleshooting these.

Where are CSD configurations stored?
If you are like me and are disappointed about not being able to do any of this in the CLI then you might be asking yourself, where are these configuration settings stored?  Good question.  When you install CSD it creates a folder in flash called ‘sdesktop’.  Within the sdesktop folder is a XML file called data.xml.  A look at the XML file shows all of our pre-login policy settings.  A screenshot of my data.xml file is shown below.  As you can see all of the checks I defined are nested in the XML.

Additionally our Default policy is defined at the bottom of the XML document.

Summary
Much like some of the other parts of CSD, pre-login policies aren’t 100% perfect.  There are however some pieces that do work and those pieces work fairly well.

Today we are going to talk about what CSD installs onto the client machine.  I will note here that I’m a Windows guy, so any and all of the below information will pertain directly to the CSD install on Windows (specifically XP).  You’ll recall that after you initially uploaded and configured WebVPN to use CSD that you got a different screen when you tried to access the portal login page.  The page you received should have looked like this…

Additionally, you were asked to install a plug-in  in Internet Explorer.  If you approved the installation, you should be able to see the the plug-in under Add-ins in internet explorer.  This is the first component that CSD installs. 

Once the IE add-on is installed, the CSD package begins loading onto your machine.  For some reason it took me a very long time to initially locate where the CSD files were being installed.  Furthermore, the Cisco documentation, at first, wasn’t very helpful in revealing the location either.  The path where CSD gets installed is…

C:\Documents and Settings\<username>\Application Data\Cisco

In the root of that directory you will most likely see two different folders.  One will be called ‘Cisco Secure Desktop’ and if you have enabled host scan, there should be a second called ‘Cisco HostScan’.  I think it’s important here to make a few distinctions.  With CSD you really have five options.  You configure these from the default policy menu in the ASDM.  Your options are….

Cache Cleaner with or without the use of host scan

Secure Desktop (Vault) with or without the use of host scan

Host Scan

If you are only looking for things like pre-login policy and host scan results to use with DAPs, then you simply uncheck both of the checked boxes. 

So back to our two folders.  If you opt to install cache cleaner or the vault feature all of the components for both of those items will be included within the ‘Cisco Secure Desktop’ folder.  That leaves just host scan components within the ‘Cisco HostScan’ folder. 

Ok, before I go into what goes where and why let’s talk about log files.  I’ll be honest, I’m thoroughly confused about this myself.  Take a look at what the Cisco release notes are for CSD 3.4.2 (which is the version I’m using)

“Control over the severity (called logging level) of the hostscan.log file. Secure Desktop Manager provides the option to record the CSD events to the hostscan.log file onto the user’s computer. This log file is now the only CSD log file. The default logging level, off, does not generate this file, and removes any hostscan.log and csd.log files left from previous releases. Choose Secure Desktop Manager > Logging Level to access this feature. From that panel, you can access the online help for instructions.”

Now, I will note that 3.4.2 is supposed to be a ‘fix’ release so really most of the document refers to the previous release 3.4.1.  At any rate, I tested this forever and I can’t seem to make the logging level setting work at all.  For instance, I tested with both cache cleaner and vault disabled and the logging level set to ‘off’.  Now if I’m reading their documentation correctly it sounds like if it’s set to off I shouldn’t get a log file.  And if there is one there already it should be deleted.  Not so…..  In fact not only do I get a hostscan.log file but I still get a csd.log file which is in total contradiction to their documentation.  A look at the hostscan.log file I get shows all sorts of log entries ranging from info to debug.  The bottom line being that I’m not convinced that the logging settings do anything at all.  Which is upsetting to say the very least…..

Additionally even when I have both the cache cleaner and the vault option disabled I still get a ‘Cisco Secure Desktop folder’ which has two sub folders that are empty.

Now that I’m done ranting (for the moment) let’s wrap up the article with the two options I have concerned myself with.  Host scan by itself and host scan with cache cleaner.   

Hostscan by itself
In this scenario I have both check boxes for on the default policy screen deselected.  The result is that I only get the benefits of host scan which can be used in conjunction with DAPs to limit access.  Let’s run through what gets installed and where.

The installer creates the ‘Cisco HostScan’ folder and creates two log files as well as installs the hostscan.exe executable.  If you look at task manager when the CSD installation screen is up, prior to being shown the logon screen, you’ll see the hostscan.exe running.

As the exe runs it pulls relevant system information and sends it back to the ASA so that the information can be used during logon by evaluating any defined DAPs.  The hostscan.log file and the csd.log file which are located in the root of the ‘Cisco HostScan folder’ contain information in regards to the CSD and HostScan installation.  Interestingly enough there isn’t any relevant information in the hostscan.log file in regards to what information it found during the hostscan which in my opinion would be nice to have. 

Cache Cleaner with Hostscan
Now this is where it gets interesting.  In this scenario, in addition to host scan running, you also get the Cisco cache cleaner application installed.  A few things will be obviously different here.  First off we’ll see the cache cleaner in the toolbar. 

A double click on the icon shows us the cache cleaner dialog which we aren’t allowed to exit out of.  I’m not going to explain what cache cleaner does.  The dialog box shown below does a pretty good job describing it.

Another look at task manager shows the process cunning as ‘cleaner.exe’
Just like host scan, the files for the cache cleaner are installed within the ‘C:\Documents and Settings\<username>\Application Data\Cisco’ folder under the folder name ‘Cisco Secure Desktop’.  However, there isn’t anything interesting within the root of this folder. You need to dig down to ‘…\Cisco\Cisco Secure Desktop\Cache\Temp8-P00h’ to see any real information.  Unfortunately I don’t know much about the folder structure or why the folder is called ‘Temp8-P00h’.  However all my testing shows it being created with the same name each time.  I will note here that ‘Temp8-P00h’ is a hidden folder so you’ll need to set your file explorer attributes to show hidden files and folders to see it.

So what’s in this folder?  There’s a cab file including the installation for the cache cleaner application, A CSDWebLaunch.exe executable, and a hostscan.log file.  Yet another log file (beating the dead horse here but per Cisco’s documentation I don’t think it’s supposed to exist) and ironically one that’s called hostscan.log.  Better yet is the fact that this log file actually includes relevant information to host scan.  The log file not only includes better installation logs for host scan but also includes the host scan results! Is anyone else confused? 

A) The log is for host scan but it’s located in the ‘Cisco Secure Desktop’ folder
B) The log is only generated when the cache cleaner is enabled
C) There isn’t any mention of how to get the client host scan results in any of its documentation

Bottom line?  If you want to troubleshoot host scan, you need to have cache cleaner enabled.  Bigger bottom line, CSD logging is screwed up big time. 

To wrap it up let’s look at this hostscan.log file and see what sort of information it has in it.

Anti Virus
Sun Jan 24 14:10:53 2010
- ->endpoint.av["WmiAV"].description = "McAfee unknown product";
Notes: This is probably why my DAPs for Anti Virus don’t work.  It evidently cant determine what version of McAfee I’m using.  Ironically it cant even determine I’m using McAfee as well…..

Computer Name
Sun Jan 24 14:10:53 2010
- ->endpoint.device.hostname = "<system name>";
Notes: This returned correctly

System MAC addresses
Sun Jan 24 14:10:53 2010
- ->endpoint.device.MAC["<NIC MAC>"] = "true";
Sun Jan 24 14:10:53 2010
- ->endpoint.device.MAC["<NIC MAC>"] = "true";
Notes: These returned correctly

Firewall software
Sun Jan 24 14:10:53 2010
- ->endpoint.fw["MSWindowsFW"] = {};
Sun Jan 24 14:10:53 2010
- ->endpoint.fw["MSWindowsFW"].description = "Microsoft Windows Firewall";
Sun Jan 24 14:10:53 2010
- ->endpoint.fw["MSWindowsFW"].enabled = "failed";
Sun Jan 24 14:10:53 2010
- ->endpoint.fw["MSWindowsFW"].exists = "false";
Notes: I have my firewall turned off and the windows service disabled.  It looks like it can figure that out

And the list goes on.  It also returned my OS version, SP level, all of my installed hot fixes, and a list of open ports.  Bottom line is there some good information in this log that can help you troubleshoot why your DAPs aren’t working.  Its just too bad that these logs aren’t laid out in a more logical sense.  If I hadn’t played around with CSD for hours on end I would have never known that there was an actual host scan log file.  Moreover I wouldn’t have known cache cleaner had to be on to get it…..