Cisco CSA (v5.1) Rootkit Detected module triggers and locks down systems; Now what?

Hello;

We are currently deploying Cisco CSA v5.1 on a Windows 2K3 AD multi-domain environment.  The target platforms are mostly Dell PoerEdge, Opti-Plex, and Latitude clients.  We have initially cloned the supplied "Desktops-All" and "Desktops-Remote" groups to deploy.  Included is a "Rootkit Detected" module and rule that is now apparently triggering on several machines with new builds.  Once a host is designated with a System State of "Rootkit Detected". the CSA agent on that machine locks down most network traffic (ports 80, 53, 135, 137, 139, etc.).  Some of these machines are new builds on totally different network segments.  We have run two separate Rootkit detection utilities (McAfee, Symantec) on these machines with clean results.  How do I determine which specific application is triggering the Rootkit detection module, and if that application is a legitimate utility (which we suspect), how do I create the correct exemption in the Cisco Management Center so that the offending utility no longer triggers the Rootkit Detection module and these machines are no longer locked down?   I hope to be able to resolve this before my users saunter into work tomorrow with their Latte'.  Any help would be greatly appreciated.  Thanks.

Jeff
jbaincAsked:
Who is Participating?
 
billwhartonConnect With a Mentor Commented:
To go backwards, there are a limited number of CSA forums out there and I was surprised to see a CSA-related question here. You'll have to create exceptions for every file you find legitimate but make sure you're sure about its legitimacy - trusted vendor, etc. As for the module <unknown>, you'll have to create a rule using the wizard for that. Next time it reoccurs, you can simply look at the event for the PSTRING1, PSTRING2 values and add these to the original rule you created. You shouldn't create more than 1-2 rootkit exception events. I've seen engineers create an exception for every event they see and this becomes a big mess very soon.

To only use it for monitor and report, I stated the procedure in my previous post. Simply find the rootkit module and configure it as 'test mode'. Test mode is available for hosts as a whole as well as particular rule modules.

I hang out here sometimes but not very often so next time you're unable to get expert help here, feel free to email me
0
 
TolomirAdministratorCommented:
no logs on the client available?
0
 
jbaincAuthor Commented:
Unfortunately, the clients are geogrphically distant.  I do have the logs from the MC.  The MC does tell me that a rootkit has been detected on a client, but not what file(s) has triggered the alarm.  I can not seem to figure out how to pull that specific information from the MC.  I would have thought this should have had some sort of large, flashing red balloon.  As a client powers on, they can initially access http addresses.  Very shortly (less than 5 minutes), the client machine can no longer access http.  I was wondering whether the CSA Network Shim could be the root cause of this.  Thanks for your time on this.   Please let me know if I can supply more detail.

Jeff
0
Evaluating UTMs? Here's what you need to know!

Evaluating a UTM appliance and vendor can prove to be an overwhelming exercise.  How can you make sure that you're getting the security that your organization needs without breaking the bank? Check out our UTM Buyer's Guide for more information on what you should be looking for!

 
billwhartonCommented:
1) You can find out which applications are triggering the rootkit module by following these steps:
a) find out which rules are contained in the rootkit module. I believe there's only one
b) click on that rule and choose 'find related events'. That'll show you all events that the rule triggered
c) within the log entry you see, you'll see which application triggered it. Quite often, it's a symantec file itself called symevent.sys which is possible since you're running this. If it's this file, you can safely create an exception

2) The rootkit module by default is experimental and isn't supposed to block all in & out network access. The module and only the RM should be configured for 'test mode'. This would prevent it from taking any actions though it'll continue detecting root kits and you'll see the relevant logs in the MC. I don't know how many Cisco SE's themselves trust the rootkit module and in my experience, I have learn not to. It can prove very dangerous and can block all your workstations from accessing the network one fine day. Risky proposition to keep it turned on

CSA is a monster and unlike network devices, undoing configurations isn't easy and can be time-consuming. You're better off knowing the product very well before implementing it in a network. Any installation that isn't perfect can cause problems in the future. Not to scare you but I'm talking through years of CSA experience..

I'm heading out but will have my Blackberry with me; you can email me at <// email removed - see member profile //Tolomir EE ZA > if you like

Good luck with your users tomorrow ;)
0
 
jbaincAuthor Commented:
Bill;

Thanks very much for your help.  We had been running fine under v4.5, but moved away from CSA as CiscoWorks (with its Win 2000 host) became too cumbersome.  CSA v5.1 was a much needed upgrade, but brought with it this new Rootkit feature (which apparently installed active, by default).

I've discovered that the CSA v5.1 agent RootKit module was being triggered by three separate files:  apoint.exe (Dell driver for laptop mouse-like devices); quickset.exe (another Dell driver); and vsdatant.sys (a Cisco VPN Client driver, I believe...go figure).   This log entry was:  
Kernel functionality has been modified by the module C:\WINDOWS\system32\vsdatant.sys. The module 'C:\WINDOWS\system32\vsdatant.sys' is used by entries in the System syscall table. The specified action was taken to set detected rootkit as Untrusted. Rule 46
 
One other entry was tripping the Rootkit trigger:
Kernel functionality has been modified by the module <unknown>. Code referenced by a system call table entry has been modified. The specified action was taken to set detected rootkit as Untrusted. Rule 46
 
I am also seeing this entry:
 An unauthorized Network Component, 'BogusDriver' was detected registering with the system. The operation was allowed.  Rule 53
 
Since most of these alerts are over legitimate files, I would like to restrict the Rootkit module to Monitor and Report, but not initially trigger and lock down a system.  What is the best way to approach this?  
Thanks again for the invaluable help.

Jeff

Do you recommend any other CSA user forums?
0
 
TolomirAdministratorCommented:
@billwharton: Regarding your email address, instead of posting it here, you should just reference to your member's profile, where you posted it already. That is not crawled by search engines.

My previous post of cause still applies.

Tolomir
0
 
billwhartonCommented:
got it
thx
0
 
jbaincAuthor Commented:
Bill;
Your advice was right on target.  We've been able to isolate the offending (and mostly legitimate) files that were tripping the Rootkit Detected' module.  We have also placed the 'Rootkit Module' in 'Test' mode for the indeterminate future.  Thanks very much for your help.  I'm sure we'll have more posts here since CSA is such a beast at times.

Thanks, again.

Jeff
0
All Courses

From novice to tech pro — start learning today.