Ironport WSA blocked surrogate

[Spaniard141]

When a user fails to authenticate to the proxy after 3 failed attemps (I think) the IP address of the PC automatically get blocked for a period of time. For some time now I have been looking for a way to see a list of surrogates in the failed authentication/blocked state and possibly be able to manually unblock it but I haven't been very successful.

I see this being very useful if we are troubleshooting an issue where a user can't access the internet. We've found that changing the user's IP address clears the issue and the user can then access the internet. This is because the new IP is not blocked. If we don't change the IP, we would have to wait 30-60 minutes before that IP is released and can be used again.

Does anyone know of a way to do this from the CLI on the Ironport WSA?

Thanks  

[kushsriva]

Hi,

You can use the "Guest Access" feature of the WSA to provide Internet Access to users who fail authentication. Please go to the user guide and check the section "Allowing Guest Access to Users Who Fail Authentication" in the chapter Identities for more information.

http://www.cisco.com/c/en/us/support/security/web-security-appliance/products-user-guide-list.html

Regards,

Kush

[cgm]

I don't even see a way to check surrogate status for authenticated users...

[Spaniard141]

cgm, see below for the answer I received from Cisco TAC on this issue. I hope you find it helpful:

There is not really a ‘blocked surrogate’ – there might be a misunderstanding of the underlying operation so let me clarify.

If a user is authenticated under an Identity Policy that uses surrogates, the WSA will cache for the surrogate timeout period the username along with the user surrogate mapping. When the timeout expires the surrogate is removed from the auth cache, and the user will be required to authenticate again before matching on the same Identity Policy.

The ‘block’ action results from the Access Policy the traffic matches on. So if a user does not authenticate or their surrogate is expired, they will then be blocked if they do not reauthenticate and fall through to a more restrictive Access Policy.

So with this in mind, we can only view the currently authenticated users in the auth cache – only an auth cache containing active surrogates is actually stored. The block action results from the policy they match on.

So the answer to your question has two parts that are ways to tell if a user is affected by an issue where their surrogate has expired, they have not reauthenticated, and/or are being blocked due to matching on the wrong policy – to monitor the current list of surrogates in the auth cache, and to monitor the policies users are matching on.

• To monitor the auth cache, from the CLI run this command -
  • CLI > authcache
  • The subcommands are the various tools for working with the authcache

WSA-CLI > authcache

Choose the operation you want to perform:

- FLUSHALL - Flush all entries from auth cache

- FLUSHUSER - Flush specific user entry from auth cache

- LIST - List all entries from auth cache

- SEARCH - Search all entries from auth cache

[]>

• To monitor the matching policies for a user, from the CLI run this command -
  • CLI > grep
  • Select the appropriate access log
  • Search on the user’s IP address
    • (optional) Answer ‘Yes’ to tail, when prompted, to tail the live traffic for this IP.
  • The log entries will show the matching policies as illustrated in the example here:

1278096903.150 97 172.16.0.101 TCP_MISS/200 8187 GET http://my.site.com/ -

DIRECT/my.site.com text/plain

DEFAULT_CASE_11-AccessOrDecryptionPolicy-Identity-OutboundMalwareScanningPolicy-DataSecu

rityPolicy-ExternalDLPPolicy-RoutingPolicy

<IW_comp,6.9,-,"-",-,-,-,-,"-",-,-,-,"-",-,-,"-","-",-,-,IW_comp,-,"-","-","Unknown","Un

known","-","-",198.34,0,-,[Local],"-","-"> -

You could also please add some extra fields to the Access Logs to allow for monitoring of certain auth related parameters, The user agent, auth method, auth group and local time will be prepended to the default log line.

1. Go to the GUI > System Administration > Log Subscriptions
2. In the Log Name column, click the name of your access logs
3. In the Custom Fields field, paste the string below
4. Submit and Commit

Custom Fields String:

[ Request Details: User Agent = %u, AD Group Memberships = ( %m ) %g, %L ]

Please explore the commands and configuration option suggested above.

[cgm]

Thanks!

But I'm not confortable with this (yet?)

The authcache only lists users, not the surrogate data (IP address in our case).

And in your problem, IF this was a user issue, changing IP address would not solve it, would it ? I have more to learn...

From what I see (and you describe), after x attempts, the IP is related to a blocking state. As this is not an authenticated user, I would expect it not to be in authcache.

I'll keep digging.

-Carlos

[Spaniard141]

I fully understand. That wasn't the answer I was looking for either but lack of time and better understanding of the Ironport appliance has kept me from further pursuing.

We do use IP address surrogates with single sign on so the credentials of the user currently logged on are passed to the Ironport and proper policies applied based on the user. Since the block takes place on the surrogate and we are using IP's intead of cookies, that is why changing IPs allows us to bypass the problem right away although it is not optimal and would still prefer to be able to remove the block manually from the Ironport instead.

If you come up with a better solution, I would be interested in knowing more about it if you don't mind sharing the knowledge.

Thanks 

****UPDATE 9/8/14*******

Carlos I looked into this once again and did some testing and this is what I came up with:

-Log into a PC with user with no Internet Access (TestUser)

-Test Internet Connectivity (Fails as expected)

-Log out and Log in with an account with Internet access (User1)

- Test Internet Connectivity and it fails (also expected based on observed previous behavior)

- SSH into Ironport and  and type "authcache" and then "flushuser", when prompted type "testuser" (replace with whatever your user is)

-On PC with User1 logged in try to connect to Internet again (successful this time)

Seems to me like when the 1st user logs in, the Ironport keeps track on the surrogate IP for that user. When user 2 logs in, the surrogate is still pointed to the initial user (at least for a period of time). If we clear the user from the authcache, the Ironport forces an authentication the next time internet access is requested from that IP.

It is still not ideal but it is a work around. I wish there was a way to clear the IP and not the user as that user might be logged into other machines.

I hope you find this useful.... I'm still looking for documentation that confirms some of these finding.

[cgm]

Raul,

if I do find out, I will tell you for sure. But I would not keep my breath for it :)

My interest in this is ephemeral, as I'm teaching a course covering the WSA, but I may get in touch with someone who knows :)

-Carlos