CSD

You are currently browsing articles tagged CSD.

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…
image

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.

Tags: ,

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.
image

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.

image

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

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.
image 

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.

image

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.
image 

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. 

image

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.image

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.

image

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

image

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

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.  image

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.

image

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.

Tags: ,

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. 
image

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. 
image

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.
image

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. 
image

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. 
image

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.

imageimage

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.

imageimage

Subsequences are just new flows.  The image below shows a subsequence, I think it’s fairly self-explanatory. 
imagePretty 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 DataCiscoCisco 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.

image 

OS Check – All only newer versions of windows
image 

Registry Check – Check the registry for HKLMSOFTWARE|McAfee
image 

File Check – Check for C:Program FilesMcAfeeManaged VirusScanVScanMcShield.exe
image

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.

image

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

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.

Tags: ,

« Older entries