Endpoint Security For Atm

MS-RPC ClientName: ubercifs.THULIN.LOCAL

10 threads started. This is the number of threads for cava.  Each thread represents a file that can actively be scanned.  Cava will process up to 10 files at once to distribute across your available cava servers.  Any additional files will be put into a holding queue until cava can get to them.  This limit here is so that we don’t overwhelm the av software running on each cava server.  This limit is adjustable by the support lab if it is determined that this will solve a performance issue. 1 Checker IP Address(es): This line tells you have many cava servers you have defined in your viruschecker.conf file.  In this example, I only have 1 server defined, but you should be running at least 2 servers at a minimum. 192.168.1.101                                  ONLINE at Thu May 26 19:41:13 2011 (GMT-00:00) This line tells you the IP address of your cava server as well as the status and the last time we checked it.  If that line says anything other than ONLINE, there is a problem with theconnection from the windows server to the celerra and that server will not be used for scanning.  More information on possible errors will be in a later post. MS-RPC over SMB, CAVA version: 4.8.5.0, ntStatus: SUCCESS This has 3 pieces of useful information.  The first is the connection method we use to send commands to the cava agent.  In this case, we are using the MSRPC protocol.  Older clients may use the ONCRPC protocol, but this is not supported on 64 bit systems.  The next part tells you the version of cava you are running.  As of writing this, i am using the latest version (VNX Event Enabler 4.8.5).  Like above where we reported the connection from windows back to the celerra, the ntStatus section reports the status of our initial connection to the windows server. AV Engine: Symantec AV This tells you the AV software we detected to use for CAVA.  This can be helpful if you have more than AV engine installed on the client.  In my case, I am using Symantec Endpoint. Last timesignature updated: Tue May 17 05:55:23 2011 (GMT-00:00) This is the last time you updated your AV definitions 1 File Mask(s): The number of file masks you have set to scan for.  In this case, it’s just 1 mask. *.* This is the file masks you have in place.  Any files that match the entries here will be processed for scanning.  In this case i have *.* (everything with a . in it), but you can cut down a lot of traffic if your only scanning for certain file types. 5 Excluded File(s): This is how many file exclusion filters you have in place.  In this case i have 5. ~$* >>>>>>>> *.PST *.TXT *.TMP These are the file filters i have in place.  There are a number of files that AV software just can’t scan (like database files).  I also have in place ~$* and >>>>>>>> to ignore Microsoft Office temporary files as they can become locked temporarily while being scanned and cause a loss of data in the office application. Share \\UBERCIFS\CHECK$. This is the beginning of the UNC path that will be sentfor file scan requests.  This is determined from the CIFSserver line in the viruschecker.conf and will change depending of if you defined it with the ip, netbios name, or FQDN.  The check$ folder is a hidden folder created just for CAVA.  The only account that can access this is the one granted the virus checking privilege. RPC request timeout=25000 milliseconds. This is the amount of time we will wait for a file to be scanned before trying again. RPC retry timeout=5000 milliseconds. This is the amount of time we wait for an acknowledgement of each RPC command. High water mark=200. I spoke before about how we process 10 files at a time, and that addition files are put into a queue.  The high watermark is when we allocate additional resources to cava to process through AV files faster.  Hitting this high limit can cause a performance impact to your cifs servers, so try not to let the queue get this bad.  In my case, i have set the limit to the default of 200. Low water mark=50. Justlike the high watermark, this is a lower limit that starts to indicate that files are queuing up too fast.  This won’t cause a performance problem, but is an indicator of a possible problem to come. Scan all virus checkers every 10 seconds. Every 10 seconds we will check the status of each cava server to make sure it’s still online and ready to take requests. When all virus checkers are offline: Shutdown Virus Checking. This is the action we will take when all the cava servers are not marked as ONLINE.  This will shutdown cava so that files don’t continue to be queued and hit a high watermark.  The other options is to do nothing (a setting of ‘no’) or to shutdown cifs (what i like to call paranoia mode). Scan on read disable. This means that scan on read is not enabled and that we are only processing scan on write.  If scan on read was enabled, the cutoff date and time would be listed in this place. Panic handler registered for 65 chunks. This is mostly just for debug information andhow many internal failures cava would survive before causing a panic.  Every process on the celerra has a panic handler and this information is of no use to basic cava troubleshooting. MS-RPC User: UBERCIFS$ Earlier i talked about how we use the MS-RPC protocol to connect to the cava agent servers.  This is the username we will use for the SMB connection.  In this case, we are using the compname of the cifs server for cava. MS-RPC ClientName: ubercifs.THULIN.LOCAL This is the FQDN of the cifs server we are using for cava which is used as part of the MS-RPC process.