DAP LUA to detect if endpoint / host scan failed

[dbgreekas]

It seems that if the user denies the Host scan during a UAC check or kills it when loading the aaa.endpoint tables do not exist and this causes very odd results in several DAP endpoint rules I have..

I have been trying to create a DAP rule to detect if host scan failed but non of my nul checks seem to work.

Any ideas on a clean way to do this?

[Jay Young]

Dbgreekas,

When performing a DAP check using LUA if the value that you are checking against is not present then the logic comes back as false.

i.e. if you were checking that aaa.endpoints.location  is equal to "home computers" and the user prevented Host scan from running, then the result will be false and you will not match that DAP policy.

As a result you may want to structure your checking in this fashion.

rule 1 - check the policy to see it was a "work computer"

     allow to connect via anyconnect

rule 2 - check the policy to see it was a "home computer"

     allow to connect via clientless

default rule

     terminate with a message saying make sure host scan runs.

Hope that helps.

-Jay

[dbgreekas]

Hi Jay,

Relying on the default terminate rule is not a scalable solution, and to me represents a significant bug.

Without a way to mate a Terminate based on the a missing value, you are forced to lump ALL allow logic into a single DAP rule, and use a single default terminate rule for ALL connections.

This does not allow for ANY USER level error feedback as to WAY the user has failed to authenticate and thus leaves all resolution to the ASA admin who as access to the logs.

When assuming that the endpoint scan HAS RUN it is possible to use custom terminate rules for each possible failure condition which each have a message defined by the admin so the use knows WHY they failed.

The only way I see to do something like this now would be to duplicate ALL of the allow logic in to a single allow rule AND have the custom terminate rules.. Where as before I thought I could rely on the users connection being terminated before reaching the simple allow aaa rule I would then need to make my allow rule a huge mess of aaa, and endpoint values just in case the endpoint scan fails.

[dbgreekas]

Another way to put it is this, how can I achieve all of the following objectives.

- Deploy to unmanaged systems (IE systems I have no control over admin rights)

- Only Allow users who have LDAP Accounts

- Only Allow computers that have a one of 4 approved vendor anti-virus products

- Only Allow computers that have the antivirus enabled

- Only Allow computers that have definitions less than 4 days old.

- And if the user is denied access inform them WHY

and remember that a hostile user may have terminated host scan to try and bypass security.

I currently have my DAP structured like this, and it works if host scan has not been aborted:

Rule 1 Check that user has an approved AV product installed

- Terminate rule

- Tests that all of the approved products are NOT installed

- Informs the user they must have an approved product if it matches

Rule 2 Check that the AV product active scan is enabled

- Terminate rule

- Tests that ALL of the a approved products are not enabled on the users system

- Informs the user that they must have active scan enabled

Rule 3 Checks that definitions are up to date

-Terminate rule

- Looks for ANY of the approve products having definitions over x days old

- Informs the user they must perform an update

Rule 4 User is a member of an LDAP group

- Allow rule

- Checks if the user is a member of a LDAP group and allows them

default

-Terminate

Due to the apparent FLAW in the way missing values are evaluated if an end user aborts host scan they could skip ALL of the terminate rules and make it to the allow rule. I could load the allow rule with the reverse of the terminate logic as well but then I end up with a VERY VERY complex allow rule and no user feedback as to why login has failed.

[Jay Young]

dbgreekas,

In the rule 4 make sure that you check the LDAP group AND that

endpoint.policy.location is equal to the pre-login policy.

If the nefarious user prevents Host Scan from running DAP will never receive 
that policy info and will cause a failure of the rule. 
Thus the user will fall then to the default rule and get denied.

-Jay

[dbgreekas]

That does solved the security access issue, well reqiring ANY of the endpoint values in the Allow rule will.

If endpoint fails for other reasons (sometimes fails when running from a browser) I still can't really give the user a good error, unless I make it the default and then make custom terminate errors for ALL other cases.

It sort of works around the problem, but not as cleanly if I could simply match a terminate rule on the absens of endpoint values.

[dbgreekas]

By adding a location check to ALL of my other rules I was able to ensure that failure and erorr messages are more graceful and informative to the end user.

At the same time it does over complicate the simple goal of checking if endpoint scan ran, since I must test that it ran on every rule and then on the rule I don't test for it display an error that suggests it hasn't run.

[Jay Young]

dbgreekas,

Couldn't you simply do a rule like as the very first rule

if

     (!(policy.location == loc1 or policy.location == loc2 or policy.location == loc3))

then

     terminate with message saying that Host Scan failed to run.

This way if the information is NOT there then the rule will come back true and terminate and if the information is there and correct the rule will come back false.

This way you can remove the checking for the policy in the anti-virus, etc checks as it has already been checked at the begining.

-Jay

[dbgreekas]

You would think so but any DAP rule that tests a value that DOES NOT EXIST returns false. It is imposible to test policy.location if the endpoint scan has not run as policy.location does not exist.

[Jay Young]

dbgreekas,

The LUA is very powerful as it allows you craft a custom query string.  You can test for attributes that don't exist.  Do the following for your first rule.

1)  Remove all entries from the top two boxes in the rule definition page.

2)  Expand out the Advanced box

3)  Select the AND button

4)  Paste the followin into the box

(not (EVAL(endpoint.policy.Nonexistantattribute,"EQ","Default","string")))

With this you can see that I made up an attribute that doesn't exist even if Host Scan is working the EVAL of the check comes back false and that is inverted by the 'not' statement.  This is what I was talking about in my previous post.

-Jay

[dbgreekas]

Hi Jay,

I can't make a global rule that evaluates like that since some of my connections do not support or need host scan..

I tried creating a test terminate rule where I put an AAA match on a single user AND the LUA evaluation you just posted.

The DAP record ALWAYS matched even when the attribute existed, so something is still wrong there.